SharkTeam：Uniswap V4 Hook最佳安全實踐

2023-08-03 00:08:26

近期 Uniswap Lab 官宣了下一代 AMM Uniswap V4 的开發進展，並公开了白皮書和代碼倉庫。這次 V4 的白皮書僅僅只有 3 頁，原因是 V4並沒有對 AMM 的核心算法邏輯做太多修改，而是在 V3 的基礎上，增加了一些新的特性，以滿足更多的場景需求。 SharkTeam 將基於目前已开源的代碼，來看看 V4 帶來了哪些新的特性，並針對V4推出的重要特性 Hook 分析最佳應用實踐。

一、V4與V3的差別

1.1 AMM

在 AMM 算法層面，Uniswap V4 並沒有對 V3 做修改，依然使用基於恆定乘積 x*y=k 的流動性算法。

在 Uniswap V3，每一個交易對可以有 4 個池子（原本是 3 個，後來增加了一個新的 1 bp pool），分別代表 0.01% , 0.05% , 0.3% , 1% 費率的池子，這些池子對應的 tick space 也各不相同，在創建池子的時候，只能選擇這 4 種中的任一個。

在 Uniswap V4，每一個交易對理論上可以有任意數量的 pool，並且每一個 pool 的 fee rate 也可以是任意值，這些 pool 的 tick space 也可以是任意值。

這同時也帶來了一個問題：Uniswap V4 中交易對的流動性將被碎片化，因此需要一個更有效的 router/aggregator 來幫助用戶找到最優的交易路徑。

1.2 Hooks

Hooks 是一組由第三方或者 Uniswap 官方开發的合約，在創建 pool 的時候，pool 可以選擇綁定一個 hook. 之後在交易的特定階段，pool 都會自動調用與之綁定的 Hook 合約。Uniswap V4 一共定義了這些可以執行 hook 合約代碼的階段：

beforeInitialize
afterInitialize
beforeModifyPosition
afterModifyPosition
beforeSwap
afterSwap
beforeDonate
afterDonate

分別表示在初始化 pool，添加/移除流動性，交易，捐贈等操作的前後，都可以調用 hook 合約。

Hook 合約需要顯式指定在上述的哪些階段進行執行，而 pool 則需要知道對應的 Hook 在某個階段是否需要執行，為了節省 gas，這些 flag 都沒有在合約中進行存儲，而是需要 Hook 使用特定的地址來標明。具體判斷的代碼如下：

可以看出，Hook 地址的前 8 bit 都別用來標記在特定階段此 Hook 是否需要執行的 flag.

因此，Hook 的开發者需要在部署合約的時候，產生出滿足 Pool 要求的地址，這通常需要使用 Create 2 + 計算隨機 Salt 來實現。

以下是白皮書中關於 Hook 執行的一個例子：

可以看到在執行 swap 的前後，pool 會先檢查 pool 對應的 Hook 是否开啓了相應的 flag，如果开啓了，就會自動調用 Hook 合約的相應函數。

1.3 動態 fee ratio

除了可以在特定階段執行代碼之外，Hook 還可以決定某一個 pool 的 swap fee 費率，和 withdraw 費率。withdraw 費率指的是用戶在移除流動性時需要向 Hook 支付的費率。除此之外，Hook 還可以指定在 swap fee 中抽成一部分給自己。

在創建 pool 時，需要使用 fee 參數（uint 24）前 4 個 bit 來標記此 pool 是否使用動態 fee，以及是否啓動 hook swap fee 和 withdraw fee：

如果啓動了動態 fee，那么 pool 會在每次 swap 之前，調用 Hook 合約來獲取當前的 swap fee ratio. Hook 合約需要實現 getFee() 函數，返回當前的 swap fee ratio.

Hooks 讓 Uniswap V4 成為了一個开發者平臺，給了 AMM 更多的可能性。一些可以用 Hooks 來實現的功能包括 TWAMM（時間加權自動做市商）、Limit Order （限價訂單）、LP 復投等將在後續的章節中詳細介紹。

1.4 Singleton 合約

Uniswap V3 中每次創建新的 pool 都需要部署一個新的合約，這會消耗大量 gas，但是其實這些 pool 使用的代碼是相同的，只是初始化參數不相同而已。Uniswap V4 引入了 Singleton 合約，用來管理所有的 pool，這樣創建新的 pool 不再需要部署新的合約了，節省了部署合約的 gas.

另外，使用 Singleton 合約的好處是，可以減少交易過程中 token 的轉账，因為所有的 pool 都在同一個合約中，所以可以直接在合約內部完成跨 pool 的 swap，而在 V3 中，跨 pool 的 swap 會需要將 token 在不同 pool 中轉來轉去，這會增加 gas.

