探索ERC-4626：安全指南

摘要: ERC-4626 是一个用于代币化金库的标准。

在引入 ERC-4626 之前，每个金库都有其独特的规范和实现细节。这使得集成变得困难、易错且浪费。

ERC-4626 试图通过引入标准规范来解决这个问题，以降低集成工作量，并创造更一致和稳健的实现模式，就像 ERC-20 一样。

什么是 ERC-4626？

ERC-4626 是一个标准↗，旨在改善 收益金库的技术参数。↗ 它为代币化收益金库提供了一个标准 API，这些金库代表了单个基础 ERC-20 代币的份额。

代币化金库已成为 DeFi 中一种极为常见的模式。收益聚合器、借贷市场、质押衍生品和许多其他去中心化应用程序 (dApps) 都利用并依赖代币化金库。代币化金库的示例包括 Yearn 和 Balancer。作为一个收益聚合器，Yearn↗ 金库允许用户存入数字资产并获得收益。Balancer 作为一个自动化投资组合管理器和流动性提供者，在其业务逻辑的核心依赖于金库。这些金库在各种池中管理代币。与此同时，它们将代币的会计和管理与池逻辑分开。

各个协议将其金库代币化以增强流动性和灵活性。代币化金库允许在 DeFi 平台之间轻松交易和利用资产。此外，它们还使得多样化、互联的金融产品的创建成为可能。行业不断倡导这一范式，通常被称为“货币乐高”。

然而，如果没有适当的适应性或标准化，组合性将带来挑战。这不仅使开发者难以遵循诸如 ERC-20 的行业标准，还会让新开发者感到困惑。如果没有适当的适应性或标准化，审核新变更和验证集成的实现细节将变得困难。

ERC-4626 已被 提议↗ 来解决这个问题，并简化集成，同时允许 DeFi 玩家最终采用更安全、稳健的统一金库规范。这也将反过来减少协议在多个协议之间集成代币时需要覆盖的攻击面。

ERC-4626 预防了哪些安全问题？

通过提供一个统一的标准供项目遵循，ERC-4626 加快了跨协议集成的构建。一个熟悉的、统一的标准也便于开发者理解，这使得编码错误的可能性降低。这有助于防止组合性问题。标准化还避免了工作重复，因为社区只需设计一次金库，而不是为每个协议单独设计。由于这些设计工作通常容易出错，它有助于避免重复造成的常见设计陷阱。

我们将在这里讨论两个案例研究，以展示 ERC-4626 可以预防的各种问题。

Rari Capital 事件

Rari Capital 被 黑客攻击↗ ，损失约 1100 万美元的代币，占 Rari Capital 以太坊池中所有用户资金的 60%。

简而言之，Rari Capital 被黑客攻击是由于不安全的跨协议实现。其以太坊池将 ETH 存入 Alpha Finance 的 ibETH 代币合约作为收益生成策略。该策略通过 ibETH.totalETH() / ibETH.totalSupply() 公式跟踪其 ibETH/ETH 的比率。在此攻击场景中，例如调用 ibETH.work() 函数时，这可能会产生不正确的输出，因为债务价值可能被人为膨胀。

攻击者只是重复调用 RariFundManager 合约中的 deposit() 和 withdraw() 函数， draining 了 Rari Fund Manager。deposit() 和 withdraw() 函数需要获取池的余额，以计算应向调用者发放的 REPT 代币数量或应向调用者发放的 ETH 金额。这个操作又触发了 Alpha 池的 getBalance() 函数，调用 ibETH 合约及其 totalETH() 函数↗。Rari 对操控此函数的可能性毫不知情。

ibETH 合约中还有另一个函数 ibETH.work()。这个函数可以调用用户指定的任何合约。这使得 Rari 的 deposit() 和 withdraw() 函数变得可重入，可以多次调用。

work() 函数是一个 payable 函数，这意味着用户可以通过 work() 函数控制 ibETH 合约中的 ETH 数量，从而改变 totalETH() 函数返回的值。更糟的是，work() 函数还支持调用其他合约，如 RariFundManager。

通过这个函数，攻击者可以再次发送 ETH，膨胀 ibETH 合约中的 totalETH 数量，并在从 RariFundManager 合约调用 withdraw 时，兑换更多资产。

下面的事后报告摘录非常清楚地说明了 ERC-4626 提案的重要性，尤其是在采纳更统一的集成规范以避免类似此次攻击场景方面。

*为了避免未来出现此类问题，我们将实施以下额外安全措施：

1. 邀请我们集成的协议审核我们的集成安全性。这是迄今为止最重要的安全措施，因为协议本身对他们写的代码了如指掌。*

该事件凸显了在 DeFi 合约中不充分集成和不兼容设计的重大风险。它突显了像 ERC-4626 这样的标准，促进一致的行为和相互理解，有助于通过增加一个关键的安全层和可预测性来预防此类攻击。

Cream Finance 事件

