FreeWheel应用的起源、架构和运营模式讲解

2018年初，比特币所使用的底层技术再次狂欢：从国内风险投资家到硅谷投资者，从BAT到互联网公司，每个人都有加入到这场运动的技术之战中。

去中心化技术给这个时代带来新革命的同时，区块链也在更多行业大展拳脚，利用去中心化计算机系统创建安全、可验证的和永久交易记录，从而解决交易不透明或不透明的问题。信誉问题。本质上，它创建了一个安全的分布式信息和交易记录数据库。

针对广告行业的交易不透明、欺诈流量、隐私泄露等现象，迫使区块链开发技术来创造新的广告环境。

例如，区块链的个人数据文件、交易认证和透明度标准等技术实施方案就更适合广告的“点播时代”。作为媒体广告管理、投放和预测提供商，FreeWheel 也必须应对相应的痛点。因此，在与第三方评估机构和主流DSP结合时，尝试构建联盟链系统来实现账本一致性。

在本文中我们将重点讲解FreeWheel 区块链应用程序的起源、架构和运行模式。

拨开云雾，看到曙光：区块链为什么要用他的技术来解决问题？

区块链是加密货币的核心技术基础，具有不可篡改、透明等特点。但广告行业涉及多方整合，容易出现数据不一致等问题。 因此FreeWheel尝试将区块链技术引入到业务场景中。但需要澄清的是，FreeWheel并不是试图建立一个新的代币系统，而是希望利用区块链来解决当前广告行业的常见痛点。

在广告行业，每个参与者都会经常与第三方进行整合。例如，在评估广告效果的场景中，与尼尔森、Comscore等市场研究公司集成，评估广告效果。此外，通过实时竞价（OpenRTB）协议，SSP还必须与DSP集成，帮助媒体公司出售剩余流量，最大程度地实现流量变现。

在整合过程中，由于核算模型和方法不同，有效广告位数量和服务通话费用的评估会导致双方报价完全不匹配。此外，按日或按月开具发票具有较高的延迟性，并且难以验证或获得一致的结果。因此，FreeWheel引入区块链技术的主要目的是让整个交易过程变得透明，共享所有参与者的整个交易记录——当整个交易数据都记录在区块链中时，所有参与者都拥有所有的账本记录和结算那让一切变得简单。

在采用区块链的技术方案之前，FreeWheel在技术选型上做了很多尝试。现有的分布式数据库无法防止恶意篡改，缺乏有效的共识算法和智能合约机制。区块链自身固有的不变性和信息协同的特性，以及Fabric或以太坊建立的终极抽象基础层，使得区块链的应用程序能够在他的计划中发挥作用。

FreeWheel 总工程师王敏解释说，目前该公司对区块链的主要挑战是解决多方集成账本不一致的问题。它希望通过提高交易的透明度来实现账本的最终一致性，因此它是基于共识机制和编程语言的。考虑到支持等方面的考虑，FreeWheel目前的选择是以面料为基础，构建广告产业联盟链。

FreeWheel区块链应用架构层次及原理

由于广告业务建立的联盟链的特点，所有参与者都是已知和可验证的，因此所有交易参与者都必须获得公钥和私钥，每个参与者将还负责创建交易 - 生成计费系统以开放和定价区块链。创建的区块链交易包含上层发送的原始请求信息、所有DSP的返回以及参与者的签名。

FreeWheel 区块链 应用程序的整体架构如下：

区块链 架构包括客户端（client）和服务器端（peer）。

区块链的客户端在收到上层的所有申请和调用后，负责创建包含原始广告请求的交易。服务器（peer）收到区块链创建的交易后，会通过验证签名来保证交易的合法性。如果合法，服务器会向存储账本添加一个新的区块，State DB 会统计不同参与者之间的调用次数并生成计费报告。

整体架构的上半部分是广告行业现有的系统，主要包括OpenRTB集成和测量集成：

• OpenRTB集成：返回多个DSP的结果后，SSP将基于当前所有候选。选择最终展示位置后，将计算第二高出价并将其返回给 DSP，然后播放广告。同时，SSP也会通过RPC调用将完整的带有多方签名的交易记录记录到相应的账本中（无论是SSP、DSP还是尼尔森，每个参与者都有这样的系统）。
• 衡量整合：评估机构收到添加了调用者签名和自己签名的请求后，将多方签名的交易登记在相应的账本中。

整体架构的下半部分要求每个参与者维护：

