人類的歷史，即分久必合，合久必分。

2017 年，比特幣因行情瘋長(zhǎng)火熱一時(shí)。2018 年伊始，其使用的底層技術(shù)區(qū)塊鏈又迎來(lái)狂歡：從國(guó)內(nèi)創(chuàng)投人到硅谷投資者，從 BAT 到互聯(lián)網(wǎng)企業(yè)眾生，都紛紛加入這場(chǎng)技術(shù)的斗艷中。

在去中心化技術(shù)給這個(gè)時(shí)代帶來(lái)新革命的同時(shí)，區(qū)塊鏈也在更多的行業(yè)施展拳腳，利用去中心化計(jì)算機(jī)系統(tǒng)來(lái)創(chuàng)建安全、可驗(yàn)證和永久的交易記錄，從而解決不透明或非可信問(wèn)題。從本質(zhì)上講，它創(chuàng)建了一個(gè)安全的、分布式的信息和交易記錄數(shù)據(jù)庫(kù)。

對(duì)于交易不透明等問(wèn)題，廣告行業(yè)存在的欺詐流量、隱私泄露等現(xiàn)象正在倒逼區(qū)塊鏈技術(shù)發(fā)展，以借其構(gòu)造新的廣告環(huán)境。

例如，區(qū)塊鏈建構(gòu)的個(gè)人數(shù)據(jù)檔案、交易認(rèn)證、透明性標(biāo)準(zhǔn)等技術(shù)實(shí)現(xiàn)方案，在廣告「按需使用時(shí)代」提供了更好的契合點(diǎn)。FreeWheel 作為媒體廣告管理、投放及預(yù)測(cè)方，同樣也需要應(yīng)對(duì)相應(yīng)痛點(diǎn)。因而在與第三方評(píng)測(cè)機(jī)構(gòu)和主流的 DSP 集成時(shí)，其嘗試搭建了一套聯(lián)盟鏈系統(tǒng)以達(dá)成賬本的一致性。

本文中，我們將集中講解 FreeWheel 區(qū)塊鏈應(yīng)用的緣起、架構(gòu)及運(yùn)作模式。

撥開(kāi)云霧見(jiàn)天日：為何使用區(qū)塊鏈技術(shù)解決問(wèn)題？

區(qū)塊鏈?zhǔn)羌用茇泿诺暮诵募夹g(shù)基礎(chǔ)，具有不可篡改、透明等特性，而在廣告行業(yè)內(nèi)涉及多方集成，容易產(chǎn)生數(shù)據(jù)不一致等問(wèn)題，所以 FreeWheel 嘗試引入?yún)^(qū)塊鏈技術(shù)到業(yè)務(wù)場(chǎng)景中。但需要澄清的是，F(xiàn)reeWheel 做區(qū)塊鏈并不是想做一個(gè)新的代幣系統(tǒng)，而是希望用區(qū)塊鏈解決當(dāng)前廣告行業(yè)當(dāng)中常見(jiàn)的痛點(diǎn)。

在廣告行業(yè)中，任何參與者都會(huì)頻繁地與第三方進(jìn)行集成。比如，在評(píng)測(cè)投向效果場(chǎng)景中，會(huì)和 Nielsen、Comscore 等市場(chǎng)調(diào)研公司集成，以評(píng)價(jià)廣告的投放效果。另外，通過(guò)實(shí)時(shí)競(jìng)價(jià)（OpenRTB）協(xié)議，SSP 也需要與 DSP 集成，幫助媒體公司賣掉剩余流量，最大程度上實(shí)現(xiàn)流量變現(xiàn)。

集成過(guò)程中，對(duì)于廣告有效投放次數(shù)和調(diào)用服務(wù)收費(fèi)的評(píng)定，會(huì)由于各自記賬模式和方法的不同而導(dǎo)致雙方報(bào)價(jià)完全不匹配。此外，按天或按月出賬單具有較高的延時(shí)性，較難驗(yàn)證或達(dá)成一致的結(jié)果。因此，F(xiàn)reeWheel 引入?yún)^(qū)塊鏈技術(shù)的最主要目的，是以期讓整個(gè)交易流程透明化，使整個(gè)交易記錄被所有參與者共享——當(dāng)整個(gè)交易數(shù)據(jù)記載在區(qū)塊鏈里，各方參與者擁有所有賬本記錄，結(jié)算即變得簡(jiǎn)單。

