Hyperledger Fabric v1.0初学框架与transaction流程

该Blog内容针对HyperLedger Fabric V1.0的内容。

HyperLedger，超级账本,是被业界非常看到的联盟链的实现，由IBM主导，并贡献了巨量代码和开源，带给我们关于区块链技术与软件工业、金融、保险、物流等领域碰撞结合的想象空间.
Github : https://link.zhihu.comtarget=https%3A//github.com/hyperledger/fabric

---

Fabric v1.0整体框架

从图中可以看到，整体架构可以分为三个部分:

1. 成员管理服务：成员注册（Registration）、身份管理（Identity Management）、成员认证（Auditability）
2. 区块链服务：共识算法（Consensus Manager）、分布式账本（Distributed Ledger）、P2P协议（P2P Protocol）、账本存储（Ledger Storage）
3. 链码服务：安全容器（Secure Container）、安全注册（Secure Registry）

Fabric v1.0运行框架

下图是Fabric v0.6的运行框架：

从v0.6到v1.0框架更新的目的：

1. 分拆Peer的功能，将Blockchain的数据维护和共识服务进行分离，共识服务从Peer节点中完全分离出来，独立为Orderer节点提供共识服务，减轻了Peer节点的负荷；
2. 实现多通道的结构，实现了更为灵活的业务适应性（业务隔离、安全性等方面）
3. 支持更强的配置功能和策略管理功能，进一步增强系统的灵活性和适应性

---

再来关注核心概念内容：

一、PKI体系

PKI（Public Key Infrastructure），用于管理和颁发证书，在密码学领域属于比较基础的地位，是建立在公私钥基础上实现安全可靠传递消息和身份确认的一个通用框架。
一般情况下，PKI体系包括如下组件:

1）CA（Certification Authority）：负责证书的颁发，与证书的作废，收集来自RA的请求。（CA可以给自己颁发证书，来保证CA颁发证书的可靠性）

2）RA（Registration Authority）：接收用户注册申请，对用户身份进行验证，校验数据合法性，负责登记，审核通过则发消息给CA。

3）证书数据库：用户存放证书。标准：X.500系列

所以在成员服务中，成员注册是通过用户向RA登记，申请证书，RA通过后发送请求给CA，CA颁发证书给用户（CA同时给CA本身颁发证书以保证CA所颁发给用户的证书的可靠性）

另外在Fabric，V1.0中，还存在一些组件如下（部分列出）：

1）Transaction Certificate Authority（TCA）：负责在验证用户提供的注册凭证后发出交易证书

2）Transaction Certificates（TCerts）：TCerts是每个交易的短期证书。它们是由TCA根据授权的用户请求颁发的。此外，TCerts可以被配置为不携带用户身份的信息。它们使得用户不仅可以匿名地参与系统，还可以防止事务的可链接性

3）TLS Certificate Authority （TLS-CA）：负责颁发允许用户使用其网络的TLS（Transport LayerSecurity，传输层安全协议）证书和凭据。

4）TLS-Certificates（TLS-Certs）：TLS-Certs是用于系统和组件之间进行通信的证书。它们携带其所有者的身份，并用于网络级安全性。

Q：为什么要采用数字证书机制：
A：区块链采用非对称加密，具有公钥和公钥，理论上Anyone能够获取他人的公钥。证书机制的存在防止用户（恶意节点）伪造或者篡改公钥，以保证体系的安全性。

二、节点

在V1.0中，主要有以下几种节点：Peer节点、Order节点、CA节点、Client节点。

1）Peer节点：在v1.0版本后，Peer节点不在充当orderer的角色，它至少是一个Committer节点，为什么说是至少?因为Peer节点有的时候充当背书（Endorsement）节点。身为Committer节点，Peer负责验证从排序服务节点区块里面的交易，负责维护区块链的账本（ledger）和状态（state）等。
而交易请求需要时，会充当背书节点，打个比方，ABCD四个节点，当AB进行交易时，有背书请求时， AB又充当背书节点，而CD不是。

2）Order节点：Order节点接收含有背书签名的交易请求，进行排序操作后，打包生成区块，并且广播给Peer节点。需要注意的是，由于多链的原因，Order节点，只会广播给用一个Channel的节点，由此实现了数据隔离。（实际上，由于Peer节点众多，Order节点会广播给Leader Peer，再由Leader Peer通过P2P同步）

3）CA节点：CA（Certificate Authority），是证书颁发机构，上图v1.0运行框架中， Membership 又是 fabric-ca。
它主要用户接收客户端的注册请求，并颁发证书（或者用于废除证书）

