我们概述一个交易的请求流程。如图2-5所示。

图2-5 交易的请求流程

图字翻译：

Peers 同级节点

Orderers 订单方

Endorse（TX） 发起交易TX

Respond（TX） 响应交易TX

Broadcast（EndorsedTX） 广播已发起的交易TX

Blocks 写入区块

（1）客户端创建交易和发送给它选择的背书peer节点

调用交易，客户端发送一个PROPOSE消息到它选择的一组背书peer节点。给定chaincodeID的背书peer节点的设置由客户端通过peer节点实现，从背书策略知道背书peer节点的设置。例如，交易能被发送给所有给定chaincodeID背书者，也就是说，一些背书者能够离线，其它人可能反对和选择不为交易背书。提交客户端尝试满足背书者可用的背书策略表达。

接下来，将描述PROPOSE消息格式，讨论在提交客户端和背书者之间可能的互动模式。

PROPOSE消息格式

一个PROPOSE消息的格式是，其中tx是强制的，anchor可选参数在下面列出。

clientID是提交客户端的身份，chaincodeID引用交易相关的链码，txPayload是提交交易自身的载体，timestamp是由客户端维护的一个单独递增整型值，clientSig是tx的其它域客户端签名.

txPayload的细节会在调用交易和部署交易之间有所不同。

对于调用交易，txPayload会包含两个域

● operation表示链码操作函数和参数● metadata表示调用相关的属性.

对于部署交易，txPayload会包含三个域

● source表示链码的源码● metadata表示链码和应用的相关属性● policies包含所有peer节点可访问的链码的相关策略，例如背书策略。注意背书策略在部署交易中不支持txPayload，但部署的txPayload包含背书策略ID和它的参数。● anchor包含读版本依赖，或更具体地说，键-版本对（即，anchor是KxN的一个子集），它捆绑或“锚”PROPOSE请求到指定KVS中key的版本。如果客户端指定anchor参数，背书者背书交易的情况是，只基于读它本地KVS匹配anchor中的相应KEY的版本号。

tx加密哈希被所有node节点用作唯一的交易标识tid（即，tid=HASH（tx））。客户端保存tid在内存中，等待背书peer节点的响应。

客户端决定与背书者互动的顺序。例如，客户端通常会发送（即，没有anchor参数）到一个单独的背书者，背书者随后产生版本依赖（anchor），客户端可以在晚些时候使用这个版本依赖（anchor）作为它的PROPOSE消息参数，发送给其它背书者。另外的例子，客户端能直接发送（没有anchor）到它选择的所有背书者。不同的通信模式都有可能，客户端在这方面是自由的。

（2）背书peer节点模拟交易和产生背书签名

在从客户端接收消息时，背书peer节点epID首先校验客户端签名clientSig，然后模拟一个交易。如果客户端指定了anchor，那么背书peer节点模拟交易只基于在它本地KVS匹配的由anchor指定的版本号对应的key读版本号（即下面定义的readset）。

模拟一个交易涉及背书节点尝试执行一个交易（txPayload），通过调用链码到交易引用（chaincodeID）和背书peer节点本地持有的状态拷贝。

作为执行的结果，背书peer节点计算读版本依赖（readset）和状态更新（writeset），也在DB语言中称为MVCC+postimage info。

回顾状态包含键/值对。所有键/值对实体都是版本化的，那就是说，每个实体包含排序版本信息，它是在每次键的值更新时增加的。解释交易的peer节点记录了所有的被链码访问的键/值对，不管读或是写，peer节点不会更新它的状态。更具体地说：

● 在背书节点执行一个交易前给定状态s，被交易读取的每个键k，键/值对（k，s（k）.version）被添加到readset。● 此外，对于每一个被交易编辑的键k到值v’，键/值对（k，v’）被添加到writeset。或者，v’能成为新值与前值（s（k）.value）的增量。

如果客户端在PROPOSE消息中指定了anchor，那么客户端指定的anchor在模拟交易时必须等于背书peer节点产生的readset.

然后，peer节点内部提交交易提案到它的逻辑部分来背书交易，称为背书逻辑。缺省时，一个peer节点的背书逻辑接受交易提案并简单签署。无论如何，背书逻辑可以执行任意功能。

如果背书逻辑决定背书一个交易，它发送消息到提交客户端，其中：

● 交易提案：=tran-proposal：=（epID，tid，chaincodeID，txContentBlob，readset，writeset），其中txContentBlob是链码/交易专用信息。目的是让txContentBlob用作tx的一些陈述（例如，txContentBlob=tx.txPayload）.● epSig是背书peer节点的交易提案签名。

否则，如果背书逻辑拒绝背书交易，背书者可以发送消息（TRANSACTION-INVALID，tid，REJECTED）到提交客户端。

注意背书者在这一步不能改变它的状态，在背书没有影响状态的情况下交易模拟产生状态更新。

（3）提交客户端收集交易背书并通过排序服务广播它

提交客户端一直等待直到它在（TRANSACTION-ENDORSED，tid，，）上收集到“足够”的消息和签名来推断出交易提案已背书。

“足够”的准确数字取决于链码背书策略。如果背书策略是安全的，交易已经背书；注意它还没提交。经过背书节点签过名的TRANSACTION-ENDORSED消息的集合包含了被背书过的交易。

如果提交客户端没有设法为交易提案收集背书，则放弃这个交易，稍后再试。

对于一个具有有效背书的交易，我们现在开始使用排序服务。提交客户端使用broadcast（blob）调用排序服务，其中blob=endorsement.如果客户端没有能力直接调用排序服务，它可以通过它选择的peer节点代理广播。这样的peer节点必须被客户端信任不会从背书移除任何消息或其它可能被无效的交易。注意一点，无论如何，代理peer节点不可能制造有效背书。

（4）排序服务向peer节点提交交易

当一个事件（seqno，prevhash，blob）发生并且一个peer节点已为所有序列号低于seqno的blosbs更新状态，peer节点执行如下流程，图2-6所示。

● 它检查blob.endorsement是有效的，根据的是它引用的链码（blob.tran-proposal.chaincodeID）。● 在典型情况下，它也验证了依赖（blob.endorsement.tran-proposal.readset）在期间没有被违反。在更复杂的用例中，背书中的交易提案域可能不同，在这种情况下，背书策略指定状态如何形成。

依赖的验证能以不同的方式实现，根据一致性属性或为状态更新选择的“孤立保证”。Serializability是一个缺省的孤立保证，除非链码背书策略指定一个不同的。Serializability能够通过在readset中的每个key关联的版本被提供，相当于key在状态中的版本，并拒绝不满足这个要求的交易。

● 如果所有这些检查通过，交易被视为有效或承诺。在这种情况下，peer节点在PeerLedger用1标记交易，适用于blob.endorsement.tran-proposal.writeset区块链状态（如果交易提案是相同的，其它背书策略逻辑定义了函数处理blob.endorsement）。● 如果blob.endorsement背书策略验证失败，交易无效，并且peer节点在PeerLedger的位掩码用0标记交易。重要的是要注意无效交易不会改变状态。

图2-6 提交交易