为何说Hook是Uniswap V4的一把“双刃剑”？

BlockSec ｜2023-11-09 18:00

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

相信 Uniswap v4 不久就会和大家见面了！

这一次 Uniswap 团队可谓目标宏大，计划引入众多全新功能[1]，包括每个交易对支持无限数量的流动性池和动态费用、单例设计、闪电记账、Hook，以及支持 ERC1155 代币标准。利用 EIP-1153 引入的瞬态存储，Uniswap v4 预计将在以太坊坎昆升级之后发布。

在诸多创新中，Hook 机制因其强大潜力引起了广泛关注。Hook 机制支持在流动性池生命周期中的特定点执行特定代码，大大增强了池子的可扩展性和灵活性。

然而，Hook 机制也可能是一把双刃剑。虽然它功能强大且灵活，但安全使用 Hook 同样是一个不小的挑战。Hook 的复杂性不可避免地带来了新的潜在攻击向量。因此，我们希望撰写一个系列文章，来系统介绍与 Hook 机制相关的安全问题与潜在风险，以此推动社区的安全发展，相信这些见解将有助于构建安全的 Uniswap v4 Hook。

作为该系列文章的开篇之作，本文介绍了与 Uniswap v4 中 Hook 机制相关的概念，并概述了Hook 机制存在的安全风险。

Uniswap V4的机制

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

1.1 Hook

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

目前有八个Hook 回调，分为四组（每组包含一对回调）：

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

下文是白皮书[2]中介绍的交换 Hook 的流程。

为何说Hook是Uniswap V4的一把“双刃剑”？

图 1：交换 Hook 流程

Uniswap 团队用一些示例（例如 TWAMM Hook[3]）介绍了操作方法，社区参与者也做出了一些贡献。官方文档[4]还链接到了Awesome Uniswap v4 Hooks[5] 仓库，该仓库收集了更多的 Hook 示例。

1.2 单例、闪电记账和锁机制

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

在 Uniswap 协议的早期版本中，兑换或添加流动性等操作涉及直接代币转移，v4 版本则有所不同，在于其引入了闪电记账和锁机制（lock mechanism）。

锁机制的运作方式如下：

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

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

3. 该locker合约在回调中执行其逻辑。在执行过程中，locker合约与池子的交互可能导致非零的货币增量。然而，在执行结束时，所有增量必须结算为零。另外，如果 lockData 队列不为空，只有最后一个locker合约可以执行操作。

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

总结来说，锁机制防止了并发访问，并保证了所有的交易都能被清算。而locker合约按顺序申请lock，然后通过 lockAcquired 回调执行交易。在每次池操作前后会触发对应的Hook回调。最后，PoolManager 会检查状态。

这种方法意味着操作调整的是内部净余额（即delta），而不是执行即时转账。任何修改都会记录在池子的内部余额中，实际的转账则在操作（即lock）结束时进行。这个过程保证了没有未清算的代币，从而维持了资金的完整性。

由于锁机制的存在，外部所有账户 (EOA) 不能直接与 PoolManager 进行交互。相反，任何交互都必须通过一个合约进行。该合约作为一个中间的locker，在进行任何池操作之前都需要请求lock。

主要存在两种合约交互场景：

某个locker合约来自官方的代码库，或者由用户部署。在这种情况下，我们可以将交互视为通过路由器进行。
某个locker合约和 Hook 集成到同一个合约中，或由第三方实体控制。对于这种情况，我们可以将交互视为通过Hook进行。在这种情况下，Hook既扮演了locker合约的角色，又负责处理回调。

威胁模型

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

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

在接下来的部分，我们将根据这两种威胁模型讨论潜在的安全问题。

2.1 威胁模型 I 中的安全问题

威胁模型 I 关注的是与 Hook 本身相关的漏洞。这个威胁模型假设开发者及其 Hook 是无恶意的。然而，智能合约现有的已知漏洞也可能出现在 Hook 中。例如，如果 Hook 是作为可升级合约实现的，那么它可能会遇到类似于 OpenZeppelin 的 UUPSUpgradeable 漏洞的相关问题。

鉴于以上因素，我们选择聚焦于v4版本特有的潜在漏洞。在 Uniswap v4 中，Hook 是能够在核心池操作（包括初始化、修改位置、交换和收集）之前或之后执行自定义逻辑的智能合约。虽然 Hook 预计将实现标准的接口，但它也允许包含自定义逻辑。因此，我们的讨论范围将限制在涉及标准 Hook 接口的逻辑。然后，我们将尝试找出可能的漏洞来源，例如，Hook 可能如何滥用这些标准 Hook 函数。

具体来说，我们将关注以下两种 Hook：

第一种 hook, 保管用户资金。在这种情况下，攻击者可能会攻击这个 hook 来转移资金，造成资产损失。
第二种 hook, 存储用户或其他协议依赖的关键状态数据。在这种情况下，攻击者可能会试图改变关键状态。当其他用户或协议使用错误状态时，可能会带来潜在风险。

请注意，这两种范围之外的 hook 不在我们的讨论范围内。

由于本文撰写时还没有 Hook 的真实用例，我们将从 Awesome Uniswap v4 Hooks 仓库中获取一些信息。

在对Awesome Uniswap v4 Hooks仓库（提交哈希为3a0a444922f26605ec27a41929f3ced924af6075）进行深入研究后，我们发现了几个严重的漏洞。这些漏洞主要源于 hook、PoolManager 以及外部第三方之间的风险交互，主要可以分为两类：访问控制问题和输入验证问题。具体发现请见下表：

为何说Hook是Uniswap V4的一把“双刃剑”？