在采用區(qū)塊鏈技術(shù)解決方案前，F(xiàn)reeWheel 在技術(shù)選型進(jìn)行了諸多嘗試。已有的分布式數(shù)據(jù)庫(kù)無(wú)法規(guī)避惡意篡改，也缺乏有效的共識(shí)算法和智能合約機(jī)制。而區(qū)塊鏈本身的不可篡改和消息協(xié)同這類天然特性，以及 Fabric 或以太坊建立的終極抽象的基礎(chǔ)層，使得區(qū)塊鏈應(yīng)用能在其方案中一施拳腳。

FreeWheel 主任工程師王敏解釋說(shuō)，目前，公司對(duì)區(qū)塊鏈的主要需求是針對(duì)多方集成賬本不一致的問(wèn)題，期望增強(qiáng)交易的透明性以達(dá)到賬本的最終一致性，所以基于對(duì)共識(shí)機(jī)制和編程語(yǔ)言支持等考慮，F(xiàn)reeWheel 目前的選擇是以 Fabric 作為基礎(chǔ)，搭建廣告行業(yè)聯(lián)盟鏈。

FreeWheel 區(qū)塊鏈應(yīng)用架構(gòu)層級(jí)及原理

正因?yàn)閺V告商業(yè)建立的聯(lián)盟鏈特性，所有參與者都是已知的并且驗(yàn)證過(guò)，因此所有交易參與者需要先從 Root CA 處獲得公鑰和私鑰，每個(gè)參與者也同樣會(huì)負(fù)責(zé)創(chuàng)建交易——生成帳單系統(tǒng)查詢?cè)搮^(qū)塊鏈并對(duì)其定價(jià)。創(chuàng)建的區(qū)塊鏈交易包含上層發(fā)送的原始請(qǐng)求信息、所有 DSP 的返回、參與者的簽名。

FreeWheel 區(qū)塊鏈應(yīng)用整體架構(gòu)如下：

該區(qū)塊鏈架構(gòu)中包含客戶端（Client）和服務(wù)端（Peer）。

區(qū)塊鏈的客戶端（Client）在收到上層次所有應(yīng)用和發(fā)出的調(diào)用后，負(fù)責(zé)創(chuàng)建一個(gè)包含原始廣告請(qǐng)求的交易。服務(wù)端（Peer）收到區(qū)塊鏈創(chuàng)建的交易后，會(huì)通過(guò)驗(yàn)證簽名來(lái)確保交易的合法性。如果合法，服務(wù)端就在存儲(chǔ)賬本里新增 Block，同時(shí) State DB 會(huì)統(tǒng)計(jì)不同參與者之間調(diào)用的次數(shù)，生成 Billing Report。

整體架構(gòu)中的上半部分則是廣告行業(yè)內(nèi)已有的系統(tǒng)，主要包括 OpenRTB 集成和 Mesurement 集成：

OpenRTB 集成：在收到多家 DSP 返回結(jié)果之后，SSP 會(huì)根據(jù)當(dāng)前所有候選廣告選出最終投放廣告，計(jì)算第二高價(jià)返回給 DSP 并播放該廣告。同時(shí) SSP 也會(huì)將完整的、包含多方簽名的交易記錄通過(guò) RPC 的調(diào)用方式（無(wú)論是 SSP、DSP，還是 Nielsen，每個(gè)參與者都有這樣一套系統(tǒng)）記錄到相應(yīng)的賬本中 。
Mesurement 集成：評(píng)測(cè)機(jī)構(gòu)在收到包含調(diào)用者簽名的請(qǐng)求并附加自己的簽名后，將該條包含多方簽名的交易記錄到相應(yīng)的賬本中 。
整體架構(gòu)中的下半部分則需要每個(gè)參與者維護(hù)：

