バラの中の棘：Uniswap v4の新フック機構におけるセキュリティリスクを探る

Uniswap v4 が登場します！チームは、(理論上) 無制限のプール数、取引ペアごとの動的な手数料率、シングルトン、フラッシュアカウンティング、フック、ERC1155 のサポートなど、数多くの新機能 [1] を導入するという野心的な計画を持っています。EIP-1153 によって導入された一時ストレージを活用し、Uniswap v4 は Ethereum の Cancun アップグレード後にローンチされる予定です。

これらのイノベーションの中でも、フック メカニズムは、その強力な可能性ゆえに大きな注目を集めています。これにより、プールの操作の特定のポイントで特定のコードを実行することができ、プールの拡張性と柔軟性を大幅に向上させます。

しかし、フックメカニズムは諸刃の剣にもなり得ます。強力で柔軟性がある一方で、安全に利用する上での課題は無視できません。この複雑さは、必然的に新たな潜在的な攻撃ベクトルを開きます。セキュリティの観点からコミュニティに貢献することを目指し、このメカニズムに関連するセキュリティ上の問題と懸念を体系的に検証する一連の記事を発表することを目標としています。これらの洞察が、安全な Uniswap v4 フックの構築に光を当てることを信じています。

この記事は、このシリーズの最初のものであり、読者の皆様に包括的な概要と基本的な理解を提供します。さらに洞察に富んだ議論にご期待ください！

Uniswap v4 のメカニズム

詳細に入る前に、Uniswap v4 のメカニズムについて基本的な理解が必要です。公式発表 [1] およびホワイトペーパー [2] によると、フック、シングルトンアーキテクチャ、フラッシュアカウンティングは、プールのカスタマイズと多数のプールを横断する効率的なルーティングを可能にする 3 つの主要な機能です。

フック

v4 のフックは、フック を通じて誰でもトレードオフの決定を行えるように設計されています。フックは、プールの操作ライフサイクルのさまざまなポイントで実行されるコントラクトです。これにより、動的手数料をネイティブにサポートするプールをカスタマイズしたり、オンチェーンの指値注文を追加したり、時間加重平均マーケットメーカー (TWAMM) として機能して大規模な注文を時間とともに分散させたりすることが可能になります。

現在、8 つ のフックコールバックがあり、4 つのグループに配置されています (各グループにはコールバックのペアが含まれます)。

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate

以下は、ホワイトペーパー [2] で提供されているスワップフックのフローを示しています。

Uniswap チームは、使用例を示すためにいくつかの例 (例: TWAMM Hook [3]) を提供しており、コミュニティの参加者も貢献しています。公式ドキュメント [4] は、より多くのフック例を集めたリポジトリ Awesome Uniswap v4 Hooks [5] へのリンクを提供しています。

シングルトン、フラッシュアカウンティング、ロックメカニズム

シングルトンアーキテクチャとフラッシュアカウンティングは、コストを削減し効率を確保することでパフォーマンスを向上させるように設計されています。具体的には、新しい singleton コントラクトが導入され、すべてのプールが 1 つのスマートコントラクト内に存在します。このシングルトン設計は、すべての プール のすべての状態を保存および管理する PoolManager に依存しています。

Uniswap プロトコルの以前のバージョンでは、スワップや流動性の追加などの操作に直接トークン転送が関与していましたが、Uniswap v4 は flash accounting と lock mechanism を導入しています。

具体的には、ロックメカニズムは次のように機能します。

ロッカーコントラクトが PoolManager に対するロックを要求します。
PoolManager は、ロッキングアドレスを lockData キューに追加し、その lockAcquired コールバックを呼び出します。
ロッカーはコールバックでロジックを実行します。ロッカーの実行中、プールとのやり取りにより、通貨デルタがゼロ以外になる場合があります。ただし、実行の終了時には、すべてのデルタはゼロに決済されなければなりません。さらに、lockData キューが空でない場合、最後のロッカーのみが操作を実行できます。
その後、PoolManager は lockData キューと通貨デルタの状態を確認します。確認後、PoolManager はロッカーを削除します。

要約すると、ロックメカニズムは同時アクセスを防ぎ、決済を保証します。ロッカーはロックをキューイングし、lockAcquired コールバックを介して実行されます。プール操作の前後に、指定されたフックコールバックが呼び出されます。最後に、PoolManager が状態を確認します。

このアプローチは、操作が即時転送を実行するのではなく、内部の正味残高（つまり デルタ）を調整することを意味します。すべての変更は、プールの内部残高に記録され、実際の転送は操作の終了時（つまり ロック）に行われます。このプロセスは、未払いのトークンがないことを保証し、それによってソルベンシーを維持します。

