バラの中の棘：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 コントラクトが導入され、すべてのプールが単一のスマートコントラクト内に存在します。このシングルトン設計は、すべてのプールのすべての状態を保存および管理する PoolManager に依存しています。

Uniswap Protocolの以前のバージョンでは、スワップや流動性追加などの操作で直接トークン転送が行われていましたが、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やコントラクトを含む）からは呼び出されるべきではありません。例えば、プールキーによって報酬が配布される状況を考えてみましょう。対応する関数が任意の口座によって呼び出されると、報酬が誤って請求される可能性があります。

これを踏まえ、特にプール自体以外の当事者によって呼び出される可能性があるため、フックに対して堅牢なアクセス制御メカニズムを確立することが不可欠です。アクセス権限を慎重に管理することで、プールはフックとの不正または悪意のあるやり取りのリスクを大幅に軽減できます。

不適切な入力検証

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

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

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

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

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

脅威モデル I の軽減策

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

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

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

フックへのアクセス方法、つまりフックに付与される可能性のある権限によって、フックを2つの異なるカテゴリに分類できます。

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

管理フック

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

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

スタンドアロンフック

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

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

直接悪用される可能性のあるアップグレード可能なプロキシ。
selfdestruct と create2 の組み合わせ使用により悪用される可能性のある、自己破壊ロジックが装備されている。

脅威モデル II の軽減策

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

結論

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