笔记：Hyperledger Fabric的链外数据相关

起因：当智能合约不再智能，我们

智能合约的验证和验证创造了透明度，并增加了对管理网络中执行的交易的流程和规则的可见性。因此，理想情况下，所有事务逻辑都应该封装在智能合约中，以保证参与交易背书过程的所有对等方执行相同的代码。

但是，在某些情况下，智能合约可能不具备完成交易处理所需的所有知识。例如，智能合约可能需要在运行时从外部系统获取不稳定的信息（如股票价格）。或者，管理一个事务的业务规则可能非常复杂和复杂，因此将它们外部化更合适。这样的情况让我们想到以下问题。

方法

第一种方法（可信第三方程序）

将智能合约的操作边界扩展到第三方系统（例如，IBM operational Decision Manager，ODM）。在这个模型中，区块链网络中的对等方调用与他们位于同一位置的第三方服务。基本假设是调用的结果是确定的。

注意事项

从技术角度，这是一个对于从现有复杂规则到新的blockchain平台的理想解决方案。但是如果需要重新实现成百上千已经实现的业务规则，对于组织而言是一大笔成本开销。另外一个缺点，是现在的智能合约缺少用户交互，对于需要人工交互数据的业务不太适合。

需要避免

• 每个组织的规则不一致，导致结果不一致，使得无法达成共识）
• 数据最终不存在智能账本上，导致没有结果可供共识，使得无法达成共识
• 第三方接口版本不同，导致结果不一致，使得无法达成共识
• 第三方是否可信问题，比如Fabric 2.x版本的chaincode审批流程

上述架构方法允许组织利用区块链网络解决方案中的现有构件，同时确保这些构件是防篡改的，并且可以在安装或更新时对其进行验证和审查。

请注意，虽然这种架构方法保持了您在区块链网络中所期望的信任，但它会带来额外的成本和运营顾虑。这主要是由于第三方系统需要与网络对等方上的智能合约共存的配置和持续维护。

第二种方法（可信预言机）

引入智能合约可以调用的链外服务。在这个模型中，oracle是一个可信的第三方，它以确定性的方式回答问题，而不知道事务的完整上下文。换言之，隐私和保密性得到保护。