Note on Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

The original paper link on ArXiv: Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

Tips:关于常用术语node和peer的翻译,为了防止混淆,本文中node = 节点;peer = 对等点。

首先,Abstract部分介绍了Fabric的主要特点:

  1. 模块化(Modular):如基于模块化支持可插拔的共识协议等;
  2. 可扩展(Extensible):采用execute-order-validation结构,依据chaincode的背书策略,peer的某个子集并行模拟执行交易,由ordering service统一进行排序达成一致性(consistency),避开网络带宽限制,使得扩展peer和client不会过多影响系统性能;
  3. 支持使用通用编程语言来编写智能合约(Supports smart contracts written in for general programming language):如Golang、Java、Node.js
  4. 成员管理(Membership):是联盟链的本质(membership maintains the nature of permissioned blockchains),permissioned blockchain和public blockchain的核心区别在于identity,通过成员管理服务,来增强隐私性/机密性。

第一部分introduction给出了了区块链的定义、公有链(public blockchain)和联盟链(permissioned blockchain)的主要区别(加入方式、共识机制等),Public blockchain的主要特点:PoW、native cryptocurrency、no identity、economic incentives;然后总结了区块链上的智能合约与基于状态机复制的弹性应用(Resilient Applications with State Machine Replication)相比所具有的特点:

  1. 区块链上是多个智能合约应用同时运行;
  2. 智能合约应用可以被任何链上成员动态部署;
  3. 区块链上的智能合约应用代码是不可信的,甚至是恶意的;

然后介绍了当前区块链系统的order-execute结构,总结了当前区块链系统的几个主要缺点:

  1. 共识机制硬嵌在平台中,有one-size-fits-all的缺陷,即链上所有不同的智能合约,或者说业务逻辑,都使用同一种共识机制;
  2. 验证交易(transaction validation)的信任模型取决于共识协议,无法修改以满足特定智能合约的需求,即共识协议和信任模型高度耦合;
  3. 开发语言局限,基本是一些领域特定语言(domain specific language),同时开发受限也影响了区块链技术的推广和发展;
  4. 所有节点都要顺序执行任一笔交易,这种大量重复既浪费了计算资源,又限制了性能,并且需要补充复杂的措施来防止源于不可信合约的拒绝服务攻击(比如Ethereum通过对各种操作收取一定的“gas”来限制大量/长时间的操作,预防可能引发的拒绝服务攻击);
  5. 交易必须是确定的,但是从编程上来讲是很难保证的;
  6. 智能合约运行在所有节点上,破坏了隐私性/机密性。

然后该部分简要介绍了Fabric的创新性结构:execute-order-validation结构,该结构顾名思义,主要由三个阶段(phase)构成:

  1. 先由链上所有peers的一个子集执行交易(这个子集是背书对等点的集合,由特定chaincode的背书策略指定),检查正确性,之后这些背书对等点(endorsement peer)对交易进行背书,节省了计算资源,提高了隐私性/机密性;
  2. 通过共识协议对交易进行排序,这一步主要由排序节点(ordering node)来集中执行,节省了计算资源和网络带宽;
  3. 交易验证,由所有对等点(peer)根据特定chaincode指定的信任假设来进行验证。

然后介绍了Fabric的几个主要组件/服务:

  1. 排序服务(Ordering Service):通过原子广播“状态更新”到对等点来建立对于交易顺序的共识,进而达成一致性,该服务使用了Apache Kafka/ZooKeeper开源项目;
  2. 身份/成员管理(Identity and Membership):负责将对等点和加密身份连接起来,membership maintains the permissioned nature of Fabric;
  3. 可扩展传播(Scalable Dissemination):提供一个可选的P2P gossip service(翻译成“P2P交流服务”?)来将排序服务输出的区块分发到各个对等点;
  4. 智能合约执行(Smart Contract Execution):通过Docker容器来给智能合约提供隔离的运行环境,Fabric目前支持Golang、Java和Node.js等通用编程语言来编写智能合约;
  5. 账本维护(Ledger Maintenance):每个对等点都在其本地维护一个append-only的账本,并用一个键值仓库(Key Value Store,KVS)来保存最新状态的一个snapshot;

在第二部分Background先介绍了当前区块链系统的order-execute结构下的交易流及其局限,之后又介绍了两个更进一步的局限。

