深読み解釈：なぜRollupにはセキュリティ委員会が必要なのか？

原文作者：PATRICK MCCORRY

原文编译：Luffy，Foresight News

暗号資産と相互作用するデータベースは、いつか必ずRollupを技術スタックとして選択することになるでしょう。開発者がこのような決定を下すには、多くの十分な理由があります：

• リアルタイム監査

• デフォルトの支払い能力証明

• ユーザー資金の保管はオプション

• 誠実な参加者が全体のシステムを保護できる

最も重要なのは、Rollupのすべての設計と実装作業が、ユーザー、彼らの資金、そして彼らのすべての相互作用を、潜在的に未知で強力なシステムオペレーターから保護することに集中していることです。

システム全体がオフラインになっても、ユーザーは一人で資金を回収できます。

もしRollupが技術スタックとして広く展開されることができれば、私たちは信頼の壁を打破し、世界中のコミュニティの誰もが財務的相互作用を行えるようになり、グローバルな電子商取引、リモート採用、そして摩擦のないサービス提供の新時代に入ることができるかもしれません。

Rollupを正しく実行するためには、確かに多くの努力が必要です。

マルチシグはどうですか？

これは良さそうですが、システム全体は最終的にマルチシグによって制御されます。もし署名者が侵害されたり悪意を持った場合、彼らは簡単にすべての資金を盗むことができます。

では、誰がRollupに関心を持つのでしょうか？CTのどこかで。

確かに、現在のすべてのRollupはマルチシグを持ち、基盤となるスマートコントラクトをアップグレードする権限を持っていますが、私たちが見るように、これはユーザー資金を保護するための保守的なメカニズムであり、より広範なシステムアーキテクチャの一部です。

セキュリティ委員会の責任

マルチシグは、複数の署名者による承認が必要な操作のシステムを指す技術用語です。たとえば、N人の署名者のうちK人がデジタル署名を完了しなければ、取引は許可されません。

Rollupの文脈では、マルチシグは通常セキュリティ委員会と呼ばれ、署名者はすべての関連スマートコントラクトをアップグレードする権限を与えられます。

私たちが非常に馴染みのあるArbitrumのセキュリティ委員会を見て、この組織がどのような責任を負う可能性があるかを見てみましょう：

• 拒否権。セキュリティ委員会がArbitrum DAOによって通過した提案がArbitrumの憲章に違反し、Arbitrumエコシステムに損害を与える可能性があると考えた場合、その提案を取り消すことができます。たとえば、ガバナンス攻撃によって通過した提案を取り消すこと。

• メンテナンス。Arbitrumのスマートコントラクトスイートを微細な変更のためにアップグレードします。これらの変更は影響が小さく、Arbitrum DAOの関与を必要としません。

• 緊急事態。緊急事態に迅速に対応し、ユーザー資金が差し迫ったリスクにさらされていると判断した場合、スマートコントラクトを緊急にアップグレードできます。

もちろん、最も重要なのは、セキュリティ委員会の主な責任は緊急事態に対応し、ユーザー資金を保護するために迅速に行動することです。

セキュリティ委員会のメンバーは非常に信頼できる人物である必要があります。

人々は、署名者が迅速に反応し、緊急事態が発生したときにスマートコントラクトをアップグレードできると信じ、彼らがスマートコントラクト内の資金の安全を最大限に保護するために努力することを信じています。

正しいマルチシグの閾値を選択する

セキュリティ委員会を設立する際に考慮すべき2つの重要な要素があります：

• 署名者は合計で何人いますか？

• 行動を承認するために必要な署名者は最低何人ですか？

• これは一見取るに足らない問題のように思えますが、2つの数字に過ぎないとしても、バランスの取れた行動を考慮する必要があります：

• セキュリティ違反：K人のメンバーが共謀してスマートコントラクトを変更し、ユーザー資金を盗む可能性があります。

