Uniswap v4 Hookメカニズムの安全リスク分析

2025-07-17 07:05:14

なぜHookがUniswap V4の"二刀流"だと言われるのか？

Uniswap v4 は近い将来に皆さんとお会いできることを期待しています。今回は Uniswap チームが壮大な目標を掲げており、各取引ペアが無限の流動性プールと動的手数料をサポートすること、シングルトン設計、フラッシュ記帳、フック、ERC1155 トークン標準のサポートなど、いくつかの新機能を導入する予定です。瞬時ストレージを活用して、Uniswap v4 はイーサリアムのカンクンアップグレード後にリリースされる見込みです。

多くの革新の中で、Hookメカニズムはその強力な潜在能力により広く注目されています。これは、流動性プールのライフサイクルの特定のポイントで特定のコードを実行することをサポートし、プールのスケーラビリティと柔軟性を大幅に向上させます。

しかし、Hook メカニズムは二刀流の剣でもあります。強力で柔軟な機能を持っていますが、Hook を安全に使用することもまた簡単な挑戦ではありません。Hook の複雑さは、新たな潜在的攻撃ベクトルを避けられません。したがって、私たちは一連の記事を通じて、Hook メカニズムに関連する安全問題や潜在的リスクを体系的に紹介し、コミュニティの安全な発展を促進したいと考えています。これらの見解が安全な Uniswap v4 Hook の構築に役立つことを信じています。

本シリーズの記事の冒頭として、この記事ではUniswap v4のHookメカニズムに関連する概念を紹介し、Hookメカニズムに存在する安全リスクの概要を説明します。

Uniswap V4のメカニズム

深く掘り下げる前に、Uniswap v4 のメカニズムについて基本的な理解を持つ必要があります。フック、シングルトンアーキテクチャ、そしてフラッシュ記帳は、カスタム流動性プールを実現し、複数のプール間で効率的なルーティングを実現するための3つの重要な機能です。

1.1 フック

Hookとは、流動性資金プールのライフサイクルの異なる段階で実行される契約を指し、UniswapチームはHookを導入することで誰もがトレードオフの決定を行えるようにしたいと考えています。この方法により、ネイティブで動的手数料をサポートしたり、オンチェーンのリミットオーダーを追加したり、時間加重平均を使用したマーケットメイキング(TWAMM)によって大口注文を分散させることが可能になります。

現在、8つのHookコールバックがあり、4つのグループに分かれています（各グループには1対のコールバックが含まれています）：

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap (スワップ前/スワップ後)
beforeDonate/アフターDonate

1.2 シングルトン、ライトニング記帳、ロックメカニズム

シングルトンアーキテクチャとライトニングブックキーピングは、コストを削減し、効率を確保することでパフォーマンスを向上させることを目的としています。これは、新しいシングルトン契約を導入し、すべての流動性プールが同じスマートコントラクトに保存されることを意味します。このシングルトン設計は、すべてのプールの状態を保存・管理するために PoolManager に依存しています。

Uniswap プロトコルの初期バージョンでは、交換や流動性の追加などの操作は直接トークンの移転を伴っていましたが、v4 バージョンでは、フラッシュアカウンティングとロックメカニズムが導入されている点で異なります。

ロックメカニズムの動作方法は次のとおりです：

特定のロッカー契約が PoolManager 上でロックを要求します。
PoolManager はそのロッカー契約のアドレスを lockData キューに追加し、lockAcquired コールバックを呼び出します。
このロッカー契約は、コールバック内でそのロジックを実行します。実行中に、ロッカー契約とプールの相互作用により、非ゼロの通貨増加が発生する可能性があります。しかし、実行が終了する際には、すべての増加はゼロに清算されなければなりません。また、lockData キューが空でない場合、最後のロッカー契約のみが操作を実行できます。
PoolManager は、lockData キューのステータスと通貨の増分を確認します。確認が完了すると、PoolManager はロッカー契約を削除します。

