Hyperledger Fabric-订购者（系统）通道与应用程序通道

Question

编辑：我先前的问题版本着重于Orderer FAQ中的一些混乱，但我认为以下问题可以更好地识别订购者（系统）渠道的混乱之处：

问：什么专门定义了Hyperledger Fabric网络的边界？

在Network Docs中，下图显示了“网络”（浅蓝色框）：

“创建网络”部分指出：

  

网络是根据财团的 定义 创建的，包括其客户，对等方，渠道和订购服务。 订购服务是网络的管理点 ，因为它包含网络中渠道的配置。 [强调我的]

该段落似乎首先暗示联盟定义了“网络”（并暗示了多个订购者渠道的潜力？），然后指出订购服务（单个？）是网络的骨干。

这是否意味着订购者（系统）通道是定义此“网络”的要素？这似乎表明网络中只能有一个订购者频道（因为它定义了网络）。

在本段中，Architecture部分也有些混乱：

  

分区（订购服务渠道）。订购服务可能支持多个渠道。 。 。尽管Hyperledger Fabric随附的某些订购服务实现支持多个渠道，但是为了便于演示，在本文档的其余部分中，我们仍假定订购服务由单个渠道/主题组成。

我最初阅读此段落时指的是应用程序通道，但也可能指的是订购者系统通道。本节是否描述了多个订购者（系统）渠道的潜力？

如果可能有多个订购者通道，那么图中的“网络”（浅蓝色框）的定义是什么？与现有的其他Hyperledger Fabric网络相比，该网络的边界是什么-它们是否可能全部重叠其不同的订购者渠道以创建一个庞大的“网络”？

configtx.yaml文件似乎也暗示了多个订购者通道的潜力，因为订购者是在每个单独的应用程序通道配置事务中定义的，而不是在单个初始系统通道事务中定义的：

这是v1.2 configtx.yaml文件Profiles部分：

Profiles:

    TwoOrgsOrdererGenesis:
        Capabilities:
            <<: *ChannelCapabilities
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    TwoOrgsChannel:
        Consortium: SampleConsortium
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities

阐明第四个常见问题解答答案也将是有帮助的：

  

尽管[有可能让组织同时充当订购和应用程序角色]，但这是一个极不鼓励的配置。 。

如果需要一个完全独立的组织来管理订购者， 用Hyperledger Fabric创建“去中心化”交易网络有什么意义？ ？公司的任何“财团”无论如何都需要第三方的参与。