Hyperledger Fabric 网络上交易流的验证阶段（假设场景下）

Question

我们的团队是 Hyperledger Fabric 的新手，并且一直在使用 official documentation。我们被困在我们非常感谢所有帮助的事情上。以下是我们的理解（与问题相关），接下来是实际问题。

---

1234563 ;执行验证检查，然后更新世界状态和区块链。 1234563

1. 在每个对等点上，块内的每笔交易都经过验证，以确保在将其应用于分类帐之前，它已得到所有相关组织的一致认可。失败的交易被保留以供审计，而不是应用于分类帐。已正确背书的交易会尝试应用到账本上。

2. 这意味着对等块与从排序者收到的块几乎完全相同，除了块中每个事务的有效或无效指示符。从这里开始，我们跟踪discussion 并收集到无效交易不会发生状态更新。它们在块元数据中被标记为无效，并且块被序列化并添加到链中，并为有效交易进行状态更新。

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

---

我们的问题是：

1. 现在会发生什么，如果这些提交节点在验证过程中同时为块提出不同的结果（比如每个节点都有自己的最终结果）。那么分类帐/世界状态将如何更新？是否有任何一组对等节点比其他节点具有更高的优先级，或者系统可能会做出基于共识的决定？如何解决这样的冲突？

2. 在任何情况下（发生此类事件 - 对等节点在验证阶段出现恶意）是否有效？或者网络中已经有检查以防止这种情况发生？

3. 如果发生这种情况，可能的原因是什么？可能的网络错误导致 Orderer 将同一块的副本发送到不同的对等点略有不同？还是有意/恶意地调整每个对等节点拥有的验证代码，然后它将在该块内的每个事务上运行？还是别的什么？

   ---

非常感谢您耐心解答我们的问题。感谢您在这方面提供的所有帮助。

Answer 1

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

简单来说，一旦 Orderer 收到来自客户端应用程序的交易包，它们就会被放在一个块中，然后发送到对等点进行处理；执行验证检查，并随后更新世界状态和区块链。

Hyperledger 结构适用于 execute-order-validate 架构。来自客户端应用程序的交易首先提交给背书节点。背书节点执行提议的交易并捕获读写集并在签名后将它们作为响应发送回应用程序。 然后应用程序将响应作为事务发送到排序服务。

回答您的问题：

1. 如果对等节点以某种方式无法得出相似的结果（不同的对等节点对区块提出自己的最终结果），现在会发生什么？是否有任何一组对等节点的结果会比其他节点得到更高的优先级，或者系统可能会做出基于共识的决定？如何解决这样的冲突？

回答。交易首先由背书节点背书，RW 集在执行和签名后发送回应用程序。如果应用程序收到了背书策略中定义的足够的背书，则将发送响应以进行排序，否则交易将在背书阶段失败。这就是处理冲突的方式。 Fabric 能够处理非确定性事务。

2.在任何情况下（发生此类事件）是否有效？或者网络中已经有检查以防止这种情况发生？

回答。在恶意节点、节点故障网络分区等情况下是可能的。

1. 如果发生这种情况，可能的原因是什么？可能的网络错误导致将同一块的副本发送到不同的对等点略有不同？还是有意/恶意地调整每个对等节点拥有的验证码，然后它将在该块内的每个事务上运行？或者别的什么？

回答。 上面已经提到的可能原因。在订购阶段之后，有一个验证阶段。在这个阶段，交易由提交节点根据背书策略进行验证，并检查交易对于当前世界状态是否仍然有效。无效交易被写入账本，但在世界状态中不更新，而有效交易在账本和世界状态中更新。