当前区块链系统的order-execute结构中,交易流(transaction flow,大概是指交易从发起到最后确认进入区块的全流程)主要分为三个步骤:

  1. 每个对等点收集可靠交易形成区块(block),为了建立交易的可靠性,该对等点需要预先执行一次这些交易;
  2. 每个对等点都努力去解决工作量证明问题(PoW puzzle);
  3. 某个幸运的对等点找到了工作量证明问题的一个答案,该对等点就将其形成的区块和该答案通过gossip service分发到其他对等点;
  4. 然后其他对等点就验证该工作量证明的答案和收到的区块中的所有交易,事实上,其他对等点会从第一步开始重复一次幸运对等点的所有操作。

当前区块链的order-execute结构的局限:

  1. 顺序执行(Sequential Execution):在所有对等点上顺序执行所有操作,限制了系统的吞吐性能,因为系统的吞吐性能和执行操作的时延呈负相关关系,这一局限就有可能被恶意智能合约利用来进行拒绝服务攻击,所以许多当前的区块链系统需要复杂的措施来进行预防,比如Ethereum的“gas”;
  2. 非确定性代码(Non-deterministic Code):待补充
  3. 执行操作的隐私性/机密性(Confidentiality of Execution):智能合约运行在所有节点上,破坏了隐私性/机密性。

当前结构的两个更进一步的局限:

  1. 限定的信任模型、不可变的信任模型:验证交易的信任模型取决于共识协议,无法修改以满足特定智能合约的需求,即共识协议和信任模型高度耦合;
  2. 硬嵌入的共识协议:共识机制硬嵌在平台中,有one-size-fits-all的缺陷,即链上所有不同的智能合约,或者说业务逻辑,都使用同一种共识机制。

第三部分Architecture介绍了Fabric的概览、execute-order-validate三阶段结构和交易流(transaction flow)。

从概览上,Fabric上的应用主要由两部分组成:

  1. 智能合约(chaincode),实现业务逻辑,在execute阶段运行,分为用于user-defined chaincode和system chaincode;
  2. 背书策略,用于在validate阶段进行评估;相关的背书步骤:交易被发送给背书策略指定的peer集合去执行,然后执行结果被记录下来,验证正确性并进行背书;背书之后,交易进入ordering阶段;

Fabric上的节点(Node)分为三种角色:客户端(client)、对等点(peer)和排序服务节点(ordering service node,OSN)

  1. 客户端(Client):发起操作的交易提案给背书对等点去执行,然后广播交易到OSN去排序;
  2. 对等点(Peer):其中的背书对等点子集执行交易提案(execute phase),所有的对等点都会验证交易(validate phase),每个对等点都在其本地维护一个完整的账本;
  3. 排序服务节点(OSN,Orderer):用于对执行过的交易进行排序,不关系交易的语义,只关注顺序/排序,负责形成共识达成一致性,有时候也会具有访问控制(access control)的作用;

下面分三阶段介绍execute-order-validate结构和交易流:

  1. Execution Phase:
    1. Transaction proposal;
    2. Endorsement peer simulation;
    3. PTM(peer transaction manager)和versioned key-value store(KVS);
    4. writeset and readset;
    5. endorsement;
    6. 设计考虑:
  2. Ordering Phase:
    1. 基本过程;
    2. broadcast(tx);
    3. B←deliver(s);
    4. Ensure safety properties:
      1. Agreement;
      2. Hashchain Integrity;
      3. No skipping;
      4. No creation;
      5. Validity;
    5. 设计考虑
  3. Validation Phase:
    1. Endorsement policy validation(VSCC);
    2. Read-write conflict check;
    3. Ledger update;

在第四部分Fabric Components介绍了Fabric的主要组件/服务:

  1. 成员管理服务(Membership Service):
  2. 排序服务(Ordering Service):
  3. 对等点交流(Peer Gossip):
  4. 账本(Ledger):
  5. 链码执行(Chaincode Execution):
    1. 账本区块仓库(Ledger Block Store):
    2. 对等点交易管理器(Peer Transaction Manager):
  6. 配置和系统链码(Configuration and System Chaincode):

Leave Comment

电子邮件地址不会被公开。 必填项已用*标注