• 中间证书颁发机构：需要注册和更新Root CA相应的证书，以及签名的合法性和验证交易。
• 客户端层：
  • 区块链客户端：连接上层服务，打包原始交易记录并添加自己的签名，创建区块链的交易并发送给对应的服务（peer）。
  • 计费系统：查询系统根据区块链记录生成发票。
• 服务层：部署智能合约并为区块链生成新区块。
• 数据层（包括StateDB和Ledger两部分）：
  • State DB：State DB统计各方之间的相互调用总数，方便快速查询。
  • 账本：包含所有交易记录，参与者之间是相同的备份，可追溯、不可篡改。

另外，整体架构除了OpenRTB集成、计量集成和参与者区块链部分外，还包括联盟链管理平台。管理平台由各中心委员会运营和维护：

• 会员管理体系及认证中心：负责新企业、新组织加入平台时颁发证书。
• 账本管理：通道，一个账本对应一个通道。公共频道由中央委员创建，全体参与者共享。每个参与者可以创建一个私有通道，并授权某些参与者，但不允许其他参与者访问，以防止信息泄露。
• 共识管理：订单服务。 Stoff 可以选择多种共识机制：Solo、KafKa、SBFT（仍在开发中）。不同的账本可以选择不同的排序服务，相同的排序服务也可以添加到不同的通道中。订单服务由中央委员会运营和维护。
• 智能合约管理：Chaincode。智能合约是各方就特定交易类型达成一致的业务逻辑。对于相关参与者来说，链码的实现是公开的，可以部署到参与者的背书节点上。

FreeWheel区块链应用系统运行模式

在评价集成场景中，例如，当系统A调用评价机构B的服务时，A会收集投放的广告、观看广告的最终用户、评价机构B的服务等信息。当前视频内容，以及相应的信息。交易的签名发送给B。 B收到系统A的请求后，其客户端将原始请求信息打包并添加B的签名并发送给区块链：

• B发送带有双方签名的交易。 A方与B的背书者，双方节点验证并确定交易的真实性，然后调用相同的链码产生一致的计费结果；
• 背书节点将链码执行结果和节点签名返回给客户端；
• Client 收到两个背书节点的返回后，将综合执行结果、背书节点的签名以及原始交易记录信息发送给订单服务；
• 订单服务将签名结果传输到各个节点（如果节点较多，参与者可以指定一个节点作为主节点，订单服务将新的交易发送到主节点，然后转发到剩余的内部节点发送，从而提高发货效率）。
• 订单服务根据时间戳或客户发送的订单对所有交易进行排序。虽然在账本记录时间的时候并没有调用智能合约，但是有一些额外的检查（比如因为签名的原因，客户端不能偷偷地改变交易ID。
• 所有节点都将新交易更新为自己的）

值得一提的是，Farbic 的记账流程与以太坊完全不同。

以太坊包含两种账户：外部账户和合约账户，每笔交易必须指定最大 Gas 值。以太坊虚拟机根据gas设置控制智能合约执行次数，防止恶意攻击，Fabric联盟链上的所有客户端和服务器都必须经过身份验证，所有交易都必须有参与者签名（交易主动签名、支持节点签名）等）减少公链中恶意节点的问题，高效并避免计算资源的浪费。

目前Fabric共识机制非常简化，更适合广告行业联盟链中的场景——即参与者数量相对有限，参与者基本可靠，竞争较高Fabric主要使用Kafka——订单服务器收到客户端的请求后，将其“塞”到Kafka集群中（相当于一个不断生成记录的生产者），然后按照塞的顺序打包到提交节点，并且提交节点收到它。当您到达消息块时，内部的所有消息都会被验证并说明。

对于Kafka来说，支持向下游发送一模一样的数据，并且顺序不颠倒。如果客户端遇到消息堆积或者网络不稳定导致系统宕机，Kafka重启后会自动重新推送默认消息。这是它非常重要的功能。对于类似的系统交换或消息积累，FreeWheel构建的区块链系统具有实时监控机制，可以暂停广播。

另外，如果参与者中有大量节点连接Kafka，并且Kafka集群需要训练，那么对Kafka的性能要求也会更高。这个问题的解决方案是：每个参与者选择一个类似于VIP或leader的节点，并且只需要这个节点连接到Kafka的Order Service。订单服务交付给Leader后，Leader会在内部进行转发，从而减轻订单服务的压力。参与者内的记账节点数量可以随意添加。

如何利用智能合约技术进行区块链开发？

