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）事件。由于对注册策略的评估和读取集中的版本依赖性的评估是确定性的，所以正确的对等体也将得出相同的结论，无论一个blob中包含的事务是否有效。因此，所有对等方提交并应用相同的事务序列，并以相同的方式更新其状态。
图1.一个可能的事务流（普通案例路径）的图示。
3.认可政策
3.1。 认可政策规范
一个认可政策，是什么赞成交易的条件。 Blockchain对等体具有一组预先指定的认可策略，这些策略由安装特定链码的部署事务引用。 认可策略可以参数化，这些参数可以由部署事务指定。
为了保证封锁和安全属性，一套认可政策应该是一套具有有限功能的成熟策略，以确保有限的执行时间（终止），确定性，性能和安全性保证。
在有限政策评估时间（终止），确定性，绩效和安全保证方面，动态添加认可政策（例如通过在链代码部署时间部署事务）非常敏感。 因此，不允许动态添加认可政策，但将来可以支持。
3.2。 对背书政策的交易评估
交易只有在根据政策被认可的情况下才被宣告为有效。链码的调用交易首先必须获得满足链码政策的认可，否则将不会被提交。这是通过提交客户和认可对等体之间的交互进行的，如第2节所述。
正式地，背书政策是对背书的一个谓词，并且可能进一步说明评估为TRUE或FALSE。对于部署事务，根据系统范围的策略（例如，从系统链码）获得认可。
认可策略谓词是指某些变量。潜在地可能是指：
与链码相关的密钥或身份（在链码的元数据中找到），例如一组签名者;
链码的进一步元数据;
背书和背书提案的要素;
并可能更多。
上面的列表是通过增加表现力和复杂性来排序的，也就是说，支持仅涉及节点的密钥和身份的策略将比较简单。
认可政策谓词的评估必须是确定性的。每个对等体应当在当地评估认可，以便对等体不需要与其他同伴进行交互，但所有正确的对等体以相同的方式评估认可策略。
3.3。 示例认可政策
谓词可能包含逻辑表达式，并且计算结果为TRUE或FALSE。通常，条件将使用数字签名对由链接代码签名的对等方发出的事务调用。
假设chaincode指定了支持者集合E = {爱丽丝，鲍勃，查理，戴夫，夏娃，弗兰克，乔治}。一些示例政策：
来自E的所有成员的相同转发方案的有效签名
任何单一成员的有效签名
根据条件（Alice OR Bob）和（任何两个：查理，戴夫，夏娃，弗兰克，乔治），同意转交方案的签名有效。
七位支持者中的任何一位的同一个转发方案都有有效的签名。 （更一般地说，对于n> 3f签名者的链码，n个签名者中的任何2f + 1的有效签名，或任何超过（n + f）/ 2个签名者的组）。
假设对于支持者，如{Alice = 49，Bob = 15，Charlie = 15，Dave = 10，Eve = 7，Frank = 3，George = 1}有一个“赞成”或“权重”总股本为100：该政策要求具有多数股权的集合（即，一个合并股份严格超过50个的股份）的有效签名，例如与Alice不同的{Alice，X}，或{大家一起除了爱丽丝}。等等。
先前示例条件中的股份的分配可以是静态的（固定在链码的元数据中）或动态的（例如，取决于链码的状态并且在执行期间被修改）。
（Alice OR Bob）对于tran-proposal1的有效签名以及来自（Charlie，Dave，Eve，Frank，George的任何两个）的有效签名，其中tran-proposal1和tran-proposal2仅在其认可的对等方和状态更新。
这些政策将如何有效地取决于应用程序，解决方案针对代理人的失败或不当行为以及各种其他属性的所需弹性。
4（Post-v1）。 验证分类帐和对账检查点（修剪）
4.1。 验证分类帐（VLedger）
为了保持分类帐的抽象，只包含有效和已承诺的交易（例如在比特币出现），除了状态和分类帐之外，对等方可以维护验证分类帐（或VLedger）。 这是通过过滤掉无效事务从分类帐派生的哈希链。
VLedger块（这里称为vBlock）的构造如下进行。 由于PeerLedger块可能包含无效的交易（即无效认可的交易或具有无效的版本相关性），所以在将来自块的事务添加到vBlock之前，此类事务被对等体过滤掉。 每个对等体本身（例如，通过使用与PeerLedger相关联的位掩码）执行此操作。 vBlock被定义为没有无效事务的块，已被过滤掉。 这样的vBlock在本质上是动态的，可能是空的。 vBlock构造的说明如下图所示
图2.从分类帐（PeerLedger）块中验证的分类帐块（vBlock）的形成图。
每个对等体都将vBlock链接到一个哈希链。 更具体地说，一个经过验证的分类帐的每个块都包含：
以前的vBlock的散列。
vBlock号码。
计算自上一个vBlock以来对方提交的所有有效事务的有序列表（即相应块中的有效事务列表）。
派生当前vBlock的相应块（在PeerLedger中）的散列。
所有这些信息被对等体连接和散列，产生验证分类帐中的vBlock的哈希值。
4.2。 PeerLedger检查点
分类帐包含无效的交易，可能不一定会永久记录。但是，对等体不能简单地丢弃PeerLedger块，从而在建立对应的vBlock时修剪PeerLedger。也就是说，在这种情况下，如果新的对等体加入网络，则其他对等体不能将丢弃的块（与PeerLedger相关）传送给加入的对等体，也不能说服加入对等体其vBlock的有效性。
为了方便修剪PeerLedger，本文档介绍了一个检查点机制。该机制通过对等网络建立vBlock的有效性，并允许检查点的vBlocks替换丢弃的PeerLedger块。这反过来又减少了存储空间，因为不需要存储无效的事务。它还减少了为加入网络的新对等体重建状态的工作（因为他们不需要通过重播PeerLedger来重建状态时确定各个事务的有效性，而是可以简单地重放验证的分类帐中包含的状态更新）。
#### 4.2.1。检查点协议
检查点由对等体每个CHK块定期执行，其中CHK是可配置参数。要启动一个检查点，对等体向其他对等体广播（例如，八卦）消息<CHECKPOINT，blocknohash，blockno，stateHash，peerSig>，其中blockno是当前块号，blocknohash是其相应的散列，stateHash是最新状态的哈希（由例如Merkle哈希生成）在块blockno和peerSig的验证时，是（CHECKPOINT，blocknohash，blockno，stateHash）上的对等体签名，参考验证的分类帐。
对等体收集CHECKPOINT消息，直到获得足够的具有匹配blockno，blocknohash和stateHash的正确签名消息，以建立有效的检查点（参见第4.2.2节）。
在使用blocknohash建立块号blockno的有效检查点时，对等体：
如果blockno> latestValidCheckpoint.blockno，则对等体分配latestValidCheckpoint =（blocknohash，blockno），
将组成有效检查点的各个对等体签名的集合存储到set latestValidCheckpointProof中，
将stateHash对应的状态存储到latestValidCheckpointedState中，
（可选）将其PeerLedger修剪成阻止号码blockno（包括）。
#### 4.2.2。有效检查点
显然，检查点协议提出了以下问题：对等体何时可以修剪其PeerLedger？ CHECKPOINT消息有多少“足够多”？这是由检查点有效性策略定义的，至少有两种可能的方法，它们也可以组合起来：
本地（特定于对象）检查点有效性策略（LCVP）。给定对等体p的本地策略可以指定一组对等体，对等体p信任，并且其CHECKPOINT消息足以建立有效的检查点。例如，对等体Alice的LCVP可以定义Alice需要从Bob或者Charlie和Dave两者接收CHECKPOINT消息。
全球检查点有效性政策（GCVP）。全局可以指定检查点有效性策略。这与本地对等策略相似，只是在系统（块链）粒度上规定，而不是对等粒度。例如，GCVP可以指定：
如果由11个不同的对等体确认，每个对等体可以信任检查点。
在特定部署中，每个订户与同一机器（即信任域）中的对等方并置，并且最多可能是（拜占庭）可能（拜占庭））故障，每个对等体可以信任检查点，如果f + 1不同对等体确认与定居者并列。
