Puffer Protocol：アクセス制御メカニズムの重要性とセキュリティ向上の手法

「Pufferは、Eigenlayer上に構築された分散型ネイティブ・リキッド・リステーキング・プロトコル（nLRP）です」。わずか数日で6億米ドルを超えるTVL（Total Value Locked）を集めています。プロトコルに対する悪意のある操作を防ぐためには、アクセス制御が重要なセキュリティ上の検討事項となります。

本ブログでは、Pufferプロトコルにおけるアクセス制御メカニズムの全体的なアーキテクチャと、その現在の設定についてレビューします。これは、コミュニティがプロトコルをより深く理解する助けとなるでしょう。なお、分析結果はイーサリアム上の現時点（ブロック 19177155、2024年2月7日 15:17:35 UTC）の状態に基づいています。

コントラクトアドレス

以下の表は、本ブログで使用しているスマートコントラクトの一覧です。

アーキテクチャ

プロトコル全体には、ユーザー資産に関連する主に2つのスマートコントラクトが含まれています。1つ目は PufferDepositor、2つ目は PufferVault です。

PufferDepositorの主な機能は、ユーザーの資産を受け入れ、それをPufferVaultに預け入れることです。ユーザーが預け入れた資産がstETHでない場合、プロトコルによって自動的にDEXでのスワップが実行されます。

PufferVaultは、ユーザー資産を保持するメインのコントラクトです。また、EigenLayerへの預け入れの入り口でもあります。プロトコル全体の主要なアクセス制御はこのスマートコントラクト内に実装されています。

アクセス制御メカニズム

アクセス制御全体は、OpenZeppelinのAccessManagerモジュールを活用して実装されています。AccessManager スマートコントラクトは、PufferDepositor および PufferVault コントラクトの権限を管理します。

AccessManagerは、異なるアドレスを含む異なる「ロール（役割）」を定義します。各ロールは、AccessManagedコントラクト（すなわちPufferDepositorとPufferVault）内の異なる関数を呼び出すように割り当てることができます。AccessManagerは、特定の関数の遅延実行をサポートしています。つまり、あるアドレスにロールを付与する際、そのロールを用いてそのアドレスから発行される操作を即時に実行するか、あるいは一定の時間を遅延させて実行するかを指定することができます。

現在のアクセス制御設定

とはいえ、アクセス制御の有効性は、その設定に依存します。私たちはこれまで、ACL（アクセス制御リスト）ルールの設定の不備がセキュリティ上の脆弱性につながった事例を数多く目撃してきました。

これに対処するため、私たちはPufferプロトコルの現在の設定をレビューし、以下に結果を提示します。なお、これらの結果はブロック19177155（2024年2月7日 15:17:35 UTC）時点の状態のみを反映していることに留意してください。

ロール

以下は、システム内の現在のロールとそれに関連付けられたアドレスの概要を示す表です。

PufferVaultコントラクト内の関数を実行するには、異なる実行パスが存在します。1つのパスはTimeLockコントラクトを経由するものです（ADMINロールを持つ。図のパス1を参照）。もう1つのパスは、呼び出し元に割り当てられたロールを使用して、Vault内の関数を直接呼び出すものです。どちらの場合も、呼び出しは必ずAccessManagerを経由する必要があります。

タイプI: TimeLockコントラクトからの呼び出し

TimeLockコントラクトから関数を呼び出す際、割り当てられるロールはADMINであることに注意してください。この指定は、Vaultの観点から見ると、呼び出し元がADMINロールを持つTimeLockコントラクトであるために生じます。その結果、TimeLockコントラクトには追加の遅延実行メカニズムが組み込まれます。

• Operation SafeWallet: このコンポーネントは、604,800秒（約7日間）の遅延後に、対象コントラクト内の関数を呼び出すことができます。
• Community SafeWallet: このコンポーネントは、対象コントラクト内の関数を即時に呼び出す能力を持っています。また、Operation SafeWalletによって提出されたキュー内の保留中の実行をキャンセルする権限も所有しています。
• Pausing SafeWallet: このコンポーネントは対象コントラクトの一時停止にのみ制限されており、他の関数を実行する権限はありません。

タイプII: Vaultコントラクトの直接呼び出し

次の方法は、Vaultコントラクト内の関数を直接呼び出すものです。各ロールに関連付けられたアドレスによって、どの関数を呼び出せるかはAccessManagerによって決定されることに注意してください。

Operation SafeWalletとCommunity SafeWalletはどちらも、upgradeToAndCall関数を直接呼び出して、対象コントラクトをアップグレードする能力を持っています。重要な違いは時期です。Community SafeWalletはこの操作を遅延なく実行しますが、Operation SafeWalletには遅延が課されます。

さらに、Operation SafeWalletには、EigenLayerへの資産の転送および出金リクエストの開始を行う関数を即時実行する権限が備わっています。

更新情報 [2024年2月8日 10:02:59 UTC]

Operation SafeWalletをロール1から削除する操作がスケジュールされました。この操作はブロック1707940908以降に実行される予定であり、これには約7日間の遅延が伴います。これらのキューに入れられたトランザクションのシミュレーションは、BlockSec Phalconを使用して行われました。

• Phalconでのシミュレートされたトランザクション: 10日後の2024年2月18日 17:59:07 (UTC) にキューに入れられた実行を完了するもの。
• Operation SafeWalletが依然としてロール1を持っているかどうかを照会するシミュレーショントランザクション（結果: false）

更新情報 [2024年2月16日 20:10:23 UTC]:

• Operation SafeWalletをロール1から削除するトランザクションが実行されました。Etherscanの結果で確認できます。

Safe Walletの設定

Safe Walletの設定もプロトコルのセキュリティに影響を与えます。

更新情報 [2024年2月8日 10:02:59 UTC]:

• アドレス 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76がOperation SafeWalletから削除され、承認レベルが3/5に調整されました。
• 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76をCommunity SafeWalletから削除するためのトランザクションが開始され、現在コミュニティからのマルチシグ承認を待機しています。
• 3つのウォレットがPausing SafeWalletから削除され、設定が1/9に調整されました。

まとめ

本ブログ投稿では、Pufferプロトコルが採用しているセキュリティメカニズムについてレビューしました。全体として、権限システムの設計は包括的なものです。

コミュニティは、潜伏するリスクを積極的に監視する必要があります。

• Community SafeWalletのオーナーの秘密鍵のセキュリティは極めて重要です。3つの秘密鍵が侵害されると、攻撃者がVaultをアップグレードできる可能性があります。
• EigenLayerなど、依存しているプロトコルのセキュリティについても積極的に監視する必要があります。