mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

a16z:详解代币化金库标准ERC-4626,如何让DeFi可组合性更安全?

Collect
Share

原文作者:Daejun Park

原文 编译:aididiaojp.eth,Foresight News

随着 DeFi 不断发展并逐渐成熟,开发人员的首要考虑是可扩展的基础设施和可组合性。用于构建基于以太坊的应用程序的标准化工具包 ERC 一直发挥着重要作用。例如广泛使用的代币标准 ERC-20 为开发人员提供一致的指导方针,让他们无需从头开始就可以为生态系统做出贡献。今年早些时候,为了鼓励收益型代币之间的交叉兼容性,代币化金库标准 ERC-4626 被推出。除此之外,ERC-4626 还可以解决紧迫的可组合性问题,使协议集成更容易,减少出错几率。

目前已经有一些 DeFi 项目为了提高其金库的可组合性,采用了该标准,我们预计整个生态系统将得到更广泛的采用。然而,调整现有的金库确实会带来一些痛苦,至关重要的是某些实施错误可能被暴露,成为新的攻击目标。即使是很小的错误(小到对使用界面的误解)也会对 安全 和用户体验产生重大影响,因此还需要更多的安全工具和措施,特别是在更可组合的 DeFi 生态系统中。

如果在被攻击之前就检测到简单的错误,则可以提供相对简单的解决方案,理想情况下甚至在部署之前就能进行检查。为此,我们发布了用于模糊测试和符号执行的 ERC-4626 属性测试,以帮助金库构建者检测可能破坏集成或导致漏洞的标准违规行为。这篇文章解释了激励问题,介绍了检测方法,并在结尾处提到一些可行的建议。

ERC-4626 标准的背景

ERC-4626 于 3 月被推出,是一套代币化金库的标准,旨在扩展广泛使用的 ERC-20 标准,推动跨收益金库的标准化,并确保需要与其交互的应用程序和协议(例如收益聚合器)的可组合性。这意味着为了与任何其他 ERC-4626 金库一起使用,在 ERC-4626 金库上构建的任何应用程序都可以轻松扩展。

金库代币化后,能够允许用户自由存入资产来铸造金库代币,然后赎回这些代币从金库中提取本金和利息。这些金库代币是 ERC-20 代币,可以轻松被交易或用作抵押以借入其他资产。例如,用户可以将他们的资产存入 Yearn 金库以铸造 yVault 代币,然后在 Uniswap 上进行交易、抵押以获得额外收益,也可以用作贷款协议的抵押品。

产生、分配收益以及确定代币价格的逻辑可能因实际情况而异。为了覆盖尽可能多的金库,ERC-4626 标准侧重于构建用户界面,而大部分实现细节未确定。只要金库满足接口的特定要求,就能够允许业务逻辑的变化,实现跨许多不同类型的应用程序和 ERC-4626 金库类型的互操作性。

随着越来越多的代币化金库被创建,我们希望看到它们从一开始就按照 ERC-4626 标准实施。但我们目前处于某种过渡阶段,为了符合标准,开发人员将需要以更大可组合性的方式来更新现有的金库、应用程序和协议,他们也面临着许多复杂挑战。

标准一致性的挑战

遵循新标准并不总是那么简单。每个 ERC-4626 金库都必须忠实且准确地实现所描述的标准要求,否则为了应对不同的变化,集成会变得越来越复杂。这种复杂性使集成天生容易出错。并且由于它们没有足够安全测试,随着时间的推移可能会导致系统漏洞。

为了安全地处理不同的行为,非 ERC-20 标准代币需要许多 DeFi 系统在执行代币转移时使用额外的金库。例如 Tether USD 在执行代币转移时需要额外用到 SafeERC-20。

这意味着如果系统的设计不能正确处理「丢失退货」的情况,任何与这些代币交互的系统都可能变得脆弱。这些场景可能会引入一个常见的安全陷阱,并增加整体开发和维护成本。因此,符合标准不仅对个人至关重要,而且对整个生态系统的安全也至关重要,单个系统或依赖项中的一个漏洞就可能会导致广泛的问题。

理想情况下,标准将被明确地正式指定,并且每个实现都可以根据标准规范进行正式验证。然而在实践中需要社区的努力且需要一定的费用或时间成本,这在短时间内并不容易实现。

通过引入可执行的 ERC-4626 属性,识别一致性问题

当我们朝着理想状态努力,每个金库都根据严格的正式规范进行了正式验证时,为了捕捉标准要求的微妙、容易遗漏的细节中的差异,我们编写了 ERC-4626 标准属性。

为了检测其实施中潜在的标准违规行为,代币化金库的开发人员可以在部署之前运行测试。金库集成商可以检查给定的金库是否符合标准,然后再将它们集成到他们的系统中。针对已经部署在主网上的实时金库,也可以通过主网 分叉 测试的方式进行测试。为了确保所有系统参数都已正确设置,尤其是在最近部署或升级的金库,测试实时金库可能会很有用。

