1. 提交交易预案
1）应用端首先构建交易的预案，预案的作用是调用通道中的链码来读取或者写入账本的数据。应用端使用 Fabric 的 SDK 打包交易预案，并使用用户的私钥对预案进行签名。
应用打包完交易预案后，接着把预案提交给通道中的背书节点。通道的背书策略定义了哪些节点背书后交易才能有效，应用端根据背书策略选择相应的背书节点，并向它们提交交易预案。
2. 背书节点处理
2）背书节点收到交易预案后，首先校验交易的签名是否合法，然后根据签名者的身份，确认其是否具有权限进行相关交易。此外，背书节点还需要检查交易预案的格式是否正确以及是否之前提交过（防止重放攻击）。
在所有合法性校验通过后，背书节点按照交易预案，调用链码。链码执行时，读取的数据（键值对）是节点中本地的状态数据库。需要指出的是，链码在背书节点中是模拟执行，即对数据库的写操作并不会对账本作改变，所有的写操作将归总到一个写入的集合（ Write Set ）中记录下来。
在链码执行完成之后，将返回链码读取过的数据集（ Read Set ）和链码写入的数据集（ Write Set ）。读集和写集将在确认节点中用于确定交易是否最终写入账本。
3. 返回响应结果
3）背书节点把链码模拟执行后得到的读写集（ Read-Write Set ）等信息签名后发回给预案提交方（应用端）。
4.发送排序节点
4）应用端在收到背书响应之后，检查背书节点的签名和比较不同节点背书的结果是否一致。如果预案是查询账本的请求，则应用端无需提交交易给排序节点。如果是更新账本的请求，应用端在收集到满足背书策略的背书响应数量之后，把背书预案中得到的读写集、所有背书节点的签名和通道号发给排序节点。
5.排序节点处理
5）排序节点在收到各个节点发来的交易后，并不检查交易的全部内容，而是按照交易中的通道号对交易分类排序，然后把相同通道的交易打包成数据块（ blob ）。
6.发送交易区块
6）排序节点把打包好的数据块广播给通道中所有的成员。数据块的广播有两种触发条件，一种是当通道的交易数量达到某个预设的阈值，另一种是在交易数量没有超过阈值但距离上次广播的时间超过某个特定阈值，也可触发广播数据块。两种方式相结合，使得排序过的交易可以及时广播出去。
7.检验区块交易
7）确认节点收到排序节点发来的交易数据块后，逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调用 VSCC（ Validation System Chaincode ）的系统链码检验交易的背书签名是否合法，以及背书的数量是否满足背书策略的要求。接下来进行多版本并发控制 MVCC 的检查，即校验交易的读集（Read Set）是否和当前账本中的版本一致（即没有变化）。如果没有改变，说明交易写集（Write Set）中对数据的修改有效，把该交易标注为有效，交易的写集更新到状态数据库中。
如果当前账本的数据和读集版本不一致，则该交易被标注为无效，不更新状态数据库。数据块中的交易数据在标注成“有效”或“无效”后封装成区块（block）写入账本的区块链中。
上述的交易流程中，采用了 MVCC 的乐观锁（ optimistic locking ）模型，提高了系统的并发能力。需要注意的是，MVCC 也带来了一些局限性。例如，在同一个区块中若有两个交易先后对某个数据项做更新，顺序在后的交易将失败，因为它的读集版本和当前数据项版本已经不一致（因为之前的交易更新了数据）。