交易背书的基本工作流程

2.交易背书的基本工作流程
在下面我们概述一个事务的高级请求流程。

注意：请注意，以下协议*并不认为所有交易都是确定性的，即允许非确定性交易。

2.1。客户端创建一个交易，并将其发送给自己选择的同行
为了调用一个事务，客户端会向所选择的一组认可对等体发送一个PROPOSE消息（可能不是同时 - 见2.1.2和2.3节）。给定的chaincodeID的一组认可的同伴可以通过对等体向客户提供，而后者又通过认可策略知道一组认可对等体（见第3节）。例如，交易可以发送给给定chaincodeID的所有支持者。也就是说，一些支持者可能离线，其他人可能会反对并选择不批准交易。提交客户端尝试通过可用的支持者来满足策略表达式。

在下文中，我们首先详细说明PROPOSE消息格式，然后讨论提交客户端和代理人之间可能的交互模式。
2.1.1。 PROPOSE消息格式
PROPOSE消息的格式是<PROPOSE，tx，[anchor]>，其中tx是以下解释的强制和锚可选参数。

tx = <clientID，chaincodeID，txPayload，timestamp，clientSig>，其中

clientID是提交客户端的ID，
chaincodeID是指交易所涉及的链码，
txPayload是包含提交的事务本身的有效载荷，
时间戳是由客户端维护的整数单调递增（对于每个新事务）
clientSig是tx的其他字段上的客户端的签名。
txPayload的详细信息将在调用事务和部署事务之间不同（即，调用涉及部署特定系统链码的事务）。对于调用事务，txPayload将由两个字段组成

txPayload = <operation，metadata>，其中
操作表示链码操作（function）和参数，
元数据表示与调用有关的属性。
对于部署事务，txPayload将由三个字段组成

txPayload = <源，元数据，策略>，其中
source表示链码的源代码，
元数据表示与链码和应用相关的属性，
政策包含与所有同行可访问的链码相关的政策，例如认可政策。请注意，部署事务中txPayload不提供认可策略，但是部署的txPayload包含认可策略ID及其参数（参见第3节）。
锚包含阅读版本依赖关系，或者更具体地说，键版本对（即，锚是KxN的子集），其将PROPOSE请求绑定或“锚定”到KVS中的指定版本的密钥（参见第1.2节）。如果客户端指定了锚参数，则代理人仅在其本地KVS匹配锚中的相应键的读取版本号后才会认可交易（有关详细信息，请参阅第2.2节）。
tx的加密散列由所有节点用作唯一的事务标识符tid（即，tid = HASH（tx））。客户端将内存中的数据存储在内存中，并等待来自同行的同行的响应。

2.1.2。留言模式
客户决定与支持者的互动顺序。例如，客户端通常将<PROPOSE，tx>（即，没有锚参数）发送到单个代码，然后将产生版本相关性（锚），客户端稍后可以使用它作为其PROPOSE消息的参数给其他支持者。另一个例子，客户端可以直接将<PROPOSE，tx>（无锚点）发送给所选的所有支持者。不同的沟通方式是可能的，客户可以自由决定这些（另见第2.3节）。

2.2。认可的同行模拟交易并产生签名签名
在接收到来自客户端的<PROPOSE，tx，[anchor]]消息时，认证对等体epID首先验证客户端的签名客户端，然后模拟事务。如果客户端指定了锚点，则只有当本地KVS中的相应密钥的读取版本号（如下文所定义的读取集合）匹配由锚定的版本号时，才支持对等体模拟事务。

模拟交易涉及通过调用事务引用的链代码（chaincodeID）和签名对等体本地保存的状态的副本来批准对等体暂时执行事务（txPayload）。

作为执行的结果，支持对等体计算读取版本依赖性（readset）和状态更新（writeset），也称为DB语言的MVCC + postimage信息。

回想一下，状态由键/值（k / v）组成。所有k / v条目都进行版本控制，也就是说，每个条目都包含有序版本信息，每次更新存储在密钥下面的值时会增加。解释事务的对等体记录链码访问的所有k / v对，用于读取或写入，但对等体尚未更新其状态。进一步来说：

