信じるか信じないか、Uniswap v4は間もなく皆さんに会います！

今回、Uniswapチームは野心的な目標を設定し、無制限の数の流動性プールと各取引ペアの動的手数料、シングルトン設計、フラッシュアカウンティング、フック、トークン標準のサポートなど、多くの新機能を導入するERC1155計画しています。EIP-1153によって導入された一時ストレージを利用して、Uniswap v4はイーサリアムカンクンのアップグレード後にリリースされる予定です。数あるイノベーションの中でも、フック機構はその強力なポテンシャルから広く注目を集めています。フックメカニズムにより、流動性プールのライフサイクルの特定のポイントで特定のコードを実行することができ、プールのスケーラビリティと柔軟性が大幅に向上します。ただし、フックメカニズムは諸刃の剣にもなり得ます。強力で柔軟性がありますが、Hookを安全に使用することも大きな課題です。フックの複雑さは、必然的に新しい潜在的な攻撃ベクトルをもたらします。そこで、コミュニティのセキュリティ開発を促進するために、Hookメカニズムに関連するセキュリティ上の問題と潜在的なリスクを体系的に紹介する一連の記事を書きたいと考えています。これらの洞察は、安全なUniswap v4フックの構築に役立つと信じています。本連載の冒頭となる本記事では、Uniswap v4のHookメカニズムに関連する概念を紹介し、Hookメカニズムに関連するセキュリティリスクについて概説します。

- 1 - Uniswap V4のメカニズム

さらに深く掘り下げる前に、Uniswap v4の背後にあるメカニズムを基本的に理解する必要があります。公式発表[1]とホワイトペーパー[2]によると、Hooks、singleton architecture、およびflash accountingは、カスタマイズされた流動性プールと複数のプール間を効率的にルーティングするための3つの重要な機能です。

1.1 フック

フックとは、流動性プールのライフサイクルの異なる段階で実行される契約を指します。Uniswapチームは、フックを導入することで、誰もがトレードオフの決定を行えるようにすることを望んでいます。これにより、動的手数料、オンチェーンリミットオーダー、または大口注文を分割するための時間加重平均市場メーカー（TWAMM）のネイティブサポートを実装することが可能になります。現時点では、8つのコールバックフックがあり、4つのペアに分かれています（各ペアには1つの前後コールバックが含まれています）。

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

以下は、ホワイトペーパー[2]で紹介されたスワップフックのフローです。

図1：スワップフックのフロー

Uniswapチームは、いくつかの例（例: TWAMM Hook [3]）を使用して方法論を示し、コミュニティの参加者も貢献しています。公式のドキュメント[4]は、さらに多くのHookの例を収集しているAwesome Uniswap v4 Hooks [5]リポジトリへのリンクも示しています。

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

シングルトンアーキテクチャとフラッシュアカウンティングは、コストを削減し効率を確保することで、パフォーマンスを向上させることを目指しています。新しいシングルトン契約を導入し、すべての流動性プールを同じスマート契約に格納します。このシングルトン設計は、すべてのプールの状態を格納し管理するためにPoolManagerに依存しています。Uniswapプロトコルの以前のバージョンでは、スワップや流動性の追加などの操作には、直接トークンの転送が含まれていました。バージョン4は、フラッシュアカウンティングとロックメカニズムを導入することで異なります。

👇🏻 ロックメカニズムの動作は次のようになります: 1. ロッカー契約はPoolManagerからロックを要求します。 2. PoolManagerはロッカー契約のアドレスをlockDataキューに追加し、そのlockAcquiredコールバックを呼び出します。 3. ロッカー契約はコールバックでロジックを実行します。実行中のプールとのやり取りにより、非ゼロの通貨増分が生じる場合があります。ただし、実行の最後にはすべての増分がゼロになる必要があります。また、lockDataキューが空でない場合、最後のロッカー契約のみが操作を実行できます。 4. PoolManagerはlockDataキューと通貨増分の状態を確認します。確認後、PoolManagerはロッカー契約を削除します。

要約すると、ロックメカニズムは同時アクセスを防止し、すべての取引が決済されることを保証します。ロッカーコントラクトは順番にロックをリクエストし、その後lockAcquiredコールバックを介して取引を実行します。対応するHookコールバックは各プール操作の前後でトリガーされます。最後に、PoolManagerは状態をチェックします。これは、操作が即座の転送を行うのではなく、内部の純残高（つまりデルタ）を調整することを意味します。すべての変更はプールの内部残高に記録され、操作（つまりロック）が終了すると実際の転送が行われます。このプロセスにより、未解決のトークンがないことが保証され、資金の完全性が維持されます。ロックメカニズムのため、外部所有アカウント（EOA）は直接PoolManagerとやり取りできません。その代わり、どんなやり取りも契約を介して行われなければなりません。この契約は中間ロッカーとして機能し、プール操作を行う前にロックをリクエストします。

👇🏻 主要な契約インタラクションシナリオは2つあります:

