本文讲解在一个标准的资产交换中的交易机制。该场景包含两个客户端 A 和 B，他们分别代表萝卜的买方和卖方。他们在网络上都有一个 Peer 节点，他们通过该节点来发送交易和与账本交互。
一、假设
该流程中，假设已经设置了一个通道，并且该通道正常运行。应用程序的用户已经使用组织的 CA 注册和登记完成，并且拿到了用于在网络中用确认身份的加密材料。
链码（包含了萝卜商店初始状态的键值对）已经安装在 Peer 节点上并在通道上完成了实例化。链码中的逻辑定义了萝卜的交易和定价规则。链码也设置了一个背书策略，该策略是每一笔交易都必须被 peerA 和 peerB 都签名。
二、交易流程
以下是我对Fabric交易流程的理解：
（一）提案（Proposal）阶段
- 客户端（Client A）创建一个交易提案（Proposal），提案是带有确定输入参数的调用链码方法的请求，该请求的作用是读取或者更新账本。
- 客户端通过SDK将交易提案打包成合适的格式（gRPC 使用的 protocol buffer）以及根据用户的密钥对交易提案生成签名，并将提案发送给指定的对等节点（Peers）。
（二）背书（Endorser）阶段
- 对等节点验证：
- 交易提案的格式完整
- 且验证该交易提案之前没有被提交过（重放攻击保护，如何验证？）
- 验证签名是有效的（使用 MSP，MSP 是节点的组件，它允许 Peer 节点验证来自客户端的交易请求，并签署交易结果（即背书））
- 验证发起者（在这个例子中是客户端 A）有权在该通道上执行该操作（也就是说，每个对等节点确保发起者满足通道 Writers 策略）
- 对等节点将交易提案输入作为调用的链码函数的参数。然后根据当前状态数据库执行链码，生成交易结果，包括响应值、读集（Read Set）和写集（Write Set，即表示要创建或更新的资产的键值对）。目前没有对账本进行更新。这些值以及对等节点的签名会一起作为“提案响应（Proposal Response）”返回到 SDK，SDK 会为应用程序解析该响应。
（三）提案响应（Proposal Response）阶段
- 检查提案响应：SDK验证对等节点的签名，并比较这些提案响应，以确定其是否相同。
- 如果链码只查询账本，SDK将检查查询响应，并且通常不会将交易提交给排序服务。
- 如果客户端应用程序打算向排序服务提交交易以更新账本，则SDK在提交之前需确定是否已满足指定的背书策略（即 peerA 和 peerB 都要背书）
（四）交易提交（Transaction Submission）阶段
- SDK将背书结果封装进交易发送给订购服务节点（Ordering Service Node）。交易会包含读写集，对等节点的签名和通道 ID。
- 订购服务节点对交易进行排序和打包，并将其打包结果形成一个区块（Block）。排序服务不需要为了执行其操作而检查交易的整个内容，它只是从网络中的所有通道接收交易，将它们按时间按通道排序，并将每个通道的交易打包成区块。区块包含了已排序的交易，以及其他相关的信息，例如前一个区块的哈希值和时间戳。
- 订购服务节点将新区块广播给网络中的所有的Peer节点。
（五）区块验证和提交（Block Validation and Commitment）阶段
- Peer节点接收到新区块后，验证区块中的交易的正确性和合法性，以确保满足背书策略。
- 并确保自交易执行生成读集以来，读集中变量的账本状态没有变化。块中的交易会被标记为有效或无效。
（六）账本更新（Ledger Updated）阶段
- 每个 Peer 节点都将区块追加到通道的链上，对于每个有效的交易，写集都提交到当前状态数据库。
- 系统会发出一个事件，通知SDK本次交易（调用）已被不可更改地附加到链上，同时还会通知交易验证结果是有效还是无效。
通过以上的流程，Hyperledger Fabric实现了交易的安全性和可靠性。通过对等节点的参与，确保了交易的正确性和一致性。同时，通过订购服务节点的排序和打包，确保了交易的顺序和可扩展性。整个交易流程是可扩展、可扩展和高效的，适用于各种企业级区块链应用场景。