• 活性違反：N-K+1人のメンバーが共謀してスマートコントラクトに対するいかなる変更も阻止し、重大な脆弱性が発見された場合、問題は特に深刻です。

難しいのは、平和な時期には資金の安全を維持し、緊急時にはユーザー資金が脅かされたときに迅速に行動できる閾値を決定することです。

具体的な例を考えてみましょう。閾値が9/10に設定されていると仮定します。この場合、9人の署名者が共同でメッセージに署名する必要があります。これは厳しいセキュリティ閾値です。なぜなら、9人の署名者が共謀しなければ資金を盗むことができないからです。しかし、欠点は、任意の2人の署名者が緊急時のいかなる行動も阻止できることです。たとえば、2人の署名者が大西洋を横断するフライトに乗っている場合、セキュリティ委員会はその職務を果たすことができません。

もちろん、セキュリティ閾値が低い場合、たとえば2/10の場合、任意の2人の署名者が共謀（または秘密鍵が漏洩）すれば、ユーザー資金が盗まれることになります。

一人の誠実さに対する見方は、時間の経過とともに変わる可能性があります。

適切な閾値を選択することは、技術的な問題というよりも社会的な問題であり、これは科学よりもむしろ芸術であると私は考えています。安全性は、個々の署名者の誠実さに大きく依存します。私たちがすぐに見るように、マルチシグへの信頼を減らす方法はいくつかありますが、これは一連のトレードオフをもたらします。

セキュリティ委員会のメンバー

主要なRollupがすべてのスマートコントラクトを即座にアップグレードするために必要なマルチシグ閾値

ほとんどのRollupは、そのセキュリティ委員会に匿名の署名者のグループを持っています。私たちは、これが以下の理由によるものであると疑っています：

• Rollupの発展段階、

• メンバーの人身安全を保護するため、

• 匿名がユーザー資金を保護する最良の選択肢であると考えられているため。

• 一方で、3つのRollupプロジェクトはそのセキュリティ委員会のメンバーを公に発表しています：

• Arbitrum：署名者は公選によって選出され、現在のリストはTallyで確認できます。署名者のうち3名のみがArbitrumプロジェクトに関連しています（2名はOffchain Labsから、1名はArbitrum財団から）。

• Base：2/2マルチシグ、1つはBaseが制御し、もう1つはOptimismが制御しています。

• Polygon zkEVM：まだ実施されていませんが、彼らはマルチシグを10/13にアップグレードすることを発表しており、Polygon Labsからの2名のメンバーとPolygon Labsの顧問が含まれています。

• zkSync Lite：zkSync LiteはzkSync Eraと区別されるべきであり、そのセキュリティ委員会は公に発表されており、Rollupプロジェクトの直接の関連機関（zkSyncの投資者を除く）を含んでいません。

Arbitrumや今後のPolygonでは、Rollupプロジェクトに直接関連する署名者はわずかであり、関連機関がセキュリティ委員会の行動を阻止することができないように十分に少ないです。zkSync Liteでは、zkSyncの投資者を除いて、プロジェクトから独立した署名者が任命されています。

すべてのケースにおいて、Rollupはプロジェクトと直接関係のない署名者を非常に重視しています。

しかし、良好なマルチシグを構成する方法については合意が欠けているようで、これがいくつかの設計上の問題を引き起こしています：

• 匿名メンバーを許可すべきか？

• メンバーは異なる地域から来るべきか？

• メンバーは個人か会社か？

• メンバーは任命されるべきか選挙で選ばれるべきか？

• 同じ会社（または国）からのメンバーは何人まで許可されるべきか？

• 適切と見なされる最小規模と閾値は存在するか？

一般的な経験則は、高い誠実さを持つメンバーを選ぶことです。これにより、一般の人々がシステムの安全性に自信を持つことができます。少なくとも、私はほとんどのプロジェクトがそうするだろうと信じていますが、これは必ずしも公に検証できるわけではありません。

