近期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 個，後來增加了一個新的1bp 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 地址的前8bit 都別用來標記在特定階段此Hook 是否需要執行的flag.

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

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

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

1.3 動態fee ratio

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

在創建pool 時，需要使用fee 參數（uint24）前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 ERC1155 mint/burn

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

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

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

ERC1155 適合頻繁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复投：用戶可利用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等建立長期合作關係