在以太坊上使用 Oracle 的最佳实践

DeFi(去中心化金融应用)是以太坊生态系统中新生且快速增长的一部分，其中一个的关键部分Oracle开始吸引了大家的注意力。

注： Oracle 是链上与链下数据交换的桥梁

如果没有Oracle，去中心化金融应用就只能获取链上数据、现实应用场景将会大大受限。很多人都知道，现在许多项目都已经在使用Oracle，但大家对Oracle的使用和相关安全模型却缺乏了解。很多新项目正在奖励，现有项目也在重构以满足更高的安全性，希望本文可以成为使用Oracle的最佳实践参考。

不是针对Oracle，仅仅是针对Oracle的使用者，我们不会过多地讨论Oracle的最佳设计原则和安全模型，只讨论在以太坊上构建应用时该如何使用Oracle。如果你希望自己开发合约或应用具备安全性，抗审查性和去中心化，可以参考以下建议：

建议 1：优先思考 Oracle 设计和交互

Oracle的最简单形式就是中心化的数据输入，就是由你（项目建立者）来输入价格数据，你可以看到很多协议在启动时使用这个方式，并且仅仅使用一个简单的多重签名来保障安全性。

选择 “渐进式去中心化” （这个说法也值得唠叨唠叨）的路线，宣称他们未来会切换到一个去中心化的Oracle。如果只是想参加黑客松，那也可以，因为中心化的Oracle性能比任何去中心化的Oracle都要高的多，如果在项目开始的时候采用中心化的Oracle, 很容易产生准确的数值总能即时提交到链上（去中心化的Oracle会做不到）的依赖， 然后基于不同系统容量和用户体验上的设计决策是截然不同。

践行这种渐进式去中心化理念的项目会处于一种尴尬的境地，即用户希望获得某种体验，但应用却在现有的去中心化技术栈上根本无法安全地实现。他们被迫通过在中心化的多重签名中加入多个参与方来假装去中心化，或者祈祷着公链可扩展性的不可能三角问题能够幸运地顺利解决。关键是，除非从一开始设计协议时就考虑加入去中心化的Oracle，否则去中心化的Oracle是很难添加到已存在的协议中的。

建议 2：不要依赖Oracle总能快速响应

我们总是喜欢假设它会能够正常运转并及时，但是也总有一些不太可能发生的情况发生，区块链的最终确定性可能需要几分钟才能确定，那 oracle 将无法输入数据。

以太坊依然是一个新生事物，尽管通常几秒钟就能出一个区块，但在转账比较频繁的时期，交易确认可能需要很长时间。如果你还记得区块链游戏 “迷恋猫” 导致的区块链堵塞事件，以及最近的 “黑色星期四” 导致转账费用暴涨事件，这时候用户如果不支付令人难以置信的高额矿工费他们的交易可能需要几个小时才能打包。即便应用用户在经济上有动力支付这些费用，你真的希望他们被迫支付这些费用吗？

除了网络堵塞问题，开发人员还应该考虑以太坊崩溃的极端情况。区块链网络不太可能长期中断，但是短时间中断是有可能的，因此必须考虑到在缺乏最终确定性的链上与（快速信息流动的）链下进行Oracle交互造成的影响。

我们总是希望协议能够保持正常和及时运行，但有时候这是做不到的，比如协议需要运行几分钟才能够确认最终性，那Oracle可能就无法输入数据了。并不是说找不到一个为 Oracle 设计的理想的时间框架，针对Oracle设计一个务实的运行间隔是很好的，但是一个稳定的去中心化金融协议应该为这些突发的极端情况做好预备。其中之一是：

建议 3：假设Oracle可能被破坏

不要在你的Oracle中假设最终确定性。许多协议都犯了依靠 Oracle更新来触发某些操作的错误（例如，一个衍生品合约仅当Oracle更新的时候才能完成结算）。这是一个错误。你应该有一套标准的操作流程，以防止Oracle出现错误的情况，即使我们希望这种情况永远不会出现。

回顾一下，Oracle可能出现两种错误：