• ロッカー契約は公式のコードベースから来るか、ユーザーによって展開されます。この場合、私たちはインタラクションをルーターを介して行われると見なすことができます。
• ロッカー契約とフックは同じ契約に統合されるか、第三者のエンティティによって制御されます。この場合、私たちは相互作用をフックを介して行われると見なすことができます。ここでは、フックはロッカー契約とコールバックの処理の両方の役割を果たします。

- 2 -脅威モデル

関連するセキュリティの問題について議論する前に、脅威モデルを確立する必要があります。主に次の2つのケースを考慮しています。

• 脅威モデルI：フック自体は無害ですが、脆弱性を含んでいます。
• 脅威モデルII：フック自体が悪意を持っています。

以下のセクションでは、これら2つの脅威モデルに基づいて、潜在的なセキュリティの問題について議論します。

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

脅威モデル I は、フック自体に関連する脆弱性に焦点を当てています。この脅威モデルは、開発者とそのフックに悪意がないことを前提としています。しかし、スマートコントラクトの既存の既知の脆弱性もフックに現れる可能性があります。たとえば、フックがアップグレード可能なコントラクトとして実装されている場合、OpenZeppelin UUPSUpgradeable のような脆弱性に関連する問題が発生する可能性があります。上記の要因を考慮して、バージョン4に固有の潜在的な脆弱性に焦点を当てることを選択します。Uniswap v4では、フックはコアプール操作(初期化、ポジション変更、スワッピング、コレクションを含む)の前後にカスタムロジックを実行できるスマートコントラクトです。フックは標準インターフェイスを実装することが期待されていますが、カスタムロジックも可能です。したがって、説明は標準のフックインターフェイスを含むロジックに限定されます。次に、脆弱性の潜在的な原因、たとえば、フックがこれらの標準フック関数をどのように悪用するかを特定しようとします。

👇🏻 特に、次の2種類のフックに焦点を当てます：

• 最初のフックのタイプはユーザーの資金を保持します。この場合、攻撃者は資金を転送するためにこのフックを攻撃する可能性があり、資産の損失を引き起こします。
• 第2のタイプのフックは、ユーザーや他のプロトコルが依存する重要な状態データを格納します。この場合、攻撃者は重要な状態を変更しようとする可能性があります。他のユーザーやプロトコルが誤った状態を使用すると、潜在的なリスクが発生するかもしれません。

これらの2つの範囲外のフックについてはここでは議論しません。この執筆時点では実世界のフックのユースケースはないため、Awesome Uniswap v4 Hooksリポジトリからいくつかの情報を取得します。Awesome Uniswap v4 Hooksリポジトリ（コミットハッシュ3a0a444922f26605ec27a41929f3ced924af6075）を徹底的に研究した結果、いくつかの深刻な脆弱性が特定されました。これらの脆弱性は、主にフック、PoolManager、外部第三者とのリスキーな相互作用から生じ、アクセス制御の問題と入力検証の問題の2つのカテゴリに分類されます。具体的な調査結果は以下の表に示されています:

要約すると、関連するプロジェクト22件（Uniswap v4に関係ないものを除く）を特定しました。これらのプロジェクトの中で、脆弱性を持つと考えられる8件（36%）があります。脆弱な8つのプロジェクトのうち、6つはアクセス制御の問題を抱えており、2つは信頼できない外部呼び出しに対して脆弱です。

2.1.1 アクセス制御の問題

この議論のこの部分では、v4のコールバック関数に関連する問題に主に焦点を当て、8つのフックコールバックとロックコールバックを含みます。もちろん、設計によって異なり、現在のスコープ外であるため、検証が必要な他のケースがあります。これらの関数はPoolManagerのみが呼び出すことができ、他のアドレス（EOAや契約を含む）からは呼び出すことができません。例えば、リワードがプールのキーから分配される場合、対応する関数が任意のアカウントから呼び出し可能であると、報酬が誤って請求される可能性があります。したがって、フックには強力なアクセス制御メカニズムを確立することが重要です。なぜなら、フックはプール自体以外の関係者によって起動される可能性があるためです。アクセス許可を厳格に管理することにより、流動性プールはフックとの未承認または悪意のある相互作用に関連するリスクを大幅に軽減できます。

2.1.2 入力検証の問題

Uniswap v4では、ロックメカニズムにより、ユーザーはプール操作を実行する前に、契約を介してロックを取得する必要があります。これにより、現在対話中の契約が最新のロッカー契約であることが保証されます。それにもかかわらず、一部の脆弱なHook実装において適切な入力検証が欠如しているため、信頼できない外部呼び出しによる潜在的な攻撃シナリオが存在します。

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

信頼できない外部呼び出しは非常に危険です。なぜなら、それはよく知られた再入攻撃を含むさまざまなタイプの攻撃につながる可能性があるからです。これらの脆弱なフックを攻撃するために、攻撃者は自分自身に偽のトークンを持つ悪意のあるプールを登録し、その後、フックを呼び出してプール上で操作を実行することができます。プールとやり取りする際、悪意のあるトークンロジックは不正行為のために制御フローを乗っ取ります。

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