同時，在 V4 中，所有 pool 使用同一個合約，並且合約內部的 token 記账也被簡化為每種 token 按 token 來記账，而不是按 pool 來記账，這樣一來如果想使用閃電貸借大量 token 也會更方便。

1.5 extload

為了方便 Hook 和其他合約的 integration，V4 合約增加了 extload 函數，這樣合約所有內部 states 都變成外部可讀了，所有 pool 的狀態將對外部完全透明。

1.6 Flash Accounting

為了減少跨 pool swap 的 token 轉账，V4 同時使用被稱為 Flash Accounting 的方法，將 swap, add/remove liquidity/flash loan 的過程都標准化成一種類似閃電貸的過程：

（1）用戶獲取一個 lock

（2）用戶進行任何操作，例如在多個 pool 中 swap，add/remove liquidity，或者通過閃電貸向 pool 借 token

（3）用戶所有操作所產生的 token 轉账都會被記錄在 lock 中

（4）所有操作結束後，用戶可以取走他獲得的 token，同時需要支付 lock 中記錄他需要支付的 token.

這些過程需要發生在一個交易中。

這樣一來，如果一個交易中需要跨多個 pool 進行 swap，在結算時只需要兩筆轉账就夠了。例如，在一次 ETH->USDC-BTC 這樣的 swap 中，USDC 作為中間 token 完全不需要任何轉账。

1.7 ERC 1155 mint/burn

Flash Accounting 可以減少同一筆交易中 swap 的 token 轉账，通過使用 ERC 1155 token ，可以進一步減少多個交易的 token 轉账。

V4 允許通過 ERC 1155 mint，將屬於你的 token 保存在 V4 合約中，這樣你就可以在多個交易中使用這些 token，而不需要每次都將 token 轉账到 V4 合約中。

使用 ERC 1155 burn 可以將保存在 V4 合約中的 token 取出。

ERC 1155 適合頻繁 swap 或 add/remove liquidity 的用戶，這些用戶可以將常用的 token 直接保存在 V4 合約中，這樣可以減少 token 轉账的 gas 开銷。

二、Hooks 的最佳實踐舉例

2.1 TWAMM（時間加權自動做市商）

Alice 想在區塊鏈上購买價值 1 億美元的以太幣。在現有的自動做市商（AMM）平臺（例如 Uniswap）上執行這么大規模的訂單將非常昂貴，因為這些平臺可能會向 Alice 收取高昂的費用，以防止她利用內幕消息獲取更好的價格。

為了獲得更好的價格，Alice 的最佳選擇是手動將訂單拆分成幾個較小的子訂單，並在幾個小時內逐步執行它們。這樣做的目的是讓市場有足夠的時間來意識到她沒有內幕消息，從而給予她更好的價格。但是，即使她發送幾個較大的子訂單，每個子訂單仍然會對價格產生重大影響，同時還容易受到敵對交易者的“三明治攻擊”。

TWAMM 通過代表 Alice 進行交易來解決這個問題。它將她的訂單分解為無限多個微小的虛擬訂單，以確保在時間上平滑地執行。同時，TWAMM 利用嵌入式 AMM 協議的特殊數學關系，能夠在這些虛擬訂單中分攤 Gas 成本。由於 TWAMM 在區塊之間處理交易，因此也不容易受到“三明治攻擊”。

總的來說，TWAMM 為 Alice 提供了一種更高效的方式來進行大規模交易，避免了高昂的手續費和潛在的市場操縱。

2.1.1 原理

TWAMM 有一個內置的 AMM，這個 AMM 和其他的 AMM 並沒有什么不同，用戶可以通過這個 AMM 直接進行現貨交易，也可以向其中添加流動性。但是 TWAMM 同時還有兩個 TWAP order pool，分別用來執行兩個方向的 TWAP order，用戶提交 order 時，指定交易的 token input 數量和時長，TWAMM 會將相同交易方向的 order 放入對應的 pool 中，並按照指定的交易速度自動進行交易。當用戶的 order 被完全執行後，用戶就可以拿出交易得到的 token。當然，在用戶的 order 在被執行完成之前，用戶也可以提前取消 order 或者修改 order 需要交易的 token 數量。

在以太坊中，智能合約只能由 EOA 地址主動發起交易觸發執行，而不能自動執行。因此 TWAMM 需要由 EOA 账戶定期發送交易來結算其 order pool 中待交易的 token，這樣就需要一個 keeper 账號來執行這些交易。

當然，也可以讓 TWAMM 在每次有用戶與其交互時，自動結算 order pool，這樣就省去了 keeper 的开銷，這也是 DeFi 協議處理流式數據常用的方式。