ロックメカニズムのため、EOA (外部所有アカウント) は PoolManager と直接やり取りすることはできません。代わりに、すべてのやり取りはコントラクトを介して行われる必要があります。コントラクトは、プール操作の前にロックを要求するための中間ロッカーとして機能します。主に 2 つのコントラクトのやり取りのシナリオがあります。

ロッカーコントラクトは公式リポジトリから提供されるか、ユーザーによってデプロイされます。これらの場合、やり取りは ルーター を介して行われると見なすことができます。
ロッカーとフックは同じコントラクトに統合されているか、サードパーティのエンティティによって制御されます。このシナリオでは、やり取りは フック を介して行われると見なすことができます。したがって、フックはロッカーとコールバックハンドラーの二重の役割を果たします。

脅威モデル

対応するセキュリティ上の問題について議論する前に、脅威モデルを決定する必要があります。基本的に、フックを使用する際に生じる考慮事項がいくつかあります。

脅威モデル I: フックは無害だが脆弱である。
脅威モデル II: フックは悪意がある。

以降のセクションでは、脅威モデルに基づいた潜在的なセキュリティ上の問題/懸念について説明します。

脅威モデル I におけるセキュリティ上の懸念

脅威モデル I は、フック自体に関連する脆弱性に焦点を当てています。明らかに、この脅威モデルは、開発者とそのフックが無害であると仮定しています。しかし、スマートコントラクトの既存の既知の脆弱性は、フックでも発生する可能性があります。たとえば、フックがアップグレード可能なコントラクトとして実装されている場合、OZ のライブラリの UUPSUpgradeable 脆弱性 [6] と同様の脆弱性に苦しむ可能性があります。

これらの考慮事項を踏まえると、v4 に固有の潜在的な脆弱性 に集中することを選択します。具体的には、Uniswap v4 では、フックはコアプールアクション（initialize、modifyPosition、swap、donate を含む）の前または後にロジックを実行できるカスタマイズ可能なスマートコントラクトです。フックは標準フックインターフェイスを実装することが期待されますが、カスタマイズされたロジックを組み込むことも許可されています。したがって、スコープは標準フックインターフェイスに関連するロジックに限定されます。次に、フックがこれらの標準フック関数をどのように採用する可能性が高いかを要約して、脆弱性の潜在的なソースを特定できます。

広義には、フックは 2 つのカテゴリに分類できます。

ユーザー資金の保管者として機能するフック。これらの場合、攻撃者はフックをターゲットにして資金を転送し、資産の損失につながる可能性があります。
ユーザーまたは他のプロトコルが依存する重要な状態データを格納するフック。これらのフックの場合、攻撃者は重要な状態を意図的に変更する可能性があります。誤った状態は、他のユーザーまたはプロトコルによって使用されると、潜在的なリスクをもたらします。

これらの 2 つのカテゴリに当てはまらないフックは、議論の範囲外です。

スコープは限られていますが、ここではすべての可能性を列挙することは依然として現実的ではありません。現時点では実際のアプリケーションがないため、Awesome Uniswap v4 Hooks リポジトリを調べて洞察を得ることにしました。

リポジトリ（コミットハッシュ 3a0a444922f26605ec27a41929f3ced924af6075）を徹底的に検査した後、いくつかの重大な脆弱性を特定しました。これらは主に、フック、PoolManager、および外部のサードパーティとの危険なやり取り から生じます。脆弱性は、不適切なアクセス制御 と 不適切な入力検証 の 2 つの主なカテゴリに分類されます。調査結果を表にまとめます。

# of flawed projects	# of flawed access control	# of improper input validation
8	6	2

全体として、22 の関連プロジェクト（Uniswap v4 に関連していないと思われるものを含む）を特定しました。そのうち 8 つ（36%）が脆弱であると見なされました。具体的には、6 つの脆弱なプロジェクトで不適切なアクセス制御が検出され、2 つは信頼できない外部呼び出しに対して脆弱でした。

不適切なアクセス制御

この議論では、v4 のコールバック関数（8 つのフックコールバックとロックコールバックを含む）に起因する v4 に関連するアクセス制御の問題に焦点を当てます。もちろん、他のケースも検証が必要になる場合があります。ただし、これらのケースは設計に依存しており、前述の議論で指定されたスコープを超えています。

