企业级区块链技术综述

Hyperledger

具有Fabric、Iroha、Burrow、Indy等多个企业级区块链平台，以适应不同的需求和场景。

Fabric

Fabric采用了合约执行与共识机制相分离的系统架构,模块化地实现了共识服务、成员服务等服务的即插即用.

• 背书节点（endorsing peer）——主要执行智能合约
• 排序服务（ordering service）——主要执行共识以对交易排序并生成区块
• 提交节点（committing peer）——主要持久化区块数据和状态数据

交易流程

(1) 客户端对新的交易数据签名并发送到一至多个背书节点;
(2) 背书节点以交易数据为输入执行智能合约并生成读写集(readset,writeset);
(3) 背书节点对读写集进行签名并返回至客户端;
(4) 客户端收集读写集,验证符合背书策略(endorsement policy)后将其广播至排序服务;
(5) 排序服务基于共识机制对多笔交易的读写集排序并将其打包成区块;
(6) 排序服务将区块传播至提交节点;
(7) 提交节点对从排序服务收到的区块中的读写集进行背书策略验证和读集(readset)版本验证,验证通
过后,将区块追加至区块链,并将写集(writeset)写入状态数据库.

准入机制

Fabric 节点中的 MSP(membership service provider)模块负责身份管理,主要完成数字证书验证、签名与验
证、私钥管理等功能。智能合约可依据调用者的数字证书、MSP ID 及其属性字段实现多种级别的访问控制 .

共识机制

Fabric 采用了合约执行、共识排序、验证写入相互解耦的系统架构,保证了各功能节点独立地进行扩展.因为共识服务不用执行交易和存储交易,即无需关心交易的具体内容,因而无状态的共识服务更易插件化

区块链数据

Fabric 区块中的交易主要由读写集表示,读写集由背书节点依据交易数据执行智能合约后生成。

读集表示执行该笔交易所需读出的数据集

写集表示存储交易执行结果所需写入的数据集

Fabric 区块链数据以日志文件的方式进行存储

Fabric 区块链中除了包含交易数据的数据区块外,还有包含配置数据的配置区块,配置区块主要包含了区块链中所有节点的数字证书、共识服务地址、区块切分依据等系统配置参数

智能合约

Fabric 智能合约被称为 Chaincode,其主要用于执行交易和访问状态数据，Chaincode 运行在背书节点,但不同于传统区块链,Chaincode 无需在所有的背书节点上运行

背书策略定义了执行 Chaincode 所需的背书节点数量及组合(如一个 Chaincode 至少要被 n 个背书节点中的任意 k 个节点执行并签名)

沙箱环境

智能合约不能直接运行在区块链节点上.因为一方面要保证在不同节点的软硬件环境下,合约执行结果始终是确定的;另一方面,合约中若含有漏洞或恶意代码,要保证不会影响其他合约的执行及区块链节点的安全.所以智能合约必须运行在沙箱环境中.目前,沙箱主要分为虚拟机和容器两类,都是为了保证合约代码在沙箱中执行时,对合约使用的资源进行限制和隔离.

Fabric 使用轻量级的 Docker 容器作为沙箱,其基于 Docker 的隔离性和安全性,保护了宿主机不受容器内恶意合约的攻击,也防止了容器之间的相互影响.Chaincode 可基于 Go,Node.js 和 Java 开发。

隐私保护——通道

多个参与者可自发组建一个通道,每个通道拥有一条专有的区块链,通道内的所有交易数据存储在内部的链上,只有通道内的节点才可访问链上的数据,没有加入通道的节点将无权访问.

Fabric 通过将交易分配到相互隔离的多条区块链上,实现私密的交易

通道实际上是一种基于多链的数据分区,一个节点根据交易需求可加入多条通道,多个通道内的交易可并行地执行.相对于单链的方案,其提高了全网的交易吞吐量.

Hyperledger其他应用场景平台

Sawtooth

Sawtooth 基于 Intel SGX(software guard extensions)可信硬件实现了经历时间证明(proof of elapsed time,简称 PoET)共识机制,相对于 PoW 共识,其无需挖矿且出块间隔更短.

Iroha

Iroha 主要针对于移动应用,其实现了基于链复制(chain replication)[10]的共识机制Sumeragi

Burrow

Burrow 集成了以太坊虚拟机并可运行以太坊智能合约,其使用了 Tendermint[11]共识机制.

Indy

Indy 是基于区块链的去中心的数字身份平台 , 其使用了 RBFT(redundant byzantine fault
tolerance)共识机制.

Corda

Corda着重服务于受监管的金融行业,强调业务数据仅对交易双方及监管可见的数据隐私性

交易流程