2.1.2 為什么說這種交易模式很難被三明治攻擊？

這種攻擊很難實施，由於一個區塊內 timestamp 不會改變，攻擊者必須要在一個區塊的最後一個交易中，將 pool 的價格拉高，這樣下一個區塊中的 TWAMM 結算才會受到影響。這就要求三明治攻擊發生在多個區塊中，這無疑會給攻擊者帶來很大的風險，因為其他套利者有可能在中間介入，導致攻擊者遭受損失。

同時，因為套利者的存在，這樣的價格操縱注定無法持久，由於 TWAP order 的特性它並不會在短時間內交易太多的 token，因此大部分情況損失也一定是有限的。

2.1.3 V4中的 TWAMM 工作流程

（1）此 Hook 維護兩個 TWAP order pool，分別表示兩個交易方向的 TWAP order

（2）用戶可以通過此 Hook 提交 TWAP order，需要指定交易的 token，數量以及時間長度

（3）此 Hook 注冊 beforeSwap 和 beforeModifyPosition，每次用戶交易或者調整倉位時，都會觸發此 Hook

（4）被觸發後，Hook 負責對 2 個 TWAP order pool 進行結算

（5）用戶也可以在任意時刻手動觸發結算

（6）用戶可以取消或者修改 TWAP order 中的 token 數量

2.1.4 實例詳解

TWAMM 注冊三個階段來進行 hooks 的邏輯調用，在 pool 初始化之前對 TWAMM 進行初始化，並在每次用戶交易或者調整倉位時觸發此 hook。

用戶可手動調用 TWAMM 中的 submitOrder 函數來提交自己需要執行的 order 到合約中。

在用戶將自己需要執行的訂單添加進合約後，在 pool 每次進行 swap 和 modifyPosition 操作時，都會自動進行 order 的執行。

每有用戶調用v4的 swap 函數進行交易或 modifyPosition 函數更改倉位，都會觸發 TWAMM 中的執行函數，函數中會調用內部函數_executeTWAMMOrders 繼續進行此前未完成 order 的執行。

_executeTWAMMOrders 函數

以上為更新訂單的執行流程，在執行結束之後，會更新當前 twamm 的訂單執行時間。

2.2 Limit Order

與立即按照最後的市場價格執行的市價單不同，限價單在達到預定價格後立即執行。基於自動做市商（AMM）的 DEX 大多默認選擇市價單系統。對新人來說簡單易懂。市價單要么被執行，要么因參數（如最大價格影響）而失敗。而在限價單中，只有當資產價格達到限價時，訂單才會成交，否則訂單將保持未平倉狀態。

例如，假設 ETH 目前在 ETH/DAI 池中的交易價格為 1 ETH = 1500 DAI。用戶可以下一個止盈訂單，主要內容是 "如果 1 ETH = 2000 DAI，賣出我所有的 ETH"。如果達到這個價格，用戶的 ETH 將自動以去中心化的方式完全在鏈上交換為 DAI。

在 Uniswap 以前的版本中，限價訂單實際上是不可能的。大多數 AMM 只允許市場买入和賣出。而在V4版本中，由於 hook 的強大特性和可擴展性，讓限價單在v4中存在了實現的基礎。

2.2.1 原理

limit order 的設計原理相比於 twamm 來說，更加簡單一些，目前實現了有關添加流動性的限價單，交易的限價單實現起來也會比較容易。

由於v4中存在 tickLower 和 tickUpper，並根據池子的交易情況變化，lower 和 upper 會發生改變，用戶在進行添加流動性時並不想在當前價格進行添加，這時就可以利用 limit Order hook 來執行此需求，在 hook 中設定對應的價格，在每次 swap 結束後，hook 會對當前 pool 的價格做判斷，若達到了設定的價格，則將對應的流動性進行添加獲取收益。

2.2.2 V4 中的 Limit Order 工作流程

1. limit 維護着多個 epoch，作為不同 lower 和交易方向的限價單。

2. 用戶通過這個 hook，提交自己的價格 lower 和交易方向，將限價單加入合約。

3. 此 Hook 注冊 afterSwap，只在每次 swap 結束後價格發生變動時觸發

4. 被觸發後，Hook 校驗當前價格區間，並從 epoch 中查驗當前價格是否存在需要進行添加流動性的限價單。

5. 用戶可以在任何時刻提款或直接添加流動性

2.2.3 實例詳解

合約注冊兩個階段觸發 hook，在 Pool 初始化後對 hook 初始化，並在每次兌換結束後觸發 hook 邏輯。

