Uniswap v4 フックメカニズムの二面性：革新と潜在的リスクの共存

Uniswap v4が間もなく登場します。このアップグレードは非常に野心的です。新しいバージョンでは、各取引ペアに無限の流動性プールと動的手数料をサポートするなど、多くの新機能が導入されます。シングルトン設計、フラッシュアカウンティング、Hookメカニズム、さらにはERC1155トークン標準のサポートも含まれています。一時的なストレージ技術を利用して、Uniswap v4はイーサリアムのカンクンアップグレード後にリリースされる予定です。

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

しかし、Hookメカニズムは両刃の剣でもあります。強力で柔軟な機能を持っているにもかかわらず、Hookを安全に使用することは同様に大きな課題に直面しています。Hookの複雑さは避けられず、新たな潜在的な攻撃ベクターをもたらします。したがって、Hookメカニズムに関連するセキュリティ問題と潜在的リスクを体系的に紹介し、コミュニティの安全な発展を促進することが必要です。これらの洞察は、より安全なUniswap v4 Hookの構築に役立ちます。

この記事では、Uniswap v4のHookメカニズムに関する関連概念を紹介し、その存在する安全リスクを概説します。

Uniswap V4のメカニズム

深く掘り下げる前に、私たちはUniswap v4のメカニズムについて基本的な理解が必要です。公式発表とホワイトペーパーによると、Hook、シングルトンアーキテクチャ、およびフラッシュアカウンティングは、カスタム流動性プールと複数のプール間での効率的なルーティングを実現するための3つの重要な機能です。

1.1 フック

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

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

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• スワップ前/スワップ後
• beforeDonate/afterDonate(寄付後)

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

1.2 シングルトン、ライトニング会計とロックメカニズム

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

Uniswap v4バージョンは、フラッシュアカウンティングとロックメカニズムを導入しました。ロックメカニズムの動作方法は次のとおりです:

1. locker契約はPoolManager上でロックをリクエストします。

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

3. lockerコントラクトはコールバック内でそのロジックを実行します。実行中、lockerコントラクトとプールとのインタラクションは非ゼロの通貨の増加を引き起こす可能性があります。しかし、実行が終了する際には、すべての増加はゼロに清算されなければなりません。また、lockDataキューが空でない場合、最後のlockerコントラクトのみが操作を実行できます。

4. PoolManagerは、lockDataキューのステータスと通貨の増分を確認します。 確認が完了すると、PoolManager はロッカー契約を削除します。

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

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

ロックメカニズムが存在するため、外部のすべてのアカウント(EOA)は直接PoolManagerと相互作用することができません。代わりに、すべての相互作用は契約を介して行う必要があります。この契約は中間ロッカーとして機能し、プール操作を行う前にロックを要求する必要があります。

主に2つの契約インタラクションシナリオが存在します:

• locker契約は公式コードライブラリから来るか、ユーザーによって展開されます。この場合はルーターを介しての相互作用と見なすことができます。

• locker契約とHookを同じ契約に統合するか、第三者のエンティティが制御します。この場合、Hookを介してのインタラクションと見なすことができます。この時、Hookはlocker契約の役割を果たし、コールバックの処理も担当します。

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

脅威モデル

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

• 脅威モデルI:Hook自体は良性であるが、脆弱性が存在する。

• 脅威モデルII:Hook自体が悪意のあるものです。

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

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

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

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

具体的には、私たちは以下の2つのHookに注目します:

• 最初のフックは、ユーザー資金の保管です。この場合、攻撃者はこのフックを攻撃して資金を移動させ、資産の損失を引き起こす可能性があります。

• 2番目のフックは、ユーザーまたは他のプロトコルが依存する重要な状態データを保存します。この場合、攻撃者は重要な状態を変更しようとする可能性があります。他のユーザーやプロトコルが誤った状態を使用すると、潜在的なリスクが生じる可能性があります。

この2つの範囲外のフックは私たちの議論の範囲にはありません。

Awesome Uniswap v4 Hooksリポジトリの詳細な調査を行った結果、いくつかの深刻な脆弱性が発見されました。これらの脆弱性は主にhook、PoolManager、および外部の第三者とのリスク相互作用に起因しており、主に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つのカテゴリに分類します:

• マネージドフック(Managed Hooks): フックはエントリーポイントではありません。ユーザーはルーター(を介して、Uniswapが提供する可能性のある)とフックと対話する必要があります。

• 独立型Hook(Standalone Hooks):hookはエントリーポイントであり、ユーザーが直接インタラクションできるようにします。

2.2.1 ホスティング型フック

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

2.2.2 スタンドアロンフック

Hookがエントリーポイントとして使用されると、状況はさらに複雑になります。この場合、ユーザーが直接hookと対話できるため、hookはより多くの権限を得ます。理論的には、hookはこの対話を通じて望ましい任意の操作を実行できます。

v4バージョンでは、コードロジックの検証が非常に重要です。主な問題は、コードロジックを操作できるかどうかです。フックがアップグレード可能である場合、見かけ上安全なフックがアップグレード後に悪意のあるものになる可能性があり、重大なリスクをもたらします。これらのリスクには以下が含まれます:

• アップグレード可能なプロキシ(は直接攻撃される可能性があります);

• 自己破壊ロジックを持っています。selfdestructとcreate2を共同で呼び出す場合に攻撃される可能性があります。

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

重要な点は、フックが悪意のあるものであるかどうかを評価することです。具体的には、ホスティング型フックについては、コスト管理の行動に注目すべきです。一方、独立型フックについては、それらがアップグレード可能かどうかが主な関心事です。

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

まとめ

この記事では、まずUniswap v4のHookのセキュリティ問題に関連する核心的なメカニズムを簡潔に概説します。その後、2つの脅威モデルを提案し、関連するセキュリティリスクを簡単に概説します。

次の記事では、各種脅威モデルにおけるセキュリティ問題を深く分析します。