给予认可对等体执行事务之前的状态，对于由事务读取的每个关键字k，将对（k，s（k）.version）添加到读取集。
另外，对于通过事务修改的每个关键字k到新值v’，对（k，v’）被添加到写入集。或者，v’可以是新值到先前值（s（k）.value）的增量。
如果客户端在PROPOSE消息中指定了锚点，则客户端指定的锚点必须等于在模拟事务时由支持对等方产生的读取集。

然后，对等体将内部转交提议（也可能是tx）转发到其认可交易的（对等体）逻辑部分，称为支持逻辑。默认情况下，同行的认可逻辑接受转交方案，并简单地签署转交方案。然而，认可逻辑可以解释任意的功能，例如与具有转发提议和tx作为输入的遗留系统交互以达成是否支持交易的决定。

如果认可逻辑决定认可交易，则会向提交客户端（tx.clientID）发送<TRANSACTION-ENDORSED，tid，tran-proposal，epSig>消息，其中：

tran-proposal：=（epID，tid，chaincodeID，txContentBlob，readset，writeset），

其中txContentBlob是链码/事务特定的信息。意图是将txContentBlob用作tx的一些表示（例如，txContentBlob = tx.txPayload）。
epSig是支持同行的转交签名
否则，如果认可逻辑拒绝批准交易，则代理人可以向提交客户端发送消息（TRANSACTION-INVALID，tid，REJECTED）。

请注意，在此步骤中，代理人不会更改其状态，在代理背景下通过交易模拟生成的更新不会影响状态！

2.3。提交客户收集交易的背书，并通过订购服务进行广播
提交客户端等待，直到它收到（TRANSACTION-ENDORSED，tid，，）语句中的“足够”消息和签名，以得出交易提案被认可。如2.1.2节所述，这可能涉及到一个或多个与支持者的往返交往。

“足够”的确切数量取决于链码认证政策（另见第3节）。如果认可政策得到满足，交易已获得批准;注意它还没有承诺。签署的交易签署的交易签署的交易信息的收集被认为是认可交易被认可的，被认可并被表示为背书。

如果提交客户端没有设法收集交易提案的背书，则会放弃此交易，并提供稍后重试的选项。

对于有效认可的交易，我们现在开始使用订购服务。提交客户端使用broadcast（blob）调用订购服务，其中blob =代言。如果客户端没有直接调用订购服务的能力，它可以通过其选择的某个对等体代理其广播。这样的对等体必须被客户信任，不要从认可中删除任何消息，否则交易可能被视为无效。请注意，然而，代理对等体可能无法制定有效的认可。

2.4。订购服务将交易交付给同行
当一个事件传递（seqno，prevhash，blob）发生，一个对等体应用了序列号低于seqno的blob的所有状态更新时，对等体执行以下操作：

它根据其引用的链码（blob.tran-proposal.chaincodeID）的策略来检查blob.endorsement是否有效。
在一个典型的情况下，它也会验证依赖关系（blob.endorsement.tran-proposal.readset）是否也被违反。在更复杂的使用案例中，认可的转交方案可能不同，在这种情况下，认可政策（第3节）规定了国家如何演变。
可以根据为状态更新选择的一致性属性或“隔离保证”以不同的方式实现依赖关系的验证。 Serializable是默认的隔离保证，除非链码认证策略指定了不同的保证。可以通过要求与读取集中的每个键相关联的版本等于该状态下的密钥版本，并拒绝不满足此要求的事务来提供可序列化。

如果所有这些支票通过，交易被视为有效或承诺。在这种情况下，对等体在PeerLedger的位掩码中将事务标记为1，将blob.endorsement.tran-proposal.writeset应用于块状态（如果转发方案相同，否则认可策略逻辑定义了获取Blob的函数。背书）。
如果blob.endorsement的认可策略验证失败，则该事务无效，并且对等体在PeerLedger的位掩码中将事务标记为0。重要的是要注意，无效的交易不会改变状态。
请注意，这足以使所有（正确）对等体在处理具有给定序列号的传递事件（块）之后具有相同的状态。也就是说，通过订购服务的保证，所有正确的对等体将接收到相同的递送顺序（seqno，prevhash，blob）事件。由于对认可策略的评估和对readset的版本依赖性的评估是确定性的，所以正确的对等体也将得出相同的结论，无论一个blob中包含的事务是否有效。因此，所有对等方提交并应用相同的事务序列，并以相同的方式更新其状态。

交易流程图（普通路径）。

图1.一个可能的事务流程（普通案例路径）的图示。