爲何說Hook是Uniswap V4的一把"雙刃劍"？

Uniswap v4 有望在不久的將來與大家見面。這一次 Uniswap 團隊制定了宏偉的目標，計劃引入多項全新功能，包括每個交易對支持無限數量的流動性池和動態費用、單例設計、閃電記帳、Hook，以及支持 ERC1155 代幣標準。利用瞬態存儲，Uniswap v4 預計將在以太坊坎昆升級後發布。

在衆多創新中，Hook 機制因其強大潛力受到廣泛關注。它支持在流動性池生命週期的特定點執行特定代碼，大大提升了池子的可擴展性和靈活性。

然而，Hook 機制也可能是一把雙刃劍。盡管功能強大且靈活，但安全使用 Hook 同樣是一個不小的挑戰。Hook 的復雜性不可避免地帶來了新的潛在攻擊向量。因此，我們希望通過一系列文章，系統介紹與 Hook 機制相關的安全問題與潛在風險，以推動社區的安全發展，相信這些見解將有助於構建安全的 Uniswap v4 Hook。

作爲該系列文章的開篇之作，本文介紹了與 Uniswap v4 中 Hook 機制相關的概念，並概述了Hook 機制存在的安全風險。

Uniswap V4的機制

在深入探討之前，我們需要對 Uniswap v4 的機制有一個基本的了解。Hook、單例架構和閃電記帳是實現自定義流動性池和跨多個池子實現高效路由的三個重要功能。

1.1 Hook

Hook 指的是在流動性資金池生命週期的不同階段運行的合約，Uniswap 團隊希望通過引入 Hook使任何人都能做出權衡決策。通過這種方式，可以實現原生支持動態費用、添加鏈上限價單、或者通過時間加權平均做市商(TWAMM)分散大訂單。

目前有八個 Hook 回調，分爲四組（每組包含一對回調）：

• beforeInitialize/afterInitialize

• beforeModifyPosition/afterModifyPosition

• beforeSwap/afterSwap

• beforeDonate/afterDonate

1.2 單例、閃電記帳和鎖機制

單例架構和閃電記帳旨在通過降低成本和確保效率來提高性能。它引入了一種新的 singleton 合約，即所有流動性池都保存在同一個智能合約中。這個單例設計依賴一個 PoolManager 來存儲和管理所有池子的狀態。

在 Uniswap 協議的早期版本中，兌換或添加流動性等操作涉及直接代幣轉移，v4 版本則有所不同，在於其引入了閃電記帳和鎖機制。

鎖機制的運作方式如下：

1. 某個locker合約在 PoolManager 上請求lock。

2. PoolManager 將該locker合約的地址添加到 lockData 隊列，並調用其 lockAcquired 回調。

3. 該locker合約在回調中執行其邏輯。在執行過程中，locker合約與池子的交互可能導致非零的貨幣增量。然而，在執行結束時，所有增量必須結算爲零。另外，如果 lockData 隊列不爲空，只有最後一個locker合約可以執行操作。

4. PoolManager 檢查 lockData 隊列和貨幣增量的狀態。驗證後，PoolManager 將刪除該locker合約。

總結來說，鎖機制防止了並發訪問，並保證了所有的交易都能被清算。而locker合約按順序申請lock，然後通過 lockAcquired 回調執行交易。在每次池操作前後會觸發對應的Hook回調。最後，PoolManager 會檢查狀態。

這種方法意味着操作調整的是內部淨餘額，而不是執行即時轉帳。任何修改都會記錄在池子的內部餘額中，實際的轉帳則在操作結束時進行。這個過程保證了沒有未清算的代幣，從而維持了資金的完整性。

