1、交易流程
- 客户端利用受支持的SDK(Golang、Java、Node、Python)提供的API构建交易提案请求，将交易事务提案打包成为一个正确的格式。交易提案包含如下要素：
①channelID:通道信息。
②chaincodelD:要调用的链码信息。
③timestamp:时间戳。
④sign:客户端的签名。⑤txPayload:提交的事务本身包含的内容，包含两项。
- operation:要调用的链码的函数及相应的参数。
- metadata:调用的相关属性。
2、在交易提案中使用用户的加密凭据为此事务提案生成唯一的签名，之后将事务提交给背书节点。其具体过程如下图所示。
3、背书节点对接收到的交易提案请求进行验证。
①交易提案格式是否正确；
②交易在之前并未提交过（重复性攻击保护）：
③提交交易提案的客户端签名是否有效(使用MSP):
④提交交易提案的请求者是否在该通道中有相应的执行权限。
验证通过后调用链码进行模拟执行，产生包括响应值、读集和写集的事务结果。对结果进行背书并响应给客户端。其过程如下图所示。
4、应用程序收集到足够的消息和背书签名之后，构建合法的交易请求并将交易请求广播给Order服务节点，如下图所示。
如果应用程序的请求仅仅是查询分类账本，则应用程序将检查查询响应信息，并且不会将事务提交给Ordering（排序）服务。
如果客户端应用程序的请求是更新分类账本数据，则会将事务提交给Ordering服务以继续下一步的操作，并且应用程序在提交事务之前检查确定请求是否已满足指定的认可策略
（即指定的背书节点都认可）。
5、交易请求被提交到Orderer节点，该事务将包含读/写集、背书签名和通道ID。Orderer节点接收到事务请求之后，并不需要检查交易中的具体数据，只是从网络中的所有通道接收交易，按时间顺序对它们进行排序，并创建交易区块，之后广播给同一通道内所有组织的Leader节点，如下图所示。
6、Leader节点：Leader节点对接收到的区块进行验证（交易消息结构是否正确、是否
重复、是否有足够的背书、读写集版本），通过验证后将结果写入本地的分类账本中，如下
图所示。
7、同步广播：Leader节点同步广播给组织内的其他节点（保证在同一通道内的）。在Hyperledger Fabric中，广播给其他节点默认为临近的3个节点。此广播数量可以通过配置进行修改。注意，跨组织广播则由组织内的锚节点负责。
8、分类账本更新：每个Peer节点将区块附加到区块链中，写集被提交到当前的状态数据库中，且对于每个有效的事务，发出一个事件，通知客户端应用程序事务（调用）已被不可变地附加到中，以及通知该事务是否已经过验证或为无效事务。