Intermediate Certificate Authority：需要從 Root CA 注冊(cè)、更新相應(yīng)的證書(shū)，并且驗(yàn)證交易里簽名的合法性。
客戶端層：
Blockchain Client：對(duì)接上層服務(wù)，打包原始交易記錄并加上自身的簽名，創(chuàng)建區(qū)塊鏈的交易發(fā)送給相應(yīng)的服務(wù)（Peer）。
Billing System：查詢系統(tǒng)，根據(jù)區(qū)塊鏈記錄產(chǎn)生賬單。
服務(wù)層：部署智能合約和產(chǎn)生新 Block 到區(qū)塊鏈。
數(shù)據(jù)層（包含兩個(gè)部分，StateDB 和賬本）：
State DB： State DB 統(tǒng)計(jì)了多方相互調(diào)用的總次數(shù)， 方便快速查詢。
賬本：包含了所有的交易記錄，在參與者中都是相同的備份，具有可追溯、無(wú)法篡改等特性。
另外，在 OpenRTB 集成、Mesurement 集成和 Participants' Blockchain 部分外，整體架構(gòu)中還包括一個(gè)聯(lián)盟鏈管理平臺(tái)。管理平臺(tái)由各中心委員會(huì)負(fù)責(zé)運(yùn)維：

會(huì)員管理系統(tǒng)和認(rèn)證中心：當(dāng)有新公司、組織加入該平臺(tái)時(shí)負(fù)責(zé)發(fā)放證書(shū)。
賬本管理：即 Channel，一個(gè)賬本對(duì)應(yīng)一個(gè) Channel。Public Channel 由中心委員創(chuàng)建，被所有參與者共享，每個(gè)參與者可以創(chuàng)建 Private Channel 并授權(quán)給部分參與者，但其不允許別的參與者訪問(wèn)以避免信息泄露。
共識(shí)管理：即 Order Service。Fabric 可以選擇不同的共識(shí)機(jī)制：Solo、KafKa、SBFT（尚在開(kāi)發(fā)中）。不同的賬本可以選擇不同的 Order Service，同一個(gè) Order Service 也可加入到多個(gè) Channel。Order Service 由中心委員會(huì)運(yùn)維。
智能合約管理：即 Chaincode。智能合約是多方對(duì)特定交易類型達(dá)成一致的業(yè)務(wù)邏輯，對(duì)于相應(yīng)參與者來(lái)說(shuō)，Chaincode 的實(shí)現(xiàn)都是公開(kāi)的，且能部署在參與者的 Endorse 節(jié)點(diǎn)上。
FreeWheel 區(qū)塊鏈應(yīng)用系統(tǒng)運(yùn)作模式

在評(píng)測(cè)集成的場(chǎng)景下，比如系統(tǒng) A 調(diào)用評(píng)測(cè)機(jī)構(gòu) B 服務(wù)時(shí)，A 會(huì)把投放的廣告、觀看廣告的終端用戶和當(dāng)前視頻內(nèi)容等信息及其對(duì)交易的簽名發(fā)送至 B，B 在收到系統(tǒng) A 請(qǐng)求之后，其所屬的客戶端會(huì)包裝原始的請(qǐng)求信息并加上 B 的簽名發(fā)送給區(qū)塊鏈：

B 將包含雙方簽名的交易發(fā)給 A 和 B 的 Endorser ，雙方節(jié)點(diǎn)各自驗(yàn)證并確定交易的真實(shí)性，接著調(diào)用相同的 Chaincode 產(chǎn)生一致的收費(fèi)結(jié)果；
Endorser 節(jié)點(diǎn)把 Chaincode 執(zhí)行后的結(jié)果、節(jié)點(diǎn)簽名返回結(jié)果給 Client；
Client 收到雙方 Endorser 節(jié)點(diǎn)的返回，綜合執(zhí)行結(jié)果，背書(shū)節(jié)點(diǎn)的簽名，原始交易記錄的信息發(fā)送給 Order Service；
Order Service 將背書(shū)后的結(jié)果廣播給所有節(jié)點(diǎn)（當(dāng)有多個(gè)節(jié)點(diǎn)的時(shí)候，參與者可指定一個(gè)節(jié)點(diǎn)為主節(jié)點(diǎn)，Order Service 將新交易廣播至主節(jié)點(diǎn)，再由其廣播到內(nèi)部剩余節(jié)點(diǎn)，從而提高廣播的效率）。
Order Service 會(huì)按時(shí)間戳或 Client 發(fā)送的先后順序?qū)λ械慕灰走M(jìn)行排序。雖然往帳本里記時(shí)不會(huì)調(diào)用智能合約，但會(huì)有一些額外的檢查（如查看交易 ID 是否重復(fù)等）。因?yàn)楹灻?，所?Client 不能偷改交易 ID。
所有節(jié)點(diǎn)把新交易更新到自己一方的賬本中。
這里值得一提的是，F(xiàn)arbic 記賬流程與以太坊有很大的不同。

