# Uniswap v4のリリースが迫る中、Hookメカニズムには安全上のリスクが潜んでいますUniswap v4が間もなくリリースされます。このアップデートでは、各取引ペアに無限の流動性プールと動的手数料をサポートすることを含む多くの新機能が導入されます。シングルトンデザイン、フラッシュアカウンティング、フックメカニズム、そしてERC1155トークン標準のサポートも含まれます。v4はイーサリアムのカンクンアップグレード後にリリースされる予定です。多くの革新の中で、Hookメカニズムはその強力な潜在能力から注目されています。これは、流動性プールのライフサイクルの特定の時点でカスタムコードを実行することを可能にし、プールの拡張性と柔軟性を大幅に強化します。しかし、Hookメカニズムは両刃の剣である可能性もあります。強力で柔軟な機能を持ちながらも、Hookを安全に使用することには同様に課題が伴います。Hookの複雑さは避けられない新しい攻撃ベクトルをもたらします。したがって、Hookメカニズムに関連するセキュリティ問題や潜在的リスクを体系的に紹介することが特に重要であり、これがより安全なUniswap v4 Hookの構築に役立つでしょう。この記事では、Uniswap v4におけるHookメカニズムの関連概念を紹介し、その存在するセキュリティリスクを概説します。## Uniswap V4のメカニズム深く掘り下げる前に、Uniswap v4のメカニズムについて基本的な理解が必要です。公式の発表とホワイトペーパーによると、Hook、シングルインスタンスアーキテクチャ、そしてフラッシュアカウンティングは、カスタム流動性プールと複数のプール間での効率的なルーティングを実現するための三つの重要な機能です。### フックHookは流動性資金プールのライフサイクルの異なる段階で動作する契約を指します。UniswapチームはHookを導入することで、誰でもトレードオフの意思決定を行えるようにしたいと考えています。この方法により、ネイティブに動的手数料をサポートし、オンチェーンのリミットオーダーを追加したり、時間加重平均を使用して(TWAMM)の大口注文を分散させることが可能になります。現在、8つのHookコールバックがあり、4つのグループに分かれています(各グループには1対のコールバックが含まれています):- beforeInitialize/afterInitialize - 変更前のポジション/変更後のポジション- スワップ前/スワップ後- beforeDonate/afterDonate(寄付後)! [なぜフックはUniswap V4の「両刃の剣」なのですか? ](https://img-cdn.gateio.im/social/moments-f652bf2a22ca7f28f19b4ce9880d0548)### シングルトン、ライトニング記帳、およびロックメカニズムシングルトンアーキテクチャとライトニング帳簿は、コストを削減し、効率を確保することでパフォーマンスを向上させることを目的としています。これにより、すべての流動性プールが同じスマートコントラクトに保存される新しいシングルトン契約が導入されます。このシングルトン設計は、すべてのプールの状態を保存および管理するためにPoolManagerに依存しています。v4バージョンでは、フラッシュアカウンティングとロックメカニズムが導入されました。ロックメカニズムの動作方式は以下の通りです:1. ロッカー コントラクトは、PoolManager のロックを要求します。2. PoolManagerはそのロッカー契約アドレスをlockDataキューに追加し、lockAcquiredコールバックを呼び出します。3. lockerコントラクトはコールバック内でそのロジックを実行します。実行中、lockerコントラクトとプールの相互作用は非ゼロの通貨増加を引き起こす可能性があります。しかし、実行が終了する時点で、すべての増加はゼロに清算されなければなりません。また、lockDataキューが空でない場合、最後のlockerコントラクトのみが操作を実行できます。4. PoolManagerは、lockDataキューのステータスと通貨の増分を確認します。 確認が完了すると、PoolManager はロッカー契約を削除します。要するに、ロックメカニズムは同時アクセスを防ぎ、すべての取引が清算されることを保証します。ロッカー契約は順番にロックを申請し、次にlockAcquiredコールバックを通じて取引を実行します。プール操作の前後に対応するフックコールバックがトリガーされます。最後に、PoolManagerが状態を確認します。この方法は、操作によって調整されるのが内部ネットバランス(、すなわちデルタ)であり、即時転送を実行するのではないことを意味します。いかなる変更もプールの内部バランスに記録され、実際の転送は操作(、つまりロック)が終了した時点で行われます。このプロセスは、未清算のトークンが存在しないことを保証し、資金の完全性を維持します。ロックメカニズムが存在するため、外部のすべてのアカウント(EOA)は直接PoolManagerと対話できません。代わりに、すべての対話は契約を通じて行う必要があります。この契約は中間ロッカーとして機能し、プール操作を行う前にロックをリクエストする必要があります。主に2つの契約インタラクションシーンが存在します:- locker契約は公式コードライブラリから来るか、ユーザーによってデプロイされます。この場合、私たちはインタラクションをルーターを介して行うことができます。- locker契約とHookが同じ契約に統合されるか、または第三者によって制御されます。この場合、私たちはインタラクションをHookを通じて行うことができます。この場合、Hookはlocker契約の役割を果たすと同時に、コールバックの処理を担当します。! [なぜフックはUniswap V4の「両刃の剣」なのですか? ](https://img-cdn.gateio.im/social/moments-ba4bfa88e0ac0b6246e82ad879361ff3)## 脅威モデル関連するセキュリティ問題について議論する前に、脅威モデルを特定する必要があります。主に以下の2つの状況を考慮します:- 脅威モデルI: Hook自体は良性ですが、脆弱性があります。- 脅威モデルII: Hook自体が悪意があります。次の部分では、これら二つの脅威モデルに基づいて潜在的なセキュリティ問題について議論します。### 威胁モデルIにおけるセキュリティ問題脅威モデルIは、Hook自体に関連する脆弱性に焦点を当てています。この脅威モデルは、開発者とそのHookが悪意を持っていないと仮定しています。しかし、スマートコントラクトに既知の脆弱性が存在することもあり、それがHookに現れる可能性もあります。私たちはv4バージョン特有の潜在的な脆弱性に焦点を当てることを選択します。Uniswap v4では、Hookはコアプール操作(の前または後にカスタムロジックを実行できるスマートコントラクトで、初期化、位置の変更、交換、そして)を収集することが含まれます。Hookは標準のインターフェースを実装することが期待されていますが、カスタムロジックを含めることも可能です。したがって、私たちの議論の範囲は標準Hookインターフェースに関連するロジックに制限されます。次に、Hookがどのようにこれらの標準Hook関数を悪用する可能性があるかなど、潜在的な脆弱性の源を特定しようとします。具体的には、私たちは以下の2つのフックに注目します:- 最初のフックは、ユーザーの資金を保管します。この場合、攻撃者はこのフックを攻撃して資金を移転させ、資産の損失を引き起こす可能性があります。- 第二のフックは、ユーザーまたは他のプロトコルが依存する重要な状態データを保存します。この場合、攻撃者は重要な状態を変更しようとする可能性があります。他のユーザーやプロトコルが誤った状態を使用すると、潜在的なリスクが生じる可能性があります。Awesome Uniswap v4 Hooksリポジトリの詳細な調査を行った結果、いくつかの重大な脆弱性を発見しました。これらの脆弱性は主にhook、PoolManager、および外部の第三者とのリスク相互作用に起因しており、主にアクセス制御の問題と入力検証の問題に分類されます。全体として、私たちは22の関連プロジェクト(を発見し、Uniswap v4に関係のないプロジェクト)を除外しました。これらのプロジェクトの中で、私たちは8つの(36%)プロジェクトに脆弱性が存在すると考えています。この8つの脆弱性のあるプロジェクトの中で、6つはアクセス制御の問題があり、2つは信頼されていない外部呼び出しに対して脆弱です。#### アクセス制御の問題この部分の議論では、主にv4のコールバック関数が引き起こす可能性のある問題に焦点を当てています。これには8つのフックコールバックとロックコールバックが含まれます。これらの関数はPoolManagerのみが呼び出すことができ、他のアドレス(、EOAおよび契約)からは呼び出されるべきではありません。例えば、報酬が資金プールキーによって配布される場合、対応する関数が任意のアカウントによって呼び出されることができれば、報酬が誤って受け取られる可能性があります。したがって、フックにとっては、特にプール自体以外の他の当事者が呼び出すことができる場合、強力なアクセス制御メカニズムを構築することが重要です。アクセス権限を厳格に管理することで、流動性プールはフックとの未承認の相互作用や悪意のある相互作用に伴うリスクを大幅に低減できます。#### 入力検証の質問Uniswap v4では、ロック機構が存在するため、ユーザーは資金プール操作を実行する前に契約を通じてロックを取得する必要があります。これにより、現在のインタラクションに参加している契約が最新のロッカー契約であることが保証されます。それにもかかわらず、いくつかの脆弱なHook実装における入力検証の不適切さに起因する信頼できない外部呼び出しの可能性のある攻撃シナリオが依然として存在します。- まず、hookはユーザーが相互作用する予定の資金プールを検証していません。これは、偽のトークンを含み、有害なロジックを実行する悪意のある資金プールである可能性があります。- 次に、一部の重要なhook関数は任意の外部呼び出しを許可します。信頼できない外部呼び出しは非常に危険です。なぜなら、それは私たちがよく知っている再入攻撃を含むさまざまなタイプの攻撃を引き起こす可能性があるからです。これらの脆弱なフックを攻撃するために、攻撃者は自分の偽のトークンのために悪意のある資金プールを登録し、フックを呼び出して資金プールで操作を実行できます。資金プールとのやり取りの際に、悪意のあるトークンロジックが制御フローをハイジャックして不正行為を行います。#### 脅威モデルIに対する対策フックに関連するこの種のセキュリティ問題を回避するためには、敏感な外部/公共関数に対する必要なアクセス制御を適切に実施し、入力パラメータを検証することで、相互作用を検証することが重要です。さらに、再入保護は、フックが標準のロジックフローで繰り返し実行されないことを確保するのに役立つ可能性があります。適切なセキュリティ対策を実施することで、資金プールはこの種の脅威に関連するリスクを低減できます。### 脅威モデルIIにおけるセキュリティ問題この脅威モデルでは、開発者とそのフックが悪意を持っていると仮定します。関与する範囲が広いため、私たちはv4バージョンに関連するセキュリティ問題にのみ注目します。したがって、重要なのは提供されたフックがユーザーの送金または認可された暗号資産を処理できるかどうかです。フックへのアクセス方法が、フックに付与される可能性のある権限を決定するため、私たちはフックを2つのカテゴリに分けます:- マネージドフック(Managed Hooks):フックはエントリーポイントではありません。ユーザーはルーター(を介して、Uniswapによって提供される可能性のあるフックと対話する必要があります。- 独立型Hook)スタンドアロンフック(:hookはエントリーポイントであり、ユーザーが直接対話することを可能にします。)# ホスティング型Hookこの場合、ユーザーの暗号資産###は、ネイティブトークンと他のトークン(を含み、routerに転送または権限付与されます。PoolManagerが残高確認を実行したため、悪意のあるhookがこれらの資産を直接盗むことは容易ではありません。しかし、潜在的な攻撃面は依然として存在します。例えば、v4バージョンの手数料管理メカニズムは、攻撃者がhookを通じて操作する可能性があります。)# スタンドアロンフックHookがエントリーポイントとして使用されると、状況はさらに複雑になります。この場合、ユーザーが直接hookと対話できるため、hookはより多くの権限を持つことになります。理論的には、hookはこの対話を通じて望む任意の操作を実行することができます。v4バージョンでは、コードロジックの検証が非常に重要です。主な問題は、コードロジックを操作できるかどうかです。もしフックがアップグレード可能であれば、一見安全なフックがアップグレード後に悪意のあるものになる可能性があり、それが重大なリスクをもたらします。これらのリスクには次のようなものが含まれます:- アップグレード可能なプロキシ###は直接攻撃される可能性があります(；- 自己破壊ロジックを持っています。selfdestructとcreate2を共同で呼び出す場合、攻撃される可能性があります。)# 脅威モデルIIに対する対策フックが悪意のあるものであるかどうかを評価することが極めて重要です。具体的には、ホスティング型フックについてはコスト管理の行動に注目すべきであり、独立型フックについては、それらがアップグレード可能であるかどうかが主な焦点となります。! [なぜフックはUniswap V4の「両刃の剣」なのですか? ]###https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053f0fb97876f16(## まとめ本稿では、Uniswap v4のHookセキュリティ問題に関連するコアメカニズムの概要を示し、2つの脅威モデルを提示し、関連するセキュリティリスクについて概説します。次の記事では、各脅威モデルにおけるセキュリティ問題を深く分析します。
Uniswap v4 Hookメカニズムには安全上のリスクが存在し、専門家は慎重に使用するよう警告しています。
Uniswap v4のリリースが迫る中、Hookメカニズムには安全上のリスクが潜んでいます
Uniswap v4が間もなくリリースされます。このアップデートでは、各取引ペアに無限の流動性プールと動的手数料をサポートすることを含む多くの新機能が導入されます。シングルトンデザイン、フラッシュアカウンティング、フックメカニズム、そしてERC1155トークン標準のサポートも含まれます。v4はイーサリアムのカンクンアップグレード後にリリースされる予定です。
多くの革新の中で、Hookメカニズムはその強力な潜在能力から注目されています。これは、流動性プールのライフサイクルの特定の時点でカスタムコードを実行することを可能にし、プールの拡張性と柔軟性を大幅に強化します。
しかし、Hookメカニズムは両刃の剣である可能性もあります。強力で柔軟な機能を持ちながらも、Hookを安全に使用することには同様に課題が伴います。Hookの複雑さは避けられない新しい攻撃ベクトルをもたらします。したがって、Hookメカニズムに関連するセキュリティ問題や潜在的リスクを体系的に紹介することが特に重要であり、これがより安全なUniswap v4 Hookの構築に役立つでしょう。
この記事では、Uniswap v4におけるHookメカニズムの関連概念を紹介し、その存在するセキュリティリスクを概説します。
Uniswap V4のメカニズム
深く掘り下げる前に、Uniswap v4のメカニズムについて基本的な理解が必要です。公式の発表とホワイトペーパーによると、Hook、シングルインスタンスアーキテクチャ、そしてフラッシュアカウンティングは、カスタム流動性プールと複数のプール間での効率的なルーティングを実現するための三つの重要な機能です。
フック
Hookは流動性資金プールのライフサイクルの異なる段階で動作する契約を指します。UniswapチームはHookを導入することで、誰でもトレードオフの意思決定を行えるようにしたいと考えています。この方法により、ネイティブに動的手数料をサポートし、オンチェーンのリミットオーダーを追加したり、時間加重平均を使用して(TWAMM)の大口注文を分散させることが可能になります。
現在、8つのHookコールバックがあり、4つのグループに分かれています(各グループには1対のコールバックが含まれています):
! なぜフックはUniswap V4の「両刃の剣」なのですか?
シングルトン、ライトニング記帳、およびロックメカニズム
シングルトンアーキテクチャとライトニング帳簿は、コストを削減し、効率を確保することでパフォーマンスを向上させることを目的としています。これにより、すべての流動性プールが同じスマートコントラクトに保存される新しいシングルトン契約が導入されます。このシングルトン設計は、すべてのプールの状態を保存および管理するためにPoolManagerに依存しています。
v4バージョンでは、フラッシュアカウンティングとロックメカニズムが導入されました。ロックメカニズムの動作方式は以下の通りです:
ロッカー コントラクトは、PoolManager のロックを要求します。
PoolManagerはそのロッカー契約アドレスをlockDataキューに追加し、lockAcquiredコールバックを呼び出します。
lockerコントラクトはコールバック内でそのロジックを実行します。実行中、lockerコントラクトとプールの相互作用は非ゼロの通貨増加を引き起こす可能性があります。しかし、実行が終了する時点で、すべての増加はゼロに清算されなければなりません。また、lockDataキューが空でない場合、最後のlockerコントラクトのみが操作を実行できます。
PoolManagerは、lockDataキューのステータスと通貨の増分を確認します。 確認が完了すると、PoolManager はロッカー契約を削除します。
要するに、ロックメカニズムは同時アクセスを防ぎ、すべての取引が清算されることを保証します。ロッカー契約は順番にロックを申請し、次にlockAcquiredコールバックを通じて取引を実行します。プール操作の前後に対応するフックコールバックがトリガーされます。最後に、PoolManagerが状態を確認します。
この方法は、操作によって調整されるのが内部ネットバランス(、すなわちデルタ)であり、即時転送を実行するのではないことを意味します。いかなる変更もプールの内部バランスに記録され、実際の転送は操作(、つまりロック)が終了した時点で行われます。このプロセスは、未清算のトークンが存在しないことを保証し、資金の完全性を維持します。
ロックメカニズムが存在するため、外部のすべてのアカウント(EOA)は直接PoolManagerと対話できません。代わりに、すべての対話は契約を通じて行う必要があります。この契約は中間ロッカーとして機能し、プール操作を行う前にロックをリクエストする必要があります。
主に2つの契約インタラクションシーンが存在します:
locker契約は公式コードライブラリから来るか、ユーザーによってデプロイされます。この場合、私たちはインタラクションをルーターを介して行うことができます。
locker契約とHookが同じ契約に統合されるか、または第三者によって制御されます。この場合、私たちはインタラクションをHookを通じて行うことができます。この場合、Hookはlocker契約の役割を果たすと同時に、コールバックの処理を担当します。
! なぜフックはUniswap V4の「両刃の剣」なのですか?
脅威モデル
関連するセキュリティ問題について議論する前に、脅威モデルを特定する必要があります。主に以下の2つの状況を考慮します:
脅威モデルI: Hook自体は良性ですが、脆弱性があります。
脅威モデルII: Hook自体が悪意があります。
次の部分では、これら二つの脅威モデルに基づいて潜在的なセキュリティ問題について議論します。
威胁モデルIにおけるセキュリティ問題
脅威モデルIは、Hook自体に関連する脆弱性に焦点を当てています。この脅威モデルは、開発者とそのHookが悪意を持っていないと仮定しています。しかし、スマートコントラクトに既知の脆弱性が存在することもあり、それがHookに現れる可能性もあります。
私たちはv4バージョン特有の潜在的な脆弱性に焦点を当てることを選択します。Uniswap v4では、Hookはコアプール操作(の前または後にカスタムロジックを実行できるスマートコントラクトで、初期化、位置の変更、交換、そして)を収集することが含まれます。Hookは標準のインターフェースを実装することが期待されていますが、カスタムロジックを含めることも可能です。したがって、私たちの議論の範囲は標準Hookインターフェースに関連するロジックに制限されます。次に、Hookがどのようにこれらの標準Hook関数を悪用する可能性があるかなど、潜在的な脆弱性の源を特定しようとします。
具体的には、私たちは以下の2つのフックに注目します:
最初のフックは、ユーザーの資金を保管します。この場合、攻撃者はこのフックを攻撃して資金を移転させ、資産の損失を引き起こす可能性があります。
第二のフックは、ユーザーまたは他のプロトコルが依存する重要な状態データを保存します。この場合、攻撃者は重要な状態を変更しようとする可能性があります。他のユーザーやプロトコルが誤った状態を使用すると、潜在的なリスクが生じる可能性があります。
Awesome Uniswap v4 Hooksリポジトリの詳細な調査を行った結果、いくつかの重大な脆弱性を発見しました。これらの脆弱性は主にhook、PoolManager、および外部の第三者とのリスク相互作用に起因しており、主にアクセス制御の問題と入力検証の問題に分類されます。
全体として、私たちは22の関連プロジェクト(を発見し、Uniswap v4に関係のないプロジェクト)を除外しました。これらのプロジェクトの中で、私たちは8つの(36%)プロジェクトに脆弱性が存在すると考えています。この8つの脆弱性のあるプロジェクトの中で、6つはアクセス制御の問題があり、2つは信頼されていない外部呼び出しに対して脆弱です。
アクセス制御の問題
この部分の議論では、主にv4のコールバック関数が引き起こす可能性のある問題に焦点を当てています。これには8つのフックコールバックとロックコールバックが含まれます。これらの関数はPoolManagerのみが呼び出すことができ、他のアドレス(、EOAおよび契約)からは呼び出されるべきではありません。例えば、報酬が資金プールキーによって配布される場合、対応する関数が任意のアカウントによって呼び出されることができれば、報酬が誤って受け取られる可能性があります。
したがって、フックにとっては、特にプール自体以外の他の当事者が呼び出すことができる場合、強力なアクセス制御メカニズムを構築することが重要です。アクセス権限を厳格に管理することで、流動性プールはフックとの未承認の相互作用や悪意のある相互作用に伴うリスクを大幅に低減できます。
入力検証の質問
Uniswap v4では、ロック機構が存在するため、ユーザーは資金プール操作を実行する前に契約を通じてロックを取得する必要があります。これにより、現在のインタラクションに参加している契約が最新のロッカー契約であることが保証されます。
それにもかかわらず、いくつかの脆弱なHook実装における入力検証の不適切さに起因する信頼できない外部呼び出しの可能性のある攻撃シナリオが依然として存在します。
まず、hookはユーザーが相互作用する予定の資金プールを検証していません。これは、偽のトークンを含み、有害なロジックを実行する悪意のある資金プールである可能性があります。
次に、一部の重要なhook関数は任意の外部呼び出しを許可します。
信頼できない外部呼び出しは非常に危険です。なぜなら、それは私たちがよく知っている再入攻撃を含むさまざまなタイプの攻撃を引き起こす可能性があるからです。
これらの脆弱なフックを攻撃するために、攻撃者は自分の偽のトークンのために悪意のある資金プールを登録し、フックを呼び出して資金プールで操作を実行できます。資金プールとのやり取りの際に、悪意のあるトークンロジックが制御フローをハイジャックして不正行為を行います。
脅威モデルIに対する対策
フックに関連するこの種のセキュリティ問題を回避するためには、敏感な外部/公共関数に対する必要なアクセス制御を適切に実施し、入力パラメータを検証することで、相互作用を検証することが重要です。さらに、再入保護は、フックが標準のロジックフローで繰り返し実行されないことを確保するのに役立つ可能性があります。適切なセキュリティ対策を実施することで、資金プールはこの種の脅威に関連するリスクを低減できます。
脅威モデルIIにおけるセキュリティ問題
この脅威モデルでは、開発者とそのフックが悪意を持っていると仮定します。関与する範囲が広いため、私たちはv4バージョンに関連するセキュリティ問題にのみ注目します。したがって、重要なのは提供されたフックがユーザーの送金または認可された暗号資産を処理できるかどうかです。
フックへのアクセス方法が、フックに付与される可能性のある権限を決定するため、私たちはフックを2つのカテゴリに分けます:
マネージドフック(Managed Hooks):フックはエントリーポイントではありません。ユーザーはルーター(を介して、Uniswapによって提供される可能性のあるフックと対話する必要があります。
独立型Hook)スタンドアロンフック(:hookはエントリーポイントであり、ユーザーが直接対話することを可能にします。
)# ホスティング型Hook
この場合、ユーザーの暗号資産###は、ネイティブトークンと他のトークン(を含み、routerに転送または権限付与されます。PoolManagerが残高確認を実行したため、悪意のあるhookがこれらの資産を直接盗むことは容易ではありません。しかし、潜在的な攻撃面は依然として存在します。例えば、v4バージョンの手数料管理メカニズムは、攻撃者がhookを通じて操作する可能性があります。
)# スタンドアロンフック
Hookがエントリーポイントとして使用されると、状況はさらに複雑になります。この場合、ユーザーが直接hookと対話できるため、hookはより多くの権限を持つことになります。理論的には、hookはこの対話を通じて望む任意の操作を実行することができます。
v4バージョンでは、コードロジックの検証が非常に重要です。主な問題は、コードロジックを操作できるかどうかです。もしフックがアップグレード可能であれば、一見安全なフックがアップグレード後に悪意のあるものになる可能性があり、それが重大なリスクをもたらします。これらのリスクには次のようなものが含まれます:
アップグレード可能なプロキシ###は直接攻撃される可能性があります(；
自己破壊ロジックを持っています。selfdestructとcreate2を共同で呼び出す場合、攻撃される可能性があります。
)# 脅威モデルIIに対する対策
フックが悪意のあるものであるかどうかを評価することが極めて重要です。具体的には、ホスティング型フックについてはコスト管理の行動に注目すべきであり、独立型フックについては、それらがアップグレード可能であるかどうかが主な焦点となります。
! [なぜフックはUniswap V4の「両刃の剣」なのですか? ]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
まとめ
本稿では、Uniswap v4のHookセキュリティ問題に関連するコアメカニズムの概要を示し、2つの脅威モデルを提示し、関連するセキュリティリスクについて概説します。
次の記事では、各脅威モデルにおけるセキュリティ問題を深く分析します。