(1) 发送者创建交易并签名;
(2) 发送者发送交易数据及签名至接收者;
(3) 接收者验证交易数据及发送者签名无误,就附加上接收者签名;
(4) 接收者发送交易数据及交易双方签名至 Notary 共识服务;
(5) Notary 验证交易数据及交易双方签名无误,就附加上 Notary 签名;
(6) Notary 返回交易数据至接收者;
(7) 接收者核对 Notary 签名无误后提交交易;
(8) 接收者返回交易数据至发送者;
(9) 发送者核对接收者及 Notary 签名无误后提交交易.

准入机制

Corda 许可服务被称为 doorman,Corda 节点需要基于节点信息向 doorman申请到根证书机构签名的 TLS
证书,才能加入到对应的 Corda 网络。为了控制交易数据的传播范围,交易发送者需在发送的消息中直接指定接
收者地址.

共识机制

Corda 依靠 Notary 服务防止双花,避免产生冲突的交易.每笔交易提交前必须获得 Notary 服务的签名,以证
明交易的每个输入状态所引用的资产都是未被花费的；

Corda 没有全局统一总账,每个节点一致性地存储着与自己业务相关的交易数据,所以为了确保发送者
提供的交易是来源是可靠的,就需针对每个输入状态沿着 UTXO 模型一直回溯至最初的发行交易,以
从其他节点获取到当前交易涉及的所有历史交易,并验证每笔交易都是有效的;

区块链数据

Corda 系统没有维护一个全局账本,每个节点通过数据库一致性地维护与自己业务相关的当前和历史状态数据

Corda 采用 UTXO 模型,一个交易包含一到多个输入状态和一到多个输出状态

与比特币的 UTXO 模型相比,Corda 的 UTXO 模型不但支持数字货币转账,还支持用户定义的通用数字资产的流转

智能合约

Corda 交易包含多个输入/输出状态,每个状态都有一个引用指向一个智能合约,执行交易时,需要执行交易中每个状态所引用的合约.

Corda 智能合约主要验证交易数据,以保证其符合各项约束条件.

沙箱环境

Corda 采用一个修订版的 JVM 作为沙箱,限制引用编程语言中一些非确定性特性.同时,对合约生成的字节码做了静态分析和重写,限制合约运行时间过长及使用内存过多.Corda 合约可基于 Kotlin 和 Java 开发,并基于 Kotlin 和 Java 定义了领域专用语言

隐私保护——Flow

Flow中的交易仅在交易参与者间共享与执行,交易数据被点对点地直接发送到指定的接收者.一笔交易在流程中需在多个节点间进行多轮通信,每个节点还需进行验证和签名

使用随机公钥隐藏了交易双方的真实身份

利用 Tear-offs 技术实现了对签名者仅展示交易的部分数据

Quorum

通过分别处理公有交易和私有交易实现了交易和合约的隐私保护,并用 Raft 共识替换了以太坊的 PoW 共识，公有交
易是全网共享的传统以太坊交易,私有交易仅在交易双方共享.

Quorum系统组成

• Quorum 节点——主要用于执行合约及维护区块链与状态数据,状态数据分为存储公有交易执行结果的公有状态数据和存储私有交易执行结果的私有状态数据
• Constellation——主要实现私有交易数据的加密、解密、存储及点对点传输.

交易流程

(1) 客户端发送私有交易到 Quorum 节点,并在交易中直接指明每个接收者的公钥;
(2) Quorum 节点将私有交易传送至对应的 Constellation 进行加密;
(3) Constellation 生成一个对称秘钥,先用该对称秘钥加密私有交易负载(payload),再分别用每个接收者
的公钥分别加密该对称秘钥,最后还要基于私有交易的加密负载计算其哈希值;
(4) Constellation 将私有交易的加密负载、私有交易的加密负载的哈希值、加密后的对称秘钥分别点对
点的传播至每个交易接收方的 Constellation;
(5) 数据传播成功后,Constellation 将私有交易的加密负载的哈希值返回至对应的 Quorum 节点;
(6) Quorum 节点将私有交易的加密负载的哈希值打包为一个以太坊交易,经以太坊 P2P 协议广播至所有
Quorum 节点;
(7) 该以太坊交易经过共识被打包进 Quorum 区块.当每个 Quorum 节点执行该以太坊交易时,需要基于该
以太坊交易的负载(即私有交易加密负载的哈希值)向对应的 Constellation 请求原始的私有交易负载;
(8) 根据 Quorum 节点的请求,各个交易接收方的 Constellation 基于自己的私钥、公钥加密的对称秘钥、
对称秘钥加密的私有交易负载解密出原始的私有交易负载;
(9) 交易接收方的 Constellation 将原始的私有交易负载返回至对应的 Quorum 节点.非交易接收方的
Constellation 没有接收过加密的私有交易负载,其向 Quorum 节点返回的是“NotARecipient”消息;
(10) 交易涉及的每个 Quorum 节点将私有交易提交至智能合约运行,智能合约会将执行私有交易时生成
的状态数据存储至私有状态数据库.