注：Arbitrumのセキュリティ委員会の6名のメンバーは現在事前に任命されていますが、彼らは3月の選挙で交代します。

委員会の権限を弱める

これまで、私たちはスマートコントラクトを即座にアップグレードする権限を持つ委員会について考えてきましたが、委員会の権限を制限する方法はいくつかあります：

時間遅延（Time delay）。委員会が承認したすべての操作は、時間Tが経過した後にのみ実行され、有効になります。

一時停止のみ（Pause-only）。ネイティブクロスチェーンブリッジが保有するすべての資産は、委員会によって凍結される可能性があります。これにより、以下の機能が一時停止される可能性があります：

• L2からL1へのメッセージの転送（つまり、出金）、

• 保留中の取引の順序付け、

• 新しいチェックポイント/証明書の完了、

• 新しいRollupデータの受け入れ（つまり、保留中のトランザクション）。

委員会を回避する（Removed）。委員会を廃止し、別のガバナンスメカニズム（DAOなど）に依存してアップグレードを承認します。

もちろん、これにより、委員会が迅速に行動する能力や、ユーザー資金を脅かす緊急事態に効果的に対応できるかどうかが制限されます。

もし脆弱性が委員会に私的に開示され、まだハッカーに利用されていない場合、委員会はスマートコントラクトをアップグレードしてバグを修正することを選択できます。アップグレードに時間遅延を加えると、攻撃者が公開されたアップグレードを研究し、脆弱性を見つけて利用するリスクが高まります。

たとえば、ビットコインのCVE-2018-17144は、最初はDDoS脆弱性として宣伝され、より深刻なトークンインフレーションの脆弱性を隠そうとしました。アップグレードの速度は、それが利用されるのを防ぐために重要です。

一時停止メカニズムの防御能力を評価する

攻撃者が脆弱性を利用する潜在的なシナリオを考えてみましょう：

• 悪意のあるL2→L1メッセージ。攻撃者はRollup上のスマートコントラクトからの任意のメッセージを作成し、ネイティブクロスチェーンブリッジを介してイーサリアム上のスマートコントラクトに転送できます。

• 無効な状態遷移。攻撃者はRollup上で状態遷移関数のルールに違反する取引を実行でき、通常は無効と見なされるべきです。

• 出金の脆弱性。攻撃者はイーサリアム（第1層）上で取引を発行するだけで、ネイティブクロスチェーンブリッジから資金を引き出すことができます。

これらの3つのケースでは、時間遅延は攻撃者に資金を盗むためのさらなる時間を与え、委員会がシステムを守る機会の窓を減少させるだけです。遅延機能は能動的な攻撃に対して防御することはできず、日常のメンテナンスや緊急でないタスクにのみ使用されます。

私たちは、一時停止システムの能力と、システムがどの程度一時停止できるかを評価します。

悪意のあるL2→L1メッセージの場合、一時停止機能は取引活動を妨げることなく攻撃を軽減できます。委員会はメッセージの転送および/または新しいチェックポイントの最終確定機能を一時停止すべきです。L2→L1メッセージは、実行前に時間遅延を設けるべきだという意見もあります。これにより、委員会はエラーを検出し、緊急事態に対応する時間を持つことができます。

無効な状態遷移を防御することはさらに厄介です。なぜなら、取引の最終性がRollup内で異なる層を持つからです。もし私たちがRollup取引だけを考慮し、いかなる副作用も考慮しない場合、セキュリティ委員会の最良の防御は、チェックポイントの最終確定能力を停止することですが、取引の順序付けを続けることです。これにより、エラーを修正し、チェックポイントの完了を再活性化し、無効な取引を単に無視する時間を確保できます。

しかし、Rollup上の取引活動を停止しない場合、ユーザー体験は非常に混乱し、Rollupはクライアントソフトウェアがアップグレードされるまで深刻に破損した状態になる可能性があります。