由於鎖機制的存在，外部所有帳戶 (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 不在我們的討論範圍內。

總的來說，我們發現了22個相關項目（排除與Uniswap v4無關的項目）。在這些項目中，我們認爲有8個（36%）項目是存在漏洞的。在這8個有漏洞的項目中，6個存在訪問控制問題，2個容易受到不受信任的外部調用。

2.1.1 訪問控制問題

在這部分討論中，我們主要關注的是v4 中的回調函數可能導致的問題，包括 8 個 hook 回調和 lock 回調。當然，還有其他情況需要驗證，但這些情況因設計而異，暫不在我們的討論範圍之內。

這些函數應該只能被 PoolManager 調用，不能被其他地址（包括EOA和合約）調用。例如，在獎勵由資金池密鑰分發的情況下，如果相應的函數可以由任意帳戶調用，那麼獎勵可能會被錯誤地領取。

因此，對於hook來說，建立強大的訪問控制機制是至關重要的，尤其是它們可以被除了池子本身之外的其他方調用。通過嚴格管理訪問權限，流動性池可以顯著降低與hook未授權交互或惡意交互的風險。

2.1.2 輸入驗證問題

在Uniswap v4中，由於存在鎖機制，用戶在執行任何資金池操作之前必須通過合約獲得一個lock。這確保了當前參與交互的合約是最新的locker合約。

盡管如此，仍然存在一個可能的攻擊場景，即由於在一些易受攻擊的 Hook 實現中輸入驗證不當而導致的不受信任的外部調用：

• 首先，hook並未驗證用戶打算交互的資金池。這可能是一個含有虛假代幣並執行有害邏輯的惡意資金池。

• 其次，一些關鍵的hook函數允許任意的外部調用。

不受信任的外部調用極其危險，因爲它可能導致各種類型的攻擊，包括我們熟知的重入攻擊。

爲了攻擊這些易受攻擊的hook，攻擊者可以爲自己的虛假代幣註冊一個惡意資金池，然後調用hook在資金池執行操作。在與資金池交互時，惡意代幣邏輯劫持控制流以便進行不良行爲。

2.1.3 針對威脅模型 I 的防範措施

爲了規避與hook相關的此類安全問題，通過適當執行對敏感的外部/公共函數的必要訪問控制，並對輸入參數進行驗證，從而對交互進行驗證是至關重要的。此外，重入保護可能有助於確保 hook 不會在標準邏輯流程中被重復執行。通過實施適當的安全防護措施，資金池可以降低與此類威脅相關的風險。

2.2 威脅模型 II 中的安全問題

在這個威脅模型中，我們假設開發者及其 hook 是惡意的。鑑於涉及範圍很廣，我們僅關注與 v4 版本相關的安全問題。因此，關鍵在於提供的 hook 是否能夠處理用戶轉帳或授權的加密資產。

由於訪問 hook 的方法決定了可能賦予 hook 的權限，我們據此將 hook 分爲兩類：

• 托管型 Hook：hook 不是入口點。用戶必須通過路由器（可能由 Uniswap 提供）與 hook 進行交互。

• 獨立型 Hook：hook 是入口點，允許用戶直接與之交互。

2.2.1 托管型 Hook

在這種情況下，用戶的加密資產（包括原生代幣和其他代幣）被轉帳或授權給 router 。由於 PoolManager 執行了餘額檢查，惡意 hook 不容易直接竊取這些資產。然而，仍然存在潛在的攻擊面。例如，v4 版本的費用管理機制可能會被攻擊者通過 hook 進行操縱。

2.2.2 獨立型 Hook

當 Hook 被用作入口點時，情況就更加復雜。在這種情況下，由於用戶可以直接與 hook 進行交互，hook 獲得了更多的權力。理論上，hook 可以通過這種交互執行想要的任何操作。

在 v4 版本中，代碼邏輯的驗證是非常關鍵的。主要問題在於是否可以操縱代碼邏輯。如果 hook 是可升級的，這意味着一個看似安全的 hook 可能會在升級之後成爲惡意的，從而構成重大風險。這些風險包括：

• 可升級的代理（可以被直接攻擊）；

• 帶有自毀邏輯。在聯合調用 selfdestruct 和 create2 的情況下可能被攻擊。

2.2.3 針對威脅模型 II 的防範措施

至關重要的一點在於評估 hook 是否是惡意的。具體來說，對於托管型 hook，我們應該關注費用管理的行爲；而對於獨立型 hook，主要的關注點在於它們是否可升級。

結論

在本文中，我們首先簡要概述了與 Uniswap v4 的 Hook 安全問題相關的核心機制。隨後，我們提出了兩種威脅模型並簡要概述了相關的安全風險。

在後續文章中，我們將對每種威脅模型下