Hyperledger Fabric共识机制

原文地址：https://zhuanlan.zhihu.com/p/25358777

共识

交易必须按照发生的顺序写入分类帐，尽管它们可能位于网络中不同的参与者组之间。为了实现这一点，必须建立交易的顺序，并且必须建立一种拒绝错误（或恶意）插入分类帐的坏交易的方法。

在分布式分类帐技术中，共识最近已成为单一功能中特定算法的代名词。然而，共识不仅仅是简单地同意交易顺序，而是通过在整个交易流程中的基本作用，从提案和认可到订购，验证和承诺，在Hyperledger Fabric中强调了这种差异化。简而言之，共识被定义为对包含块的一组交易的正确性的全面验证。

当块的交易的顺序和结果符合明确的政策标准检查时，最终达成共识。这些制衡是在交易的生命周期内进行的，包括使用认可政策来规定哪些特定成员必须认可某一交易类，以及系统链式代码，以确保执行和维护这些政策。在承诺之前，同行将采用这些系统链码来确保有足够的认可，而且它们是从适当的实体派生出来的。此外，在分类帐的当前状态被同意或同意之前，在包含交易的任何块附加到分类帐之前，将进行版本控制。

除了发生的众多认可，有效性和版本检查之外，还有在交易流程的所有方向上进行的持续身份验证。访问控制列表在网络的层次层次上实现（从订单服务到通道），并且随着事务提议通过不同架构组件，有效负载被重复签名，验证和验证。总而言之，协商一致意见不仅仅局限于一批交易的商定订单，而是作为在交易从提案到承诺的过程中进行的正在进行的验证的副产品而实现的总体表征。

Hyperledger Fabric共识机制，目前包括SOLO，Kafka，以及未来可能要使用的PBFT（实践拜占庭容错）、SBFT（简化拜占庭容错）

SOLO
SOLO机制是一个非常容易部署的非生产环境的共识排序节点。它由一个为所有客户服务的单一节点组成，所以不需要“共识”，因为有一个中央权威机构。相应地没有高可用性或可扩展性。这使得独立开发和测试很理想，但不适合生产环境部署。order-solo模式作为单节点通信模式，所有从peer收到的消息都在本节点进行排序与生成数据块，详细流程见下图：

order-solo过程分析：

Peer（客户端）通过GRPC发起通信，与Orderer连接成功之后，便可以向Orderer发送消息。Orderer通过Recv接口接收Peer发送过来的消息，Orderer将接收到的消息生成数据块，并将数据块存入ledger，peer通过deliver接口从orderer中的ledger获取数据块。

Kafka

利用kafka排序功能实现共识

PBFT

SBFT