Rollup に安全委員会が必要な理由を理解するには、さらに詳しくお読みください。
原作者: パトリック・マッコーリー
オリジナル編集：ルフィ、フォーサイトニュース
暗号資産とやり取りするデータベースは、いつかそのテクノロジー スタックとして Rollup を選択することになるでしょう。開発者がこの決定を下すのには多くの正当な理由があります。
リアルタイム監査
デフォルトの支払い能力の証明
ユーザー資金のエスクローはオプションです
正直な当事者はシステム全体を保護します
最も重要なことは、Rollup の設計と実装のすべての取り組みは、ユーザー、その資金、およびそのすべてのやり取りを、潜在的に未知の強力なシステム オペレーターから保護することに重点を置いているということです。
システム全体がオフラインであっても、ユーザーは自分で資金を回収することができます。
Rollup がテクノロジー スタックとして広く展開できれば、信頼の壁を打ち破り、グローバル コミュニティの誰とでも金融交流が可能になり、グローバルな電子商取引、リモート リクルーティング、スムーズなサービスの新時代の到来をもたらす可能性があります。配達。
Rollup を正しく機能させるには多大な労力がかかります。
マルチシグネチャについてはどうですか?
これは素晴らしいことのように聞こえますが、システム全体は最終的にマルチシグネチャによって制御されます。署名者が侵害されているか悪意がある場合、すべての資金を簡単に盗むことができます。
では、ロールアップを気にする人はいないでしょうか? CTのどこか。
確かに、現在のすべてのロールアップには、基礎となるスマート コントラクトをアップグレードする権限を持つマルチ署名がありますが、後で説明するように、これはユーザーの資金を保護するための保守的なメカニズムであり、より広範なシステム アーキテクチャの一部です。
安全委員会の責任
マルチ署名は、アクションを承認するために複数の署名者を必要とするシステムを指す技術用語です。たとえば、トランザクションは、N 人の署名者のうち K 人がデジタル署名を完了した場合にのみ許可されます。
ロールアップの文脈では、マルチシグはセキュリティ委員会と呼ばれることが多く、署名者には関連するすべてのスマート コントラクトをアップグレードする権限が与えられます。
この組織がどのような責任を負うのかを理解するために、Arbitrum の安全委員会 (私はよく知っているので) を見てみましょう。
拒否権。仲裁委員会 DAO によって可決された提案が仲裁憲章に違反し、仲裁委員会のエコシステムに損害を与える可能性があるとセキュリティ委員会が判断した場合、提案を取り消すことができます。たとえば、ガバナンス攻撃により可決された提案をキャンセルするなどです。
維持する。 Arbitrum スマート コントラクト スイートをアップグレードして、影響が少なく、Arbitrum DAO の関与を必要としない小さな変更を加えます。
緊急。緊急事態に迅速に対応し、ユーザーの資金が差し迫った危険にさらされていると判断した場合は、スマートコントラクトを緊急にアップグレードできます。
もちろん、最も重要なことは、セキュリティ委員会の主な責任は、緊急事態に対応し、ユーザーの資金を保護するために迅速に行動することです。
安全委員会のメンバーは信頼性の高い人でなければなりません。
署名者は、迅速に対応し、緊急事態が発生した場合にスマート コントラクトをアップグレードし、スマート コントラクト内の資金を保護するために最善を尽くすと信頼されています。
適切なマルチシグネチャしきい値の選択
安全委員会の設置を決定する際には、考慮すべき 2 つの重要な要素があります。
署名者は合計何名いますか?
アクションを承認するために必要な署名者の最小数は何人ですか?
結局のところ、これは単なる 2 つの数字であるため、これは些細な質問のように思えるかもしれませんが、考慮する必要があるバランス作業があります。
セキュリティ違反: K 人のメンバーが共謀してスマート コントラクトを変更し、ユーザーの資金を盗む可能性があります。
Liveness Violation: N-K+ 1 メンバーは共謀してスマート コントラクトの変更を阻止します。これは、重大な脆弱性が発見された場合に特に問題となります。
問題は、平時は資金の安全性を維持しながら、ユーザーの資金が脅かされている緊急時に迅速な行動を可能にする閾値を決定することにあります。
具体的な例を考えてみましょう。しきい値が 9/10 に設定されており、9 人の署名者がメッセージに共同署名する必要があるとします。資金を盗むには 9 人の署名者が共謀する必要があるため、これはセキュリティ上の厳しい基準です。ただし、緊急時には 2 人の署名者があらゆるアクションをブロックできるという欠点があります。たとえば、2 人の署名者が大西洋横断便で遠く離れたところに旅行した場合、安全委員会はその責任を果たすことができません。
もちろん、セキュリティしきい値が 2/10 など、より低い場合は、2 人の署名者が共謀するだけで (または秘密キーが漏洩し)、ユーザーの資金が盗まれます。
人の誠実さに対する認識は時間の経過とともに変化する可能性があります
適切なしきい値を選択することは、技術的な問題というよりも社会的な問題であり、科学というよりも芸術的な問題だと思います。セキュリティは、個々の署名者の完全性に大きく依存します。すぐに説明するように、マルチシグの信頼性を低下させる方法はありますが、これには独自のトレードオフが伴います。
安全委員会委員
メジャー ロールアップにより、すべてのスマート コントラクトに必要なマルチシグネチャのしきい値が即座にアップグレードされます
ほとんどのロールアップには、セキュリティ委員会に匿名の署名者のグループが含まれています。これは次のことが原因であると考えられます。
ロールアップの開発段階では、
会員の個人の安全を守り、
ユーザーの資金を保護するには匿名性が最良の選択肢であると考えてください。
一方で、安全委員会のメンバーであることを公表しているロールアップ プロジェクトが 3 つあります。
仲裁: 署名者は公選されており、現在のリストは次の場所で確認できます。Tallyそれをチェックしてください。 Arbitrum プロジェクトに関係する署名者は 3 社のみです (Offchain Labs から 2 名、Arbitrum Foundation から 1 名)。
Base: 2/2 マルチシグネチャ。1 つは Base によって制御され、もう 1 つは Optimism によって制御されます。
Polygon zkEVM: まだ実装されていませんが、Polygon Labs から 2 人のメンバーと Polygon Labs からのアドバイザーを含むマルチシグを 10/13 にアップグレードすると発表しました。
zkSync Lite: zkSync Lite は、そのセキュリティ委員会が公表されており、ロールアップ プロジェクトの直接の関係者 (zkSync 投資家以外) が含まれていないという点で、ZkSync Era とは区別される必要があります。
Arbitrum と今後の Polygon では、Rollup プロジェクトに直接関係する署名者はほんの一握りであり、その数は関連会社が共謀して安全保障理事会の行動を阻止することができないほど十分に少ない。 zkSync Liteでは、zkSyncの投資家に加えて、プロジェクトとは独立した署名者も任命します。
いずれの場合も、Rollup はプロジェクトに直接関係のない署名者を高く評価します。
ただし、優れたマルチシグを構成するものについてはコンセンサスが得られていないようで、次のような設計上の問題が残されています。
匿名メンバーは許可されるべきですか?
メンバーは地理的に異なる場所から参加する必要がありますか?
会員は個人ですか、それとも法人ですか?
メンバーは任命または選出される必要がありますか?
同じ会社 (または国) からのメンバーは何人まで許可されるべきですか?
適切と考えられる最小サイズとしきい値はありますか?
一般的な経験則として、国民がシステムのセキュリティに信頼を寄せられるよう、誠実性の高いメンバーを選択する必要があります。少なくとも、たとえこれが常に公的に検証可能であるとは限らないとしても、ほとんどのプロジェクトはおそらくこれを行うと私は信じています。
追伸：Arbitrum の安全委員会のメンバー 6 名は現在事前に任命されていますが、3 月の選挙で交代する予定です。
委員会の権限を縮小する
これまでのところ、スマートコントラクトを即座にアップグレードする権限を持つ委員会のみを検討してきましたが、委員会の権限を制限する方法があります。
時間遅延。委員会によって承認されたすべての操作は、時間 T が経過した後にのみ実行され、有効になります。
一時停止のみ。ネイティブクロスチェーンブリッジが保有するすべての資産は、委員会によって凍結される可能性があります。これにより、次の機能が一時停止される可能性があります。
メッセージを L2 から L1 に渡します (つまり、引き出し)、
保留中のトランザクションの完全なソート、
新しいチェックポイント/証明書を完了します。
新しいロールアップ データ (つまり、保留中のトランザクション) を受け入れます。
バイパス委員会 (削除されました)。委員会を放棄し、別のガバナンス メカニズム (DAO など) に依存してアップグレードを承認します。
もちろん、これにより、委員会が迅速に行動する能力や、ユーザーの資金を脅かす緊急事態に効果的に対応する能力が制限されます。
脆弱性が委員会に非公開で開示されているが、まだハッカーによって悪用されていない場合、セキュリティ委員会はスマート コントラクトをアップグレードしてバグを修正することを選択する可能性があります。アップグレードに時間遅延を加えると、攻撃者が公開されたアップグレードを調査し、脆弱性を発見し、それを悪用するリスクが高まります。
たとえば、ビットコインの CVE-2018-17144 は、より深刻なトークンインフレの脆弱性を隠蔽する目的で、当初は DDoS 脆弱性として宣伝されました。悪用を防ぐには、アップグレードの速度が非常に重要です。
一時停止のみのメカニズムの防御能力を評価する
攻撃者がこの脆弱性を積極的に悪用できる可能性のあるシナリオを考えてみましょう。
悪意のある L2 → L1 メッセージ。攻撃者は、ロールアップ上のスマート コントラクトから発信される任意のメッセージを作成し、ネイティブ クロスチェーン ブリッジを通じてイーサリアム上のスマート コントラクトにメッセージを転送できます。
無効な状態遷移です。攻撃者は、状態遷移関数のルールに違反するトランザクションをロールアップで実行する可能性があり、通常は無効であると見なされます。
撤退の抜け穴。攻撃者は、イーサリアム (レイヤー 1) でトランザクションを発行するだけで、ネイティブ クロスチェーン ブリッジから資金を引き出すことができます。
3 つのケースすべてにおいて、時間の遅れは攻撃者に資金を盗み続ける時間を与え、委員会がシステムを防御する機会を狭めるだけです。遅延機能はアクティブな攻撃から保護することはできず、日常的なメンテナンスや緊急でないタスクにのみ使用できます。
システムを停止できるかどうか、およびシステムを停止できる範囲のみを評価します。
悪意のある L2 → L1 メッセージの場合、一時停止機能により取引活動を妨げることなく攻撃を軽減できます。委員会はメッセージングを一時停止したり、新しいチェックポイントの機能を最終決定したりする必要があります。委員会にエラーを検出して緊急事態に対応する時間を与えるために、L2 → L1 メッセージには実行前に時間遅延を設ける必要があるという議論があります。
トランザクションのファイナリティにはロールアップのレイヤーが異なるため、無効な状態遷移に対する防御はより困難になります。副作用を考慮せずにロールアップ トランザクションのみを考慮する場合、安全委員会の最善の防御策は、チェックポイントを確定する機能を停止するが、トランザクションの順序付けは引き続き許可することです。これにより、エラーを修正し、チェックポイントの完了を再アクティブ化し、無効なトランザクションを単純に無視する時間を確保できます。
ただし、ロールアップでの取引アクティビティがオフになっていない場合、ユーザー エクスペリエンスは混乱し、クライアント ソフトウェアがアップグレードされるまでロールアップはひどく壊れた状態になる可能性があります。
これで次のシーンに進みます。ロールアップ上の無効なトランザクションが他のシステムにどのような影響を与えるかを考慮した場合、委員会はどのように反応すべきでしょうか?最善の防御線は、ネイティブのクロスチェーン ブリッジのトランザクションの順序付けを完了する機能を凍結するか、順序付け者を完全にオフにすることです。
これは、あるロールアップから別のロールアップに資金を移動する高速クロスチェーン ブリッジなどの一部のシステムは、ロールアップのトランザクション (無効なトランザクションを含む) が順序付けされていると判断すると、資金の移動を許可する可能性があるためです。この例では、攻撃者がロールアップ上の DeFi プロトコルを悪用し、高速クロスチェーン ブリッジを介して別のロールアップに資金を転送することで資金を迅速に移動できる可能性があります。
委員会が脆弱性を修正し、無効なトランザクションを復元するまでに、被害はすでに発生している可能性があります。 DeFi プロトコルとクロスチェーン ブリッジの LP は両方とも、攻撃によって引き起こされる損失を被る可能性があります。
最後に、Nomad Hack と同様に、この脆弱性により攻撃者がネイティブのクロスチェーン ブリッジから直接資金を引き出すことができた場合、セキュリティ委員会はそれを阻止することができない可能性があります。
最後に、一時停止メカニズムに関する全体的な問題が 1 つあります。アップグレードを承認し、ロールアップを再アクティブ化できる、より広範なガバナンス システムがあると想定する必要があります。ガバナンス システムが、ロールアップで実行されるオンチェーン投票システムを備えた DAO であると仮定すると、実装に注意が必要な問題が発生します。
たとえば、L2→L1 メッセージのクロスチェーン ブリッジが一時停止された場合、DAO の投票結果をロールアップからイーサリアム上のネイティブ クロスチェーン ブリッジに渡すことができなくなり、DAO が承認情報を送信し、アップグレードを実行します。
安全委員会の段階的廃止
コミュニティの中には安全委員会を段階的に廃止すべきだと考える人もいますが、私の意見では、これには次の 2 つの問題が生じます。
誤った安心感。このエクスプロイトについて知っている攻撃者は、セキュリティ委員会がそのエクスプロイトを段階的に廃止するまで待ってから攻撃を実行します。これにより、時間の経過とともに、システムのセキュリティに対する信頼が失われる可能性があります。
回復のオプションは限られています。安全委員会がなければ、コミュニティは攻撃者に反撃することができません。利用可能な唯一の選択肢は、並行してホワイトハットハックを実行し、資金の一部を取り戻すことを期待することです。
安全委員会は常に必要であると思いますが、安全委員会に与えられる権限は段階的に削減されるべきです。
これを念頭に置くと、設計上の質問は次のようになります。
ユーザーへの影響を最小限に抑えながらセキュリティ委員会がシステムを一時停止できるようにしながら、バグを修正してシステムを再アクティブ化する方法の決定に幅広いコミュニティが参加できるようにするにはどうすればよいでしょうか?
言い換えれば、安全委員会の停止権限を制限する前に、コミュニティが実際に介入してシステムを復元できるスキームが必要です。
レイヤー 1 ブロックチェーンの世界では、ユーザーがアクティブ化したフォークを使用してコミュニティに直接アクセスできますが、イーサリアム全体をフォークする必要がないため、この方法はイーサリアム上のスマート コントラクト (ロールアップなど) には機能しません。場合によっては、2016年のTheDAOのように、イーサリアムコミュニティが集合的にRollupを保存することを決定する可能性がありますが、Rollupはそのような結果に依存したり期待したりしてはなりません。
これらの方向に沿ったもう 1 つの興味深いアイデアは、イーサリアム最高裁判所を実装してスマート コントラクトのアップグレードを決定し、ユーザーがアクティブ化するフォークのようなものを有効にすることです。
前に述べたように、Rollup がそのセキュリティを DAO に委任する場合、DAO がイーサリアム上で直接投票できるように実装する必要があります。これは、特に投票プロトコルがロールアップに存在する場合、非常に注意が必要です。
最後になりますが、私は、安全保障理事会からの対応が必要となる可能性のある状況の種類を包括的に検討することが、その必要性に関する議論を助けるために必要であると考えています。
複数の署名がある場合、ロールアップについて心配する必要はありません。
私たちは安全委員会の責任、設計、要件を理解するのにかなりの時間を費やしましたが、この記事の最初の質問に戻ることが重要です。
ロールアップは単なるマルチシグネチャですか?
答えはいいえだ。
その理由を理解するには、一歩下がってブロックチェーン システムが実際に何をしようとしているのかを理解することが最善です。
ブロックチェーン プロトコルは、ユーザーがデータベースのコピーを計算し、他のユーザーと同じデータベースを持っていることを確信できるようにするツールです。
これを念頭に置くと、ブロックチェーン システムには 2 つのコンポーネントがあります。
ブロックチェーンプロトコル。ソフトウェア、暗号化、分散システムを組み合わせることで、誰でもデータベースの整合性を確信できるようになります。
ガバナンスシステム。すべての利害関係者が協力してブロックチェーン プロトコルの変更に同意できるようにする調整メカニズム。
ロールアップを含むブロックチェーン システムの目標は、ブロックチェーン プロトコルが常に非常に信頼性の高い 99.9999% の稼働時間で動作することを保証することです。信頼できるシステム オペレーターによるシステムの日常的な実行にはほとんど混乱が生じないはずです。ユーザー残高、スマート コントラクト コード、および状態を保護する最終的な責任を負うのは、ソフトウェア、暗号化、および分散システムです。
ユーザーの利益を向上させるために、ブロックチェーン プロトコルを変更する必要がある場合があります。コミュニティは、構成の問題を修正したり、新しい機能を追加したり、システムの完全性を脅かす重大な脆弱性に対応したりすることを希望する場合があります。これには人間の介入が必要で、0.0001% の確率でのみ呼び出すことができます。
ガバナンス システムは人間の介入を可能にする責任があり、長年にわたっていくつかのアプローチが登場しました。
中央集権的な当事者: 単一の当事者がシステムのアップグレード方法を単独で決定できます (ビットコインを含む多くのプロジェクトがこの方法で開始されました)。
大まかなコンセンサス: ほとんどの参加者は、アップグレードを展開し、マーク日を決定し、マーク日 (ビットコイン/イーサリアム) にアップグレードを実行する準備ができていることを示しています。
投票プロトコル: すべての当事者が選挙に参加し、アップグレードを承認するかどうかを明示的に投票します。
干渉できない: スマート コントラクトは不変であり、システムは決して変更できません。
上記に加えて、コミュニティは緊急時に迅速な行動を取るためのガバナンスを補完するオプションとして安全委員会を任命することを決定する場合があります。
セキュリティ委員会は攻撃を阻止しません。これは、ユーザーの資金やブロックチェーン プロトコルのシステムの信頼性/パフォーマンスが攻撃にさらされている場合に、ガバナンスと並行して機能する受動的なメカニズムです。
やっと
ブロックチェーンプロトコル、ガバナンス、セキュリティ委員会に関するすべての議論が重要です。この議論の存在こそが、仮想通貨を特別なものにしているのです。
これはトラスト エンジニアリングの良い例です。トラスト エンジニアリングは、システムの信頼要素を特定、測定、削減/削除することに重点を置いたエンジニアリング分野です。
暗号通貨では、強力なシステムオペレーターからユーザーを保護するだけでなく、最も不利な条件下でもシステムが確実に（安全に）動作できるようにするシステムの構築に重点を置いています。
このため、コミュニティメンバーがセキュリティ委員会の役割に懐疑的なままであるのは健全ですが、緊急時に受動的にユーザー資金を保護するためのより良いソリューションを考え出すのはコミュニティメンバーの責任です。
この記事で、安全委員会がなぜ有用であるか、安全委員会は今日必要であるが、スマートコントラクトシステムの広範なアーキテクチャのほんの一部にすぎないのかが明確になったことを願っています。
