企业级区块链技术综述

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 同时维护着公有状态数据和私有状态数据:公有状态数据需要在全网所有节点间达成共识,私有状态数据仅需在交易参与者%E