共计 3303 个字符，预计需要花费 9 分钟才能阅读完成。
fabric 作为目前世界上最为出名的联盟链开源我的项目，所波及的模块和概念很多，本文以交易作为一个切入点，通过剖析一笔交易从发送到最终上链所经验的各个环节，将 fabric 的外围模块串联起来，为接下来更为深刻的各个模块的源码剖析奠定根底。
1. 发送签名提案音讯到 Endorser 背书节点申请解决
Client 节点结构签名提案音讯 <font color=”blue”>(SignedProposal 类型)</font>，通过调用 Endorser 背书服务客户端的 <font color=”blue”>ProcessProposal() 接口 </font>，提交该音讯到 Endorser 背书节点，申请模仿执行交易提案并签名背书。
2. Endorser 背书节点模仿执行交易提案并签名背书 Endorser 背书
节点收到签名提案音讯之后，进行如下解决。
- 查看签名提案音讯的格局合法性与签名有效性，包含通道头部、签名头部、签名 域、交易 ID、音讯扩大域的 Chaincodeld 属性与 PayloadVisibility 可见性模式等；
- 查看提案音讯的创建者是否满足指定通道上的通道拜访权限，即 /Channel/ Application/Writers 写权限；
- 查看并启动链码容器以模仿执行交易提案，并将模仿执行后果临时保留在交易模拟器中，期待排序共识与交易验证，而不是间接更新到账本中。其中，<font color=”blue”> 交易模仿执行后果釆用状态数据读写集（读数据的键和版本、写数据的键值）记录交易造成的状态变更后果；</font>
- <font color=”blue”> 调用 ESCC 零碎链码对该提案音讯的模仿后果读写集等进行签名背书 </font>。
3. Endorser 背书节点向客户端返回提案响应音讯，并散发隐衷数据明文
Endorser 背书节点基于背书信息、模仿执行后果等结构提案响应音讯（ProposalResponse 类型），并回复给申请客户端。
目前，模仿执行后果读写集蕴含私有数据（包含公共数据与隐衷数据哈希值）与公有数据（或隐衷数据）。
其中，私有数据交由 0rderer 节点进行排序出块，再提交到账本区块 数据文件，并播送到该通道上的所有节点。
如果模仿执行后果中还存在无效的隐衷数据明文，则 <font color=”blue”>Endorser 背书节点通过 Gossip 音讯协定将隐衷数据发送给通道内受权的其余节点（由隐衷数据汇合配置的签名策略决定），交由 transient 隐衷数据存储对象临时保留到本地的 transient 隐衷数据库（LevelDB）, 并在提交账本时存储到隐衷数据库（LevelDB）, 同时清理 transient 隐衷数据库中的过期数据 </font>。
4. 解决提案响应音讯
Client 节点解析 Endorser 背书节点回复的提案响应音讯，获取背书后果并查看提案响应音讯状态的合法性，以判断是否收集到了 <font color=”blue”> 足够多的符合要求的背书签名信息 </font>。
5. 发送交易数据给 Orderer 服务节点申请排序
当收集到足够多数量的符合要求的 Endorser 背书签名之后（由背书策略决定），<font color=”blue”>Client 节点基于模仿执行后果、背书签名等结构非法的签名交易音讯（Envelope 类型），通过 Broadcast（）服务接口将该音讯提交给 Orderer 节点 </font>，申请交易排序解决。其中，配置交易消 息不须要通过 Endorser 节点解决。
6. Orderer 服务节点对交易进行排序并结构新区块
Orderer 排序节点 <font color=”blue”> 提供 Solo 类型（用于单节点测试）、Kafka 类型（反对 CFT 容错）等共识组件 </font>，对合乎通道解决要求的非法交易音讯（一般交易音讯、配置交易音讯等）进行排序并达成统一观点，并对一段时间内接管的一批交易音讯依照打包交易的岀块规定（出块周期 工夫、区块字节数限度、配置交易独自出块等）结构新区块，创立利用通道或更新通道配置同时提交账本。
7. Leader 主节点申请 Orderer 服务节点发送通道账本区块
<font color=”blue”>Leader 主节点通过 Deliver() 服务接口代表组织从 Orderer 节点申请通道账本上所有的区块数据，并通过 Gossip 音讯协定散发到组织内的其余 Peer 节点 </font>。如果申请的区块数据不 存在，则 Orderer 节点默认阻塞期待，直到指定区块创立实现并提交账本，再将该区块发送 给 Leader 主节点。
8. Committer 记账节点验证交易并提交账本
Committer 记账节点对区块与隐衷数据（明文）执行如下查看，并提交至本地账本。如果不存在隐衷数据明文，则跳过隐衷数据的相关检查与提交账本的步骤。
- 查看交易音讯格局的正确性、签名合法性、交易内容是否篡改、音讯头部的合法性等。
- <font color=”blue”> 调用 VSCC 零碎链码 </font>，验证收集的签名背书后果是否合乎指定的背书策略。
- 对模仿后果中私有数据（即区块数据，含有公共数据与隐衷数据哈希值）的 <font color=”blue”> 读写集执行 MVCC 查看 </font>，针对单个键查问、键范畴查问、隐衷数据哈希值三种状况，查看读数据版本与交易时的账本是否统一，即是否存在读写抵触，并将存在抵触的交易标记为有效交易。
- 验证模仿后果中隐衷数据的正确性，遍历区块中无效交易的隐衷数据读写集哈希值，取岀对应交易的原始隐衷数据读写集明文，从新计算其哈希值并对两者进行比拟。如果两者完全相同，则阐明该交易的隐衷数据是真实有效的。
- 保留所有的区块数据（即私有数据）到 <font color=”blue”> 区块数据文件 </font> 中，保留所有的公有数据（即隐衷数据）读写集到 <font color=”blue”> 隐衷数据库（LevelDB）</font> 中，建设区块索引信息到 <font color=”blue”> 区块索引数据库 </font>，将最新的无效交易数据（蕴含公共数据读写集、隐衷数据读写集、隐衷数据读写集哈希值）更新到 <font color=”blue”> 状态数据库 </font>，最初将区块数据中通过 Endorser 背书的无效交易数据同步到 <font color=”blue”> 历史数据库 </font>。同时，清理 <font color=”blue”>transient 隐衷数据库中 </font> 的过期数据。
9. Leader 主节点散发数据与状态同步
Leader 主节点基于 <font color=”blue”>Gossip 音讯协定 </font> 将区块数据散发到组织内的其余节点上。同时，<font color=”blue”> 节点之间通过反嫡算法等机制被动拉取缺失的数据 </font>（区块数据与隐衷数据）、节点身份信息等, 以确保组织内所有节点上的账本数据等信息放弃同步。
10. Committer 记账节点验证交易并提交账本（同步骤 8）
至此，Hyperledger Fabric 零碎上的一次残缺交易解决流程即告完结。
预报
从下一篇开始，咱们就要正式开启 fabric 源码剖析的专题了，本篇文章其实是一个常识筹备。这里多说一句，就是我为什么要开启这个 fabric 源码剖析的专题，其实这件事始终在我心中酝酿，然而因为前一段时间较忙，而且心田总是有一些否定的声音让我陷入自我狐疑，到底要不要做，因为当初网上曾经有很多对于 fabric 源码剖析的材料，而且品质也很高，为什么不间接抄“学霸”的作业呢，肯定要本人搞一遍，不累吗？其实我是这样想的，“一千个读者就有一千个哈姆雷特”。那么我可不可以这么了解，“一千个开发者就有一千个 fabric”。他人对于源码解读的文章都是基于其自己的常识架构下的，而如果咱们肯定要去灌输到本人的大脑中，可能会有些消化不良。而且咱们也不能一味的科学“权威”，学霸的作业也可能有疏漏的中央，他人的剖析都是通过二次加工的产物，带有强烈的主观主义色调，咱们还是应该忠于源码，摸索“属于我本人的 fabric”。好了，废话有点多，接下来就进入正题吧。