典型交易流程

假定各个节点已经颁发好了证书，且已经正常启动，并加入到了创建好的通道中，下图是一个典型的交易流程。

现在介绍已经实例化了的链码通道上发起一个调用交易到最终记账的全过程。

创建交易提案并发送给背书节点

使用应用程序构造交易提案，SignedProposal的结构如下所示：


上述结构是这样的：
SignedProposal是封装了Proposal的结构，添加了调用者的签名信息。背书节点会根据签名信息验证其是否是一个有效的消息。Proposal由两部分组成：

• 消息头：
  • 通道头（ChannelHeader）
    通道头包含了与通道和链码调用相关的信息。（如：在哪个通道上调用哪个版本的链码）TxId是应用程序本地生成的交易号，跟调用者的身份证书相关，可以避免交易号的冲突。背书节点和记账节点都会校验是否存在重复交易。
  • 签名头（SignatureHeader）
    签名头包含了调用者的身份证书和一个随机数，用于消息的有效性校验。应用程序构造好交易提案请求后，选择背书节点执行并进行背书签名。背书节点是链码背书策略里指定的节点（有一些背书节点是离线的，其他背书节点可以拒绝对交易进行背书，也可以不背书）。应用程序以何种顺序给背书节点发送背书请求是没有关系的，正常情况下背书节点执行后的结果是一致的，只有背书节点对结果的签名不一样。
• 消息结构（以后再做讨论）

背书节点模拟交易并生成背书签名

背书节点在收到交易提案后会进行一些验证，包括：

• 交易提案的格式是否正确
• 交易是否提交过（重复攻击保护）
• 交易签名有效（通过MSP）
• 交易提案的提交者在当前通道上是否已授权有写权限

验证通过后，“背书节点”会根据“当前账本数据” 模拟“执行链码中的业务逻辑” 并生成 “读写集（RwSet）”，其中包含“响应值”，“读写集” 等。在模拟执行时账本数据不会更新，背书节点对这些读写集进行签名成为“提案响应”（Proposal Response），然后返回给应用程序。

ProposalResponse结构如下：

收集交易的背书

应用程序收到ProposalResponse后对背书节点签名进行验证 （所有节点收到任何消息后都要先验证消息合法性）。若链码只进行账本查询，应用程序会检查查询响应，但不会将交易提交给排序服务节点；若链码对账本进行Invoke操作，则需提交交易给排序服务进行账本更新，应用程序会在提交前判断背书策略是否满足，如果没有收集到足够的背书就提交交易了，记账节点在提交验证阶段会发现交易不能满足背书策略，标记为无效交易。

构造交易请求并发送给排序服务节点

应用程序收到所有背书节点签名后，会根据背书签名调用SDK生成交易，广播给排序服务节点。生成交易过程较简单：先确认所有背书节点的执行结果完全一致，再交易提案，提案响应，背书签名打包生成“交易”。

交易结构如下所示：

排序服务节点对交易进行排序并生成区块

排序服务不读取交易内容，若在生成交易信封内容时伪造了交易模拟执行的结果，排序服务节点也不会发现，但会在最终交易验证阶段校验出来并标记为无效。
排序服务要做的很简单：

1. 接收网络中所有通道发出的交易信息
2. 读取交易信封Envelope.Payload.Header,.ChannelHeader.Channelid以获取通道名称
3. 按各个通道上交易的接收时间顺序对交易信息进行排序，生成区块

排序服务节点以广播给组织的主节点

排序服务节点生成区块后会广播给通道上不同组织的主节点。

记账节点验证区块内容并写入区块

背书节点是动态角色，只要参与交易的背书就是背书节点。哪些交易选择哪些节点作为背书节点是由应用程序选择的，这需要满足背书策略才能生效。所有背书节点都属于记账节点。所有peer节点都是记账节点，记录的是节点已加入通道的账本数据。

记账节点接收到的是“排序服务节点生成的区块”，验证区块交易的有效性，提交到本地账本后再产生一个生成区块的事件，监听区块事件的应用程序可以进行后续的处理
。

记账节点处理流程如图所示：

交易数据的验证

区块数据的验证是以“交易验证”为单位，每次对区块进行验证时都会生成一个交易号的位图TxValidationFlags，它记录每个交易号的交易验证状态，只有状态为TxValidationCode_VALID才有效。位图也会写入到区块的元数据BlockMetadataIndex_TRANSACTIONS_FILTER中。

交易验证会检查如下内容：

• 是否为合法的交易：交易格式是否正确，是否有合法签名，交易内容是否被篡改。
• 记账节点是否加入了这个通道

上述基本验证通过后，提交给VSCC进行背书策略验证。

记账节点与VSCC

链码的交易是隔离的，每个交易的模拟执行结果集TxRwSet都包含了交易所属的链码。为了避免错误地更新链码交易数据，在交易提交给系统链码VSCC验证交易内容前，还会对链码进行校验。以下交易都是非法的：

基于状态数据的验证和MVCC检查

交易通过VSCC检查后，进入“记账流程”。kvledger还会对读写集TxRwSet进行MVCC（Multi-Version Concurrency Control）检查。
kvledger实现的是基于键值对（key-value）的状态数据模型，对状态数据键有3种操作：

• 读状态数据
• 写状态数据
• 删除状态数据

对状态数据读操作有2种形式：

• 基于单一键的读取
• 基于键范围的读取

无效的交易处理

在组织内部同步最新的区块

暂略