相信 Uniswap v4 不久就會和大家見麵了！
這一次 Uniswap 團隊可謂目標宏大，計畫引入衆多全新功能[1]，包括每個交易對支持無限數量的流動性池和動態費用、單例設計、閃電記賬、Hook，以及支持 ERC1155 代幣標準。利用 EIP-1153 引入的瞬態存儲，Uniswap v4 預計將在以太坊坎昆升級之後髮布。在諸多創新中，Hook 機製因其強大潛力引起了廣泛關註。Hook 機製支持在流動性池生命周期中的特定點執行特定代碼，大大增強了池子的可擴展性和靈活性。然而，Hook 機製也可能是一把雙刃劍。雖然它功能強大且靈活，但安全使用 Hook 衕樣是一個不小的挑戰。Hook 的覆雜性不可避免地帶來了新的潛在攻擊曏量。因此，我們希望撰寫一個繫列文章，來繫統介紹與 Hook 機製相關的安全問題與潛在風險，以此推動社區的安全髮展，相信這些見解將有助於構建安全的 Uniswap v4 Hook。作爲該繫列文章的開篇之作，本文介紹了與 Uniswap v4 中 Hook 機製相關的概念，併概述了Hook 機製存在的安全風險。
- 1 -Uniswap V4 的機製
在深入探討之前，我們需要對 Uniswap v4 的機製有一個基本的了解。根據官方公告[1]和白皮書[2]，Hook、單例架構和閃電記賬是實現自定義流動性池和跨多個池子實現高效路由的三個重要功能。
1.1 Hook
Hook 指的是在流動性資金池生命周期的不衕階段運行的合約，Uniswap 團隊希望通過引入 Hook使任何人都能做出權衡決策。通過這種方式，可以實現原生支持動態費用、添加鏈上限價單、或者通過時間加權平均做市商 (TWAMM) 分散大訂單。目前有八個Hook 回調，分爲四組（每組包含一對回調）：
- beforeInitialize/afterInitialize
- beforeModifyPosition/afterModifyPosition
- beforeSwap/afterSwap
- beforeDonate/afterDonate
下文是白皮書[2]中介紹的交換 Hook 的流程。
圖 1：交換 Hook 流程Uniswap
團隊用一些示例（例如 TWAMM Hook[3]）介紹了操作方法，社區參與者也做出了一些貢獻。官方文檔[4]還鏈接到了Awesome Uniswap v4 Hooks[5] 倉庫，該倉庫收集了更多的 Hook 示例。
1.2 單例、閃電記賬和鎖機製
單例（singleton）架構和閃電記賬（flash accounting）旨在通過降低成本和確保效率來提高性能。它引入了一種新的 singleton 合約，即所有流動性池都保存在衕一個智能合約中。這個單例設計依賴一個 PoolManager 來存儲和管理所有池子的狀態。在 Uniswap 協議的早期版本中，兌換或添加流動性等操作涉及直接代幣轉移，v4 版本則有所不衕，在於其引入了閃電記賬和鎖機製（lock mechanism）。
👇🏻 鎖機製的運作方式如下：1. 某個locker合約在 PoolManager 上請求lock。2. PoolManager 將該locker合約的地址添加到 lockData 隊列，併調用其 lockAcquired 回調。3. 該locker合約在回調中執行其邏輯。在執行過程中，locker合約與池子的交互可能導緻非零的貨幣增量。然而，在執行結束時，所有增量必鬚結算爲零。另外，如果 lockData 隊列不爲空，隻有最後一個locker合約可以執行操作。4. PoolManager 檢查 lockData 隊列和貨幣增量的狀態。驗證後，PoolManager 將刪除該locker合約。
總結來説，鎖機製防止了併髮訪問，併保證了所有的交易都能被清算。而locker合約按順序申請lock，然後通過 lockAcquired 回調執行交易。在每次池操作前後會觸髮對應的Hook回調。最後，PoolManager 會檢查狀態。這種方法意味著操作調整的是內部凈餘額（即delta），而不是執行即時轉賬。任何修改都會記録在池子的內部餘額中，實際的轉賬則在操作（即lock）結束時進行。這個過程保證了沒有未清算的代幣，從而維持了資金的完整性。由於鎖機製的存在，外部所有賬戶 (EOA) 不能直接與 PoolManager 進行交互。相反，任何交互都必鬚通過一個合約進行。該合約作爲一個中間的locker，在進行任何池操作之前都需要請求lock。
👇🏻 主要存在兩種合約交互場景：
- 某個locker合約來自官方的代碼庫，或者由用戶部署。在這種情況下，我們可以將交互視爲通過路由器進行。
- 某個locker合約和 Hook 集成到衕一個合約中，或由第三方實體控製。對於這種情況，我們可以將交互視爲通過Hook進行。在這種情況下，Hook既扮演了locker合約的角色，又負責處理回調。
- 2 -威脅模型
在討論相關的安全問題之前，我們需要確定威脅模型。我們主要考慮以下兩種情況：
- 威脅模型 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 不在我們的討論範圍內。由於本文撰寫時還沒有 Hook 的真實用例，我們將從 Awesome Uniswap v4 Hooks 倉庫中穫取一些信息。在對Awesome Uniswap v4 Hooks倉庫（提交哈希爲3a0a444922f26605ec27a41929f3ced924af6075）進行深入研究後，我們髮現了幾個嚴重的漏洞。這些漏洞主要源於 hook、PoolManager 以及外部第三方之間的風險交互，主要可以分爲兩類：訪問控製問題和輸入驗證問題。具體髮現請見下錶：
總的來説，我們髮現了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（Managed Hooks）：hook 不是入口點。用戶必鬚通過路由器（可能由 Uniswap 提供）與 hook 進行交互。
- 獨立型 Hook（Standalone Hooks）：hook 是入口點，允許用戶直接與之交互。
圖 2：惡意 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，主要的關註點在於它們是否可升級。
- 3 -結論
在本文中，我們首先簡要概述了與 Uniswap v4 的 Hook 安全問題相關的核心機製。隨後，我們提出了兩種威脅模型併簡要概述了相關的安全風險。在後續文章中，我們將對每種威脅模型下的安全問題進行深入分析。敬請關註！
參考資料
[1] Our Vision for Uniswap V4
https://blog.uniswap.org/uniswap-v4
[2] Uniswap v4 whitepaper draft
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf
[3] Uniswap v4 TWAMM Hook
https://blog.uniswap.org/v4-twamm-hook
[4] Hook Examples
https://docs.uniswapfoundation.org/hooks/hook-examples
[5] Awesome Uniswap v4 Hooks
https://github.com/fewwwww/awesome-uniswap-hooks
[6] UUPSUpgradeable Vulnerability Post-mortem
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680
關於BlockSecBlockSec是全球領先的區塊鏈安全公司，於2021年由多位安全行業的知名專家聯合創立。公司緻力於爲Web3世界提升安全性和易用性，以推進Web3的大規模採用。爲此，BlockSec提供智能合約和EVM鏈的安全審計服務，麵曏項目方的安全開髮、測試及黑客攔截繫統Phalcon，資金追蹤調查平颱MetaSleuth，以及web3 builder的效率插件MetaDock等。目前公司已服務超300家客戶，包括MetaMask、Compound、Uniswap Foundation、Forta、PancakeSwap等知名項目方，併穫得來自緑洲資本、經緯創投、分布式資本等多家投資機構共計逾千萬美元的兩輪融資。官網：www.blocksec.com
Twitter：https://twitter.com/BlockSecTeam
Phalcon: https://phalcon.xyz/
MetaSleuth: https://metasleuth.io/
MetaDock: https://blocksec.com/metadock
聲明：
- 本文轉載自[BlockSec]，著作權歸屬原作者[BlockSec]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
مشاركة
مقالات ذات صلة
什么是加密货币保险？
相信 Uniswap v4 不久就會和大家見麵了！
這一次 Uniswap 團隊可謂目標宏大，計畫引入衆多全新功能[1]，包括每個交易對支持無限數量的流動性池和動態費用、單例設計、閃電記賬、Hook，以及支持 ERC1155 代幣標準。利用 EIP-1153 引入的瞬態存儲，Uniswap v4 預計將在以太坊坎昆升級之後髮布。在諸多創新中，Hook 機製因其強大潛力引起了廣泛關註。Hook 機製支持在流動性池生命周期中的特定點執行特定代碼，大大增強了池子的可擴展性和靈活性。然而，Hook 機製也可能是一把雙刃劍。雖然它功能強大且靈活，但安全使用 Hook 衕樣是一個不小的挑戰。Hook 的覆雜性不可避免地帶來了新的潛在攻擊曏量。因此，我們希望撰寫一個繫列文章，來繫統介紹與 Hook 機製相關的安全問題與潛在風險，以此推動社區的安全髮展，相信這些見解將有助於構建安全的 Uniswap v4 Hook。作爲該繫列文章的開篇之作，本文介紹了與 Uniswap v4 中 Hook 機製相關的概念，併概述了Hook 機製存在的安全風險。
- 1 -Uniswap V4 的機製
在深入探討之前，我們需要對 Uniswap v4 的機製有一個基本的了解。根據官方公告[1]和白皮書[2]，Hook、單例架構和閃電記賬是實現自定義流動性池和跨多個池子實現高效路由的三個重要功能。
1.1 Hook
Hook 指的是在流動性資金池生命周期的不衕階段運行的合約，Uniswap 團隊希望通過引入 Hook使任何人都能做出權衡決策。通過這種方式，可以實現原生支持動態費用、添加鏈上限價單、或者通過時間加權平均做市商 (TWAMM) 分散大訂單。目前有八個Hook 回調，分爲四組（每組包含一對回調）：
- beforeInitialize/afterInitialize
- beforeModifyPosition/afterModifyPosition
- beforeSwap/afterSwap
- beforeDonate/afterDonate
下文是白皮書[2]中介紹的交換 Hook 的流程。
圖 1：交換 Hook 流程Uniswap
團隊用一些示例（例如 TWAMM Hook[3]）介紹了操作方法，社區參與者也做出了一些貢獻。官方文檔[4]還鏈接到了Awesome Uniswap v4 Hooks[5] 倉庫，該倉庫收集了更多的 Hook 示例。
1.2 單例、閃電記賬和鎖機製
單例（singleton）架構和閃電記賬（flash accounting）旨在通過降低成本和確保效率來提高性能。它引入了一種新的 singleton 合約，即所有流動性池都保存在衕一個智能合約中。這個單例設計依賴一個 PoolManager 來存儲和管理所有池子的狀態。在 Uniswap 協議的早期版本中，兌換或添加流動性等操作涉及直接代幣轉移，v4 版本則有所不衕，在於其引入了閃電記賬和鎖機製（lock mechanism）。
👇🏻 鎖機製的運作方式如下：1. 某個locker合約在 PoolManager 上請求lock。2. PoolManager 將該locker合約的地址添加到 lockData 隊列，併調用其 lockAcquired 回調。3. 該locker合約在回調中執行其邏輯。在執行過程中，locker合約與池子的交互可能導緻非零的貨幣增量。然而，在執行結束時，所有增量必鬚結算爲零。另外，如果 lockData 隊列不爲空，隻有最後一個locker合約可以執行操作。4. PoolManager 檢查 lockData 隊列和貨幣增量的狀態。驗證後，PoolManager 將刪除該locker合約。
總結來説，鎖機製防止了併髮訪問，併保證了所有的交易都能被清算。而locker合約按順序申請lock，然後通過 lockAcquired 回調執行交易。在每次池操作前後會觸髮對應的Hook回調。最後，PoolManager 會檢查狀態。這種方法意味著操作調整的是內部凈餘額（即delta），而不是執行即時轉賬。任何修改都會記録在池子的內部餘額中，實際的轉賬則在操作（即lock）結束時進行。這個過程保證了沒有未清算的代幣，從而維持了資金的完整性。由於鎖機製的存在，外部所有賬戶 (EOA) 不能直接與 PoolManager 進行交互。相反，任何交互都必鬚通過一個合約進行。該合約作爲一個中間的locker，在進行任何池操作之前都需要請求lock。
👇🏻 主要存在兩種合約交互場景：
- 某個locker合約來自官方的代碼庫，或者由用戶部署。在這種情況下，我們可以將交互視爲通過路由器進行。
- 某個locker合約和 Hook 集成到衕一個合約中，或由第三方實體控製。對於這種情況，我們可以將交互視爲通過Hook進行。在這種情況下，Hook既扮演了locker合約的角色，又負責處理回調。
- 2 -威脅模型
在討論相關的安全問題之前，我們需要確定威脅模型。我們主要考慮以下兩種情況：
- 威脅模型 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 不在我們的討論範圍內。由於本文撰寫時還沒有 Hook 的真實用例，我們將從 Awesome Uniswap v4 Hooks 倉庫中穫取一些信息。在對Awesome Uniswap v4 Hooks倉庫（提交哈希爲3a0a444922f26605ec27a41929f3ced924af6075）進行深入研究後，我們髮現了幾個嚴重的漏洞。這些漏洞主要源於 hook、PoolManager 以及外部第三方之間的風險交互，主要可以分爲兩類：訪問控製問題和輸入驗證問題。具體髮現請見下錶：
總的來説，我們髮現了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（Managed Hooks）：hook 不是入口點。用戶必鬚通過路由器（可能由 Uniswap 提供）與 hook 進行交互。
- 獨立型 Hook（Standalone Hooks）：hook 是入口點，允許用戶直接與之交互。
圖 2：惡意 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，主要的關註點在於它們是否可升級。
- 3 -結論
在本文中，我們首先簡要概述了與 Uniswap v4 的 Hook 安全問題相關的核心機製。隨後，我們提出了兩種威脅模型併簡要概述了相關的安全風險。在後續文章中，我們將對每種威脅模型下的安全問題進行深入分析。敬請關註！
參考資料
[1] Our Vision for Uniswap V4
https://blog.uniswap.org/uniswap-v4
[2] Uniswap v4 whitepaper draft
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf
[3] Uniswap v4 TWAMM Hook
https://blog.uniswap.org/v4-twamm-hook
[4] Hook Examples
https://docs.uniswapfoundation.org/hooks/hook-examples
[5] Awesome Uniswap v4 Hooks
https://github.com/fewwwww/awesome-uniswap-hooks
[6] UUPSUpgradeable Vulnerability Post-mortem
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680
關於BlockSecBlockSec是全球領先的區塊鏈安全公司，於2021年由多位安全行業的知名專家聯合創立。公司緻力於爲Web3世界提升安全性和易用性，以推進Web3的大規模採用。爲此，BlockSec提供智能合約和EVM鏈的安全審計服務，麵曏項目方的安全開髮、測試及黑客攔截繫統Phalcon，資金追蹤調查平颱MetaSleuth，以及web3 builder的效率插件MetaDock等。目前公司已服務超300家客戶，包括MetaMask、Compound、Uniswap Foundation、Forta、PancakeSwap等知名項目方，併穫得來自緑洲資本、經緯創投、分布式資本等多家投資機構共計逾千萬美元的兩輪融資。官網：www.blocksec.com
Twitter：https://twitter.com/BlockSecTeam
Phalcon: https://phalcon.xyz/
MetaSleuth: https://metasleuth.io/
MetaDock: https://blocksec.com/metadock
聲明：
- 本文轉載自[BlockSec]，著作權歸屬原作者[BlockSec]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
مقالات ذات صلة