(译)超级账本公文的基本概念(3)-同行
织物的基本概念
最初，应用程序将选择一组对等方来生成帐簿更新建议。哪一个对等体将被选择基于签署策略，该策略确定哪些组织需要在广播账簿更新提议之前签署更新提议。这样会影响理解的方式。任何关心更新提议是否被认可的组织将在向对等体广播该提议并被对等体接受之前确认该提议是否被认可。
对等体对提议的响应的认可是将他的数字签名添加到响应中，并用他的私钥对整个响应进行签名。然后，可以使用批注的内容来证明该响应是由组织的同行生成的。在我们的示例中，如果对等方P1属于组织1(Org1)，则认可E1相当于证明事务T1和L1上的响应R1是由组织1的对等方P65438+做出的。
当应用程序获得足够多的签名提案响应时，第一阶段就结束了。
我们注意到peer可能返回不同的信息，所以同一个事务可能有不一致的返回信息。这可能是因为响应是在不同的时间、不同的对等体和不同的帐簿上生成的。在大多数情况下，应用程序可以多次请求更新建议回应。另外更严重，但概率小因为链码的不确定性导致响应不一致。不确定性是链码和账本的大敌。如果出现这种情况，对于拟交易来说是非常严重的，不一致的提议响应肯定不会提交到账本上。独立节点不可能知道事务结果是非确定性事务。在检测非确定性事务之前，有必要对事务进行总结和比较(严格来说，即使这还不够，我们也将这个讨论推迟到事务部分，在事务部分不确定性有详细讨论)。
在第一阶段结束时，如果应用程序愿意，它可以安全地丢弃不一致的响应，以提前结束事务处理。我们将在后面看到，如果应用程序向分类帐提交的响应不一致，它将被拒绝。
工艺2包装
第二个交易过程是打包。订购者节点是这个过程中的一个关键点，它接收来自许多应用程序的认可的提议的事务响应。订购方对交易进行排序，将大量交易打包成块，并准备将块分发给与订购方连接的所有对等方，包括背书对等方。
订购者的第一个角色是打包账簿更新建议。在上面的示例中，应用程序A1向订购者O1发送由E1和E2背书的交易T1。同时，应用A2向订购者O1发送由E1背书的交易T2。O1将来自A1的交易、来自A2的交易和其他交易打包到B2块中。我们可以看到，块B2中的事务顺序是T1，T2，T3，T4，T6，T5，不一定按照到达订购者节点的顺序(这个例子展示了一个非常简单的订购者配置)。
订购者节点还将接收由网络信道中的不同应用发送的帐簿更新建议。订购者节点的任务是按照预定义的顺序整理这些更新建议，并将它们打包成块，以准备下一次分发。这些石块将形成一个区块链。一旦订购者节点生成了具有预期大小的块，或者超过了最大等待时间，订购者将把该块发送给连接到其特定通道的对等体。第三个过程将详细介绍这个过程。
块中事务的顺序与事务到达order节点的顺序之间没有直接关系。事务可以在一个块中以任何顺序排列，这个顺序就是事务执行的顺序。重点是有严格的交易排名，但排名多少并不重要。
块中严格的事务顺序使得Fabric不同于公共链中的事务可以被打包到多个不同的块中的情况。在Fabric中，不可能出现这种情况，多order生成的块就是最终的块，因为事务写入块后，事务的位置顺序就确定了。这意味着织物不会出现分叉。事务一旦写入块中，就不能在以后重写。
我们可以看到，peer存储书籍和链码，orderer根本不存储。当每笔交易到达order时，order只是机械地将交易打包成块，而不考虑交易的价值和额度。这是织物的一个重要特征。所有事务都将按照严格的顺序进行排序，不会丢弃任何事务。
到第二阶段结束，我们可以理解订购者的职责是收集必要且简单的交易更新提议，对其进行排序，将其打包成块并准备分发。
流程3认证
最后一个事务工作流程是从订购方到对等方分发和验证块。如果验证成功，将提交到总账。
特别地，在每个对等体中，块中的每个交易在被更新到帐簿之前都被验证，以确保所有交易都已被相关组织认可。失败的交易将被保留以备将来审查，并且不会在账簿中更新。
除了流程2中的打包角色，Orderer还负责将块分发到流程3中的对等节点。在此示例中，O1将块分发到P1和P2。P1处理Block 2，然后将Block 2添加到P1的账簿L1。同时，P2处理块2，然后将块2添加到P2的账簿L1。一旦操作完成，账簿L1在P1和P2中被更新，并且每个对等体可以将处理结果发送到连接到它们的应用程序。
订购者将块分发给连接到他的对等体，这是过程3的开始。连接到订购者节点的信道的对等端将接收订购者生成的新块的副本。每个对等节点将独立处理接收到的块，但是所有对等节点都以相同的方式处理该块。这样，不同同行的账本就可以达到* * *知识。不是所有的对等体都必须连接到orderer节点，块可以通过gossip协议在对等体之间传递，这样对等体也可以独立处理相同的块。
收到块后，peer将按照块中出现的顺序处理事务。对于每笔交易，peer将根据生成交易的链码认可策略检查交易是否得到相关组织的认可。例如，某些交易可能只需要一个组织背书，而其他交易则需要多个组织同时背书。该验证过程验证所有相关组织产生的结果或输出是否一致。同时请注意，第三阶段验证与第一阶段不同。在第一阶段，应用程序仅接收来自背书节点的响应，并判断是否需要发送交易提议。如果应用程序发送了错误的交易并违反了背书策略，peer仍然可以在第三个验证阶段拒绝该交易。
如果交易的背书是正确的，peer将尝试将交易提交到分类帐。为了编写账簿，peer必须检查账簿的一致性，以确保当前账簿与更新后的账簿一致。这种状态并不总是一致的，即使交易有完整的背书。例如，另一项交易可能更新了分类账中的同一项资产，因此我们将要更新的交易将永远不会写入分类账。在这种情况下，每个节点中的账簿必须通过网络保持通知，每个节点的验证方法是相同的。
在peer核实每笔独立交易后，分类账将被更新。失败的交易将作为审查材料保存。这意味着除了块中指示事务成功或失败的标志之外，对等体中的块与从订购方接收的块相同。
我们还要注意，链码不是在第三阶段执行的，这一步只会在第一阶段完成，这一点很重要。这意味着链码只在背书节点可用，不在全网可用，保证了链码在背书机构的安全性和私密性。这不同于接收链代码的执行结果。执行结果将与通道中的所有对等体共享，而不管他是否可以签署该事务。背书节点就是这样设计的，方便扩展。
最后，每向对等体的账本提交一个块，对等体就会生成一个相应的事件。块事件包含一个块的所有内容，而块事务事件只包含简短的信息，例如每个块中的事务是否有效。链码执行产生的链码事件也可以在此时释放。应用程序可以注册这些事件，并在事件发生时接收通知。这些通知在事务工作流的第三个也是最后一个阶段完成。
一般来说，我们可以知道第三阶段orderer生成的块是不断同步到账本中的。区块链中交易的严格排序允许每个对等点一致地验证区块链网络中的交易，并将它们提交给分类帐。
订购者和* * *知识
整个事务工作流被称为* * *知识，因为所有的peer都同意事务的排序和内容，在执行过程中由orderer节点协调。* * * knowledge是一个多步骤的过程，只有在* * * knowledge过程结束时才会通知应用程序，但通知时间在不同的对等体上可能会有所不同。
我们稍后将更多地讨论订购者。现在，我们只是把orderer看成是一个从应用收集并分发账本更新建议给对等端的过程，对等端会对账本进行验证和更新。