（1）客户端应用程序发送交易请求（即提出议案proposal）
（1-1）客户端发出请求，根据背书策略把交易请求发给相应的peer节点（背书节点）。（Q：背书策略是在一开始就定义好的？）
（1-2）构建交易提案（proposal），客户端应用程序利用支持的SDK（Go, Java, Python）中的API生成proposal，提案是带有确定输入参数的调用链码方法的请求，该请求可能是读取或更新账本。
（1-3）SDK作用：1. 将交易提案打包成合适的格式（gRPC）；2. 根据用户的密钥对交易提案生成签名。
（2）背书节点验证签名并执行交易
（2-1）背书节点验证：1. 交易提案的格式是否正确；2.交易提案之前没有被提交过；3. 签名是有效的（使用MSP）；4. 请求发起者（即客户端）是否已经被授权在该通道上执行该操作（即，每个背书节点确保发起者满足通道 Writers 策略）。
（2-2）背书节点将交易提案输入作为调用的链码函数的参数。然后针对当前状态数据库执行链码，生成交易结果，包括响应值、读集和写集。（Q：怎么理解读集合写集）
（2-3）响应值以及背书节点签名作为“提案响应”传回给SDK，SDK为客户端应用程序解析“提案响应”中的信息。
（3）客户端应用程序检查“提案响应”
（3-1）客户端应用程序验证背书节点签名，比较多个“提案响应”，确定“提案响应”是否相同，当客户端收到足够数量的相同的“提案响应”后才会执行下一步。
（3-2）查询请求：客户端应用程序只查看响应结果，通常不会将交易提交给排序节点。
（3-3）更新请求：客户端应用程序先确定响应信息是否满足指定的背书策略；若满足，将交易提交给排序节点（Order）。
（4）排序服务进行排序并将交易封装成区块
（4-1）客户端应用程序将交易发送给排序服务（Order节点），交易包括读/写集，背书节点签名和Channel ID。
（4-2）排序服务从所有的channel中接收交易，利用排序算法（如solo，kafka等）按时间和通道进行排序，并将每个channel中的交易打包成区块。
（5）验证和提交交易
（5-1）排序节点（Order）将交易区块发送给channel上所有的peer节点（包括commit peer，endorsing peer等）。
（5-2）peer节点对区块内的交易进行验证：1. 确保满足背书策略；2. 确保自交易执行生成读集以来，没有对读集变量的账本状态进行更改。验证完之后对区块中的交易进行标记为：有效或无效。
（6）账本更新
（6-1）peer节点将区块添加到区块链上。
（6-2）peer节点将每个有效交易写入各自的账本中以及世界状态（world state）。
（6-3）系统会发出一个事件，通知客户端应用程序本次交易（调用）已被不可更改地附加到区块链上，同时还会通知交易验证结果是有效还是无效。