これにより、次のシナリオに進みます。Rollup上の無効な取引が他のシステムにどのように影響するかを考え、委員会はどのように反応すべきか。最良の防線は、ネイティブクロスチェーンブリッジの取引の最終確定の能力を凍結するか、完全に順序付けを停止することです。

これは、資金を1つのRollupから別のRollupに移動する迅速なクロスチェーンブリッジなどの特定のシステムが、Rollupの取引（無効な取引を含む）が順序付けられたと考えると、資金移動を許可する可能性があるからです。この例では、攻撃者がRollup上のDeFiプロトコルを利用し、その後迅速なクロスチェーンブリッジを介して別のRollupに資金を迅速に移動することを許可する可能性があります。

委員会が脆弱性を修正し、無効な取引を復元する際には、損害がすでに発生している可能性があります。DeFiプロトコルやクロスチェーンブリッジ内のLPは、攻撃による損失を被る可能性があります。

最後に、その脆弱性が攻撃者にネイティブクロスチェーンブリッジから資金を直接引き出させる場合、Nomad Hackのように、セキュリティ委員会はそれを阻止する力を持たないかもしれません。

一時停止メカニズムには、最終的な全体的な問題があります。私たちは、より広範なガバナンスシステムがアップグレードを承認し、Rollupを再活性化することができると仮定しなければなりません。もし私たちがガバナンスシステムを、Rollup上で動作するオンチェーン投票システムを持つDAOと仮定すると、実施上の厄介な問題が発生します。

たとえば、L2→L1メッセージのクロスチェーンブリッジが一時停止された場合、DAOの投票結果はRollupからイーサリアム上のネイティブクロスチェーンブリッジに伝達できず、DAOが承認情報を送信し、アップグレードを実行するための代替手段が必要です。

セキュリティ委員会の段階的廃止

コミュニティの中には、セキュリティ委員会を段階的に廃止すべきだと考える人もいますが、私の見解では、これには2つの問題があります：

誤った安全感。脆弱性を利用する攻撃者は、セキュリティ委員会が段階的に廃止されるのを待ってから攻撃を実行します。時間が経つにつれて、私たちのシステムの安全性に対する信頼が弱まります。

回復オプションが限られる。セキュリティ委員会がなければ、コミュニティは攻撃者に対抗することができません。唯一の選択肢は、並行してホワイトハットハッキングを行い、一部の資金を取り戻すことを期待することです。

私は、セキュリティ委員会は常に必要であると考えていますが、彼らに与えられる権限は徐々に縮小されるべきです。

この点を考慮して、設計上の問題は次のようになります：

ユーザーに最小限の影響を与えながら、セキュリティ委員会がシステムを一時停止し、より広範なコミュニティがエラーを修正し、システムを再活性化する方法を決定することを許可するにはどうすればよいでしょうか？

言い換えれば、私たちは、コミュニティが介入し、システムを復元することを真に許可するスキームが必要であり、その後にセキュリティ委員会の一時停止権限を制限する必要があります。

Layer 1ブロックチェーンの分野では、コミュニティはユーザーがアクティブなフォークを使用して直接合意に達することができますが、この方法はイーサリアム上のスマートコントラクト（Rollupなど）には適用できません。なぜなら、イーサリアム全体をフォークする必要がないからです。特定の状況では、イーサリアムコミュニティがRollupを保存することを集団で決定することがあるかもしれませんが、2016年のTheDAOのように、Rollupはそのような結果に依存すべきではなく、期待すべきでもありません。

この考えに沿ったもう一つの興味深いアイデアは、イーサリアム最高裁判所を実現し、スマートコントラクトのアップグレードを決定し、ユーザーアクティブフォークに似たものを有効にすることです。

前述のように、Rollupがその安全性をDAOに委任する場合、DAOがイーサリアム上で直接投票できるようにする実装が必要です。これは非常に厄介で、特に投票プロトコルがRollup内に存在する場合はそうです。

