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時的資產安全。