4）Client节点：用户操作的实体。发送请求到背书节点，或者将含有背书的请求发送给Order节点。

---

三、链与通道

Fabric的保密性和安全性可以体现在多链和多通道中。

链（Chain）：将Peer节点、Ledger账本、Order节点包含在一起的逻辑结构，它使得不在当前链中的节点隔离，满足了不同情况下的数据访问需要。
值得注意的是：同一个Peer节点可以参与到多个链中。

如下图，既有三条链：

通道（Channel）：通道是共识服务提供的通信机制，与Peer节点，类似于发布与订阅的关系。由此形成和Peer节点的链路（假象），实现了隔离。如下图所示：

图中可以表示成如下形式{（P1,PN）,（P1,P2,P3）,（P2,P3）}

---

四、共识服务

共识服务是Order节点汇聚形成的，Order节点为Peer节点提供了共享的通道，并且具有广播的功能。在Fabric V1.0版本中，提供一下几种共识算法：

1）Solo：单节点共识机制，Peer节点通过gPRC连接到Order节点，Order将收到的消息生成区块，存入账本，随后Peer通过接口从Order中Ledger获取区块。
由于是单节点共识，并不适合实际的实际Fabric 网络。多用于测试

2）kafka:分布式队列共识机制，Peer（客户端）Peer节点通过gPRC连接到Order节点，发送消息，Order通过Recv接口接收Peer发送过来的消息，并将消息推送到Kafka。同时与Kafka相连接的Order通过Consumer，实例消费Kafka上的消息，将消费的消息进行同一排序，排序完成后，当达到生成区块（Block）的条件（条件有两个1：下一数据块定时器到期，定时器通过向Order向Kafka发送定时器消息，再通过Kafka消费来达到定时效果。2：每消费一条真实数据，就触发判断是否达到生成一个新的区块条件，该条件由当前待生成区块的数据总的大小以及记录数决定），并创建新的区块），创建成功则将区块写入ledger。

3)PBFT:拜占庭容错共识机制，它一共可以分为以下五个阶段：

1. 请求（Request）：客户端节点发送请求到主节点。
2. 预准备（pre-prepare）：主节点收到客户端请求，给请求编号，并发送pre-prepare的信息给其他从节点。从节点收到re-prepare的信息，如果同意该请求，就进入prepare阶段，否则返回。
3. 准备（prepare）：从节点发送该请求的编号，以prepare的信息到其他从节点，不同意或者宕机则不发送。从节点收到其他节点来发的足够的prepare消息，则进入prepared状态，拥有一个prepared认证证书。
4. 提交（commit）：进入prepared状态的从节点，发送一条commit类型信息给其它所有节点，存在一个prepared认证证书，若某个节点收到了大于等于2f+1条commit消息，则表示该节点进入committed状态。（f为错误节点数量）进入committed节点会执行请求，并且认为其他节点同意了请求！（容错）
5. 回复（reply）：节点给与客户端反馈。

步骤可以表示成下图：

考虑一下两个问题：
Q1：为什么要共识？
A：由于区块链是一个分布式账本，保证分布节点内容的一致性是关键，要满足一致性，就要采用一定的共识算法。另外一方面，共识算法解决了某个提案，大家一致意见的过程。
Q2:共识算法的优劣性？
A：共识算法有许多，诸如PoW,PoS、PBFT等。
以比特币网络的PoW为例，放宽最终一致性的需求，并且约定以最长的链拓展，需要矿工不停的挖矿，浪费许多资源、算力、电力等，并且更新频率在约10分钟/次，不符合目前的交易数据量，但另一方面，若有人想破坏这个平衡，必须掌握51%以上的算力，代价大。
在比较PBFT，它有一定的容错办法，能够检查宕机和恶意的节点，交易频率高，但是通信次数繁多（O（n）=N²），并且，受到节点数量的限制

---

Fabric v1.0交易流程

以下即为Fabric v1.0交易流程的示意图：

交易可以分以下几个步骤：

1. 客户端向背书节点发送一个提案（proposal）
2. 背书节点验证客户端签名，模拟交易步骤，构建读写操作集合，并且进行背书签名
3. 背书节点返回提案请求的结果给客户端
4. 当客户端收集了足够多的背书签名，将交易提案和结果传给共识服务
5. 共识服务进行排序，交易完成，生成区块后，将会以广播的形式传送给该通道内所有的节点
6. 所有节点（Commit Peer）验证每个交易并且记入账本，写入数据库。

欢迎纠错、指正和补充。