Hyperledger fabric 超级分类账事务提交

如果“由于背书策略的评估和readset中版本依赖性的评估是确定的，所有正确的对等方也将得出相同的结论”，则只有一个对等方足以验证/提交事务。我们必须将事务发送给所有对等方，主要是因为这些对等方必须更新其状态。这是真的吗？

你是对的。您有一个分布式账本，因此必须将所有交易发送给所有对等方（发送到该对等方上的leader节点），以便它们可以保留相同的副本

在Hyperledger结构中，订购服务管理此功能，在生产中，此功能应为Kafka

我们必须将事务发送给所有对等方，主要是因为这些对等方必须更新其状态。这是真的吗

我不是100%确定你说的“将交易发送给所有同行”是什么意思，但让我澄清一下

更具体地说，您或客户端应用程序必须将您的事务发送给对等方，以使其满足链码认可策略

背书对等方将模拟事务执行，并通过RWSet哈希以RWSet+签名的形式将结果返回给客户端

客户端收集所有签名将其与RWset结果连接起来，并将其提交给订购服务

订购服务收集由不同客户提交的许多交易，并偶尔中断

块传递给领先的对等方，并分布在通道中的所有对等方

每个对等方独立地迭代块中的所有事务，以验证两件事：a）与背书策略的一致性；b） MVCC-多值并发控制，用于检查并发修改

一旦交易被确认，区块最终被提交到分类账

---

我怀疑。从正式文档来看，验证可能只有两个结果：所有节点验证事务或所有节点不验证事务。如果，也就是说，一个节点与其他节点不一致，则该节点存在问题（错误或恶意）。您非常正确，验证结果必须在所有对等节点上相同，例如，为了诱导确定性行为。当您说“在Hyperledger结构中，订购服务管理此，在生产中，这应该是Kafka”，这到底是什么意思？在这两种情况下（solo和Kafka），都是订购服务（一个或多个）向领先的对等方发送事务，对吗？还是我错了？没错，但SOLO不是容错的，也不是为生产而设计的。见：