智能合约属于各方对某一特定交易达成一致的业务处理逻辑，即约定的链码（Chaincode）。如上所述，Chaincode 在参与者之间是公开的，并部署在其背书节点上，可以自动执行交易并产生结果，无需第三方干预。

相比以太坊主要支持Solidity（类似JavaScript）和Serpent（类似Python），Fabric支持使用Golang、Java和Node.js实现智能合约。 FreeWheel在开发过程中主要基于Golang。实现智能合约只需要集成fabric的一个接口，实现Init和Invoke两个函数，fabric chaincode通过gRPC与peer节点交互。 init函数仅在首次启动和每次升级时调用，负责内部参数的初始化。每次交易验证期间都会调用

type Chaincode interface {
Init(stub ChaincodeStubInterface) pb.Response
Invoke(stub ChaincodeStubInterface) pb.Response
}

Invoke 函数。例如，签名的验证、加载方式的确定等都是由Invoke函数来完成的，Invoke函数负责主要业务逻辑的实现。传入的参数主要包括以下几部分。您可以通过GetFunctionAndParameters获取要支持的原始交易记录以及客户端发送的预期操作。

对于简单的业务场景，或许可以实现一个调用功能。但对于复杂的业务场景，可以通过多个链码之间的调用来实现，将复杂的智能合约模块化，并且链码之间的调用不会产生意外的交易记录和意外的区块，而是生成一个综合账本，或者几个小账本。

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在开发过程中发现，Golang的chaincode目前只支持官方标准包，否则无法在endorser节点上正常运行。这也是当前发展中遇到的重要问题之一。关于如何更好的引入第三方包，FreeWheel目前还没有更好的解决方案。

区块链的微服务与安全

由于广告行业经常涉及多方集成和复杂的业务逻辑，以方便部署和运维，因此采用了大量的微服务架构和容器化等相关技术。 ;出于安全考虑，FreeWheel 还为 OpenSSL 添加了 CA 认证。

针对复杂的业务场景，FreeWheel 希望尽量将所有系统功能模块化，从而可以使用 gRPC 等微服务框架来实现链码间的调用——即基于 gRPC 和 HTTP2 的微服务框架进行模块间和跨客户沟通。例如，通过微服务对验证结果进行集群，并增加背书节点的吞吐量，当由Docker或Kubernetes管理时，可以非常方便地扩展和增加节点数量。同时，在订单服务分发方面，微服务也可以减轻分发压力。

同时，FreeWheel 主要使用 Kubernetes 进行容器编排，这使得所有参与者都可以非常方便快捷地在私有云或公有云上部署客户端、节点和微服务。

由于联盟链的特性，对于联盟区块链应用还有一个考验：安全性。因此，FreeWheel 主要提供基于 Fabric 的多层 CA 认证系统，确保联盟链上的所有参与者都经过验证（未经验证的交易立即被拒绝），并使用 OpenSSL 协议来保证通信的安全，特别是对于通过模块并涉及 HTTP 事务和服务。

区块链应用开发的其他重点和难点

由于广告行业竞争激烈、实时报价请求量大，区块链应用最明显的性能问题就是延迟。一方面，增加总同步需求和节点数量必然导致性能下降；另一方面，如何最大限度地减少不同地区、不同网络环境下不同参与者选择的不同私有云的延迟。这些都使得这个问题成为FreeWheel接下来要克服的难点之一。

目前，恶意攻击等很多问题在比特币或以太坊中都被削弱了，并且没有女巫节点等，这必然会更好地提高性能。但斯托夫·区块链进入了活跃期。在FreeWheel实验环境中，对于两个参与者，Fabric吞吐量为350 tps，每笔交易的平均延迟时间约为1秒（从交易生成到记录到账本所消耗的时间） ，其中背书进程平均耗时 55ms。在实验中，Fabric的主要瓶颈是Committer Peer目前不可扩展（最大TPS为3K），并且无法通过分布式来提高计算性能。同时，FreeWheel仍在继续在多参与者、多节点的复杂网络环境中进行性能测试，以评估其有效性。

未来业务层多方融合将是常态。 FreeWheel 与合作伙伴讨论如何协作以及如何创建、组建和管理中央委员会。在技​​术层面，FreeWheel将针对高并发、低延迟、多参与者参与的广告场景，持续测试fabric在不同场景下的性能。

采访者：

王敏，2013年加入FreeWheel，现任总工程师。主要负责用户数据管理与整合、广告预测、区块链研究等核心业务。带领团队完成了用户管理平台的改造，目前主要负责竞价广告预测平台和区块链应用平台。