Hyperledger Fabric网络上事务流的验证阶段（在假设的场景下）

Question

我们的团队是Hyperledger Fabric的新手，并一直在浏览官方文档。我们被困在一个我们真的很感激所有帮助的地方。以下是我们的理解（与问题相关），然后是实际问题。

>

在简化的意义上，当我们进入事务流的验证阶段时，订货者从客户机应用程序接收一组事务，它们被放在一个块中，然后被发送给提交的对等方；执行验证检查，并随后更新世界状态和区块链。

在所有正常情况下，期望所有提交对等方都将为该块返回相同的结果（因为所有对等方都应用了相同的处理），然后将该结果传递给客户机应用程序。

我们的问题是：

>

如果这些提交对等体在验证期间同时为块产生不同的结果（就像每个对等体都有自己的最终结果一样），那么现在会发生什么。那么分类帐/世界状态将如何更新？是否有一组对等节点会被给予比其他节点更大的优先级，或者系统可能会选择基于共识的决策？如何解决这样的冲突？

非常感谢你耐心地回答我们的问题。我们感谢您在这方面所能提供的一切帮助。

Answer 1

首先，我想纠正你理解的第一点：

在简化的意义上，一旦订货者从客户机应用程序接收到一组事务，它们就被放在一个块中，然后被发送到对等方进行处理；执行验证检查，并随后更新世界状态和区块链。

Hyperledger fabric工作在执行-命令-验证体系结构上。来自客户端应用程序的事务首先提交给认可节点。背书节点执行提出的事务，捕获读写集，并在签名后将其作为响应发送回应用程序。应用程序然后将响应作为事务发送到订购服务。

1.如果对等点没有得到类似的结果（不同的对等点为块提出自己的最终结果），现在会发生什么？是否有一组对等节点的结果会比其他节点得到更大的优先级，或者系统可能会选择基于共识的决策？如何解决这样的冲突？

安斯。事务首先由背书对等方背书，RW集在执行和签名后被发回应用程序。如果应用程序收到了在背书策略中定义的足够的背书，则响应将被发送用于订购，否则事务将在背书阶段失败。冲突就是这样处理的。Fabric能够处理不确定的事务。

2.在任何情况下（发生这种事件的）是有效的可能性吗？或者网络中已经有检查来防止这种情况发生？

安斯。上面已经提到的可能原因。在订购阶段之后，有一个验证阶段。在此阶段中，事务由提交对等方根据背书策略进行验证，并检查事务对于当前世界状态是否仍然有效。无效的事务处理被写入分类帐，但不在世界状态下更新，而有效的事务处理在分类帐和世界状态下更新。