为什么极力反对同时成为申请者和排序者组织？
Why is it highly discouraged to be an application and orderer organization at the same time?
让我们以 3 个公平组织为例，即每个组织都运行对等组织，并且应该平等地参与订购过程。
对我来说，将这 3 个组织配置为拥有一个排序节点和一些对等节点感觉很自然。但是，强烈建议不要使用此设置。引自 FAQ:
Question: Can I have an organization act both in an ordering and application role?
Answer: Although this is possible, it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
在 another SO question 中，有一个回答更详细地介绍了这个主题：
First, it's very easy to misconfigure your policies and reduce the security of the system significantly. The ordering service and the application operate based on the principle of separation of powers. It is important that ordering nodes cannot fabricate authenticate transactions, and it is likewise important that application transactors cannot fabricate blocks.
并继续：
Second, because the MSP definition must appear in both sections of the channel config, you end up with two identical copies of the MSP definition, which must be kept exactly in sync. Since both MSPs have the same ID, if the contents are not exactly the same, then it creates an ambiguity in evaluating identities.
如果此设置配置不当，我整晚都在思考哪些攻击媒介和参与者可能会对我的组织或整个网络带来潜在的安全风险。
不幸的是，我只能想到一种情况：如果排序节点二进制文件中存在漏洞，另一个组织的排序节点可能会利用此漏洞以我的组织身份创建交易。
问题：如果您在单个组织中有同级和订购者并且配置不正确，会暴露哪些攻击媒介？谁会是演员？客户、管理员、网络的其他组织，完全的局外人？
奖励问题：在给定场景中建议的替代方案是什么？是否应该将每个参与组织拆分成一个单独的同级组织和排序组织？像 Company1PeerOrg、Company1OrdererOrg、Company2PeerOrg、...?
Question: What attack vectors can be exposed, if you have peers and orderers in a single organization and it's not configured correctly? Who would be the actors? Clients, admins, other organizations of the network, complete outsiders?
对于正常的交易流程，在提交交易之前，基本上需要签署三种类型的参与方。
首先是提交者或客户，他们请求背书、创建交易并将其发送到订单。一般来说，客户端属于ApplicationWriters的范畴。他们被授权调用对等 API 和排序者广播。
其次是执行交易并产生交易结果的节点。节点知道执行时的世界状态，以及与调用的链码相关的业务逻辑。对等方签署执行结果以证明业务逻辑已正确执行。 Peer 通常属于应用程序 Reader 的类别，因为他们需要查看所有交易以保持其世界状态最新（因此他们可以执行以帮助产生新交易）。
最后是orderer(s)，它为交易建立一个总的订单，将其放入一个区块中，然后签名以证明该订单已达成共识，并且peer可以考虑该交易的命令为最终命令。排序器属于排序器 Reader 和 Writer 的类别，因为它们复制现有链并附加到它们。
那么，关于您的问题，如果将这些角色混为一谈，会出现什么问题。如果一个身份被错误地设计，或者策略被错误地设计成一个单一的身份可以满足所有这些角色，那么这个身份就有可能进行双花攻击。
松散的架构，因为这个身份有资格作为客户端，它可以创建两个看起来有效的交易，一个向 Alice 发送 5 美元，另一个向 Bob 发送相同的 5 美元。通常，交易被发送到ordering，接收total order，第一个获胜。然而，因为这个身份可以充当排序者，它可以产生两个具有相同块号的看起来有效的块，每个块包含一个交易。现在，如果没有有效的 TLS 服务器证书，客户端无法将区块作为排序者注入系统，但是，如果身份是对等方，那么它现在可以尝试通过八卦工具将区块注入网络.如果可以诱骗两个不同的节点采用两个不同的伪造块，那么这些节点都会认为他们看到的 tx 是有效的。而且，你现在已经产生了双花。 （当然网络最终会检测到伪造的区块，这可以归咎于此，但损害已经造成。）
可能还有其他新颖的攻击，但希望这能证明让一个身份同时满足所有三个角色是有问题的。在 Fabric v1.0 中，唯一的角色是 "Admin" 和 "Member"。所以在这个时候，订购组织和应用组织不重叠是绝对关键的。然后引入了"Peer"的作用，最后是后来的"Orderer"。这些新角色使制定策略以确保网络安全变得更加容易，但在 CA 级别拆分这些组织仍然比在角色级别拆分更安全。
Bonus question: What is the proposed alternative in the given scenario? Should each participating organization been split into a separate peer and orderer organization? Like Company1PeerOrg, Company1OrdererOrg, Company2PeerOrg,...?
是的，建议为每个成员简单地设置一个逻辑排序组织和应用程序组织。
让我们以 3 个公平组织为例，即每个组织都运行对等组织，并且应该平等地参与订购过程。
对我来说，将这 3 个组织配置为拥有一个排序节点和一些对等节点感觉很自然。但是，强烈建议不要使用此设置。引自 FAQ:
Question: Can I have an organization act both in an ordering and application role?
Answer: Although this is possible, it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
在 another SO question 中，有一个回答更详细地介绍了这个主题：
First, it's very easy to misconfigure your policies and reduce the security of the system significantly. The ordering service and the application operate based on the principle of separation of powers. It is important that ordering nodes cannot fabricate authenticate transactions, and it is likewise important that application transactors cannot fabricate blocks.
并继续：
Second, because the MSP definition must appear in both sections of the channel config, you end up with two identical copies of the MSP definition, which must be kept exactly in sync. Since both MSPs have the same ID, if the contents are not exactly the same, then it creates an ambiguity in evaluating identities.
如果此设置配置不当，我整晚都在思考哪些攻击媒介和参与者可能会对我的组织或整个网络带来潜在的安全风险。
不幸的是，我只能想到一种情况：如果排序节点二进制文件中存在漏洞，另一个组织的排序节点可能会利用此漏洞以我的组织身份创建交易。
问题：如果您在单个组织中有同级和订购者并且配置不正确，会暴露哪些攻击媒介？谁会是演员？客户、管理员、网络的其他组织，完全的局外人？
奖励问题：在给定场景中建议的替代方案是什么？是否应该将每个参与组织拆分成一个单独的同级组织和排序组织？像 Company1PeerOrg、Company1OrdererOrg、Company2PeerOrg、...?
Question: What attack vectors can be exposed, if you have peers and orderers in a single organization and it's not configured correctly? Who would be the actors? Clients, admins, other organizations of the network, complete outsiders?
对于正常的交易流程，在提交交易之前，基本上需要签署三种类型的参与方。
首先是提交者或客户，他们请求背书、创建交易并将其发送到订单。一般来说，客户端属于ApplicationWriters的范畴。他们被授权调用对等 API 和排序者广播。
其次是执行交易并产生交易结果的节点。节点知道执行时的世界状态，以及与调用的链码相关的业务逻辑。对等方签署执行结果以证明业务逻辑已正确执行。 Peer 通常属于应用程序 Reader 的类别，因为他们需要查看所有交易以保持其世界状态最新（因此他们可以执行以帮助产生新交易）。
最后是orderer(s)，它为交易建立一个总的订单，将其放入一个区块中，然后签名以证明该订单已达成共识，并且peer可以考虑该交易的命令为最终命令。排序器属于排序器 Reader 和 Writer 的类别，因为它们复制现有链并附加到它们。
那么，关于您的问题，如果将这些角色混为一谈，会出现什么问题。如果一个身份被错误地设计，或者策略被错误地设计成一个单一的身份可以满足所有这些角色，那么这个身份就有可能进行双花攻击。
松散的架构，因为这个身份有资格作为客户端，它可以创建两个看起来有效的交易，一个向 Alice 发送 5 美元，另一个向 Bob 发送相同的 5 美元。通常，交易被发送到ordering，接收total order，第一个获胜。然而，因为这个身份可以充当排序者，它可以产生两个具有相同块号的看起来有效的块，每个块包含一个交易。现在，如果没有有效的 TLS 服务器证书，客户端无法将区块作为排序者注入系统，但是，如果身份是对等方，那么它现在可以尝试通过八卦工具将区块注入网络.如果可以诱骗两个不同的节点采用两个不同的伪造块，那么这些节点都会认为他们看到的 tx 是有效的。而且，你现在已经产生了双花。 （当然网络最终会检测到伪造的区块，这可以归咎于此，但损害已经造成。）
可能还有其他新颖的攻击，但希望这能证明让一个身份同时满足所有三个角色是有问题的。在 Fabric v1.0 中，唯一的角色是 "Admin" 和 "Member"。所以在这个时候，订购组织和应用组织不重叠是绝对关键的。然后引入了"Peer"的作用，最后是后来的"Orderer"。这些新角色使制定策略以确保网络安全变得更加容易，但在 CA 级别拆分这些组织仍然比在角色级别拆分更安全。
Bonus question: What is the proposed alternative in the given scenario? Should each participating organization been split into a separate peer and orderer organization? Like Company1PeerOrg, Company1OrdererOrg, Company2PeerOrg,...?
是的，建议为每个成员简单地设置一个逻辑排序组织和应用程序组织。