Fabric 的交易流程如下图
发送交易前，应用程序需要向CA注册和登记，并获取到用于在网络中用确认身份的加密材料。
1. 发送提案
客户端使用SDK中的API生成一个交易提案。提案是带有确定输入参数的调用链码方法的请求，该请求的作用可能是读取或者更新账本。
SDK 的作用是将交易提案打包成合适的格式（gRPC 使用的 protocol buffer）以及根据用户的密钥对交易提案生成签名。
2. 背书交易
背书节点验证提案请求，通过后执行模拟执行交易并对结果进行签名背书。背书节点主要处理过程主要有：（1）校验交易提案的格式完整，（2）验证该交易提案之前没有被提交过（重放攻击保护），（3）验证签名是有效的（使用MSP），（4）验证发起者是已经被授权在该通道上执行该操作（也就是说，每个背书节点确保发起者满足通道 Writers 策略），（5）背书节点将交易提案输入作为调用的链码函数的参数。然后针对当前状态数据库执行链码，生成交易结果，包括响应值、读集和写集（即表示要创建或更新的资产的键值对）。模拟执行交易时还没有对账本进行更新。这些值，以及背书节点的签名，一起作为“提案响应”传递回SDK，应用程序调用SDK返回响应解析出来这些数据再后续使用。
MSP 是节点的组件，它允许 Peer 节点验证来自客户端的交易请求，并签署交易结果（即背书）。写入策略在通道创建时就会定义，用来确定哪些用户有权向该通道提交交易。
3. 检查提案响应
应用程序验证背书节点的签名，并比较多个提案响应，以确定提案响应是否相同。如果链码只查询账本，应用程序将检查查询响应，并且通常不会将交易提交给排序服务。如果客户端应用程序打算向排序服务提交交易以更新账本，则应用程序在提交之前需确定是否已满足指定的背书策略。如果应用程序选择不检查响应或以其他方式转发未背书的交易，背书策略仍将由节点强制执行，并在提交验证阶段遵守该策略。
4. 发送交易
如果只是查询账本的交易，则不需要再发送交易到排序节点排序，再由Peer节点进行提交到账本。客户端收集到足够的背书支持后可以利用背书构造一个合法的交易请求，发给Orderer进行排序。然后客户端可以通过事件机制来监听网络中的消息，获知交易是否被成功接收。
5. 交易排序
应用程序将交易提案和“交易消息”中的交易响应“广播”给排序服务。排序节点会为网络中所有合法交易进行全局排序，并将一批排序后的交易组合生成区块结构。排序服务不需检查交易的整个内容，它只是从网络中的所有通道接收交易，将它们按时间、按通道排序，并将每个通道的交易打包成区块。
6. 发送交易
Orderer节点将打包的区块发送到Peer（Committer）节点，通常Orderer发送区块到组织的锚节点中，锚节点再负责发送区块到组织内的其他Peer（Committer）节点。
7.验证和提交交易
交易区块被“发送”给通道上的所有 Peer 节点。对区块内的交易进行验证，以确保满足背书策略，并确保自交易执行生成读集以来，没有对读集变量的账本状态进行更改。块中的交易会被标记为有效或无效。验证通过后，每个 Peer 节点都将区块追加到通道的链上，对于每个有效的交易，写入集都提交到当前状态数据库。系统会发出一个事件，通知客户端应用程序本次交易（调用）已被不可更改地附加到链上，同时还会通知交易验证结果是有效还是无效。
