Uniswap v4 は間もなく誰でも利用できるようになると思います。

今回、Uniswap チームは野心的な目標を掲げており、無制限の流動性プールと各取引ペアの動的手数料のサポート、シングルトン設計、ライトニング アカウンティング、フック、ERC1155 トークンのサポートなど、多くの新機能 [1] を導入する予定です。標準。 EIP-1153 によって導入された一時ストレージを活用する Uniswap v4 は、イーサリアム カンクンのアップグレード後にリリースされる予定です。

数多くのイノベーションの中でも、フック機構はその強力な可能性により広く注目を集めています。フック メカニズムは、流動性プールのライフサイクルの特定の時点での特定のコードの実行をサポートし、プールのスケーラビリティと柔軟性を大幅に強化します。ただし、フック機構は諸刃の剣にもなり得ます。 Hook は強力で柔軟性がありますが、安全に使用することも大きな課題です。

フックの複雑さは、必然的に新たな潜在的な攻撃ベクトルをもたらします。したがって、私たちは、コミュニティのセキュリティ開発を促進するために、Hook メカニズムに関連するセキュリティ問題と潜在的なリスクを体系的に紹介する一連の記事を執筆し、これらの洞察が安全な Uniswap v4 Hook の構築に役立つと信じています。この記事シリーズの冒頭として、この記事では Uniswap v4 のフック メカニズムに関連する概念を紹介し、フック メカニズムのセキュリティ リスクの概要を説明します。

1 -Uniswap V4の仕組み

これについて詳しく説明する前に、Uniswap v4 のメカニズムを基本的に理解する必要があります。

公式発表 [1] とホワイトペーパー [2] によると、フック、シングルトン アーキテクチャ、ライトニング アカウンティングは、カスタム流動性プールを実装し、複数のプール間で効率的なルーティングを実現するための 3 つの重要な機能です。 1.1 フックフックとは、流動性プールのライフサイクルのさまざまな段階で実行されるコントラクトを指します。Uniswap チームは、フックを導入することで、誰でもトレードオフの意思決定ができ​​るようにしたいと考えています。このようにして、動的な手数料をネイティブにサポートしたり、オンチェーンキャップ注文を追加したり、時間加重平均マーケットメーカー (TWAMM) を通じて大規模な注文を分散したりすることができます。

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

- 初期化前/初期化後

- beforeModifyPosition/afterModifyPosition

- スワップ前/スワップ後

- 寄付前/寄付後

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

- スワップ前/スワップ後

- 寄付前/寄付後

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

図1: フック交換プロセス

Uniswap チームは、いくつかの例 (TWAMM Hook[3] など) を使って操作方法を紹介し、コミュニティ参加者もいくつかの貢献をしました。公式ドキュメント[4]は、より多くのフックの例を収集する Awesome Uniswap v4 Hooks[5] リポジトリにもリンクしています。

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

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

Uniswap プロトコルの以前のバージョンでは、流動性の交換や追加などの操作には直接トークン転送が必要でしたが、v4 バージョンではライトニング アカウンティングとロック メカニズムが導入されている点が異なります。

ロック機構は次のように機能します。

1. ロッカー コントラクトは、PoolManager のロックを要求します。

2. PoolManager は、ロッカー コントラクトのアドレスを lockData キューに追加し、lockAcquired コールバックを呼び出します。

3. ロッカー コントラクトは、コールバックでロジックを実行します。実行中に、ロッカー コントラクトとプールとのやり取りにより、通貨の増分がゼロ以外になる場合があります。ただし、実行の終了時には、すべてのデルタがゼロに落ち着く必要があります。さらに、lockData キューが空でない場合、最後のロッカー コントラクトのみが操作を実行できます。

4. PoolManager は、lockData キューのステータスと通貨増分をチェックします。確認後、PoolManager はロッカー契約を削除します。要約すると、ロック メカニズムは同時アクセスを防止し、すべてのトランザクションを確実にクリアできるようにします。ロッカー コントラクトはロックを順番に適用し、lockAcquired コールバックを通じてトランザクションを実行します。対応するフック コールバックは、各プール操作の前後にトリガーされます。最後に、PoolManager はステータスをチェックします。

このアプローチは、即時転送を実行するのではなく、操作が内部ネットバランス (つまりデルタ) を調整することを意味します。変更はすべてプールの内部残高に記録され、実際の転送は操作の終了時に行われます (つまり、ロック)。このプロセスにより、未処理のトークンがないことが保証され、資金の完全性が維持されます。

ロック メカニズムにより、外部所有アカウント (EOA) は PoolManager と直接対話できません。代わりに、対話は契約を通じて行われる必要があります。このコントラクトは中間ロッカーとして機能し、プール操作を実行する前にロックを要求する必要があります。

契約対話の主なシナリオは 2 つあります。

特定のロッカー コントラクトは、公式コード ベースから取得されるか、ユーザーによって展開されます。この場合、対話はルーターを経由すると考えることができます。

特定のロッカー契約とフックが同じ契約に統合されているか、第三者機関によって管理されています。この場合、対話はフックを通じて行われると考えることができます。この場合、フックはロッカー コントラクトの役割を果たし、コールバックの処理を担当します。

2 - 脅威モデル

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

脅威モデル I: フック自体は無害ですが、脆弱性があります。

脅威モデル II: フックは本質的に悪意があります。

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

脅威モデル I: フック自体は無害ですが、脆弱性があります。

脅威モデル II: フックは本質的に悪意があります。

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

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