まとめると、ロックメカニズムは同時アクセスを防ぎ、すべての取引が清算されることを保証します。そして、ロッカーコントラクトは順番にロックを要求し、lockAcquiredコールバックを介して取引を実行します。プール操作の前後には、それぞれのフックコールバックがトリガーされます。最後に、PoolManagerが状態を確認します。

この方法は、操作によって調整されるのは内部の純残高であり、即時転送を実行するわけではないことを意味します。変更はプールの内部残高に記録され、実際の転送は操作が終了した時に行われます。このプロセスは、未決済のトークンが存在しないことを保証し、資金の完全性を維持します。

ロックメカニズムの存在により、外部のすべてのアカウント (EOA) は PoolManager と直接対話することができません。代わりに、すべての対話は契約を通じて行う必要があります。この契約は中間的なロッカーとして機能し、プール操作を行う前にロックをリクエストする必要があります。

主に存在する2つの契約インタラクションシナリオ：

あるロッカー契約は公式のコードライブラリから来ているか、ユーザーによってデプロイされます。この場合、私たちはインタラクションをルーターを介して行うことができます。
あるロッカー契約とHookが同じ契約に統合されるか、または第三者によって制御される場合、この状況では、インタラクションをHookを介して行うことができます。この場合、Hookはロッカー契約の役割を果たし、コールバックの処理も担当します。

! なぜフックはUniswap V4の「両刃の剣」なのですか?

脅威モデル

関連するセキュリティの問題を議論する前に、脅威モデルを特定する必要があります。主に以下の2つの状況を考慮します：

脅威モデル I：Hook 自体は良性ですが、脆弱性があります。
脅威モデル II：Hook 自体が悪意があります。

次の部分では、これら二つの脅威モデルに基づいて潜在的なセキュリティ問題について議論します。

2.1 脅威モデル I におけるセキュリティ問題

脅威モデル I は、Hook 自体に関連する脆弱性に焦点を当てています。この脅威モデルは、開発者およびその Hook が悪意を持たないと仮定しています。しかし、スマートコントラクトに既知の脆弱性が存在する場合、それらは Hook にも現れる可能性があります。例えば、Hook がアップグレード可能なコントラクトとして実装されている場合、OpenZeppelin の UUPSUpgradeable 脆弱性に関連する問題に直面する可能性があります。

以上の要因を考慮して、私たちはv4バージョン特有の潜在的な脆弱性に焦点を当てることを選択しました。Uniswap v4では、Hookはコアプールの操作（初期化、ポジションの変更、交換、収集を含む）の前または後にカスタムロジックを実行できるスマートコントラクトです。Hookは標準的なインターフェースを実装することが期待されていますが、カスタムロジックを含めることも許可しています。したがって、私たちの議論の範囲は標準Hookインターフェースに関わるロジックに制限されます。その後、Hookがこれらの標準Hook関数をどのように悪用する可能性があるかなど、潜在的な脆弱性の源を見つけ出そうとします。

具体的には、以下の二つのフックに注目します：

第一のフックは、ユーザー資金を保管することです。この場合、攻撃者がこのフックを攻撃して資金を移動させ、資産の損失を引き起こす可能性があります。
第二のフックは、ユーザーまたは他のプロトコルが依存する重要な状態データを保存します。この場合、攻撃者は重要な状態を変更しようとする可能性があります。他のユーザーやプロトコルが誤った状態を使用すると、潜在的なリスクがもたらされる可能性があります。

この2つの範囲外のフックは、私たちの議論の範囲外であることに注意してください。

全体として、私たちは22の関連プロジェクトを発見しました（Uniswap v4に関連しないプロジェクトは除外）。これらのプロジェクトの中で、8つ（36%）のプロジェクトに脆弱性が存在すると考えています。この8つの脆弱なプロジェクトの中で、6つはアクセス制御の問題があり、2つは信頼できない外部呼び出しに対して脆弱です。