Cream Finance 在一次复杂攻击中被 利用↗，攻击利用了平台的两个基本弱点，一个可操控的混合预言机和没有上限的代币供应。攻击的关键部分是操控混合预言机，这影响了 yUSD 代币的感知价值。当攻击者向 yUSD 金库发送大量 Yearn 4-Curve 代币时，就实现了这一目标，从而改变了金库报告的汇率，最终影响了预言机对 yUSD 代币的感知价值。

这里的关键教训是，强大且不可操控的价格预言机对 DeFi 协议的稳定性的重要性。时间加权平均价格 (TWAP) 预言机可以在特定时间段内计算平均价格，能够帮助防止这种黑客攻击，因为它们对突发价格操控更具抗性。这个不幸的事件强调了安全和可靠的预言机在保障 DeFi生态 系统健康与稳健中的关键作用。

通过 ERC-4626，协议目前被鼓励实施convert 方法，将时间加权平均价格用于资产与份额之间的转换。

这些以及其他脆弱性模式，可以通过仔细的采用和实施 ERC-4626 来考虑和缓解。

ERC-4626 下的潜在安全隐患

总是存在权衡。对于代币化金库，必须在将其集成到智能合约时谨慎对待潜在的隐患。

管理 feeOnTransfer 代币

如果金库旨在支持 feeOnTransfer 代币，请在转移资产时检查金库中的数量和份额是否在预期范围内，特别是在扣除费用时。

正确使用 decimals

尽管 convertTo 函数应消除对任何 EIP-4626 金库的 decimals 变量的使用，但仍强烈建议在可行的情况下，与基础代币的 decimals 保持一致。此做法有助于消除潜在的混淆来源，并简化各种前端和链外用户的集成。

四舍五入

根据规范↗，金库的实现者应意识到在不同的可变和查看方法中需要特定的、相 Opposite 的四舍五入方向，因为在计算时，为了安全起见，应优先考虑金库本身，而不是其用户：

• 如果(1)计算用户因提供特定数量的基础代币而应发放多少份额，或(2)确定针对返回特定数量份额应转移给他们的基础代币数量，则应向下取整。
• 如果(1)计算用户必须提供多少份额才能获得特定数量的基础代币，或(2)计算用户必须提供多少基础代币才能获得特定数量的份额，则应向上取整。

唯一在偏好四舍五入方向上存在歧义的函数是 convertTo 函数。为了确保所有 EIP-4626 金库实现的一致性，指定这些函数必须总是向下取整。集成者可以希望自己模仿这些函数的向上取整版本，例如通过给结果加一个 Wei。

你给的未必是你得到的

用户通过赎回金库中的份额（previewRedeem）可能获得的基础资产数量与在铸造相同数量份额时（previewMint）所需扣除的数量可能有显著差异。差异可能很小（例如，由于四舍五入错误）或显著（例如，如果金库实施了提款或存款费用）。因此，集成者应小心使用与其用例最相关的预览函数，绝不能假设它们是可互换的。

重写核心功能

为实现或扩展预期功能，建议使用现有Hook，而不是更改核心函数。这一做法确保有效代码测试和审计的可追踪性更高。

零份额案例

ERC-4626 的原始规范 没有↗ 规定如何处理金库中可用份额为零的边缘情况，以及金库是否应正常工作或回滚。这可能成为潜在的混淆和错误来源。

金库作为价格预言机

关于预言机价格操控攻击的风险，preview 方法返回的值应尽可能接近准确。因此，它们可以通过改变链上条件而受到操控，并不总是安全用作价格预言机。4626 规范包括可以不精确的 convert 方法和 totalAssets 方法，因此可以作为稳健的价格预言机发挥作用。例如，使用时间加权平均价格实施 convert 方法在资产与份额之间转换是正确的做法。

实施特定问题

集成者必须在进一步集成之前审查代币化金库的任何实现，因为可能存在表面遵循接口、但核心功能的设计规范完全不同的恶意实现。

EOA 直接访问

如果金库旨在被 EOA 直接访问，其实现需要有函数来处理滑点损失或意外的存款/提款限额。与智能合约不同，EOA 在调用四个核心函数时，如果没有达到确切的输出，将没有回滚的故障机制。

金库扩展

随着越来越多的参与者开始采用 ERC-4626 标准，我们将看到越来越多针对标准的扩展实施。例如，Superform 开发了一个 实验性的 MultiVault扩展↗，以支持在一个金库合约内进行单独会计的多种资产。自然，实施越偏离原始标准，引入新漏洞的可能性就越高。开发者和审计人员可以根据自己的用例找到在多大程度上偏离是值得风险的其最优选择。

值得注意的是，导致灾难性事件的并不是每个协议的最小改动，而是它们结合在一起时的总和。

上述潜在攻击向量是与 4626 标准相关的众多讨论问题之一。随着采纳速度的增加，我们肯定会进一步探索关于 4626 金库的更多实施和集成角度。

额外阅读

1. ERC-4626: 代币化金库↗
2. ERC-4626 资源↗
3. ERC4626 属性测试 ( a16z↗, Trail of Bits↗)

• 原文链接： zellic.io/blog/exploring...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～