脅威モデル I は、フック自体に関連する脆弱性に焦点を当てています。この脅威モデルは、開発者とそのフックが無害であることを前提としています。ただし、スマート コントラクトの既存の既知の脆弱性がフックにも現れる可能性があります。たとえば、フックがアップグレード可能なコントラクトとして実装されている場合、OpenZeppelin の UUPSUpgradeable 脆弱性に関連する問題が発生する可能性があります。

上記の要因を考慮して、v4 バージョンに固有の潜在的な脆弱性に焦点を当てることにしました。 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 アクセス制御の問題

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

これらの関数は PoolManager によってのみ呼び出す必要があり、他のアドレス (EOA やコントラクトを含む) によって呼び出すことはできません。たとえば、報酬がプール キーによって分配される場合、対応する関数がどのアカウントでも呼び出せる場合、報酬が誤って請求される可能性があります。

したがって、特にフックはプール自体以外の関係者によって呼び出される可能性があるため、フックに対する強力なアクセス制御メカニズムを確立することが重要です。アクセス権を厳密に管理することで、流動性プールはフックとの不正または悪意のある相互作用のリスクを大幅に軽減できます。

2.1.2 入力確認の質問

Uniswap v4 では、ロック メカニズムにより、ユーザーはファンド プール操作を実行する前にコントラクトを通じてロックを取得する必要があります。これにより、現在対話に参加しているコントラクトが最新のロッカー コントラクトであることが保証されます。それにもかかわらず、攻撃シナリオの可能性は依然として存在します。つまり、一部の脆弱なフック実装における不適切な入力検証による信頼できない外部呼び出しです。

Uniswap v4 では、ロック メカニズムにより、ユーザーはファンド プール操作を実行する前にコントラクトを通じてロックを取得する必要があります。これにより、現在対話に参加しているコントラクトが最新のロッカー コントラクトであることが保証されます。それにもかかわらず、攻撃シナリオの可能性は依然として存在します。つまり、一部の脆弱なフック実装における不適切な入力検証による信頼できない外部呼び出しです。

まず、フックはユーザーが対話しようとしているプールを検証しません。これは、偽のトークンを含み、有害なロジックを実行する悪意のあるプールである可能性があります。

第 2 に、一部のキー フック関数では任意の外部呼び出しが可能です。

信頼できない外部呼び出しは、再入攻撃として知られるものを含むさまざまな種類の攻撃につながる可能性があるため、非常に危険です。これらの脆弱なフックを攻撃するために、攻撃者は自分の偽のトークン用に悪意のある資金プールを登録し、そのフックを呼び出して資金プール内で操作を実行することができます。プールと対話するときに、悪意のあるトークン ロジックが制御フローをハイジャックして、望ましくない動作を実行します。

2.1.3 脅威モデルⅠに対する予防策

このようなフックに関連するセキュリティ問題を回避するには、機密性の高い外部/パブリック関数への必要なアクセス制御を適切に実施し、入力パラメータを検証することにより、対話を認証することが重要です。さらに、再入保護は、標準ロジック フローでフックが繰り返し実行されないようにするのに役立ちます。適切なセキュリティ保護手段を実装することで、プールはそのような脅威に関連するリスクを軽減できます。

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

この脅威モデルでは、開発者とそのフックが悪意のあるものであると仮定します。範囲が広いため、v4 バージョンに関連するセキュリティ問題のみに焦点を当てます。したがって、提供されたフックがユーザーによって譲渡または認可された暗号資産を扱えるかどうかが鍵となります。フックにアクセスする方法によってフックに付与される権限が決まるため、フックを 2 つのカテゴリに分類します。

マネージドフック: フックはエントリポイントではありません。ユーザーはルーター (おそらく Uniswap によって提供される) を介してフックと対話する必要があります。

スタンドアロン フック: フックは、ユーザーがフックと直接対話できるようにするエントリ ポイントです。

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

2.2.1 マネージドフック

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

2.2.2 独立したフック フックがエントリ ポイントとして使用される場合、状況はさらに複雑になります。

この場合、ユーザーがフックを直接操作できるため、フックの機能がさらに強化されます。理論的には、フックはこのインタラクションで必要なことを何でも行うことができます。 v4 バージョンでは、コード ロジックの検証が非常に重要です。主な問題は、コードのロジックを操作できるかどうかです。フックがアップグレード可能である場合、これは、一見安全なフックがアップグレード後に悪意のあるものになる可能性があり、重大なリスクを引き起こす可能性があることを意味します。これらのリスクには次のものが含まれます。

アップグレード可能なエージェント (直接攻撃可能)。

自己破壊ロジック付き。自己破壊と作成の共同呼び出しの場合、攻撃の可能性2。

2.2.3 脅威モデルⅡに対する予防策

アップグレード可能なエージェント (直接攻撃可能)。

自己破壊ロジック付き。自己破壊と作成の共同呼び出しの場合、攻撃の可能性2。

2.2.3 脅威モデルⅡに対する予防策

フックが悪意のあるものであるかどうかを評価することが重要です。具体的には、マネージド フックの場合はコスト管理の動作に焦点を当てる必要がありますが、独立したフックの場合はアップグレード可能かどうかが主な焦点となります。 - 3 - 結論 この記事では、まず、Uniswap v4 のフック セキュリティ問題に関連するコア メカニズムの概要を簡単に説明します。続いて、2 つの脅威モデルを提案し、関連するセキュリティ リスクの概要を簡単に説明します。以降の記事では、各脅威モデルにおけるセキュリティ問題の詳細な分析を実施します。乞うご期待！