我们正在从HL Composer过渡到本机Fabric，并尝试调整我们一直在为您的示例网络讨论开发的可行演示模型： https://hyperledger-fabric.readthedocs.io/en/release-1.4/network/network.html
我们的网络规则仅稍有不同，但是有人可以确认或纠正我们的方法吗？区别如下：
R1，R2，R3，R4和R5这五个组织共同决定并签署协议，他们将建立和利用HL Fabric网络，即我们的演示网络N。
差异— R4是R1的公司母公司，并且对R1所做的一切进行业务监督–但不参与日常运营。这很重要，因为它想查看/查看所有内容，但本身不执行任何操作。
背景-R1向R2和R3都收取一定费用的某些资产。它可以向两者借出相同的资产，但贷款交易的条款在R1 / R2和R1 / R3之间是私有的。因为R2和R3是慈善机构，所以当某些事件发生时，R2和R3也会向R5支付费用。 R5除了接收并确认已收到该慈善机构外，不在网络上进行其他任何交易。
为清楚起见进行编辑：与示例HLF网络不同，我们的演示网络在C2上具有R1和R3，而不是R2和R3。
R4已被指定为网络发起者（admin）–已被授予设置网络初始版本的权力。 R4无意在网络上执行业务交易。
差异—但是，我们希望R4对所有交易，资产转移等具有完全的可见性。IOW，我们希望使R4对演示网络N拥有“上帝的眼光”。一切都包括渠道活动。
这可能吗？
R1和R2需要在整个网络内进行专用通信。 R1和R3具有相同的需求。差异-R5有权查看C1和C2上的某些交易-确认正在从R2和R3进行正确付款并接受这些付款。 R5还可以向R1和R4提交交易报告。
这可能吗？ IOW是否可以通过某些权利将R5加入C1和C2？ C1将授予R5审查付款建议，接受并报告的权利。 C2会做同样的事情。隐私将在C1内维护，与C2相同。 IOW R2和R3将无法看到彼此的活动。
示例网络讨论的所有其他方面-订购服务，渠道数量等，我们希望保持不变-使用您当前的逻辑。
除了您的其他详细信息外，这五个组织中的每一个都有首选的证书颁发机构，例如我们将为R5添加一个CA。
我们认为R5不需要单独的同级或订购服务，但这可能是错误的-有人可以确认或更正吗？
谢谢您的指导。
答案 0 :(得分：1)
您已经问了很多问题，我将尝试以无特定顺序回答尽可能多的问题。我认为有些困惑是由于该系统中没有permissions.acl的等同物。
差异— R4是R1的公司母公司，并且对R1所做的一切进行业务监督–但不参与日常运营。这很重要，因为它想查看/查看所有内容，但本身不执行任何操作。
如果您希望每个组织都拥有自己的CA，那么这一点无关紧要。 R4将拥有自己的对等节点和CA。如果您愿意将R4和R1视为一个实体，则可以将系统缩减为4个组织。
R4已被指定为网络发起方（admin）–已被授予设置网络初始版本的权力。
Afaik没有网络启动器之类的东西。在Hyperledger Composer中，我们所谓的PeerAdmin是单个组织的管理员。对于要建立的网络，每个组织都有自己的管理员，他们将对等连接到渠道并安装所需的链码。这必须是共同的努力。
R4无意在网络上执行业务交易。
太好了，那么R4不需要进行任何API调用。这里没什么可做的。
我们希望为R4提供演示网络的“众目view”
仅当R4下的对等节点已加入所有通道时才可能。他们会自动获得读取权限，并可以执行丰富的查询。
R5有权查看C1和C2上的某些交易
像R5这样的声音是一种调节器/监督器。为此，他们需要同时加入您已经确定的两个通道，这意味着R5的人员可以访问R4设置的节点，也可以拥有自己的节点。在IRL场景中，监督者应该自己拥有独立的对等节点。
答案 1 :(得分：0)
现在看来这一切都很好，但是随着组织的数量不断增加，在不同组织之间维持独立的渠道将成为一个噩梦，而且还会影响性能。
为什么不尝试使用私有数据收集，而不是每次都希望在两方之间保持私密性时添加新渠道。这样，只有网络中的有意方才能查看交易数据。 / p>
R5需要一个同级。