为了使属性可执行,我们用 Foundry 编写,并由 fuzzer 运行。为了正式验证给定的进金库是否满足所有可能的输入和条件的属性,将来它们也可能由符号执行或模型检查工具运行。

在编写时通用性是首先考虑的,我们希望测试可以应用于实现不同业务逻辑的各种金库。我们只使用公共接口函数来使它们与实现细节无关。但是由于此限制,某些涉及特定于实现的内部数据的标准要求从属性中省略了。

例如,以下属性对应于 convert To Shares() 函数的要求之一,「不得根据调用者显示任何变化。」

给定两个账户地址和金额,它使每个账户以相同的金额调用 convertToShares(),并确保两个返回值相等。此属性独立于实现细节 convertToShares()。这些细节因金库的不同而异,并且必须由任何实现 ERC-4626 的金库来满足。在这种情况下可以通过提供特定输入值(用于单元测试)、许多用于模糊测试的随机输入或用于符号执行和形式验证的符号值来执行此属性。它也可以在本地运行或针对主网分叉运行。

a16z:详解代币化金库标准ERC-4626,如何让DeFi可组合性更安全?

用例:测试舍入错误的属性

例如舍入错误是一类看似轻微的但很重要的错误,它可能会产生一些系列影响。在 ERC-4626 的基本会计逻辑中,舍入误差是不可避免的,例如计算要铸造的资产数量,或要提取的资产数量,等使用定点算法实现的指令。为了安全性考虑,该标准明确指定了每个接口函数的首选舍入方向,同时未指定误差范围。具体来说 deposit() 和 redeem() 函数应该返回一个低于精确值的近似值,而 mint() 和 withdraw() 函数应该返回一个高于精确值的近似值。例如当前股价(即每股资产数量)为 2,那么 deposit()3 wei 的资产最多只能铸造 1 wei 的代币(即 floor(3/2)),而 withdraw()3 wei 的资产应该在至少 2 wei 的代币(即 ceil(3/2))。

我们将舍入相关属性编写为独立于基础会计逻辑,并将其视为「黑匣子」。具体来说我们将它们表述为所谓的「往返」属性,它描述了两个相反函数之间的关系。例如以下属性规定,通过铸造 N 股来提取刚刚托管的资产必须燃烧不少于 N 股。换句话说,没有人可以通过反复铸造和提现来反复转换资产和金库代币来获利。

a16z:详解代币化金库标准ERC-4626,如何让DeFi可组合性更安全?

事实上,我们发现主网上的几个 ERC-4626 保险库由于舍入错误而无法满足上述属性。这意味着任何人都可以通过简单的反复铸造和提取,慢慢地耗尽金库来赚取 satoshi BTC (在撰写本文时为 1 satoshi ~= 0.02 美分)。在低 Gas 费的链如 Fantom 上可能会实现获利,或者在价格上涨时也会获利。

ERC-4626 标准的广泛测试

我们在主网上约 100 个 ERC-4626 金库进行了属性测试,发现许多金库未能遵循标准要求。其中的主要原因是舍入错误。具体来说 mint() 函数尽管标准明确要求这样做,但某些金库未能铸造该函数请求的确切份额数量。其中一些还发出了不一致的 Deposit 事件,其中记录的数据与实际生成的数据不同,甚至有些金库根本就没有进行现场铸造过。相反他们只是将铸币请求放入队列中,稍后将它们作为单独的事务分批处理。

尽管这些不同的行为本身是不可利用的,但当它们集成到只执行标准行为的其他系统中时,它们可能会变得容易受到攻击。这些问题将使金库集成变得更加困难,可能会抵消一部分努力。

属性测试和其他可操作的步骤实现标准一致性

在部署之前严格遵循标准可以防止出现不同的行为。我们希望我们的属性和一些额外的操作项对于那些正在开发或集成 ERC-4626 金库的人能够提供帮助:

 

  • 我们强烈建议对您的金库运行属性测试。如果有任何明显违反标准的行为,问题会很快被发现。

  • 我们还建议检查我们的属性,以检查您对标准要求的理解,如果有任何无意的差异,请调整实施方案。

  • 如果金库必须偏离标准,我们建议明确记录非标准行为,以便其他人在与金库集成时可以正确处理这些偏差。

小结

在可预见的未来,ERC-4626 金库有可能成为 DeFi 的重要组成部分。为了保持可组合性,新的和现有的金库都必须遵循该标准。新的标准将出现,因此现在是现有金库标准化的最佳时机。

当我们朝着不同金库统一组合的理想状态努力时,可以运行 ERC-4626 属性测试以更轻松地检测金库实施中的标准违规行为。属性测试的文档和示例都在我们的 Github 存储库中公开可用。

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content