基于联盟链技术的数据交易平台设计
2022-07-07李旭
李旭
（广东省深圳市北京大学深圳研究生院 广东省深圳市 518071）
1 背景
进年来随着以互联网为代表的信息技术高速发展推动了整个社会运转数字化的进程，每时每刻在社会运转各个场景：消费、企业管理、金融、工业制造、安全监控、医疗等领域都在产生大量的数据，而很多数据是极为有价值的资产甚至数据是一个企业的核心竞争力已是社会的普遍共识。在这个背景下数据作为一种资产进行交易开始有较为迫切的诉求，但是数据交易也面临诸多挑战。如何解决这些挑战成为一个意义的课题。
2 本文主要工作
当前数据交易产业和技术研究还处在初期阶段，无论还是产业标准以及商业化还是技术研究都不太成熟。
数据交易的特点：
（1）数据易泄漏：数据作为特殊的商品，区别与实物商品，可以无轻松的复制拷贝，一旦泄漏难以追回。这使得数据卖家在交易数据过程中特别谨慎。
（2）所见即所得：传统商品的所有权都有一个显式的、公认的证明，数据商品没有了传统所有权的概念，拥有数据商品也更为简单，成本更低，看过即拥有了数据商品，就能获得效用。
（3）交易的数据规模可能较大，需要考虑海量数据存储、交割的性能。
基于上述原因数据资产的交易对交易安全有着更高的诉求。目前产业界较为知名的数据交易市场有国内的贵阳大数据交易所以及国外的azure在线数据市场。其模式都是通过权威的中心化机构作为信用背书进行交易，机构从中收取的交易费用。这种传统中心化的数据交易平台主要的问题是交易成本高，并且即便有第三方的权威机构背书，由于数据交易的特殊性还是存在信任问题。
基于上述问题近年来学者开始尝试基于区块链技术构建交易系统，试图解决交易信任以及数据安全问题比如：Prabal Banerjee等人探索了区块链交易市场设计挑战和方向，杨茂江提出的基于密码和区块链结合的数据交易平台设计，提出了一种去中心化的数据交易思路，邵晓蓓设计的区块链交易系统，提出一种线上支付线下数据交割的设计方案。Haoqian Zhang提出了一种去中心化的信息分享方案。Benet 设计了星际文件系统，旨在连接所有有相同的文件系统的计算机设备，对分布式数据的安全共享与存储提供了较好的思路。
总的来说这个方向目前还在探索阶段，不太成熟。目前的设计主要问题是：
（1）数据如何安全交割没有具体的设计。
（2）数据交割和支付过程分离，需要线上支付线下交割数据或只考虑数据交割。
本文旨在设计一种新型的基于联盟链技术的数据资产交易平台，从数据发布到交易执行全部在链上完成，同时支持第三方电子支付平台进行支付。交易和支付过程无需借助线下渠道完成。从技术上保证交易过程数据资产安全，可以降低交易双方的信任成本。
3 基于联盟链的数据交易平台设计
3.1 系统实现方案概述
经过技术调研，考虑到使用场景以及大数据量存储、交易的性能问题，系统的整体设计决定联盟链技术上实现。基础区块链平台实现参考较为成熟的fisco联盟链，依托fisco联盟链基础平台完成如下工作：
（1）引入了轻节点和全节点两种不同联盟链节点，两种节点配合实现数据交易合约的执行，在一定程度上牺牲去中心程度来提升数据交割性能。同时在节点存储设计上扩展了世界态state数据结构，引入数据资产索引树(data storage trie)结构、数据资产摘要倒排索引池（data abstract inverted index pool）支撑数据的加密存储与交割。
（2）实现一种预编译的特殊智能合约：数据交易智能合约，可以方便发布合约并在合约执行时可以对接三方电子支付系统，支付后自动执行链上数据交割工作。
（3）基于PBFT算法实现合约交易执行共识。
3.2 整体架构
本文所描述的区块链交易平台由三部分组成：全节点、联盟链网络、轻节点。如图1所示。
图1：架构概要
轻节点：轻节点由加盟的卖家或买家维护，用于保存某个卖家发布的数据资产、买家买到的数据资产、数据资产摘要并通过卖家的密钥对数据资产进行加密后存储，为提升效率降低轻节点的负载，每个轻节点只保留对应卖家账号发布的数据资产、以及对应的数据资产摘要。但每个轻节点都保留有全网的区块头链以及当前卖家账号状态树。卖家通过轻节点发布数据后会生成一份交易智能合约。
全节点：保存有全网的区块链交易记录、全网数据资产摘要索引、交易智能合约。同时提供成员接入和认证管理、提供数据摘要查询能力、发起智能交易合约执行、智能交易合约执行结果数据维护。但是中节点不保存卖家数据资产信息只保存数据资产摘要信息。中心节点一般由平台开发方、大机构、大卖家、监管机构部署。
联盟链网络：轻节点和全节点通讯和执行基础能力，实现区块同步、共识机制、合约执行、连接轻节点和中心节点网络、同步数据摘要索引。
交易节点的分层架构设计：
区块链基础服务：实现区块链的链式数据结构、交易执行引擎和存储驱动、区块链的基础P2P网络通信、共识机制和区块同步机制。
管理层：实现区块链的数据资产管理、合约管理、用户权限管理。
接口层：对用户提供http服务，封装交易平台能力。
轻节点和中心节点的区别：
（1）轻节点不提供全网数据资产摘要索引，该索引只存在与全节点中，因此买家查询数据摘要信息需要路由到中心节点查询。
（2）合约执行流程轻节点和中心节点职责不同。合约执行主要由中心节点发起调度执行，轻节点参与合约执行验证、共识以及提供本地数据。详细见2.5章节。
3.3 节点存储设计
全局的数据存储基于全局数据存储设计如下所示。在传统联盟链设计基础上新增数据结构，用于存储账户拥有的数据资产索引。
其中数据资产文件只会存储在轻节点中，数据资产摘要倒排索引只存在全节点中。数据资产索引树在轻节点和全节点中都会存储。
3.3.1 账户状态account state
有两种类型的账户：
用户持有 – 私钥的所有者控制
交易合约 – 一种由代码控制，部署在网络上的智能交易合约。
字段名称 类型 描述nonce Unit64显示从帐户发送的交易数量的计数器balance 这个地址拥有的 Wei 数量codeHash Byte[]该哈希表示以太坊虚拟机 (EVM) 上的帐户代码storageRoot Byte[]存储hash dataHash Byte[]数据资产存储hash
3.3.2 交易transtation
记录交易结构信息
字段名称 类型 描述type enum 交易类型，表明该交易是创建合约还是调用合约交易nonce u256 消息发送方提供的随机数，用于唯一标识交易value u256 转账数额，目前不需要receiveAddress h160 交易接收方地址gasPrice u256 本次交易的gas的单价gas u256 次交易允许最多消耗的gas数量data Byte[]与交易相关的数据，或者是创建合约时的初始化参数chainId u256 记录本次交易所属的链信息/业务信息groupId u256 记录本次交易所属的群组extraData Byte[]预留字段，记录交易信息
3.3.3 区块头
字段名称 类型 描述parentHash h256 父区块的哈希值stateRoot h256 状态树的根哈希值transactionsRoot h256 交易树的根哈希值receiptsRoot h256 收据树的根哈希值dbHash h256 分布式存储通过计算哈希值来记录一区块中写入的数据number int64_t 本区块的块号，块号从0号开始计算gasLimit u256 本区块中所有交易消耗的Gas上限gasUsed u256 本区块中所有交易使用的Gas之和timestamp int64_t 打包区块的unix时间戳
3.3.4 数据资产信息datainfo
记录数据资产存储相关信息
字段名称 类型 描述dataAbstractHash Byte[]数据摘要索引hash dataHash Byte[]数据内容hash dataFileAddress Byte[]数据存储文件地址
3.4 预编译交易合约运行交互流程
整体交互协议设计如图2所示：描述了预编译交易合约（以下简称合约）的发布、执行流程。
图2：数据交易智能合约执行流程
3.4.1 预编译合约
所谓预编译合约会被区块执行引擎所调用，区块验证器通过区块执行引擎来执行区块，执行引擎执行区块时，会根据被调用合约的地址，来判断使用EVM还是预编译合约引擎。
当被调用的合约地址是EVM合约时，执行引擎会创建并执行EVM来执行交易；当被调用合约地址是已注册的预编译合约地址时，执行引擎通过调用地址对应的预编译合约接口来执行交易。本方案中的交易智能合约即采用预编译合约的方式实现。
3.4.2 合约发布
卖家通过本地本地轻节点发布合约。
（1）轻节点获取到卖家账号公钥，通过公钥加密待交易的数据，将加密后的数据作为文件存储。同时将数据摘要信息打包生成数据摘要索引以便提供搜索。
（2）轻节点加载预编译数据交易合约模版，向全网发起数据交易合约交易广播。
（3）其他节点执行发布合约交易，将本次合约写入本地区块中。中心节点在交易过程中扮演着核心作用，因此系统必须在超过1/3的中心节点写入合约成功后发布发布才算成功。
3.4.3 合约执行
买家通过本地的轻节点发起合约执行。
（1）轻节点首先会找到一个中心节点发起合约执行请求，中心节点接到到该请求后自动执行合约代码，根据请求调用三方电子支付系统生成支付链接或付款码。
（2）买家根据中心节点合约执行生产的付款码使用第三方电子支付系统支付。支付成功后第三方电子支付系统根据回调地址通知中心节点支付是否成功。
（3）如果支付成功，中心节点根据合约记录周到对应的卖家轻节点地址，以及本地支付的买家轻节点地址。然后发起数据传输指令。
（4）买卖双方轻节点根据中心节点指令建立安全通讯信道，通过握手协议生成本次传输数据的密钥。卖家轻节点在内存中通过卖家私钥对数据解密，并通过安全信道将数据发送到买家轻节点中。
（5）买家轻节点收到数据后通知中心节点数据交割完成。
（6）中心节点收到数据交割完成消息后更新本地状态数据，并将本次交易快照打包后广播。其他节点验证交易并更新本地交易记录，完成合约执行。
3.5 合约共识算法
一个合约在某个中心节点执行完成后需要在全网达成共识。本文共识算法设计基于PBFT算法设计，适用于本交易平台交易的共识。
算法共有无种消息：
PrepareReqPacket:
包含区块的请求包，由leader产生并向所有Replica节点广播，Replica节点收到Prepare包后，验证PrepareReq签名、执行区块并缓存区块执行结果，达到防止拜占庭节点作恶、保证区块执行结果的最终确定性的目的；
SignReqPacket:
带有区块执行结果的签名请求，由收到Prepare包并执行完区块的共识节点产生，SignReq请求带有执行后区块的hash以及该hash的签名，分别记为SignReq.block_hash和SignReq.sig，节点将SignReq广播到所有其他共识节点后，其他节点对SignReq(即区块执行结果)进行共识；
CommitReqPacket:
用于确认区块执行结果的提交请求，由收集满(2*f+1)个block_hash相同且来自不同节点SignReq请求的节点产生，CommitReq被广播给所有其他共识节点，其他节点收集满(2*f+1)个block_hash相同、来自不同节点的CommitReq后，将本地节点缓存的最新区块上链；
ReplayReqPacket：
确认CommitReqPacket请求的回复消息。
ViewChangeReqPacket:
视图切换请求，当leader无法提供正常服务(如网络连接不正常、服务器宕机等)时,其他共识节点会主动触发视图切换，ViewChangeReq中带有该节点即将切换到的视图(记为toView，为当前视图加一)，某节点收集满(2*f+1)个视图等于toView、来自不同节点的ViewChangeReq后，会将当前视图切换为toView。
算法流程描述如下：
3.5.1 REQUEST
交易合约执行过程中某个被选中执行的全节点（执行节点）执行交易合约，验证支付结果通过后更新本地数据库支付状态，向主节点（一定是全节点）p发送
3.5.2 PRE-PREPARE
主节点（只能是全节点）收到执行节点请求，需要进行以下交验：
a.请求消息签名是否正确。
非法请求丢弃。正确请求，分配一个编号n，编号n主要用于对执行节点的请求进行排序。然后广播一条消息PrepareReqPacket
为了保持消息较小。
3.5.3 PREPARE
副本节点（包含主节点和轻节点）i收到主节点的PrepareReqPacket消息，需要进行以下校验：
a.主节点PrepareReqPacket消息签名是否正确。
b.当前副本节点是否已经收到了一条在同一v下并且编号也是n，但是签名不同的PrepareReqPacket消息。没有收到是合法的 这是为了以防主节点作恶，将不同的请求分到相同的n,从而在其他节点产生请求混乱 因为在短时间会有很多请求，各个请求通过v和n区分，从而相同请求在各个节点一起执行。
c.d与m的摘要是否一致。
d.n是否在区间[h,H]内。非法请求丢弃。正确请求，副本节点i向其他节点包括主节点发送一条SignReqPacket
3.5.4 COMMIT
主节点和副本节点收到SignReqPacket消息，需要进行以下校验：
a.副本节点SignReqPacket消息签名是否正确。
b.当前副本节点是否已经收到了同一视图v下的n。
c.n是否在区间[h,H]内。
d.d是否和当前已收到PrepareReqPacket中的d相同非法请求丢弃。如果副本节点i收到了2f+1个验证通过的SignReqPacket消息（表明至少有f+1个诚实节点在视图v中发送了序列号为n的PrepareReqPacket消息或者是SignReqPacket消息），则向其他节点包括主节点发送一条CommitReqPacket
CommitReqPacket消息的内容SignReqPacketPrepare消息内容相同，但消息类型和数字签名是不同的，所以可以区分。
3.5.5 REPLY
主节点和副本节点收到CommitReqPacket消息，需要进行以下校验：
a.副本节点CommitReqPacket消息签名是否正确。
b.当前副本节点是否已经收到了同一视图v下的n。
c.d与m的摘要是否一致。
d.n是否在区间[h,H]内。非法请求丢弃。如果副本节点i收到了2f+1个验证通过的CommitReqPacket消息，说明当前网络中的大部分节点已经达成共识，运行客户端的请求操作o，并返回ReplayReqPacket
3.5.6 VIEW CHANGE：
当共识超时时，系统会试图切换到更高的视图(将要切换到的视图toView加一)，并触发ViewChange处理流程；节点收到ViewChange包时，也会触发ViewChange处理流程：
（1）判断ViewChange包是否有效，有效的View Change请求中带有的块高值必须不小于当前节点最高块高，视图必须大于当前节点视图。
（2）缓存有效ViewChange包，防止相同的View Change请求被处理多次，也作为判断节点是否可以切换视图的统计依据。
（3）收集ViewChange包，若收到的ViewChange包中附带的view等于本节点的即将切换到的视图toView且本节点收集满2*f+1来自不同节点view等于toView的ViewChange包，则说明超过三分之二的节点要切换到toView视图，切换当前视图到toView。
5 交易性能评估
交易效率受到很多方面的影响，本实验在普通商用服务器（8核16G）部署3台中心节点2台轻节点，整体性能表现上交易TPS与交易数据大小强相关，主要的瓶颈在数据交割传输以及数据加解密。测试过程中mock外部三方电子支付系统交互。性能表现：
数据10byte左右，交易峰值TPS在1700左右，交易数据大小超过1mb后性能急剧下降到10TPS左右,交易时间近似等于p2p数据交割时间。可见系统性能优化方向主要在数据交割部分。如图3所示。
图3：交易性能数据
6 总结
本文通过在传统的联盟链技术上改进：引入轻节点和中心节点，并设计预编译数据交易合约协议和共识算法打通三方电子支付系统实现数据资产的线上交易和数据线上交割。较好的保护了数据在交易过程的安全性，通过技术手段提升了交易双方的信任感，同时降低了双方的交易成本。
不足之处是本方案考虑到交易性能、数据存储成本、数据交割成本，采用半去中心化的技术，海量的敏感数据只存储在本地轻节点中，在一定程度上会降低交易合约执行的可靠性。同时面对大数据量的数据交割时性能会是一个瓶颈，如何将轻节点数据存储完全分布式化并保证交易性能以及数据安全有待进一步研究。
