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

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

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

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

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

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

撥開云霧見天日：為何使用區(qū)塊鏈技術(shù)解決問題？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

采訪嘉賓：

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