Michael.W谈hyperledger Fabric第15期-Fabric的交易流程和共识机制详解补充

1 前言

这几天在网上又看了一些资料，对Fabric整个的交易流程和共识机制有了更深一层的了解！在这里我再补充说明一下。
之前我写过一个关于Fabric的系统结构的帖子：
Michael.W谈hyperledger Fabric第3期-关于Fabric你所需要知道的基本知识二
如果不了解Fabric交易流程的朋友可以去那里看看。

2 关于Fabric交易流程的补充

1. 智能合约在初始化的时候必须指定背书节点。如果一个智能合约要求至少要有两个背书节点进行背书，那我们客户端至少要发送交易提案到两个背书节点。如果因为网络等原因，一直没有收到背书节点的返回数据，那么客户端要将提案发送给第三个背书节点。
2. 所有的背书节点返回的交易结果应该是一样的，除了各自的签名不一样。
3. 背书节点在接到交易提案时，首先要做验证，比如对交易提案的格式的验证、该交易以前是否被提交过、交易发送者的签名是否正确以及该发送者是否有权利去提交这笔交易等。如果验证通过后，背书节点会将交易发送给智能合约进行隔离执行。执行完会返回一个执行结果，背书节点并对这个返回结果进行签名（即背书），然后返回给应用程序（客户端）。
   注意上面的操作都是模拟交易，并不会产生任何持久化操作。
4. 当客户端收到背书节点返回的结果时，会进行验证。验证都通过后再进行后续操作。这个交易会有两种处理结果：
   • 如果该交易是一个查询交易（读账本操作），只要验证签名已通过，客户端就会拿着返回值做下一步业务逻辑判断的依据。可能会导致下一个交易的产生，此次交易结束。
   • 如果该交易是一个写账本交易，客户端必须收到足够多的背书结果，然后将交易提案、背书结果和自己的签名组合起来成为一个交易，然后发送给排序节点进行排序。
5. 排序节点并不会去读取交易的内容来检查是否背书结果都一致。它只会接收网络中所有的交易然后按照规定好的排序逻辑进行排序。然后打包，广播给各个组织的主节点。主节点接到区块后，会验证这笔交易是否有效。如果无效会被标记成无效交易，并存储到区块账本里面，但是并不会更新状态数据库。所以，无效交易只会浪费磁盘空间，后续版本应该可以改进为过滤到无效交易。
6. 之后就是在组织内部进行区块同步，以及在记账节点保存区块（在同组织内的其他peer节点上）、更新世界状态（在同组织内的其他peer节点上）。

3 orderer节点排序

共识机制在狭义上就是指Fabric中对交易的排序。
就像在前面帖子中讲到的，orderer节点接收到客户端发过来的模拟交易结果，然后是调用排序服务器进行对数据的排序，而不是orderer节点自己来完成数据排序的工作。
orderer节点的工作主要有以下三类：

3.1 调用排序服务器对数据进行排序

对交易数据排序的最终目的是保证Fabric中交易顺序的一致性。
这里要引进一个概念：有限状态机。
什么是有限状态机呢？
有限状态机指：如果一个系统从最初始的状态开始，如果每一状态改变条件都一致的话，它一定会得到一个一致的结果。
区块链中每个节点都是独立的，那怎么保证每个节点记出来的账都是一致的呢？
首先要保证交易的顺序。顺序一致，状态机的改变条件才会一致，才能保证得到相同的结果。

3.2 数据区块的分发

排序节点产生的区块，并非是每一个记账节点本地存储的区块（未必都会被提交节点最终写入到账本中）。只是一个中间状态区块，里面包含了有效和无效的交易。
在最后记账时还是会引用该临时区块的一些属性，如区块哈希和区块高度等。

3.3 多通道隔离

多通道隔离是Fabric最引人注目的一个功能。
扒一张网上的图，依然对作图的大神致以最真诚的感谢！这张图就非常形象地描述了多通道隔离的状态逻辑。

• 客户端在提交交易时会指定一个通道，表明该交易是发往哪一个通道的。排序节点收到该交易时会按照通道进行拆分。差分后再进行排序，也就是排序不是全局排序。然后分别组装成区块后，分别发往主节点。
• 多通道数据隔离这个功能，我们可以对比为一个发布-订阅模型。可以为一组业务逻辑创建一个通道，各个组织的节点都可以订阅这个通道，任何发往该通道的交易最终都会发往该节点。
• 通道之间是隔离的，他们不会知道彼此的存在。但，每个组织的节点可以订阅多个通道。

ps:
本人热爱图灵，热爱中本聪，热爱V神，热爱一切被梨花照过的姑娘。
以下是我个人的公众号，如果有技术问题可以关注我的公众号来跟我交流。
同时我也会在这个公众号上每周更新我的原创文章，喜欢的小伙伴或者老伙计可以支持一下！
如果需要转发，麻烦注明作者。十分感谢！

公众号名称：后现代泼痞浪漫主义奠基人