Hyperledger fabric Hyperledger中组织的连接方式

我一直在努力弄清楚Hyperledger中各个组织是如何相互联系的

---

例如，当最终用户发起交易并将其发送到客户端应用程序时，应用程序将其发送到背书人对等方，背书人检查交易有效性，调用链码，模拟交易并创建读/写集。之后，背书人对等方再次向客户端应用发送交易响应。现在，客户端应用程序将其发送给订购者对等方。其他组织也需要在其分类账中记录此交易，对吗？但我不知道在那之后这笔交易是如何与其他组织联系在一起的？有人能帮我弄清楚吗？

整个流程分为7个步骤，您要问的是流程中第4步之后会发生什么

步骤1 — 客户端（应用程序），用户向网络发送交易建议（完成步骤后，请参阅下图）

步骤2 — 网络中的每个背书对等方都会收到该提案，他们会模拟该提案（通过背书对等方托管的智能合约），并创建一个读写集。读写（RW set）是交易在读取时根据当前分类账的世界状态模拟捕获的内容，以及如果交易已执行，将写入分类账的内容

步骤3 — 然后，该RW集由每个背书对等方签名并发送回客户端应用程序

步骤4 — 然后，应用程序将RW集和已签名事务转发给订购服务

步骤5–订购服务接收这些已背书的交易和RW集，并将其订购到块中，并将其交付给网络中的所有提交对等方 订购服务仅指定交易提交到共享分类账的顺序，它们既不维护分类账，也不保存链码或模拟交易

步骤6-从订购服务接收块时提交对等方，验证块中的每个事务。它是如何验证的？它将接收到的RW集与当前世界状态进行比较，以检查它们是否匹配验证后，交易将写入分类账，当RW集合中的写入数据写入分类账时，世界状态将更新 提交对等方可能持有也可能不持有智能合约。他们只是更新分类账的世界状态

---

步骤7–每个对等方将通知应用程序交易的成功或失败

，但订购方对等方不应该相互了解吗？当有许多订购者和许多组织时会发生什么？订购方不应该同步吗？订购方对等方从多个客户端获取输入，并且独立于组织。存在多个订购方节点以降低故障率。