• 你的Oracle提交了一个错误的值。
• 你的Oracle宕机了从而不往链上提交数据

第一种情况问题，举个例子，如果你使用的是中心化的价格Oracle，而价格提供方意外地将价格乘以10000，你肯定不想以这个值结算，甚至Oracle本身也会删除这个值（在 Tellor Oracle中这会引发争执并被移除），但问题仍然存在 —— 需要等多久才能对数据进行验证？

最终取决于协议的设计，因为有些智能合约可能比其他合约需要一个 更慢/更健壮 的检查机制和确认机制。一个延迟确认的例子是 Maker 协议，Maker 协议 Oracle 更新周期是一个小时。慢一点，不要认为数据都是对的。

第二种破坏Oracle机制的方式显得更加迂回。一个例子就是中心化Oracle丢失了私钥导致不能更新合约，那这时候你的衍生品智能合约会怎么样？另外一个影响Oracle 活跃的事情是，数据提供者不愿意（足够）快速提供数据。假设以太坊网络堵塞，每笔交易的矿工费是 20 美元，而你的Oracle只提供每笔 1 美元的交易手续费，那么智能合约可能要花费几个小时才能更新数据，回到建议 2 的角度看，你可能为此做了准备，但也应该知道数据提供商是否有能力单方面控制此延迟。在 Tellor 中，我们通过 POW 的竞争方式让数据上链，因此活跃度得到了激励机制的保证。一些更为中心化的Oracle则没有这样的保证，Oracle提供者可以容忍延迟交易，甚至可以根据贿赂或自己的立场对数据进行审查。

当一个Oracle 宕机或者涉嫌中心化控制时，这是几个可能的应对方法（当然最好别用到），包括：

• 停止合约执行并等待Oracle反馈正确的数值
• 转向使用另一个/后备的 Oracle
• 启用多个Oracle

• 返还所有资金/用默认数值完成结算 主要强调的是协议层面处理 Oracle 的后备和安全性，后备选项在每种情况下应该怎么使用很难用一个统一的范式来表达，但要确保各方完全没有动力去采用这些后备选项，后备机制的目的是保障网络安全，而不是为恶意攻击提供另一条路径。

  建议 4：知道破坏Oracle的成本

  无论你是否承认，攻击者总有办法破坏Oracle，只是成本不同罢了。有些时候这个成本是购买声誉或投票支出，有些时候是项目所发行的代币市值的一部分，或许更多的情况是买通数据提供者或对相关参与方的成本（例如传统的中心化模式）。 无论破坏Oracle的成本实际是多高，破坏Oracle的代价也不是一成不变的，你都应该对你的协议的安全性有一个大致的了解。对于希望有朝一日会持有数百万甚至数十亿美元资金的项目来说，拿只有几百万美元市值的 token 来给Oracle的安全性背书，或者拿某些团体的声誉来背书，都有很大的风险。 知道破坏Oracle的成本可以让协议开发者明白要多少安全措施才可以保证系统的稳定，使用一个Oracle也许无法保证智能合约资产的安全性，但是使用多个Oracle或者采取一些后备方案，将会使得对合约的攻击成本大大提高。目前，已经有人提交一份以太坊升级提案（EIP2362），这份提案通过标准化价格和数据流数据来让新的协议（合约）能够简单快速地集成多个Oracle。

  

补充

你应该知道你的协议最终的安全性来自哪里，如果你将价格数据安全性外包给一个数据提供者，那么请了解他们在什么情况下会出问题，并相应地采取对策。如果你给自己的协议设计了终极治理机制，请确保这个机制能保护整个系统的公正性和去中心化。以太坊是一个了不起的生态系统，在它上面建立了很多最顶级的项目，同时Oracle也得到了应有的关注。我们可以在去中心化网路上建立一个有意义的系统，只需我们诚实地面对目前的技术限制，灵活地处理遇到的极端情况，并有决心创建真正去中心化的应用程序。 原文链接: https://medium.com/tellor/best-practices-for-oracle-users-on-ethereum-1ad9e2a43c3b 作者： Tellor Core， Tellor 是一个 简单又安全的去中心化预言机解决方案。