以太坊包含兩種賬戶：外部賬戶和合約賬戶每筆交易都需要指定最大 gas 的值，以太坊虛擬機(jī)會(huì)基于 gas 的設(shè)置來(lái)控制智能合約執(zhí)行的數(shù)量，防止惡意攻擊。而 Fabric 聯(lián)盟鏈里所有的客戶端和服務(wù)端都必須已認(rèn)證，所有的交易必須有參與者簽名（交易發(fā)起者的簽名，背書(shū)節(jié)點(diǎn)的簽名等），降低公有鏈的惡意節(jié)點(diǎn)問(wèn)題。

相對(duì)于以太坊共識(shí)機(jī)制 PoW，F(xiàn)abric 共識(shí)機(jī)制可以選擇（目前支持 Solo，Kafka），達(dá)成共識(shí)效率也更高，避免計(jì)算資源的浪費(fèi)。

目前 Fabric 共識(shí)機(jī)制處理得非常簡(jiǎn)化，比較適合廣告行業(yè)聯(lián)盟鏈中的場(chǎng)景——即參與者數(shù)量相對(duì)有限，參與者之間基本可信，并發(fā)高。Fabric 主要采用 Kafka——Order Server 收到 Client 發(fā)的請(qǐng)求之后往 Kafka 集群里「塞」（相當(dāng)一個(gè) Producer 不停地產(chǎn)生記錄），接著按照塞的先后順序排序打包并廣播給 Commit Peer，Commit Peer 收到消息塊則驗(yàn)證里面所有的消息并記賬。

對(duì)于 Kafka，其本身支持向下游發(fā)送完全一樣的數(shù)據(jù)，順序不會(huì)顛倒。當(dāng) Client 端偶遇網(wǎng)絡(luò)不穩(wěn)定而形成的消息堆積或系統(tǒng)宕機(jī)時(shí)，重啟后 Kafka 會(huì)自動(dòng)把缺省的消息再次推送。這是其非常重要的功能。對(duì)于類似的系統(tǒng)宕機(jī)或消息堆積，F(xiàn)reeWheel 搭建的區(qū)塊鏈系統(tǒng)有實(shí)時(shí)監(jiān)控機(jī)制，可實(shí)現(xiàn)暫緩發(fā)送。

另外，如果參與者內(nèi)部有大批節(jié)點(diǎn)連接 Kafka 并需要訓(xùn)練該 Kafka 集群，這樣對(duì) Kafka 性能要求也較高。對(duì)于這種問(wèn)題的解決方案是：每個(gè)參與者選一個(gè)類似于 VIP 或 Leader 節(jié)點(diǎn)，并且只需 該節(jié)點(diǎn)連 Kafka 的 Order Service。 待 Order Service 下發(fā)至 Leader 后，Leader 會(huì)做內(nèi)部的轉(zhuǎn)發(fā)，從而減小 Order Service 的壓力，而參與者內(nèi)部的記賬節(jié)點(diǎn)數(shù)量可自己隨意添加。

如何使用智能合約技術(shù)進(jìn)行區(qū)塊鏈開(kāi)發(fā)？

智能合約屬于多方針對(duì)某交易達(dá)成一致的業(yè)務(wù)處理邏輯，即達(dá)成一致的鏈碼（Chaincode）。如上文所說(shuō)，Chaincode 在參與者之間公開(kāi)，且部署在其 Endorse 節(jié)點(diǎn)上，可自動(dòng)執(zhí)行交易并產(chǎn)生結(jié)果，不需要第三方介入。

