Hyperledger/Quorum等区块链技术综述
[1]邵奇峰,张召,朱燕超,周傲英.企业级区块链技术综述[J].软件学报,2019,30(09):2571-2592.
摘要
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（会员服务提供商）模块承担身份认证工作，并完成数字证书验证、签名认证以及私钥存储和管理等功能。智能合约根据调用者的数字证书、MSP ID及其相关属性字段实现多层次的访问权限控制。
共识机制
Fabric基于合约执行机制、共识排序规则以及验证写入流程构建了具有解耦设计的系统架构, 从而实现了各功能节点之间能够方便地进行扩展。由于共识服务在运行过程中无需处理具体交易细节, 并且不涉及交易数据的存储问题, 因此无状态的设计使得其具备易于插件化的特性。
区块链数据
Fabric 区块中的交易主要基于读写集 来表示,其中读写集是由背书节点根据交易数据运行智能合约并输出的结果。
读集 表示执行该笔交易所需读出的数据集
写集 表示存储交易执行结果所需写入的数据集
Fabric 区块链数据以日志文件的方式进行存储
Fabric 区块链中的数据结构主要由两部分组成：一部分用于存储交易信息的数据区块，另一部分则为系统配置提供支持的配置区块。该配置区块具体包含了参与节点所持数字证书信息、共识机制所需的服务端点地址以及节点间划分新区块的标准等关键系统参数设置。
智能合约
以 Fabric 为开发平台构建的智能合约系统被命名为 Chaincode，并主要应用于交易处理与状态数据的访问。该系统运行于共识节点网络中，在某些方面与传统的区块链技术存在显著差异。与传统的区块链不同的是，在 Chaincode 中，并非所有共识节点都需要参与合同的运行。
该策略决定了实现Chaincode所需的最低回测节点数及其组合形式，并规定了一个Chaincode至少需要由n个回测节点中的任意k个进行操作并生成签名
沙箱环境
智能合约无法直接部署于区块链节点上。原因在于：一是必须确保无论是在何种软硬件配置下运行的环境里，智能合约的行为结果都是可预测且一致的；二是如果智能合约存在漏洞或恶意代码片段，则必须防止这些缺陷导致其他智能合约无法正常运行或威胁到整个区块链网络的安全性。因此，在开发过程中，通常会将智能合约部署在一个独立于主链表中的沙箱环境中。现有的解决方案主要包括使用虚拟机和容器两种主要的技术方案。这些设计旨在限制和隔离用于运行智能合约所消耗的各项资源。
Fabric采用轻量级Docker容器作为隔离环境，并通过Docker技术实现隔离与安全防护。这种设计不仅保障宿主机免受内部恶意合约威胁，并且能够有效避免不同容器间的负面影响。支持开发人员使用Go、Node.js或Java构建应用。
隐私保护——通道
多个方 formations 可以 自行组网 一个 通路, 每个 通路 拥有 独立的一条 blockchain 链, 通路内所有的交易记录 存储于 通道内部专用链中, 只有 通路内部的所有节点才有权限访问其专用链.
Fabric 通过将交易分配到相互隔离的多条区块链上,实现私密的交易
实际是一种基于多条链路的数据分区机制，在线ñ能根据不同的交易需求灵活地加入到多个不同的通道中，在线ñ这些不同渠道中的交易活动可以同时进行.相比于单一链条的方式而言,该方法显著提升了整个网络的交易吞吐量.
Hyperledger其他应用场景平台
Sawtooth
Sawtooth 利用 Intel SGX 平台采用了Proof of Elapsed Time (PoET)共识机制,相较于 PoW 模式,其出块间隔显著缩短。
Iroha
Iroha 专注于移动应用领域，并实现了基于链复制（chain replication）[10]的共识机制 Sumeragi
Burrow
Burrow对以太坊虚拟机进行了整合，并支持运行以太坊智能合约。该系统采用Tendermint共识机制。
Indy
Indy 依托区块链技术构建了一个分布式、去中心化的数字身份平台；该系统采用了冗余拜占庭容错（RBFT）共识机制。
Corda
Corda主要面向受到严格监管的金融领域，并特别注重企业间及其监管机构的数据在数据隐私保护方面的安全性。
交易流程
(1) 发送方负责创建并签署该笔特定的交易；
(2) 发送方将包含该笔交易数据及其签署信息的内容传输给接收方；
(3) 当接收方确认收到完整且无误的数据与签署信息时，则会附加其 own signature;
(4) 该笔待处理的交易数据及其双方参与者的全部签字被提交至Notary共识服务系统；
(5) 当Notary核实所有相关的信息与签字准确无误时，则会附加其 own signature;
(6) 不确定性服务系统将在完成审核后将该笔待处理的原始数据返回给接收方；
(7) 在收到Notary所附加的 signature 后且确认其真实性后, 受信任方即可提交此份文件；
(8) 受信任方随后将此份文件重新传回发件人处以供核查；
(9) 发件人将在完成对双方参与者全部签字的真实性核查后选择性地提交这份文件.
准入机制
Corda 许可服务被称作 doorman. Corda 节点通过获取节点信息并获得根证书机构签名的 TLS 证书后才能加入到对应的 Corda 网络. 为了控制交易数据传播范围, 交易发送者必须明确指定接收者的地址.
共识机制
Corda 借助 Notary 服务有效抑制双重 spending 行为,确保无冲突交易的发生.每笔交易需经授权后方可提交,以便验证其所有引用资产均未发生支出记录；
Corda 缺乏统一的全局总账机制 ，每一个节点都独立维护与其业务相关的独特交易记录。为此，在保证发送方提供的交易具有可信来源的前提下 ，系统必须针对每个输入状态 从UTXO模型出发追踪其起源的初始发行交易 ，从而能够通过其他节点收集所有相关的历史记录，并对每笔历史记录进行有效性验证
区块链数据
Corda系统不运营一个全球账本；而是每个节点依靠数据库来一致地管理与自己业务相关的当前和历史状态数据。
Corda基于UTXO模型设计,每个交易由1至n个输入状态构成,并由1至n个输出状态构成
相较于比特币,Corda 的UTXO模型不仅涵盖数字货币交易以及,还允许这些自定义数字资产在其范围内流通。
智能合约
在Corda系统中,一个交易涉及多个状态单元,这些状态单元通过引用特定的智能合约来实现其功能.在处理这些状态单元时,系统会依次激活相应的智能合约
Corda 智能合约主要验证交易数据,以保证其符合各项约束条件.
沙箱环境
Corda 基于新版本的 JVM 设计为沙箱环境，并实现了对引用编程语言中某些不确定特性的限制。此外，在生成合同比特码时进行了静态分析与重构优化，以优化性能指标如运行时间与内存使用量。Corda 支持使用 Kotlin 和 Java 开发合约为，并定义了一个适用于这两者的领域专用语言库
####隐私保护——Flow
该系统中的每一次交易仅限于参与方之间的共享与执行。每一次交易的数据通过点对点的方式直接传输至指定接收方。一个订单在其生命周期内需多次经过多个节点以完成整个传输过程。每个节点都需要完成确认与签名验证环节。
使用随机公钥隐藏了交易双方的真实身份
利用 Tear-offs 技术实现了对签名者仅展示交易的部分数据
Quorum
通过分门别类地对公有交易与私有交易进行处理,确保了交易与合约的隐私性,并采用Raft共识机制替代了以太坊的PoW共识系统。其中,公有交易作为全网共有的传统以太坊交易模式存在,而私有交易仅限于双方共同参与的情形。
####Quorum系统组成
- Qorum节点——主要负责处理合同事务并维持区块链及其相关状态数据。其中，公有的状态数据用于存储并记录所有公有交易的具体执行结果；而私有的则专注于处理并保存各自独有的交易记录。
- Constellation——主要负责加密、解密、存储以及完成点对点的数据传输任务。
交易流程
(1) Quorum节点从客户端接收私有交易，并明确指定每个接收方的公钥。
(2) Quorum节点将私有交易数据传输至对应的Constituents节点进行加密处理。
(3) Constituents节点生成对称密钥k，并使用该密钥对私有交易负载进行加密；随后分别使用每个接收方的公钥对密钥k进行加密；最后计算并存储私有交易负载数据的哈希值。
(4) Constituents节点将加密后的私有交易负载数据、其哈希值以及解密后的对称密钥k分发给所有接收方。
(5) 数据传输成功后,Constituents节点返回被加密的私有交易负载哈希值给对应的Quorum节点。
(6) Quorum节点将接收到的所有被加密的私有交易负载哈希值整合为一个以太坊交易记录，并通过P2P网络传播至所有Quorum节点。
(7) 该以太坊记录经过共识机制整合后包含在Quorum区块中；每当Quromoo节点执行该区块时,会根据区块中的负载信息向对应的Constituents请求原始未加密的私有交易数据。
(8) 根据Quromoo节点的需求,各个接收方Constituents基于自身公钥和相关密钥信息解密出原始未加密的私有交易数据。
(9) 各个接收方Constituents将解密得到的所有原始 private transactions 返回给对应的Quromoo节点；而非接收方则返回"NotARecipient"消息.
(10) 所有参与此事务的Quromoo节点将private transactions提交至智能合约运行区,智能合约将在每次执行private transaction操作时记录状态数据并存入private state database.
准入机制
仅限于获得授权的节点方能加入。
每个节点均配置了一个JSON格式的参数文件,该文件指定了所有具有Quorum权限的网络节点。
网络协议
基于 go-ethereum 的点对点传输机制，在 Quorum 节点间传播公有交易。当处理私有交易时，在 Quorum 中明确标识了接收方的公钥。因此, Constellation 通过 HTTPS 将私有交易直接传递给接收方对应的 Constellation,而未参与私有交易的节点无法接收任何此类交易。
共识机制
Quorum负责维护全局网络各节点之间的共识，并对公共状态数据进行同步管理；该系统还支持局域范围内的交易确认机制
区块链数据
Quorum 将系统中的交易划分为公有类交易和私有类交易，并分别为其设置相应的事务处理规则与数据存储区域
相对于公有交易,私人交易引入了一个可选参数 privateFor,它包含了一个多个接收者的公钥列表**并明确地表明该私有交易应仅发送给这些接收者。
特定类型的交易数据被存储在链外**(off-chain)**, 采用的是 constellation 技术。具体来说, 这些私有交易在其智能合约运行的结果被记录于 Quorum 节点上的隐私本地存储（PLS）中。
智能合约
Quorum 智能合约分为公有合约和私有合约,它们在编程实现上并无分别
公有合约被部署于每一个节点，并采用公有交易数据作为输入参数，在完成计算后将计算结果记录于公有状态数据库中
仅在与交易相关的参与者节点上运行的私有合约，基于私有交易数据作为输入，并将计算结果存储于私有状态数据库中。
受限于对私有状态数据访问的权限控制, Quorum 的公有合约为实现业务功能而被设计为无法直接调用对应的私有的合约为此受限. 在 Quorum 框架下, 私有的状态管理合约为实现业务功能而被设计为无法直接调用对应的公有的状态管理合约为此受限. 在 Quorum 框架下, 私有的状态管理合约为实现业务功能而被设计为无法直接调用对应的公有的状态管理合约为此受限.
沙箱环境
Quorum采用了以太坊定制化的EVM构建了一个沙箱环境，该EVM能够执行以太坊自定义编译后的字节码；这些字节码无法访问宿主机的网络系统、文件系统和其他进程，并且仅允许合约之间进行有限次数的交互。Quorum合约采用的是基于以太坊定制化的Solidity语言开发
隐私保护
为确保数据隐私安全,Qstrom平台为公有与私有交易各自采用了不同的交易流程与状态数据库,其中采用的是基于Constellation技术来完成私有交易中的加密解密过程、数据存储环节以及数据传输环节。
Constellation primarily consists of two core functionality modules: transaction management (TM) and enclave module.
交易管理主要实现了敏感信息（私有交易）的离线存储功能、采用哈希算法进行加密处理以确保私有交易安全访问、通过直接通信过程完成点对点的数据传输；同时将所有敏感信息通过加密机制传递给指定接收方;
- Enclave 负责私有交易负载的加解密
借助Constellation平台实现私有交易数据管理,未参与私有交易的节点无法接收、无法存储或执行私有交易,仅能获取包含该私有交易负载哈希值的加密数据.
其他企业级区块链
MultiChain
支持比特币生态系统，并且专注于数字资产相关应用场景。该平台能够迅速部署到 Windows、Linux 以及 macOS 等操作系统上。
Ripple
利用分布式账本构建了实时跨境支付网络, 该系统由ILP(interledger protocol)[19]协议完成了不同账本间的互联。
BigchainDB
该系统兼具良好的扩展性，并宣称既具备分布式数据库的高吞吐量、低延迟与大容量优势,也融合了区块链技术中的去中心化、不可篡改与资产传输特征,因而被定义为将区块链元素融入传统分布式数据库体系
该系统兼具良好的扩展性，并宣称既具备分布式数据库的高吞吐量、低延迟与大容量优势,也融合了区块链技术中的去中心化、不可篡改与资产传输特征,因而被定义为将区块链元素融入传统分布式数据库体系
BCOS
基于企业级架构的应用方案，在以太坊平台之上增加了身份认证模块、采用PBFT共识机制框架以及集成隐私保护功能，并率先在国内金融领域实现商业化应用，并获得了良好的实践效果。
研究挑战与趋势
吞吐量
- Fabric 其他技术指标表现优异，在主网测试中达到每秒约3500笔的处理能力（参考文献43）。该系统通过采用分布式账本存储技术实现了高并发数据一致性。
- 在完成每一笔交易前需确保所有参与方的数字签名与数据验证工作得以完成；此外基于拜占庭容错协议（BFT）设计的共识机制以及串行执行的智能合约也将对系统的吞吐能力产生影响。
- 实际部署中通过优化策略和系统参数设置能够有效提高其处理效率。
- 不同的应用场景下可能采用不同的协议栈版本或其他扩展方案来满足特定业务需求。
共识机制
- 当前,共识机制是整个系统性能的主要瓶颈
- 许多区块链平台声称拥有高性能的共识机制,但这些方案均未提供前提假设、数学模型以及形式化证明过程,因而其安全特性无法得到充分验证
- 企业级区块链平台无需自行开发 consensus 机制,可以直接采用通用解决方案
- 同一个 consensus 在不同的安全假设和可信环境下的表现各异;因此,企业级区块链平台必须支持可扩展的插件化、可配置的 consensus 服务架构
可扩展性
- 企业级区块链的主要节点主要负责管理与自身业务相关的交易数据,从而使得系统更容易提升其扩展能力.
- 相较于传统横向扩展策略依赖于增加节点数量以线性提升系统吞吐量和容量这一目标,当前的企业级区块链技术仍存在较大差距.因此,如何实现更加高效灵活地提升系统的扩展能力将是当前研究的重点.
隐私保护
- 隐私保护技术在区块链中的应用面临双重挑战：一方面需有效隐藏交易细节以保障隐私；另一方面则需确保交易的有效性能够得到验证.目前基于Fabric、Corda 与 Quorum平台实现的隐私保护方案均存在一定的技术缺陷
- Fabric 通道系统在仅两个交易者建立通道时所面临的开销问题较为突出；同时其排序服务需可读取所有参与通道交易的数据这一功能也存在明显不足
- Corda平台在处理每笔交易前都需要进行历史数据验证工作；这一流程不仅降低了交易处理效率还可能导致历史数据泄露风险
- Quorum私有状态数据仅限于内部节点访问无法被非参与者节点调用；这使得跨私有合约间的交易双花问题无法得到妥善解决
跨链
该协议致力于构建统一的跨链通信平台，并将其中心架构命名为中继链（relay chain），主要基于以太坊技术实现对各类平行链（parachain）的支持。每个平行链均代表一个独立的区块链生态系统，并通过中继链实现互联互通。该协议同时规划了扩展方向，并致力于使以太坊能够直接连接至任意区块链
Cosmos 致力于推进数字资产间的跨链交互 。该平台将各类区块链子网划分为功能区，并通过其核心网络上的智能交互协议（IBC），促进各个功能区间的互联互通。
Hyperledger Quilt 专注于开发多链支付功能。
不同类型的区块链平台在系统架构设计和交易数据处理模式上存在明显的不同之处；这些差异使得对跨链技术的研究变得更加复杂
评测系统
- 基于区块链的技术评测体系（基准评测系统）为用户提供多区块链平台间的性能对比分析，并能根据用户的实际需求优化配置；同时该体系还能帮助发现现有系统的潜在问题并提出优化方案。
Blockbench 是一个专注于评估企业级区块链系统的开源评测工具。它将区块链平台划分为共识层、数据模型层、智能合约执行层以及应用层，并提供了从宏观层面到微观层面的整体性能评估基准和分层性能评估基准。具体可以从吞吐量、延迟、可扩展性、容错性和安全性五个维度进行评估。
Hyperledger Caliper 是华为开发的主要用于blockchain 开源测评的工具。它通过灵活配置适配层来集成多种区块链平台，并基于一组预定义用例从吞吐量、延迟和资源利用率三个维度开展测评。
在实际应用中，
不同区块链平台的特点包括节点数量差异
，
共识机制的不同类型
，
交易模式及规模的不同
，
智能合约的功能复杂度不同以及测试用例差异等
，
这些都会对所展示出来的性能产生影响。
因此，
需要评测系统不仅具备多维度指标综合评价的能力
，
还需要深入了解blockchain平台的系统架构及其运作机制。
为了实现更为客观公正的测评结果
，
也需要制定一套被行业广泛认可的通用评测标准。
底层数据库
- 当前,企业级区块链底层数据库主要以NoSQL数据库为主,其核心功能是基于Key-Value的数据查询方式.然而,现有的技术人员对SQL查询更为熟悉,且现有的数据分析工具多基于SQL开发.为了满足企业级区块链应用的需求,亟需开发专门支持该技术栈的SQL查询工具.
- 尽管节点数量受限,但企业级区块链本质上仍属于弱中心化的架构.为了满足复杂的企业应用场景需求,这类系统更应具备高吞吐量、高并发能力以及丰富的查询功能.此外,权限控制和数据备份恢复机制也是不可或缺的特性.
智能合约
相较于公有链而言，在企业级区块链中业务逻辑更加复杂。这些复杂的功能与数据结构通常需要借助智能合约来实现，并且为了确保执行结果的一致性和智能合约语言的易用性这一双重目标的存在，则进一步提高了对智能合约语言设计的要求。因此，在设计智能合约语言时。
研究者应致力于构建智能化的形式化验证机制以便能够有效检测出存在于现有合同中的潜在漏洞[75]这一目标不仅有助于提升系统的安全性也将成为未来研究工作的主要方向。
在实际应用过程中随着系统功能的需求不断变化以及出现如Bug等修复问题时如何实现无需中断全网同步更新并保持状态数据的一致性和兼容性则成为了必须解决的关键问题。
可治理性
- 基于公私钥验证机制实现去中心化区块链系统的功能部署仍需投入繁重的手工配置任务;与此同时针对私钥存储和安全性问题也需要开发实用可靠的解决方案
- 该系统不依赖全局管理员进行管理而在动态升级和节点接入过程中需由联盟成员共同投票确认从而导致决策效率低下且响应迟缓
- 区块链技术追求高度自治的特点与其监管机构间的政策冲突日益明显如何平衡两者之间的冲突并满足相关法规要求成为一个重要的研究方向
可治理性
- 去中心化的区块链协议依赖于公钥和私钥验证机制的支持下仍需经历复杂的手动配置步骤。与此同时，在私钥的安全存储和防止丢失方面也需要开发出易于使用的解决方案。
- 去中心化的区块链架构不依赖全局管理员来控制网络运行。当软件进行自动升级或新节点自动加入网络时（即通过共识机制进行验证），这一特性反而会导致决策效率低下。
- 区块链技术追求去中心化与政府监管机构提出的合规性要求之间存在冲突。如何在实现技术创新的同时满足监管政策的需求，则是当前研究的重要课题。
[外链图片转存中…(img-WLjxdl54-1619362312485)]
[外链图片转存中…(img-s2fD6gnl-1619362312488)]