准入机制

只有被授权的节点才可加入.Quorum 在每个节点都设置一个 JSON 配置文件,其定义了所有被授权的网络节点

网络协议

采用 go-ethereum 的 P2P 传输层在 Quorum 节点间传播公有交易;Quorum 在私有交易中指明了接收者的公钥,所以 Constellation 直接将私有交易经 HTTPS 发送至接收者的 Constellation,没有参与私有交易的节点不会接收到交易

共识机制

Quorum 同时维护着公有状态数据和私有状态数据:公有状态数据需要在全网所有节点间达成共识,私有状态数据仅需在交易参与者间达成共识.

区块链数据

Quorum 将系统中的交易分为公有交易和私有交易,以对其采用不同的交易流程和存储

相对于公有交易,私有交易加入了一个可选参数 privateFor,它包含了多个接收者公钥的列表,指明了该私有交易应该只发送给那些接收者

私有交易数据存储在链外(off-chain),也就是 Constellation.私有交易在智能合约中的执行结果存储在 Quorum 节点的私有状态数据库中

智能合约

Quorum 智能合约分为公有合约和私有合约,它们在编程实现上并无分别

公有合约运行在所有节点,以公有交易数据为输入,将执行结果存储在公有状态数据库

私有合约仅运行在与交易相关的参与者节点,以私有交易数据为输入,将执行结果存储在私有状态数据库

因为私有状态数据的访问限制,Quorum 公有合约不能调用私有合约.私有合约可以调用公有合约,但仅允许执行读操作,不能执行写操作

沙箱环境

Quorum 沿用了以太坊自定义的 EVM 作为沙箱,运行以太坊自定义的字节码,这些字节码不能访问 EVM 宿主机的网络系统、文件系统和其他进程,合约之间也只有有限的调用.Quorum 合约需基于以太坊自定义的Solidity 语言开发

隐私保护

为了实现隐私保护,Quorum 平台针对公有交易和私有交易分别使用了不同的交易流程和状态数据库,其中,私有交易的加解密、存储及点对点传输都是依靠 Constellation 来实现的

Constellation 主要包含交易管理(transaction manager)和 Enclave 两个模块.

• 交易管理主要实现了私有交易的链外存储、基于加密负载哈希的私有交易负载访问、点对点的传输
  私有交易的加密负载至指定接收者;
• Enclave 负责私有交易负载的加解密

通过依靠 Constellation 进行私有交易数据管理,没有参与私有交易的节点不接收私有交易、不存储私有交易、不执行私有交易,其仅能访问到私有交易负载被加密后的哈希值.

其他企业级区块链

MultiChain

兼容于比特币系统,侧重于数字资产类应用,可快速部署在 Windows,Linux 和 Mac OS 多种操作系统之上

Ripple

基于分布式账本的实时跨境支付网络,其通过 ILP(interledger protocol)[19]协议实现了不同账本与支付系统间的互联

BigchainDB

可扩展的区块链数据库,其声称既拥有高吞吐量、低延迟、大容量、丰富查询和权限等分布式数据库的优点,又拥有去中心化、不可篡改、资产传输等区块链的特性,因此被称为在分布式数据库中加入了区块链特性

BCOS

适用于企业级应用,其在以太坊基础上加入了 CA 身份认证、PBFT共识机制、隐私保护等组件,在国内率先应用于金融领域并取得了商用实践成果.

研究挑战与趋势

• 吞吐量

  • Fabric 的交易吞吐量约为 3500TPS[43],Corda 的交易提供吞吐量约为1000TPS[62],Quorum 的交易吞吐量约为 100TPS[16],与比特币(7TPS)、以太坊(15TPS)相比已有相当改善,但与传统的数据库系统相比,仍有着不小的差距。
  • 以区块为单位提交交易、每笔交易涉及的多方签名与验证、基于 BFT 的共识机制、串行执行的智能合约等都会限制其吞吐量，在实际部署应用时,不同的策略与配置也会影响吞吐量

• 共识机制

  • 共识机制目前仍是整个系统性能的关键瓶颈
  • 当前,许多区块链平台声称提出了高性能的共识机制,但这些共识并没给出前提假设、数学模型和形式化证明,其安全性无法衡量
  • 企业级区块链平台未必要自己实现共识机制,完全可以采用通用的解决方案
  • 同一共识在不同的安全假设与可信场景下会展现出不同的性能.所以企业级区块链平台必须支持插件化、可配置的共识服务,以灵活支持从局域网到广域网、从 BFT 到 CFT 不同场景下的多种共识.

• 可扩展性

  • 企业级区块链的每个节点通常仅处理、存储与自己业务相关的交易数据,使其更易于支持可扩展性
  • 与通过增加节点数而线性提高系统吞吐量和容量的横向扩展性目标相比,企业级区块链尚有很大的差距.因此,如何更高效灵活地实现可扩展性,将是研究的热点.