相對(duì)于以太坊主要支持 Solidity（類似 JavaScript）、Serpent（類似 Python），F(xiàn)abric 支持用 Golang、Java、Node.js 實(shí)現(xiàn)智能合約，F(xiàn)reeWheel 在開(kāi)發(fā)過(guò)程中主要基于 Golang。要實(shí)現(xiàn)智能合約，只需集成 Fabric 的一個(gè)接口，實(shí)現(xiàn) Init 和 Invoke 兩個(gè)函數(shù)即可，而 Fabric Chaincode 通過(guò) gRPC 與 Peer 節(jié)點(diǎn)交互。Init 函數(shù)只會(huì)在第一次啟動(dòng)和每次升級(jí)的時(shí)候會(huì)被調(diào)用，負(fù)責(zé)初始化的內(nèi)部參數(shù)。

type Chaincode interface {
Init(stub ChaincodeStubInterface) pb.Response
Invoke(stub ChaincodeStubInterface) pb.Response
}
Invoke 函數(shù)會(huì)在每筆交易驗(yàn)證中調(diào)用。例如，驗(yàn)證簽名和收費(fèi)模式的判定都由 Invoke 函數(shù)執(zhí)行，負(fù)責(zé)主要業(yè)務(wù)邏輯的實(shí)現(xiàn)。傳入的參數(shù)主要包含以下部分，可以通過(guò) GetFunctionAndParameters 拿到 Client 發(fā)送的待背書(shū)的原始交易記錄和期望的操作。

對(duì)于簡(jiǎn)單的業(yè)務(wù)場(chǎng)景，或許一個(gè) Invoke 函數(shù)就可以實(shí)現(xiàn)。但針對(duì)復(fù)雜的業(yè)務(wù)場(chǎng)景，則可以通過(guò)多個(gè) Chaincode 之間調(diào)用來(lái)實(shí)現(xiàn)，進(jìn)而模塊化復(fù)雜的智能合約，并且 Chaincode 間的調(diào)用不會(huì)產(chǎn)生非預(yù)期的交易記錄和非預(yù)期的 Block，而是產(chǎn)生一個(gè)綜合的帳本，或若干個(gè)小帳本。

type ChaincodeStub struct {
TxID string
args [][]byte
…
}
//get transactions from parameters
func (stub *ChaincodeStub) GetFunctionAndParameters() (function
string, params []string)
//invoke other chaincode
func (stub *ChaincodeStub) InvokeChaincode(chaincodeName string, args
[][]byte, channel string) pb.Response

FreeWheel 在開(kāi)發(fā)中發(fā)現(xiàn) Golang 的 Chaincode 目前只支持官方標(biāo)準(zhǔn)包，否則無(wú)法正常運(yùn)行在 Endorser 節(jié)點(diǎn)上。這也是其目前在實(shí)際開(kāi)發(fā)中遇到的重要問(wèn)題之一，關(guān)于如何更好地引入第三方包，F(xiàn)reeWheel 目前還沒(méi)有更好的解決方案。

區(qū)塊鏈中的微服務(wù)化和安全

由于廣告行業(yè)往往會(huì)涉及到多方集成、復(fù)雜的業(yè)務(wù)邏輯，為方便部署和運(yùn)維，所以大量采用了微服務(wù)架構(gòu)和容器化等相關(guān)技術(shù)；出于安全性的考慮，F(xiàn)reeWheel 也加入了 CA 認(rèn)證和 OpenSSL。

對(duì)于復(fù)雜的業(yè)務(wù)場(chǎng)景而言，F(xiàn)reeWheel 期望盡力把所有系統(tǒng)功能都模塊化，這樣 Chaincode 間調(diào)用就可以用 gRPC 這類微服務(wù)框架實(shí)現(xiàn)——即基于 gRPC 和 HTTP2 的微服務(wù)框架實(shí)現(xiàn)模塊間和跨客戶的通信。比如，通過(guò)微服務(wù)化將驗(yàn)證結(jié)果集群化，增加背書(shū)節(jié)點(diǎn)的吞吐量，那么通過(guò) Docker 或 Kubernets 管理的話，非常方便進(jìn)行擴(kuò)展和增加節(jié)點(diǎn)數(shù)。同時(shí)在 Order Service 分發(fā)上，微服務(wù)化也可以減小分發(fā)壓力。