用戶調用 place 函數傳入想要添加流動性的數量，價格以及交易方向，hook 會先將用戶想要添加的流動性加入 pool 中保存，隨後為用戶創建對應的限價單。

在每次 swap 結束後都會觸發此 hook，根據當前價格區間將區間價格內存在的限價單完成添加流動性的操作。

用戶可在限價單完成之前調用 kill 函數取消限價單並獲得此次添加流動性獲得的收益。

用戶可在想要移除流動性時調用 withdraw 函數，即可提取想要的流動性。

總的來說，此 limit order hook 為用戶提供了一個更便捷的途徑，用戶可設定自己想要添加流動性時的價格，在池子中價格區間到達該價格後，hook 自動為用戶到 pool 中執行添加流動性的操作，且用戶可以隨時取消和提取流動性。

除 TWAMM 和 Limit Order 外，基於 Hook 還可以實現 LP 復投、動態手續費變化等功能，因為篇幅原因，我們將在後續的分析中展开介紹：

LP 復投： LP 用戶可利用 hook 來進行流動性的添加，修改和移除，hook 可注冊 afterSwap 和 afterModifyPosition 來進行調用。由於用戶統一使用 hook 來進行流動性的添加，所以在 poolManager 中添加流動性的地址只有 hook, hook 可在每次觸發時查驗當前時間，每經過一定時間段後，選擇提取流動性獎勵並將獲得的 lp 代幣再次到 pool 中添加流動性，從而自動化優化用戶收益。

動態手續費變化： hook 可注冊 beforeSwap 等接口，來進行交換之前的動態手續費修改。動態手續費可以不是簡單地根據時間线性變化，可以根據單筆 swap 產生的 tick 跳躍數量來量化波動率，從而動態改變手續費，實現對於 LP 無常風險的對衝。從而減少因為交易產生的無常損失對流動性提供者造成的影響。

三、Hooks 安全最佳實踐

減少 require 和 revert 的使用

在有關 pool 對 hooks 調用的函數邏輯中，盡量減少回退語句的使用，由於 pool 合約與 hooks 合約存在共通關系，在 hooks 中發生交易回滾後，會導致 pool 中的交易同樣回退，如果在 hooks 中出現與 pool 中正常交易不相關的回退語句，可能會導致用戶無法正常使用 pool 中的功能。

避免使用自毀函數

避免在 hook 中使用 selfdestruct 函數，如果 hook 中調用到了自毀函數，不僅會導致 hook 中的邏輯出現問題，並且會導致 pool 中的功能也無法正常進行，使整個 pool 池中的資產丟失並且功能無法正常進行。

嚴格進行權限控制

嚴格控制 hook 合約中的權限，避免出現權限過大的角色，並對特權角色進行多籤管理，防止出現單點攻擊。避免存在特權角色可任意修改合約狀態變量的情況，可能會出現邏輯錯誤導致整個交易發生回滾，影響 pool 的正常使用。驗證最小權限原則，我們應當使用 openzeppelin 的 AccessControl 合約來實現控制訪問更細粒度的權限，因為該實踐限制每個系統組件遵循最小權限原則。

做好防重入限制

hooks 作為 Pool 的外部擴展代碼，同樣應該注意合約中可能出現的重入攻擊，例如限價單中在進行原生代幣轉账時可能出現的重入，導致合約資產出現損失。在調用外部合約或所謂的“檢查-生效-交互”模式之前檢查並嘗試更新所有狀態。這樣，即使重入，也不會產生任何影響，因為所有狀態都已完成更新。.

合約升級控制

有些开發者可能會使用代理合約以便後續對 hook 的邏輯進行變動和升級，但也因此需要注意到合約升級方面可能存在的問題。首先，hook 中即使採取代理模式，代理合約中也需要聲明對應的階段，例如 beforeSwap 等，否則 pool 無法校驗到正確的返回值。其次，在調用 delegatecall 之前檢查目標合約是否存在，Solidity 不會替我們執行此檢查，忽略檢查可能會導致意外行為和安全問題，仔細考慮變量聲明的順序，因為會出現變量打包存儲同一個插槽、影響 gas 成本、內存布局、delegate 調用結果等問題。

About Us

SharkTeam 的愿景是全面保護Web3世界的安全。團隊由來自世界各地的經驗豐富的安全專業人士和高級研究人員組成，精通區塊鏈和智能合約的底層理論，提供包括智能合約審計、鏈上分析、應急響應等服務。已與區塊鏈生態系統各個領域的關鍵參與者,如 Polkadot 、Moonbeam、polygon、OKC、 Huobi Global、 imToken 、 ChainIDE 等建立長期合作關系。

官網 | Twitter