• 隐私保护

  • 区块链隐私保护的难点在于既需隐藏交易细节,又需验证交易的有效性.目前,Fabric,Corda 与 Quorum 提供的隐私保护方案都有着一定的局限性
  • Fabric 通道面临着仅两个交易者也需建立通道所带来的开销问题以及排序服务可读取所有通道交易数据的问题;
  • Corda 处理每笔交易前都需验证从当前交易到发行交易之间的全部历史交易,存在着交易验证流程低效及历史交易数据泄露的问题
  • Quorum私有状态数据无法被非交易者节点读取见证,因而无法解决跨私有合约交易时的双花问题

• 跨链

  • Polkadot 专注于实现通用的跨链通信。Polkadot 的主干网络被称为中继链(relay chain),其以以太坊为主实现了与各种平行链(parachain)的互联,每个平行链就是一个单独的区块链网络.Polkadot 还以其他公有链为升级目标,最终让以太坊可直接与任何链进行互联。

  • Cosmos 专注于实现跨链的数字资产交易。Cosmos 把不同种类的区块链子网看做 Zone,通过主干网络 Cosmos Hub 上运行的 IBC(inter-blockchain communication)协议,实现不同 Zone之间的互联.

  • Hyperledger Quilt 则专注于实现跨链的支付操作。Hyperledger Quilt 是 ILP 协议的 Java 实现,ILP 是无需中介的跨账本支付协议,其实现了不同数字资产账本间的自动路由与原子支付操作

    各类企业级区块链平台无论在系统整体架构还是在交易数据格式上都存在着很大差别,这些都加大了跨链技术的研究难度

• 评测系统

  • 基准评测系统可帮助使用者对比各区块链平台,以选择适合自己需求的平台;也可帮助系统设计者识别出
    系统缺陷以进行改进
  • 专用于评测企业级区块链的开源评测框架 Blockbench(https://github.com/ooibc88/blockbench),其将区块链平台分为共识层、数据模型层、智能合约执行层和应用层,提供了整体性能评估的宏观评测基准和分层性能评估的微观评测基准,具体可从吞吐量、延迟、可扩展性、容错性和安全性这 5 个维度进行评测。
  • Hyperledger Caliper (https://github.com/hyperledger/caliper)是主要由华为开发的区块链开源测评工具,其通过可插拔的适配层来集成不同区块链平台，Hyperledger Caliper 基于一组预定义用例,从吞吐量、延迟和资源利用率这 3 个维度进行评测
  • 对不同区块链平台而言,网络节点数目不同、共识机制容错类型不同、交易模型及尺寸不同、智能合约功能复杂度不同、测试用例不同等,都直接影响着其所能展示出来的性能.这就要求评测系统不仅要基于多个维度指标进行综合评估,还要对区块链平台内在的系统架构、交易流程、应用领域等方面有着深入的理解.为了实现更为客观、公平的评测,也非常需要制定可被行业所广泛接受的通用评测基准.

• 底层数据库

  • 目前,企业级区块链底层数据库大多是 NoSQL 数据库,其主要支持的是 Key-Value 查询.但现有的技术人员更熟悉 SQL 查询,现有的数据分析工具更多基于 SQL 构建,目前迫切需要支持企业级区块链的 SQL 查询工具.
  • 节点数目有限的企业级区块链事实上是弱中心化的,其更需要支持高吞吐、高并发、丰富查询、权限控制、备份与恢复等特性的适合于企业级应用的数据库.

• 智能合约

  • 相对于公有链,企业级区块链中的业务逻辑更为复杂,需要智能合约支持更复杂的功能与数据结构,同时还要确保执行结果的确定性以及合约语言的易用性,这对智能合约语言的设计提出了更高的要求
  • 研究智能合约的语义模型,并通过形式化验证检测合约漏洞[75]以保障智能合约的运行时安全,将是今后的主要研究方向
  • 智能合约发布后,因需求变更、Bug 修复等原因,如何实现不停机的全网合约同步升级以及向下兼容先前版本的状态数据,也是必须解决的问题.

• 可治理性

  • 去中心化的区块链基于公钥与私钥验证的实现仍需大量繁琐的手工配制,私钥的存储与丢失问题也需要易用可行的解决方案
  • 去中心化的区块链系统没有控制全局的管理员,系统在软件动态升级、节点动态加入等方面需要联盟成员集体表决并签名,其造成了决策的低效与滞后
  • 区块链的去中心化与政府部门与监管机构的监管政策相矛盾,如何在实现去中心化同时兼顾政府与监管的合规性要求,也是需要研究的问题.

[1]邵奇峰,张召,朱燕超,周傲英.企业级区块链技术综述[J].软件学报,2019,30(09):2571-2592.