Uniswap v4的Hook机制:潜力与风险并存

Uniswap v4即将推出,这次更新引入了多项全新功能,包括支持每个交易对无限数量的流动性池和动态费用、单例设计、闪电记账、Hook机制,以及支持ERC1155代币标准。其中,Hook机制因其强大潜力引起了广泛关注。

Hook机制允许在流动性池生命周期的特定点执行自定义代码,大大增强了池子的可扩展性和灵活性。然而,Hook机制也可能是一把双刃剑。虽然功能强大且灵活,但安全使用Hook同样是一个不小的挑战。Hook的复杂性不可避免地带来了新的潜在攻击向量。

本文将介绍Uniswap v4中Hook机制的相关概念,并概述其存在的安全风险。

Uniswap v4的核心机制

在深入探讨之前,我们需要对Uniswap v4的机制有一个基本了解。根据官方公告和白皮书,Hook、单例架构和闪电记账是实现自定义流动性池和跨多个池子高效路由的三个重要功能。

Hook机制

Hook指在流动性资金池生命周期不同阶段运行的合约,旨在让任何人都能做出权衡决策。通过这种方式,可以实现原生支持动态费用、添加链上限价单,或者通过时间加权平均做市商(TWAMM)分散大订单。

目前有八个Hook回调,分为四组(每组包含一对回调):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• beforeSwap/afterSwap
• beforeDonate/afterDonate

单例、闪电记账和锁机制

单例架构和闪电记账旨在通过降低成本和确保效率来提高性能。它引入了一个新的singleton合约,即所有流动性池都保存在同一个智能合约中。这个单例设计依赖一个PoolManager来存储和管理所有池子的状态。

v4版本引入了闪电记账和锁机制。锁机制的运作方式如下:

1. locker合约在PoolManager上请求lock。

2. PoolManager将该locker合约地址添加到lockData队列,并调用其lockAcquired回调。

3. locker合约在回调中执行其逻辑。执行过程中与池子的交互可能导致非零的货币增量,但执行结束时,所有增量必须结算为零。

4. PoolManager检查lockData队列和货币增量的状态。验证后,删除该locker合约。

总的来说,锁机制防止了并发访问,并保证了所有交易都能被清算。这种方法意味着操作调整的是内部净余额,而不是执行即时转账。任何修改都会记录在池子的内部余额中,实际的转账则在操作结束时进行。

由于锁机制的存在,外部所有账户(EOA)不能直接与PoolManager交互。任何交互都必须通过合约进行。主要存在两种合约交互场景:

• locker合约来自官方代码库或由用户部署。这种情况可视为通过路由器进行交互。

• locker合约和Hook集成到同一个合约中,或由第三方实体控制。这种情况可视为通过Hook进行交互。

威胁模型

在讨论相关安全问题之前,我们需要确定威胁模型。主要考虑以下两种情况:

• 威胁模型I:Hook本身是良性的,但存在漏洞。
• 威胁模型II:Hook本身就是恶意的。

威胁模型I中的安全问题

威胁模型I关注与Hook本身相关的漏洞。这个威胁模型假设开发者及其Hook是无恶意的。然而,智能合约现有的已知漏洞也可能出现在Hook中。

我们选择聚焦于v4版本特有的潜在漏洞,主要关注以下两种Hook:

• 保管用户资金的Hook。攻击者可能会攻击这个Hook来转移资金,造成资产损失。

• 存储用户或其他协议依赖的关键状态数据的Hook。攻击者可能会试图改变关键状态,当其他用户或协议使用错误状态时,可能带来潜在风险。

经研究,我们发现了几个严重的漏洞,主要源于Hook、PoolManager以及外部第三方之间的风险交互,可分为访问控制问题和输入验证问题两类。

访问控制问题

v4中的回调函数可能导致问题,包括8个Hook回调和lock回调。这些函数应该只能被PoolManager调用,不能被其他地址调用。对于Hook来说,建立强大的访问控制机制至关重要,尤其是它们可以被除了池子本身之外的其他方调用。

输入验证问题

尽管存在锁机制,仍存在一个可能的攻击场景,即由于一些易受攻击的Hook实现中输入验证不当而导致的不受信任的外部调用:

• Hook并未验证用户打算交互的资金池。这可能是一个含有虚假代币并执行有害逻辑的恶意资金池。

• 一些关键的Hook函数允许任意的外部调用。

不受信任的外部调用极其危险,可能导致各种类型的攻击,包括重入攻击。

防范措施

为规避与Hook相关的此类安全问题,通过适当执行对敏感的外部/公共函数的必要访问控制,并对输入参数进行验证,从而对交互进行验证是至关重要的。此外,重入保护可能有助于确保Hook不会在标准逻辑流程中被重复执行。

威胁模型II中的安全问题

在这个威胁模型中,我们假设开发者及其Hook是恶意的。关键在于提供的Hook是否能够处理用户转账或授权的加密资产。

根据访问Hook的方法,我们将Hook分为两类:

• 托管型Hook:Hook不是入口点。用户必须通过路由器与Hook进行交互。

• 独立型Hook:Hook是入口点,允许用户直接与之交互。

托管型Hook

用户的加密资产被转账或授权给router。由于PoolManager执行了余额检查,恶意Hook不容易直接窃取这些资产。然而,仍存在潜在的攻击面,例如v4版本的费用管理机制可能被攻击者通过Hook进行操纵。

独立型Hook

当Hook被用作入口点时,情况更加复杂。Hook获得了更多的权力,理论上可以通过这种交互执行想要的任何操作。

在v4版本中,代码逻辑的验证非常关键。主要问题在于是否可以操纵代码逻辑。如果Hook是可升级的,这意味着一个看似安全的Hook可能会在升级之后成为恶意的,从而构成重大风险。这些风险包括:

• 可升级的代理(可以被直接攻击)
• 带有自毁逻辑。在联合调用selfdestruct和create2的情况下可能被攻击。

防范措施

至关重要的一点在于评估Hook是否是恶意的。具体来说,对于托管型Hook,我们应该关注费用管理的行为;而对于独立型Hook,主要的关注点在于它们是否可升级。

结语

本文简要概述了与Uniswap v4的Hook安全问题相关的核心机制,并提出了两种威胁模型及相关的安全风险。Hook机制虽然功能强大,但也带来了新的安全挑战。开发者和用户都需要充分意识到这些潜在风险,采取适当的防范措施,以确保在使用Uniswap v4时的资产安全。