これらの関数は、PoolManager によってのみ呼び出されるべきであり、他のアドレス（EOA やコントラクトを含む）によって呼び出されるべきではありません。たとえば、プールキーによって報酬が分配される状況を考えてみましょう。対応する関数が任意のウォレットによって呼び出される可能性がある場合、報酬が誤って請求される可能性があります。

これ Given this, it's crucial to establish robust access control mechanisms for hooks, especially since they can be invoked by parties other than the pool itself. Through careful management of access permissions, pools can substantially minimize the risk of unauthorized or malicious interactions with the hooks.

不適切な入力検証

Uniswap v4 では、ロックメカニズムのため、ユーザーはプール操作を実行する前にコントラクトを介してロックを取得する必要があります。これにより、現在やり取りしているコントラクトが最新のロッカーであることが保証されます。

それにもかかわらず、一部の脆弱なフック実装における 不適切な入力検証 による、信頼できない外部呼び出し という潜在的な攻撃シナリオが残っています。

第一に、フックはユーザーがやり取りしようとしているプールを検証しません。これは、偽のトークンを保持し、有害なロジックを実行する悪意のあるプールである可能性があります。
第二に、いくつかの重要なフック関数では、任意の外部呼び出しが許可されています。

信頼できない外部呼び出しは、よく知られている再入性問題を含むさまざまな種類の攻撃につながる可能性があるため、非常に危険です。

このような脆弱なフックを悪用するために、攻撃者は偽のトークン用に悪意のあるプールを登録し、その後フックを呼び出してプールで操作を実行できます。プールとやり取りする際、悪意のあるトークンロジックが制御フローをハイジャックして不正行為を容易にします。

脅威モデル I の緩和策

このようなフックの問題を回避するには、機密性の高い外部/パブリック関数の必要なアクセス制御を適切に強制することによりやり取りを検証し、入力引数の検証を適切に行うことが不可欠です。さらに、再入性ガードは、フックが標準ロジックフロー内で繰り返し実行されないことを保証するのに役立つ場合があります。適切な保護措置を講じることで、プールはこの種の脅威に関連するリスクを軽減できます。

脅威モデル II におけるセキュリティ上の懸念

この脅威モデルでは、開発者とそのフックは悪意がある と仮定されます。可能性の範囲が広いため、v4 に関連する問題に主に焦点を当てることを選択しました。したがって、主な考慮事項は、提供されたフックがユーザーが転送または承認した暗号資産を処理できるかどうかです。

フックへのアクセス方法、つまりフックに付与される潜在的な権限を決定する方法に基づいて、フックを 2 つの明確なカテゴリに分類できます。

管理フック: フックはエントリポイントではありません。ユーザーは、Uniswap が提供する可能性のあるルーターを介してフックとやり取りする必要があります。
スタンドアロンフック: フックはエントリポイントであり、ユーザーはフックと直接やり取りできます。

管理フック

管理フックの場合、ユーザーの暗号資産（ネイティブトークンおよびその他を含む）は、router に転送または承認されます。PoolManager によって強制される残高チェックのため、悪意のあるフックがこれらの資産を直接収穫することは容易ではありません。

しかし、潜在的な攻撃面は依然として存在します。たとえば、v4 の手数料管理メカニズムは、フックを介して攻撃者によって操作される可能性があります。

スタンドアロンフック

スタンドアロンフックの形式でフックがエントリポイントとして使用される場合、状況はより複雑になります。このシナリオでは、フックはユーザーが直接やり取りできるため、より強力になります。理論的には、フックはこのやり取りを通じて望むどんな操作でも実行できます。

v4 シナリオでは、コードロジックの検証は重要なポイントです。主な懸念は、コードロジックが操作できるかどうかです。フックはアップグレード可能として実装でき、これは、安全に見えるフックが後で悪意のあるものにアップグレードされる可能性があり、重大なリスクをもたらすことを意味します。これには以下が含まれます。

直接悪用される可能性のあるアップグレード可能なプロキシ。
selfdestruct と create2 の併用により悪用される可能性のある自己破壊ロジックを搭載。

脅威モデル II の緩和策

フックが悪意のあるものであるかどうかを評価することが不可欠です。具体的には、管理フックについては、手数料管理の動作に焦点を当てるべきです。一方、スタンドアロンフックについては、主な懸念はアップグレード可能であるかどうかです。

結論

この記事では、まず v4 のセキュリティ上の問題に関連する Uniswap v4 のコアメカニズムの簡単な概要を説明します。その後、2 つの脅威モデルを定義し、それぞれのセキュリティ上の問題について高レベルの議論を提供します。このシリーズの次の記事では、各脅威モデルの下でのセキュリティ上の問題の詳細な分析を提供します。乞うご期待！