单组织双Peer场景下Fabric Composer背书机制及相关问题咨询

嘿，我来帮你把单组织双Peer场景下Fabric Composer的背书机制拆解得明明白白，一个个问题给你捋清楚：

关于单组织下的背书策略定义 #

你从文档和Rocket Chat了解到的“单组织无法定义背书策略”，其实是Fabric Composer在简化部署时的默认逻辑——当网络只有一个组织时，Composer会自动套用该组织内所有已安装链码的Peer都需参与背书的默认规则，不需要用户手动配置复杂的策略表达式。不过从Fabric底层来说，单组织其实是可以自定义策略的（比如要求组织内至少1个Peer背书，或者指定某几个特定Peer），只是Composer为了降低单组织场景的配置门槛，把这一步给默认化了。

组织内Peer结果不一致时的背书行为 #

如果同一组织内的两个Peer执行链码后给出不同的结果，背书环节会直接失败，具体流程是这样的：

• 客户端发起交易后，会把交易提案同时发给这两个Peer
• 每个Peer独立执行链码模拟交易，生成包含结果、读写集和自身签名的背书响应
• 客户端收到两个响应后，首先会校验所有响应的结果和读写集是否完全一致——一旦发现分歧，会立刻终止流程，不会把交易提交给排序节点
• 这时你会在客户端收到类似endorsement responses do not match的错误提示，交易绝对不会被写入账本

组织内的Peer是否自动成为背书节点 #

是的，但有两个关键细节要注意：

• 只要你把链码安装到该组织的Peer上，这个Peer就自动具备了背书能力
• 具体哪些Peer会被实际选为背书节点，取决于你的Composer配置：
  • 如果在connection.json里没有手动指定背书节点列表，Composer默认会把该组织内所有安装了链码的Peer都加入背书节点池
  • 客户端发起交易时，会向这个池里的所有Peer发送提案，它们都会参与背书流程

内容的提问来源于stack exchange，提问作者Akshay Jindal