Hyperledger Fabric 示意图

作者: 简闻 | 来源:发表于2017-04-07 10:49 被阅读2772次

谢谢大家不断的为这篇文章点赞。从 3 月份开始专注于区块链开发，那时国内基本没有区块链的相关内容，科学上网还是必备技能，一点一点积累和开拓吧。现在国内有很多的各种链，大大小小的组织和会议，应该有很多的『新人』在做区块链了，我后面会为每一幅图解加一些文字解释，希望可以帮助到大家。如果有不对的地方大家也可以留言。

1. fabric-ca.png

fabric-ca.png

有两种方式与 Fabric CA 服务端交互：通过 Fabric CA 客户端，或者 Fabric SDK，所有与 Fabric CA 的交互都是通过 REST APIs 来实现的。REST APIs 的 swagger 说明文档见 fabric-ca/swagger/swagger-fabric-ca.json

swagger/swagger-fabric-ca.json APIs 的文档.

Fabric CA 客户端或者 SDK 可能会连接到 Fabric CA 集群中某一个 Fabric CA 服务端，这一部分可以通过上图右上部分获得更好的理解。客户端连接的是一个 HA 代理节点，这个 HA 代理节点为 Fabric CA 集群作负载均衡。所有的 Fabric CA 服务端共享同一个数据库。数据库用来保存用户和证书信息。如果配置了 LDAP，那么用户信息将会保存在 LDAP 中，而不是数据库中。

2. fabric-ca 运行时流程图.png

fabric-ca 运行时流程图.png

3. 两个不同的chaincode并行进行背书和共识处理的过程.png

两个不同的chaincode并行进行背书和共识处理的过程.png

4. transaction flow.png 这张图在文档中已经做了修改请看图36

transaction flow.png

该流程图对应的交易处理步骤如下：
1、Client发起交易，这个场景下的Client是通过Submitting Peer代理和其他Peer以及交易共识排序系统交互的，Client的接入合法性可由Submitting Peer来控制。主要看系统是如何设计的；
2、Submitting Peer按照背书策略，继续发送交易给其他节点（Endorsing Peer）,模拟执行智能合约（Chain Code），暂存合约执行结果（Key-Value读写集），但执行结果不会真正更新到本地账本和Key-Value 状态数据库中；
3、Endorsing Peer验证交易签名，验证读写集版本依赖关系是否有效，并将结果发送给Submitting Peer；
4、Submitting Peer收集Endorsing Peer的签名的执行结果和交易数据，发送到共识排序服务（Consensus Service，又称Ordering Service）；
5、共识排序系统按特定的共识算法将多笔交易排序打包成区块，并将区块递交给同一通道内的全部Peer；
6、接收到区块的全部Peer检查验证区块里的每一笔交易，比对模拟执行读写集结果，根据比对结果设置交易是否生效，设定好标记，并更新本地账本和状态数据库，这时，交易才真正反映到区块链上；
7、补充一个步骤，图中没有画出来，Submitting Peer需将交易是否执行成功等信息反馈给Client,或者Client可以通过调用SDK接收Fabric“事件”（event）得知交易执行结果。