Hyperledger fabric 在Hyperledger结构中，我们是否可以强制交易由遗留/链外系统验证？

与许多区块链解决方案（例如：以太坊、Corda）不同，Fabric的背书架构意味着智能合约不必是确定性的和沙盒式的：唯一重要的是背书人同意R/W集

从中，可以通过链码执行与外部世界通信

如果验证逻辑很复杂和/或依赖于世界状态之外的数据，那么是否可以调用Web服务来执行验证

---

另外：假设链码策略强制组织Org1认可所有事务，那么我们应该能够编写一个链码来检查执行上下文，并且只有在验证Web服务由Org1执行时才调用它，并根据WS调用的结果拒绝事务或继续。这是正确的吗？

在我看来，背书政策在所有背书对等方之间验证世界状态，以便所有组织的对等方都同意世界状态

您所指的不是背书政策，而是智能合同中的逻辑。这在任何链码实现中都是可能的，但如果您正在使用Hyperledger Composer实现链码，那么从他们的文档中可以看出：

运行时API是所有事务的可用API 功能。它允许访问API来生成和发出查询- 发出事件-获取所有类型的注册表-获取当前 参与者-获取序列化程序以从JavaScript创建资源 对象-post HTTP REST调用

根据最后一部分

post-httprest

调用，您应该能够在逻辑上拒绝任何事务'

如果验证逻辑很复杂和/或依赖于世界状态之外的数据，那么是否可以调用Web服务来执行验证

虽然从技术上讲，可以提供VSCC（验证系统链码）的定制实现，但我建议您不要这样做，因为这可能会导致不确定的结果

例如，您有您的外部web服务和两个对等方，它们根据此服务验证事务。如果由于某种原因，peer1无法访问web服务，而peer2可以访问，则验证结果将不同。因此，您应该非常小心并且避免在进行验证时调用外部系统或考虑将外部Web服务调用为链代码执行流程的一部分。 另外：假设链码策略强制组织Org1认可所有事务，那么我们应该能够编写一个链码来检查执行上下文，并且只有在验证Web服务由Org1执行时才调用它，并根据WS调用的结果拒绝事务或继续。对吗

默认的验证系统链码注意确保每当满足背书策略时，该链码都会生效，因此在您的示例中，如果Org1未背书交易，则该链码将失效