什麼是Hooks
Hooks，即Hook 程式設計（Hook Programming），是一種程式設計模式，其中透過Hook，也就是預先定義的函數或程式碼區塊，允許開發者在一個系統、應用程式或函式庫的執行路徑中插入自訂程式碼，而不需要修改原本的程式碼。 Hooks 經常被用於許多程式設計環境和框架中，例如作業系統、框架和程式庫、Web開發以及插件系統。
透過使用Hooks，開發者可以增加程式的可擴展性和可自訂性，不必為了每一個變更或拓展需求去修改原有的程式碼，有助於保持程式碼的清潔和穩固。 Hooks 為軟體的擴充提供了一種優雅的實現方式，是軟體設計中非常有用的程式設計模型。
特別的，AOP（Aspect-oriented Programming， 面向切面程式設計）經常和Hook 程式設計拿來比較，AOP 是實現橫切關注點（cross-cutting concerns）的模組化的程式設計範式，目標也是在不更改主要業務邏輯的情況下增強或修改功能。這裡不詳細展開AOP，可以簡單認為AOP 是抽象層次更高的HooK 程式設計。
Uniswap V4：Hooks 革命
2023 年6 月，Uniswap 宣布並公開了Uniswap V4 白皮書的草稿版本，Uniswap V4 的一個重要特性是引入了Hooks。
其實，Hooks 在Web2 的金融系統中已經有著廣泛的應用，因為這些系統通常需要高度的客製化和可擴展性。客製化的場景例如在處理交易時，透過Hooks 在交易執行前後插入額外的驗證邏輯，如二次驗證、風控偵測和反洗錢（AML）策略。可擴展性的場景例如透過Hooks 與外部API 或微服務集成，在金融系統中拓展新的功能，如身份驗證服務、匯率轉換、支付網關等。但將Hooks 引入DeFi，Uniswap 還是創下了先河。
Uniswap V4 Hooks 本質是一個由開發者創建和定義的外部合約，流動性池被創建時可以選擇綁定一個Hook 合約。之後，流動性池會在生命週期的不同階段呼叫之前綁定的Hook 合約執行指定的操作，提供了高度的自訂性。開發者可以基於Uniswap 的Hooks 滿足更個人化的交易場景，並建立出更豐富的DApp，例如：
- 動態費用：透過Hooks，流動性池可以根據市場波動性或其他輸入參數動態調整費用，以更好地適應市場狀況；
- 鏈上限價單（On-chain Limit Orders）：Hooks 可實現在鏈上建立和執行限價訂單，使用戶能夠以指定價格進行交易；
- 時間加權平均做市商(TWAMM)：利用Hooks 機制建立支援TWAMM 策略的流動性池，以便在一段時間內平均分散大筆訂單的交易。
目前Uniswap V4 支援四組Hook 回調，每組包含一對回呼：
- beforeInitialize/afterInitialize：初始化流動性池；
- beforeModifyPosition/afterModifyPosition ：增加/減少/移除流動性；
- beforeSwap/afterSwap ：交換；
- beforeDonate/afterDonate ：捐款（Uniswap V4 引進的新功能，給予位於交易範圍內的流動性提供者小費）。
下圖是白皮書中展示的beforeSwap/afterSwap Hook 的流程，可以看到在執行交換的前後，會先檢查流動性池對應的Hook 是否開啟了相應的flag，如果開啟了，才會調用Hook 合約的相應函數。
這些Hooks 可以在交易開始開始前和交易結束後執行，從而實現類似於鏈上限價訂單的功能。用戶在Hook 合約上下限價訂單，隨後在afterSwap 的回檔裡根據自訂或託管預言機判斷價格是否滿足這個限價，如果滿足，就執行交易，如果不滿足，就取消交易。
Uniswap V4 透過Hooks 將流動性與DApp 本身的發展深度綁定，增強DApp 功能的同時也增強了Uniswap 的網路效應，使其成為整個DeFi 生態系統的底層基礎設施。
Uniswap V4 Hooks 的安全問題
BlockSec 團隊曾經探究過Uniswap V4 中Hooks 機制的安全風險，除了Hook 合約本身就是惡意的外，良性的Hook 合約也極為容易有漏洞。 BlockSec 團隊分析了Awesome Uniswap v4 Hooks 倉庫（提交哈希為3a0a444922f26605ec27a41929f3ced924af6075），並發現倉庫中超過30%的專案有漏洞。這些漏洞主要源自於Hook、PoolManager 以及外部第三方之間的風險交互，主要可分為兩類：
- 存取控制問題：主要關注的是Uniswap V4 中的回呼函數，這些函數應該只能被PoolManager 調用，不能被其他位址（包括EOA 和合約）呼叫。例如，在獎勵由資金池金鑰分發的情況下，如果相應的函數可以由任意帳戶調用，那麼獎勵可能會被錯誤地領取。因此，對於Hook 來說，建立強大的存取控制機制是至關重要的，尤其是它們可以被除了池子本身之外的其他方調用；
- 輸入驗證問題：由於在一些易受攻擊的Hook 實作中輸入驗證不當而導致的各種類型的攻擊，包括我們熟知的重入攻擊。最常見的情況是在某些關鍵Hook 函數裡調用了不受信任的外部合約，為了攻擊這些易受攻擊的Hook，攻擊者可以為自己的虛假代幣註冊一個惡意資金池，然後調用Hook 在資金池執行操作。在與資金池互動時，惡意代幣邏輯劫持控制流以便進行不良行為。
即使適當執行對敏感的外部/公用函數的必要存取控制，並對輸入參數進行驗證，降低了以上兩類Hook 相關的安全風險，但合約漏洞本身還是無法完全規避的，特別是Hook 如果作為可升級合約實現的，那麼也可能會遇到類似OpenZeppelin 的UUPSUpgradeable 漏洞的相關問題。
究其原因，還是因為Hook 程式設計會增加智慧合約的複雜度，進而加大攻擊向量。對於普通智能合約，OpenZeppelin 會有系列最佳實踐類別庫，讓基於它開發出來的合約是安全的，但它本質上還是為開發者添加了「安全使用約束」。而Hook 合約與普通合約相比，需要更嚴格的「安全使用約束」。因此，Hook 程式設計要廣泛應用，還需要一個全面的框架：需要有安全執行環境、適用Hook 的程式設計範式，和更嚴格的使用限制。
Artela Aspect：協定級支援Hook 編程
Uniswap V4 Hooks 是透過智慧合約來實現的，它的安全性問題也是由於智慧合約的限制所帶來的，那有沒有一種從協定層級支援Hook 程式設計的方案呢？ Artela Aspect 給了我們答案！
Artela 是一個高擴展性高效能的EVM 相容Layer 1 區塊鏈網絡，專為開發人員建立模組化、功能豐富、可擴展且可自訂的應用程式。 Artela 中定義了一個新的可程式模組作為原生擴展，稱為Aspect，創新性地把AOP 引入了區塊鏈網路中。 Aspect 需要指定連接點，即在整個交易處理生命週期中執行Aspect 的位置，類似於Hook 的回調，連接點包括：
- Block Init：區塊初始化；
- Transaction Verification：交易驗證；
- Pre Execute：執行前；
- Post Execute：執行後；
- Block Finalize：區塊最終確定。
Aspect 目前只支援Typescripts，其程式碼被編譯為WebAssembly (WASM) 字節碼並部署到Artela 網路。 Aspect 部署完成後，智慧合約擁有者可以將合約與Aspect 綁定。智慧合約所有者是指其外部帳戶（EOA）地址能夠通過智能合約isOwner(address) returns (bool)的檢查。
隨後，呼叫智能合約的後續交易將由Aspect 處理，如下圖所示：
Artela Aspects 作為協議層級的Hooks 實現，相較於Uniswap V4 Hooks 有非常大的優勢：
首先Artela Aspects 使用WASM 執行其程式碼，執行效率比EVM 高出幾個數量級；
其次，Artela Aspects 可以Hook 整個交易的生命週期，而不只是DeFi 核心邏輯，可以建立功能更豐富的DApp；
最後，也是最重要的，Artela Aspects 獨立運作在一個安全的沙盒環境中，這種隔離可確保Aspects 的執行不會影響到合約執行的安全性。
Artela Aspects 的隔離性限制了Hook 合約作為一個普通合約與外部其他合約間的相互調用，解決了Uniswap V4 Hooks 存取控制和輸入驗證的痛點。對於類似Uniswap 這樣的DeFi 合約部署到Artela 可以享受到更快更強更安全的Hook 體驗。
總結
Uniswap 作為DeFi 行業的重要參與者和領導者，在推動行業進步和完善功能方面發揮了至關重要的作用，此次Uniswap V4 引入的Hooks，毫無疑問也會引領DEX 的發展方向，被後繼者爭相模仿。
但Uniswap V4 Hooks 受限於智能合約本身的局限性，無論協議上設計得多牢固，工具庫所做的多完善，也無法從根源上阻止Hook 合約和外部其他合約之間的相互調用，存在潛在的安全漏洞。
Artela 作為一個高效能EVM 相容於Layer 1 區塊鏈網絡，從一開始的協議上，就設計了獨立運行於WASM 中的Aspect 來原生支援Hooks 編程，極大地提升了安全性。這給將安全視為生命的DeFi 協定提供了一個進階的解決方案。
