我们的团队是Hyperledger Fabric的新手，已经经历了official documentation。我们坚持不懈地希望获得所有帮助。以下是我们对问题的理解，然后是实际问题。
从简单的意义上说，当我们进入交易流程的验证阶段时，订购者从客户端应用程序接收一捆交易，将它们放在一起放在一个块中，然后将其发送到提交对等方;执行验证检查，然后更新世界状态和区块链。
此外，此块已分配到的通道上的每个对等点都独立地对其进行处理，尽管其方式与该通道上的每个其他对等点完全相同（以便使分类帐保持一致）
在每个对等方，对区块中的每个交易进行验证，确保在将其应用于分类账之前，所有相关组织均一致认可该交易。失败的交易将保留以进行审核，而不应用于分类帐。正确认可的交易将尝试应用于分类帐。
这意味着对等块几乎与从定购者收到的块完全相同，除了该块中每个事务的有效或无效指示符。从这里开始，我们遵循discussion并收集到无效交易不会发生状态更新。它们在块元数据中被标记为无效，并且对块进行序列化并将其添加到链中，并对有效交易进行状态更新。
在所有正常情况下，期望所有提交对等方将为该块返回相同的结果（因为它们所有人都应用了相同的处理），然后将其传达给客户端应用程序。
我们的问题是：
现在发生的情况是，如果这些提交的对等方在验证期间同时为该区块提出了不同的结果（例如每个都有自己的最终结果）。然后如何更新分类帐/世界状态？是否有任何对等节点组的优先级高于其余节点，或者系统可能会寻求基于共识的决策？这样的冲突将如何解决？
在任何情况下是否有可能（发生这样的事件-对等节点在验证阶段变坏）？还是网络中已经存在阻止这种情况发生的检查？
如果发生这种情况，可能会导致这种情况的可能原因是什么？可能的网络错误导致订购者将同一块的稍微不同的副本发送到不同的对等方？还是对每个对等节点拥有的验证代码进行有意/恶意的调整，然后它将在该块内的每个事务上运行？也许还有其他东西？
非常感谢您耐心回答我们的问题。我们感谢您在这方面可以提供的所有帮助。
答案 0 :(得分：0)
首先，我想纠正您的理解的第一点：
从简化的意义上讲，订购者从客户端应用程序接收到一捆交易后，会将它们放在一起放在一个块中，然后将其发送给对等方进行处理；进行验证检查，然后更新世界状态和区块链。
超级账本结构在 execute-order-validate 体系结构上工作。来自客户端应用程序的事务首先被提交给认可节点。认可节点执行提议的事务并捕获读写集，并在签名后将它们作为响应发送回应用程序。 应用程序然后将响应作为事务发送到订购服务。
回答您的问题：
1。如果对等方以某种方式未达到相似的结果（不同的对等方针对该块得出自己的最终结果），现在会发生什么？是否有任何对等节点的结果优先级高于其余对等节点，或者系统可能会寻求基于共识的决策？这样的冲突将如何解决？
回答。事务首先由背书的同级背书，RW集在执行和签名后发送回应用程序。如果应用程序收到了认可策略中定义的足够认可，则将发送响应以进行订购，否则交易将在认可阶段失败。这就是处理冲突的方式。 Fabric能够处理不确定的交易。
2。在任何情况下，是否存在（发生此类事件的）可能性？还是网络中已经存在阻止这种情况发生的检查？
回答。在恶意节点，节点故障网络分区等情况下，这是可能的。
回答。 上面已经提到的可能原因。在订购阶段之后，有一个验证阶段。在此阶段中，事务由提交的对等方根据背书策略进行验证，并检查事务对于当前世界状态是否仍然有效。无效交易被写入分类帐，但不会在世界状态下更新，因为有效交易会在分类账和世界状态下更新。