hyperledger-overview

Hyperledger Fabric 是 IBM 贡献给 Linux 基金会的商用分布式账本系统，自项目创立伊始就吸引了金融、银行、互联网、传统行业领域的巨头们的眼光。

Hyperledger Fabric 是基于 Golang 实现的可插拔的区块链系统，它主要面向企业之间或者企业多个部门之间提供服务。

Architecture

  • Membership 即成员管理服务，提供身份管理、证书校验。在 Fabric 中每个通讯组件都必须提供身份证明，每个事务的发起者会被永久记录在区块链上，审核人员可以追溯事务。
  • Blockchain Services 即区块链服务，提供分布式一致性算法，维护全网数据一致，提供账本存储服务，基于 P2P 网络实现节点之间的通讯。
  • Chaincode Services 即链码服务，智能合约在 Fabric 中称为链码。链码是操作状态数据库的唯一方法，大部分事务都是通过链码完成的。该部分提供链码的部署和运行环境。

区块链

区块链是一种分布式多写的、防篡改的数据库

分布式多写

共识算法

多写一定要保证数据最终一致性；也搞清楚解决问题的办法——通过“固定的”规则决定顺序，节点中的所有服务器只要遵循这个规则那么数据最终一定一致。

拜占庭将军和 PBFT

拜占庭将军问题是要解决在一个消息可能丢失、重复、伪造的环境达到数据一致问题。

接下来看 Practical Byzantine Fault Tolerance（PBFT）算法，它的过程如下：

  1. 从全网节点选举出一个主节点，新区块由主节点负责生成。
  2. 每个节点把新交易向全网广播，主节点把从网络收集到需放在新区块内的多个交易排序后存入列表，并将该列表向全网广播。
  3. 每个节点接收到交易列表后，依据排序模拟执行交易。所有交易执行完后，基于交易结果计算新区块的哈希摘要，并向全网广播。
  4. 如果一个节点收到的 2f（f 为可容忍的恶意节点数）条其它节点发来的摘要都和自己相同，就向全网广播一条 commit 消息。
  5. 如果一个节点收到 2f+1 条 commit 消息， 即可正式提交新区块及其交易到本地的区块链和状态数据库。

PBFT只适合于内部使用（联盟链或者私有链），因为互联网上不太可能确定“全网排序节点”。

防篡改

Merkle Tree

所有的数据（事务）都放在二叉树的叶子节点，非叶子节点是其对应子节点的 Hash 值。当数据发生变化会引起非叶子节点的连环变化，最终引起 Root 的变化。

区块链的底层存储是一个链表，包括区块头和区块体。头部是一个链表结构，分别是前一块的 Hash 值、Merkle Root、本数据块的 Hash 值（Nonce)；区块体是一个树结构，叶子节点是事务（Tx），其他节点是下级节点的 Hash 值，最终树根的 Hash 值就叫 Merkle Root，放在头部。

Blocks

所以如果要篡改某个区块必须把该区块的所有前驱都给修改掉，修改比较麻烦——注意不是不能修改

对于比特币来说仅仅做到这一点是不够的，它毕竟是数字货币，利益诱惑比较大。所以比特币设计了两个门槛：

  • 最新的前驱节点（最新的数据块）不一定被篡改者算出来，除非计算能力特别强大；
  • 区块的 Hash 值是特殊的，PoW 中的“Hash 游戏”是寻找一种特别的 Hash 值，只能通过不断遍历才可能算出这个值，这也是“工作量”体现。所以重新计算 Hash 值相当于重新进行工作量计算，这个计算开销也非常巨大。相当于把整个链上的区块全部重新算一遍。

Hyperledger 和 Fabric

Hyperledger 是一个开放源代码的区块链和相关工具的总括项目，由 Linux 基金会管理。Fabric 是一个商用分布式账本，它最早由 IBM 和 Digital Asset 贡献给了 Hyperledger 项目。它主要用于“企业内部使用”，技术架构选择了和比特币、以太坊完全不同的策略。

Fabric 的共识设计

Fabric 被设计为一个数据存储系统，写入速度是一个非常重要的性能指标，所以不可能采用 PoW 算法。

共识就是要解决排序问题

Fabric 采用了一个很简单、粗暴，而又充满工程化考虑的设计方案——排序节点（PBFT 算法）。在整个网络中有一个或者一组节点充当排序节点，其他节点都按照排序节点给出的顺序进行数据写入，完整的过程如下图所示。

PBFT

应用程序首先向所有 Peer 节点（也有文档叫背书节点、记账节点）发起“记账要求”（Proposal）；每个节点把数据记录下来——此时还没有提交到状态数据库（没有生效），然后返回应用程序一个“事务签名”（Proposal Response）；应用程序把“事务签名”发送给排序服务器，排序服务器可能同时收到很多事务，按照一定规则给出事务的顺序，发送给记账节点；记账节点在收到排序服务器的顺序后会校验一下“事务签名”确定是自己给出的票然后更新状态数据库，数据生效。这个过程可以简单的归纳为投票 -> 排序 -> 验证。

排序服务器排序的规则有两种，SOLO 和 Kafka 。可以把 SOLO 机制理解为单机版的队列，排序服务器按收到的顺序依次放入队列。SOLO 的性能并不高，在开发环境中用这种机制，生产环境建议使用“真刀真枪的 MQ”——Kafka。

Fabric 的防篡改机制

比特币防篡改的机制是基于 PoW 精心设计的，如果要修改数据那么必须“算力足够”，所以比特币的一切都是围绕 PoW 设计，而设计目标则是——发币。对于没有采用 PoW 的 Fabric 来说防篡改机制必须另谋出路。

这个“出路”其实不是技术考虑，更多的是业务场景考虑。Fabric 主要面向内部使用（联盟链或者私有链）“内部环境”比较容易实现“审计机制”，我们可以通过 Fabric 的 Event 记录整个系统的运行过程，当数据不一致的时候通过“审计机制”发现谁的数据有问题（需要人工介入）然后把它“踢”出去。简单来说——Fabric 的防篡改是“人肉审计”机制。

Fabric 提供一个模块化的构架，其中的节点、智能合约、共识机制、成员服务都是模块化，可扩展的。如果开发者觉得 Fabric 的设计策略不适合，那么可以做相关的扩展开发。

Fabric 基本概念

  • Channel，一个“链”。可以理解为一个数据库。以太坊、比特币它们都属于“单链”，Fabric 可以同时运行多个链。
  • Chaincode，链码。区块链上的数据改变都是通过智能合约操作的，在 Fabric 中智能合约叫 ChainCode。
  • Fabric 网络，在 Fabric 中组成区块链系统的各个进程组成的通讯网络叫 Fabric 网络。
    Fabric 网络可以是由一个物理节点组成，也可以由多个不同的物理节点组成。一般在开发环境中运行在同一个物理节点上（开发者自己的机器），在生产环境中需要根据组织或者部门在不同的节点上启动相关进程。

Fabric 提供了各个平台的二进制文件，但是一般不直接使用这些二进制文件，而是通过容器的方式部署系统。

锚节点 Peer （Anchor peer）