2.1.1 アクセス制御の問題

この部分の議論では、主にv4のコールバック関数が引き起こす可能性のある問題に焦点を当てています。これには8つのフックコールバックとロックコールバックが含まれています。もちろん、他にも検証が必要な状況がありますが、これらの状況は設計によって異なるため、私たちの議論の範囲には含まれていません。

これらの関数は PoolManager のみが呼び出すことができ、他のアドレス（EOAやコントラクトを含む）から呼び出すことはできません。例えば、報酬が資金プールのキーによって分配される場合、該当する関数が任意のアカウントから呼び出せると、報酬が誤って受け取られる可能性があります。

したがって、hookにとって強力なアクセス制御メカニズムを構築することが重要です。特に、それらがプール自体以外の他の当事者によって呼び出される可能性があるためです。アクセス権を厳格に管理することで、流動性プールはhookの未承認の相互作用や悪意のある相互作用に関連するリスクを大幅に低減できます。

2.1.2 入力検証の質問

Uniswap v4では、ロックメカニズムが存在するため、ユーザーは資金プール操作を実行する前に契約を通じてロックを取得する必要があります。これにより、現在のインタラクションに参加している契約が最新のロッカー契約であることが保証されます。

それにもかかわらず、いくつかの脆弱なフック実装における入力検証の不備により、不信任の外部呼び出しが発生する可能性のある攻撃シナリオが存在します。

まず、hookはユーザーが相互作用しようとしている資金プールを検証していません。これには、偽のトークンを含み、有害なロジックを実行する悪意のある資金プールが含まれる可能性があります。
次に、いくつかの重要なhook関数が任意の外部呼び出しを許可します。

信頼できない外部呼び出しは非常に危険であり、私たちがよく知っている再入攻撃を含むさまざまなタイプの攻撃を引き起こす可能性があります。

これらの脆弱なフックを攻撃するために、攻撃者は自分の偽トークンのために悪意のある資金プールを登録し、その後フックを呼び出して資金プールで操作を実行します。資金プールとの相互作用中に、悪意のあるトークンのロジックが制御フローを奪取し、不正行為を行います。

2.1.3 脅威モデル I に対する対策

フックに関連するこのようなセキュリティ問題を回避するためには、センシティブな外部/公共関数への必要なアクセス制御を適切に実行し、入力パラメータを検証することによって、相互作用の検証が重要です。さらに、再入防止は、フックが標準的な論理フロー内で繰り返し実行されることを確実にするのに役立ちます。適切なセキュリティ対策を実施することで、資金プールはこのような脅威に関連するリスクを低減することができます。

! なぜフックはUniswap V4の「両刃の剣」なのですか?

2.2 脅威モデル II におけるセキュリティの問題

この脅威モデルでは、開発者とそのフックが悪意を持っていると仮定します。関与する範囲が広いため、私たちはv4バージョンに関連するセキュリティ問題にのみ注目します。したがって、重要なのは提供されるフックがユーザーの送金または承認の暗号資産を処理できるかどうかです。

フックへのアクセス方法によって、フックに与えられる可能性のある権限が決定されるため、私たちはフックを2つのカテゴリに分類します:

ホスティング型フック：フックはエントリーポイントではありません。ユーザーは、フックと対話するためにルーター（おそらくUniswapが提供）を介する必要があります。
独立型 Hook：hook はエントリーポイントであり、ユーザーが直接対話できるようにします。

2.2.1 ホスティング型フック

この場合、ユーザーの暗号資産（ネイティブトークンやその他のトークンを含む）は、routerに転送または許可されます。PoolManagerが残高チェックを実行するため、悪意のあるhookがこれらの資産を直接盗むことは容易ではありません。しかし、潜在的な攻撃面が依然として存在します。たとえば、v4バージョンの手数料管理メカニズムは、攻撃者によってhookを介して操作される可能性があります。