摘要

关于预批准 Aave v3.7 的提案，旨在授权在最终链上 AIP 激活投票前完成安全流程。

作为额外说明，本次批准仅确认一组候选功能与变更，其范围在 AIP 阶段只能缩减不能扩大（除非为修复生产环境问题而进行的调整）。

候选变更/功能如下：

• 简化 eMode 配置，新增隔离标志。
• 移除隔离抵押品与独立可借贷功能（这些功能已不再适用）。
• 移除 L2 序列器预言机。
• 明确移除撤销储备的流程，使储备列表变为仅可追加。
• 清算计算的小幅改进。
• 代码库外围基础设施的多项改进/简化（非链上变更）。

背景

在之前的升级（v3.4/5、v3.6）中，我们已与社区讨论过：虽然不应完全排除未来升级的可能性，但升级规模自然会比以往小得多，将侧重于针对可维护性的精准调整与简化。

v3.7 严格遵循这一思路，从代码规模和侵入性角度看属于较小幅度的升级，重点在于简化协议以适应当前及预期的使用场景。

我们认为此次升级对减少不必要的维护负担和建模工作至关重要。特别是考虑到 Aave 即将推出 v4 版本，很快将有三个生产协议并行运行。

Aave v3.7 变更内容

1. eMode isolated（隔离）配置

在 eMode 类别中新增 bool isolated 标志位，当 isolated = true 时：

• 仅 eMode 的 collateralBitmap 中明确列出的资产贡献 LTV。用户提供的其他所有资产均被视为零 LTV（这些资产仍会影响清算阈值和健康因子，但不能作为新增借贷的抵押品）。
• 启用非 eMode 抵押品的用户无法进入隔离 eMode——由于这些资产将变为零 LTV，进入操作会被阻止。
• 已处于隔离 eMode 的用户无法将非 eMode 资产启用为抵押品。

→ 变更动机

在当前 Aave 版本（v3.6）中，eMode 类别通过 collateralBitmap 决定哪些资产适用 eMode 增强的 LTV/LT 参数。但位图之外的资产仍按其常规（非 eMode）LTV 计算。这意味着处于"ETH 关联"eMode 的用户仍可基于非 ETH 抵押品以基础 LTV 进行借贷，这违背了 eMode 风险隔离的设计初衷。

v3.6 的解决方案是让治理方手动为每个非 eMode 资产设置 ltvzeroBitmap 位。虽然这种方式非常明确且有效，但操作负担较重：需要在资产上线时对多个资产设置 LTV0。

isolated 标志通过自动将所有 collateralBitmap 之外的资产视为零 LTV 来解决此问题，无需再对每个资产进行手动维护（同时仍支持通过 eMode 的 LTV0 进行精细控制）。

---

2. 移除隔离抵押品/独立可借贷配置

Aave v3.7 移除了 v3.0 引入的两项配置功能：

1. 隔离模式 - 将用户限制为单一抵押资产，并设置债务上限和有限的可借贷资产
2. 隔离借贷 - 若某资产被标记为隔离状态，则阻止用户借贷多种资产

→ 变更动机

• 当前无需使用这些模式
  • 隔离借贷：从未在生产环境中实际使用
  • 隔离抵押品：极少有资产配置债务上限（所有网络中大多数隔离资产均为 LTV0），且风险团队未来可通过其他机制实现需求，无需依赖此功能
• v3.6（及 v3.7 的隔离 eMode）引入了更简单的机制实现类似控制。例如：可通过 eMode 的借贷启用/禁用功能实现隔离借贷效果，抵押品隔离也可通过 eMode 以类似方式实现
• 降低 v3 代码库复杂度。以非侵入性方式简化协议的多个组件，主要变更集中在验证逻辑中。这将提升可审计性/可维护性，并减少整体攻击面
• 简化风险与增长服务提供商的推理模型和配置机制

---

3. 移除 L2 序列器正常运行时间预言机

此功能曾用于部分 L2 部署，以检查 L2 序列器是否在线，并在恢复后为用户执行宽限期，具体机制如下：

• 当定序器宕机或宽限期尚未结束时，借款功能将被阻止（isBorrowAllowed()）。

• 清算功能在相同条件下也被阻止（isLiquidationAllowed()），但有一个特殊例外：当某个头寸的健康因子低于 MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD（0.95）时，无论哨兵状态如何，清算始终被允许。

这两项检查现已被移除。借款和清算现在无需等待定序器正常运行即可进行。

→ 变更动机

历史上，L2 上的定序器运行时间检测一直非常临时，每个网络都有不同的机制和可靠性特征来报告定序器状态。这种缺乏标准化的情况导致了不同部署/链之间的基础设施差异，从而给 Aave 方和 Chainlink 等中间件带来了高维护开销，并产生了误报。这对系统来说非常成问题，因为误报在最坏情况下可能导致：

• 阻止清算：允许不健康的头寸进一步恶化，在恰恰最需要清算的时刻增加了协议风险。

• 阻止借款：在网络实际上没有任何问题的时期阻止正常的用户活动。

总之，我们对风险与价值的评估告诉我们，正确的决定是移除该机制。这与本次 v3.7 中包含的其他变更类似，旨在提高简洁性和可审计性，同时减少攻击面。

---

4. 移除 drop reserve 流程

这包括从 PoolConfigurator 和 Pool 合约中移除 dropReserve() 方法，以及直接相关的逻辑。

但是，我们保留了代码库中一些（现在已冗余的）验证，因为它们实际上没有影响，但可以减少变更范围。

→ 变更动机

移除储备金的功能从未被使用过，并且也没有计划使用。此外，我们知道它应该强制执行一些当前代码中未包含的额外验证，并且在没有对流程和安全程序进行深入审查的情况下，我们不会批准使用它的治理提案。因此，实际上，它是代码中一个非活跃/已弃用的部分，我们正在使其更加明确。

这也从与本次 v3.7 中其他功能相同的角度增加了价值：简化，因为现在储备金列表将变为仅追加模式。

---

5. 清算方面的小幅精度改进

在 v3.5 版本之后（为协议添加了定向舍入），我们检测到协议清算逻辑中一些较小的部分可以在舍入方面进一步改进，而不会过于侵入。这些改进已包含在此次 v3.7 提案中，具体细节将在我们完成内部开发/安全评估后公布。

→ 变更动机

提高协议中数学计算的精度。

---

6. 其他简化

与 Aave 的编号版本发布并行（但异步于它们），我们在 Aave v3 Origin 仓库中对非核心协议组件执行不同的维护任务。

除了其他微小变更外，自 v3.6 版本发布以来，我们一直在进行以下高级别变更：

• 一些非侵入性的依赖项清理。

• 从 v3 Origin 中归档不再在生产中使用的 Paraswap 适配器。

• 归档当前未使用的 RevenueSplitter 合约。

• 简化 V3 ConfigEngine。

→ 变更动机

对 Aave v3 Origin 仓库进行总体简化，以减少全局编译时间或减少依赖项的不一致性。基本上，这是对可维护性的持续改进。