このようなフック関連のセキュリティ問題を回避するには、機密性の高い外部/公開関数に適切なアクセス制御を実行し、入力を検証して相互作用を確認することが重要です。さらに、再入ガードを使用すると、フックが標準ロジックフロー中に再入されないようにするのに役立ちます。適切なセキュリティ保護を実装することで、プールはこのような脅威に関連するリスクを軽減できます。

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

この脅威モデルでは、開発者とそのフックが悪意を持っていると仮定しています。広範囲なスコープを考慮して、バージョン4に関連するセキュリティに焦点を当てています。その鍵は、提供されたフックが暗号通貨のユーザーの送金や認可を処理できるかどうかにかかっています。フックへのアクセス方法によってフックに付与される権限が決まるため、これに基づいてフックを2つのタイプに分類します。

• Managed Hooks：フックはエントリーポイントではありません。ユーザーは、ルーター（おそらくUniswapが提供する）を介してフックとやり取りする必要があります。
• Standalone Hooks：このフックはエントリーポイントであり、ユーザーが直接それとやり取りすることを可能にします。

図2：悪意のあるフックの例

2.2.1 管理されたフック

この場合、ユーザーの暗号通貨資産（ネイティブトークンや他のトークンを含む）がルーターに転送または承認されます。 PoolManagerが残高チェックを実行するため、悪意のあるフックはこれらの資産を簡単に直接盗むことはできません。ただし、潜在的な攻撃対象はまだ存在します。たとえば、バージョン4の手数料管理メカニズムは、攻撃者によってフックを介して操作される可能性があります。

2.2.2 スタンドアローンフック

フックがエントリーポイントとして使用されると、状況はより複雑になります。ここでは、ユーザーがフックと直接やり取りできるため、フックにはより多くの権限が付与されます。理論的には、フックはそのようなやり取りを通じて任意の操作を実行できます。バージョン4では、コードロジックの検証が非常に重要です。主要な問題は、コードロジックが操作可能かどうかです。フックがアップグレード可能である場合、セキュアに見えるフックがアップグレード後に悪意を持つようになり、重大なリスクを引き起こす可能性があります。これらのリスクには、次のものが含まれます:

• アップグレード可能なプロキシ（直接攻撃される可能性がある）
• 自己破壊を伴うロジック。selfdestructの呼び出しとcreate2と連携して攻撃される可能性があります。

2.2.3 脅威モデルIIに対する対策

重要なポイントは、フックが悪意を持っているかどうかを評価することです。特に、管理されたフックの場合は手数料の管理行動に注意を払うべきです。一方、スタンドアロンフックの場合は、アップグレード可能かどうかに主眼を置くべきです。

- 3 - 結論

この記事では、まずUniswap v4 Hookセキュリティ問題に関連するコアメカニズムを簡単に説明しました。次に、2つの脅威モデルを提案し、関連するセキュリティリスクを簡単に説明しました。次回の記事では、各脅威モデルの下でセキュリティ問題について詳細な分析を行います。お楽しみに！

参考文献

[1] Uniswap V4のビジョン
https://blog.uniswap.org/uniswap-v4

[2] Uniswap v4ホワイトペーパードラフト
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Uniswap v4 TWAMM フック
https://blog.uniswap.org/v4-twamm-hook

[4] フックの例
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] ゴージャスなUniswap v4フック
https://github.com/fewwwww/awesome-uniswap-hooks

[6] UUPSアップグレード可能性の脆弱性ポストモーテム
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

BlockSecは、2021年にセキュリティ業界の著名な専門家によって設立された、世界をリードするブロックチェーンセキュリティ企業です。同社は、Web3のセキュリティと利便性を向上させ、Web3の普及を促進することに専念しています。これを実現するために、BlockSecは、プロジェクトオーナー向けのスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、Phalconと呼ばれるセキュリティ開発、テスト、ハッカーの妨害システム、MetaSleuthと呼ばれる資金追跡および調査プラットフォーム、Web3ビルダー向けの効率プラグインであるMetaDockを提供しています。現在、同社はMetaMask、Compound、Uniswap Foundation、Forta、PancakeSwapなどのよく知られたプロジェクトを含む300以上のクライアントにサービスを提供しており、Oasis Capital、IDG Capital、Distributed Capitalなどの投資機関から数千万ドルを超える2回の資金調達を受けています。ホームページ：www.blocksec.com

Twitter：https://twitter.com/ブロックセキュリティチーム

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

メタドック：https://blocksec.com/metadock

免責事項：

1. この記事は[から転載されていますブロックSec]. すべての著作権は元の著者に帰属します [ブロックSec]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対応します。
2. 免責事項：この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、あるいは盗作は禁止されています。