同時(shí)，F(xiàn)reeWheel 主要采用 Kubernets 進(jìn)行容器編排，使得所有參與者都能非常方便、快速地安裝客戶端、Peer 和微服務(wù)在私有云或公有云上。

由于聯(lián)盟鏈特性，聯(lián)盟區(qū)塊鏈應(yīng)用還有一環(huán)考驗(yàn)：安全。所以，F(xiàn)reeWheel 主要基于 Fabric 提供了多層 CA 認(rèn)證系統(tǒng)，以保證聯(lián)盟鏈中所有的參與者都是已驗(yàn)證（非驗(yàn)證的交易會(huì)被直接拒絕），并使用 OpenSSL 協(xié)議保證通信的安全性，特別是對(duì)于跨模塊和涉及到 HTTP 交易和服務(wù)的參與者。

區(qū)塊鏈應(yīng)用開(kāi)發(fā)中的其他要點(diǎn)及難點(diǎn)

由于廣告行業(yè)實(shí)時(shí)競(jìng)價(jià)并發(fā)性高、請(qǐng)求量大，區(qū)塊鏈應(yīng)用最明顯的就是延遲方面的性能問(wèn)題。一方面，全部同步需求和節(jié)點(diǎn)數(shù)增加，勢(shì)必會(huì)使性能有所下降；另一方面，不同參與者選擇的不同私有云，在不同地域和不同網(wǎng)絡(luò)環(huán)境下，延遲性怎樣縮減至最小。這些都使該問(wèn)題成為 FreeWheel 接下來(lái)要攻克的難點(diǎn)之一。

目前比特幣或以太坊中的惡意攻擊等很多問(wèn)題已被弱化，也不存在女巫節(jié)點(diǎn)等，那么勢(shì)必會(huì)讓性能提升得更好。但 Fabric 區(qū)塊鏈已經(jīng)進(jìn)入活躍期，在 FreeWheel 的實(shí)驗(yàn)環(huán)境下，針對(duì)兩個(gè)參與者的情況，F(xiàn)abric 的 Throughput 在 350 tps，每條交易的平均延遲時(shí)間在 1 秒左右（從產(chǎn)生交易到記入賬本所花費(fèi)的時(shí)間），其中 Endorser 過(guò)程平均花費(fèi)了 55ms。實(shí)驗(yàn)中，F(xiàn)abric 主要瓶頸在 Commiter Peers 目前不具有擴(kuò)展性 (最高 TPS 在 3K)，并且無(wú)法通過(guò)分布化來(lái)提升記賬性能。同時(shí) FreeWheel 仍然在繼續(xù)多參與者多節(jié)點(diǎn)復(fù)雜網(wǎng)絡(luò)環(huán)境的性能測(cè)試進(jìn)而評(píng)估其有效性等。

未來(lái)，業(yè)務(wù)層多方集成頻繁，F(xiàn)reeWheel 正與合作伙伴共同商談如何合作，中心委員會(huì)如何創(chuàng)建、組成和管理。技術(shù)層，F(xiàn)reeWheel 會(huì)針對(duì)于高并發(fā)、低延遲和眾多參與者參與的廣告場(chǎng)景，進(jìn)一步測(cè)試 Fabric 在不同場(chǎng)景下性能。

采訪嘉賓：

王敏，2013年加入FreeWheel，現(xiàn)任主任工程師，主要負(fù)責(zé)用戶數(shù)據(jù)管理和集成、廣告預(yù)測(cè)、區(qū)塊鏈調(diào)研等核心業(yè)務(wù)。帶領(lǐng)團(tuán)隊(duì)完成了用戶管理平臺(tái)的重構(gòu)，目前主要負(fù)責(zé)競(jìng)價(jià)廣告預(yù)測(cè)平臺(tái)和區(qū)塊鏈應(yīng)用平臺(tái)。