最後に、安理会が反応する必要がある状況のタイプを包括的にレビューし、その必要性に関する議論を助けることが重要だと考えています。

マルチシグがあれば、なぜRollupを心配する必要があるのか？

私たちは、セキュリティ委員会の責任、設計、ニーズを理解するのにかなりの時間を費やしましたが、重要なのは、この記事の最初の質問に戻ることです：

Rollupは単なるマルチシグですか？

答えはノーです。

なぜそうなのかを理解するためには、一歩引いて、ブロックチェーンシステムが本当に何をしたいのかを理解するのが最良です。

ブロックチェーンプロトコルは、ユーザーがデータベースのコピーを計算し、他の人と同じデータベースを持っていることを確信できるようにするツールです。

これを考慮すると、すべてのブロックチェーンシステムには2つのコンポーネントがあります：

• ブロックチェーンプロトコル。ソフトウェア、暗号学、分散システムの組み合わせで、誰もがデータベースの完全性に自信を持てるようにします。

• ガバナンスシステム。すべての利害関係者が協力し、ブロックチェーンプロトコルを変更することに同意するための調整メカニズムです。

すべてのブロックチェーンシステム（Rollupを含む）の目標は、ブロックチェーンプロトコルが常に99.9999%の非常に信頼性の高い稼働時間で動作することを保証することです。信頼されたシステムオペレーターは、システムの日常運営にほとんど干渉するべきではありません。最終的に、ユーザーの残高、スマートコントラクトのコード、状態を保護する責任は、ソフトウェア、暗号学、分散システムにあります。

時には、ユーザーの利益を改善するためにブロックチェーンプロトコルを変更する必要があります。コミュニティは、設定の問題を修正したり、新しい機能を追加したり、システムの完全性に対する脅威に反応したりしたいと考えるかもしれません。これは人為的な介入を必要とし、0.0001%の時間でのみ呼び出されることができます。

ガバナンスシステムは、人為的な介入を実現する責任があり、何年にもわたっていくつかの方法が登場しています：

• 中央集権的政党：一方が単独でシステムのアップグレード方法を決定できます（ビットコインを含む多くのプロジェクトはこの方法で始まりました）。

• 大まかな合意：大多数の参加者がアップグレードを展開する準備ができていることを示し、マーク日を決定し、その日付にアップグレードを実行します（ビットコイン/イーサリアム）。

• 投票プロトコル：各当事者が選挙に参加し、アップグレードを承認するかどうかを明確に投票します。

• 介入不可能：スマートコントラクトは不変であり、システムは永遠に変更できません。

上記の内容に加えて、コミュニティは緊急時に迅速に行動するためのガバナンスの補完オプションとしてセキュリティ委員会を任命することを決定できます。

セキュリティ委員会は攻撃を防ぎません。これは受動的なメカニズムであり、ブロックチェーンプロトコルのユーザー資金またはシステムの信頼性/性能が攻撃されているときに、ガバナンスと共に機能します。

最後に

ブロックチェーンプロトコル、ガバナンス、セキュリティ委員会に関するすべての議論は非常に重要です。このような議論が存在することが、暗号通貨を特別なものにしています。

これは信頼工学の良い例です：システム内の信頼要素を特定、測定、減少/排除することに焦点を当てた工学の分野です。

暗号通貨では、私たちはユーザーを強力なシステムオペレーターから保護するだけでなく、最も不利な条件下でもシステムが信頼性（安全）を持って動作するように構築することに焦点を当てています。

だからこそ、コミュニティメンバーがセキュリティ委員会の役割に対して懐疑的であることは健全ですが、彼らは緊急事態の間にユーザー資金を受動的に保護するためのより良い解決策を提案する責任があります。

この記事が、なぜセキュリティ委員会が有用であり、今日必要であるのか、そしてそれがスマートコントラクトシステムのより広範なアーキテクチャの一部に過ぎないことを明確に示すことを願っています。