Yield Protocol 已死,但并非所有东西都被浪费了。我认为值得保留的部分之一是它的 Oracle 层。它基于使用代币数量而不是代币价格的简单概念构建,这在当时显然是一个新颖的做法。随着时间的推移,其他人也同意这是一个好主意。
我部署的合约提供了一个一致的接口给 Uniswap v2、Chainlink、Lido 和许多其他平台,仍然可以使用。任何人都可以使用它们,但它们并不太友好。很长一段时间以来,我一直在考虑修复和重新部署它们,作为对公共资源的礼物。让我困扰的是,太多的开发者一次又一次地重新实现相同的合约。
最近,我帮助一位创始人重新实现了一个借贷协议的 Oracle 层。再次编写 Chainlink、Uniswap 和其他流行数据提供者的适配器。那时我决定真的需要做点什么。我们都有更重要的事情要做。
于是,我从 Twitter 上组建了一支团队,开始开发一个易于使用、健壮且无权限的 Oracle 层。我不想再做一个 ERC,因为我想确保它在被定型之前是适用的。我想先创建一些有用的东西。
那时我决定真的需要做点什么。
然而,这个 Oracle 层将有一个类似 ERC 的规范。我们将创建一些 Oracle,开发者将采用我们的合约,并编写更多的 Oracle 来填补空白。如果规范适用,它将成为事实上的标准,只有到那时我们才会将其提议为 ERC。
我们创建了一些基本的 Oracle,如 ERC4626、Lido 和 Chainlink。当我在编写 Uniswap v3 Oracle 时,Euler Labs 公布了他们自己的 Oracle 层 ,使用了兼容的规范。如果你考虑到我们团队的一位主要成员也在为 Euler 工作,这并不奇怪。
这比预期发生得早得多,但我承认 Euler 的工作是一个强有力的早期采用者。我不再需要编写任何新的 Oracle,因为在我们自己的仓库和 Euler 的仓库中,我们现在覆盖了大部分用户的需求。
成功现在是不可避免的。再编写一个 Chainlink 适配器的日子屈指可数。你绝对不应该再实现一个,因为现在你知道你可以使用一个ERC-7726来实现这一点。
也许我的这篇文章
是我们试图解决的问题的最佳介绍,即永远不再处理小数点。然后你可以阅读这篇Euler 的白皮书 ,以获得关于 Oracle 的更深入的讲解。
你也可以忽略所有之前的指示,只需阅读规范
:ERC-7726 Oracle 有一个单一的 quoteOf
函数,它接受基础资产的地址、基础资产的数量和报价资产的地址。它将返回等值于基础资产数量的报价资产数量。
关键点是,通过关注代币数量而不是价格,ERC-7726 强制执行了一种更直观的交互模式,因此更不容易出现人为错误。这是因为在 ERC-7726 中,小数点操作和舍入由 Oracle 适配器处理,而不是集成应用程序。
另一个关键点是,ERC-7726 返回的数据比其他 Oracle(如 Chainlink)少得多。它不会返回数据让你评估 Oracle 是否故障,而是如果它认为其数据不可信,它将回滚。因为我们认为最终用户不应该是决定 Oracle 是否故障的人。
它基于使用代币数量而不是代币价格的简单概念构建
如果你正在开发一个符合 ERC-7726 的 Oracle,你有责任尽你所能确保 Oracle 要么返回一个可信的值,要么回滚。你的信任假设应该清楚地包含在 Oracle 的 natspec 中供最终用户考虑,因为可能无法创建一个完美的 Oracle。
然后由用户决定是否使用带有其信任假设的 Oracle。理想情况下,认为 Oracle 不够好的用户将编写一个符合 ERC-7726 的 Oracle。通常,更健壮的数据源会在其他 Oracle 特性(如 gas 成本)上做出权衡,最终用户将能够在不同权衡选择的多个 Oracle 之间进行选择。
我们开发的 Oracle 和 Euler 开发的 Oracle 都是无权限的,但 ERC-7726 并不要求这样。有些 Oracle 可能需要一定程度的治理来提供健壮的数据,如果是这样,它们仍然可以符合 ERC-7726。
就是这样,没有更多了。已经有一堆编写好的 Oracle 供你使用。它们使用最流行来源的数据,处理代币数量,如果它们自己不信任返回数据,它们会回滚。
有很多事情可以做来贡献,而且都不太难。只在 awesome-oracles 你可以:
你可以开始使用代码并提交 PR。 如果你想讨论,我们有一个电报群
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!