Hyperledger fabric 订购方组织的Hyperledger结构所有权

根据大多数示例，逻辑上至少有3个组织（

org1、org2、order

）。 实际上只有两个实体组织（

org1，org2

）。任一组织或约定的第三方必须移交订购方组织的责任

Q1:谁应该是Hyperledger网络中“订购方组织”的所有者

Q2:如果一个组织成为“订购方组织”并拥有Hyperledger网络中的所有订购方节点（Raft），是否会存在安全漏洞？

Q1:谁应该是Hyperledger网络中“订购方组织”的所有者

第一个问题的答案很棘手。为了回答这个问题，请先说一句，因为Fabric的设计依赖于确定性一致性算法，所以对等方验证的任何块都保证是最终的和正确的。账本无法像比特币或以太等许多其他分布式、无许可的区块链网络那样分叉订购者/订购节点执行此事务订购，它与其他订购者节点一起形成一个订购服务

与同行一样，订购节点属于一个组织，所有与区块链网络交互的事物，包括订购者，都从其数字证书和会员服务提供商（MSP）定义中获取其组织身份

每个通道在Raft协议的一个单独实例上运行，该协议允许每个实例选择不同的领导者。这种配置还允许在集群由不同组织控制的排序节点组成的用例中进一步分散服务。虽然所有Raft节点必须是系统通道的一部分，但它们不一定必须是所有应用程序通道的一部分渠道创建者（和渠道管理员）能够选择可用订购者的子集，并根据需要添加或删除订购节点（只要一次只添加或删除一个节点）

因此渠道创建者和渠道管理员可以选择可用订购者的子集或添加/删除单个订购者。此外，多个组织可以控制拥有订购节点的集群。因此，您可以将其称为所有者

问题2：如果一个组织成为“订购方组织”并拥有Hyperledger网络中的所有订购方节点（Raft），是否会存在安全漏洞

在明确回答之前，请注意以下几点：

• 订购者看不到交易数据，他们只订购交易
• 与区块链网络交互的所有东西，包括对等方、应用程序、管理员和订购方，都从其数字证书和会员服务提供商（MSP）定义中获得其组织身份
• 虽然组织可以同时扮演订购和应用程序角色，但它是一种非常不鼓励的配置。默认情况下，/Channel/Orderer/BlockValidation策略允许订购组织的任何有效证书对区块进行签名。如果组织同时扮演订购和应用程序角色，则应更新此策略，以将块签名者限制为授权订购的证书子集
• 在授权任何事务（订购）之前，由对等方对其进行验证，并在验证之后提交共识事务
• 在Hyperledger结构中，由订购服务生成的块是最终的。一旦一笔交易被写入一个区块，它在分类账中的位置就会得到不变的保证。正如我们前面所说，Hyperledger结构的最终性意味着不存在分类账分叉，并且验证的交易将永远不会恢复或删除
• Raft遵循“领导者和追随者”模型，其中选择一个领导者节点（每个通道），追随者复制其决策

因此，如果在实施过程中考虑到以上几点，并考虑到安全性，则不应认为这是一个安全缺陷，因为订购方只进行订购，看不到交易，在提交交易之前由对等方验证，对等方和订购方是不同的组织，一旦交易按顺序提交，它将是最终的，在其顺序和位置上是不可变的。

资料来源：