ロールアップに安全委員会が必要な理由についてもっと読む

原作者:パトリック・マッコーリー

オリジナルコンピレーション:ルフィ、フォーサイトニュース

暗号資産とやり取りするデータベースは、いつの日かテクノロジースタックとしてRollupを選択するでしょう。 開発者がこのような決定を下すには、いくつかの正当な理由があります。

*リアルタイム監査 *デフォルトのソルベンシー証明書 *ユーザー資金のエスクローはオプションです *正直なパーティー参加者は、システム全体を保護します

最も重要なのは、Rollup の設計と実装に関するすべての取り組みが、ユーザー、ユーザーの資金、およびユーザーのすべてのやり取りを、潜在的に未知の強力なシステム オペレーターから保護することに重点を置いていることです。

システム全体がオフラインの場合でも、ユーザーは自分で資金を回収できます。

ロールアップが技術スタックとして広く展開されれば、信頼の壁を打ち破り、グローバルコミュニティの誰もが金融取引を行えるようになり、グローバルなeコマース、リモート採用、摩擦のないサービス提供の新時代が到来する可能性があります。

ロールアップを正しく実行するには、多くの労力が必要です。

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

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

では、誰がロールアップを気にするのでしょうか? CTのどこかで。

現在のすべてのロールアップにはマルチシグがあり、基盤となるスマートコントラクトをアップグレードする権利があるのは事実ですが、これから説明するように、これはユーザーの資金を保護する保守的なメカニズムであり、より広範なシステムアーキテクチャの一部です。

安全委員会の責務

マルチシグとは、アクションを承認するために複数の署名者を必要とするシステムを指す技術用語です。 例えば、N 人の署名者のうち K 人が、許可されるトランザクションのデジタル署名を完了します。

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

アービトラムの安全保障理事会(私はよく知っている)を見て、この組織が負う可能性のある責任の種類について考えてみましょう。

*拒否権。 セキュリティ委員会は、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 つあります。 *アービトラム:署名者は公選され、現在のリストはTallyで閲覧できます。 Arbitrumプロジェクトに関連する署名者は3社(Offchain Labsから2社、Arbitrum Foundationから1社)のみです。
  • Base: 2/2 マルチシグ、1 つは Base で制御し、もう 1 つは Optimism で制御します。
  • Polygon zkEVM: まだ実装されていませんが、マルチシグを 10/13 にアップグレードすると発表しており、これには Polygon Labs から 2 名、Polygon Labs から 1 名のコンサルタントが参加しています。
  • zkSync Lite:zkSync Liteは、安全委員会が公表され、Rollupプロジェクトの直接の関連会社(zkSyncの投資家を除く)を含まないZkSync Eraとは区別されるべきです。

Arbitrumと近日公開予定のPolygonでは、Rollupプロジェクトに直接関与している署名者はほんの一握りであり、その数は、アフィリエイトが共謀してセキュリティ委員会の行動を阻止することができないほど少ない。 zkSync Liteでは、zkSyncの投資家に加えて、プロジェクトから独立した署名者を任命します。

いずれの場合も、ロールアップはプロジェクトに直接関係のない署名者に高い価値を置きます。

しかし、何が良いマルチシグを構成するかについてのコンセンサスが不足しているようで、いくつかの設計上の問題が生じています。

*匿名のメンバーは許可されるべきですか?

  • メンバーは異なる地域から参加する必要がありますか?
  • 会員は個人ですか、法人ですか? *メンバーは任命されるべきですか、それとも選出されるべきですか? *同じ会社(または国)のメンバーは何人まで許可する必要がありますか?
  • 適切と考えられる最小サイズとしきい値はありますか?

一般的な経験則は、一般の人々がシステムのセキュリティに信頼を寄せるように、高い誠実さを持つメンバーを選ぶことです。 少なくとも、ほとんどのプロジェクトは、必ずしも公に検証できるとは限らないとしても、おそらくそうだと思います。

P.S. 現在、アービトラム安全保障委員会の6人の委員が事前に任命されているが、3月の選挙で交代する予定である。

欧州委員会の権限を弱める

深读解读为什么Rollup都需要安全委员会?

ここまでは、スマートコントラクトをすぐにアップグレードする権限を持つ1つの委員会しか検討していませんが、委員会の権限を制限する方法はいくつかあります。

時間遅延。 委員会によって承認されたすべての行動は、時間Tが経過するまで実行されず、有効になりません。

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

  • L2 から L1 にメッセージを配信する (つまり、お金を引き出します)。 *保留中のトランザクションのソートを完了し、 *新しいチェックポイント/証明書を完了し、 *新しいロールアップデータ(つまり、保留中のトランザクション)を受け入れます。

コミッションのバイパス (削除済み)。 委員会を放棄し、DAOなどの別のガバナンスメカニズムに頼ってアップグレードを承認します。

もちろん、これは、迅速に行動する委員会の能力と、ユーザーの資金を脅かす緊急事態に効果的に対応する能力を制限します。

脆弱性が委員会に非公開で開示されているが、まだハッカーに悪用されていない場合、セキュリティ委員会はスマートコントラクトをアップグレードしてバグを修正するオプションがあります。 アップグレードに遅延時間を追加すると、攻撃者が公開されているアップグレードを調査し、脆弱性を見つけて悪用するリスクが高まります。

たとえば、BTCのCVE-2018-17144は当初、より深刻なトークンインフレの脆弱性を隠すためにDDoS脆弱性として宣伝されました。 アップグレードのスピードは、悪用を防ぐために重要です。

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

攻撃者が脆弱性を積極的に悪用する潜在的なシナリオを考えてみましょう。

  • 悪意のある L2 → L1 メッセージ。 攻撃者は、ロールアップ上のスマートコントラクトから発信された任意のメッセージを作成し、ネイティブのクロスチェーンブリッジを介してETH上のスマートコントラクトにメッセージを転送できます。
  • 無効な状態遷移。 攻撃者は、状態遷移関数の規則に違反するロールアップでトランザクションを実行する可能性があり、通常は無効と見なす必要があります。 *撤退の抜け穴。 攻撃者は、ETH Fang(レイヤー1)でトランザクションを発行するだけで、ネイティブのクロスチェーンブリッジから資金を引き出すことができます。

これら3つのケースすべてにおいて、時間遅延は攻撃者が資金を盗み続けるためのより多くの時間を与え、委員会がシステムを防御する機会を減少させるだけです。 タイムラプス機能はアクティブな攻撃から保護するものではなく、定期的なメンテナンスや緊急性のないタスクにのみ使用できます。

システムを一時停止する能力と、システムを一時停止できる範囲のみを評価します。

悪意のある L2 → L1 メッセージの場合、一時停止機能により、取引活動を妨害することなく攻撃を軽減できます。 委員会は、メッセージングを一時停止するか、新しいチェックポイントの機能を最終決定する必要があります。 L2 → L1 メッセージが実行されるまでに時間遅延を設けて、委員会がエラーを検出して緊急事態に対応する時間を確保する必要があるという議論があります。

無効な状態遷移に対する防御は、トランザクションのファイナリティがロールアップで異なるレイヤーを持つため、より厄介です。 副作用を考慮せずにロールアップ トランザクションのみを考慮する場合、セキュリティ委員会にとっての最善の防御策は、チェックポイントのファイナライズ機能を停止し、トランザクションの並べ替えは引き続き許可することです。 これにより、バグを修正し、チェックポイントの完了を再アクティブ化し、無効なトランザクションを単に無視する時間を確保できます。

ただし、ロールアップの取引操作がオフになっていない場合、ユーザー エクスペリエンスは混沌とし、クライアント ソフトウェアがアップグレードされるまでロールアップがひどく壊れているように見えることがあります。

これは、次のシナリオにつながります。 ロールアップの無効なトランザクションが他のシステムにどのように影響するかを考慮する場合、委員会はどのように対応する必要がありますか。 最善の防御策は、トランザクションの順序付けを確定するネイティブクロスチェーンブリッジの機能を凍結するか、シーケンサーを完全にオフにすることです。

これは、あるロールアップから別のロールアップに資金を送金する高速クロスチェーンブリッジなどの特定のシステムが、ロールアップのトランザクション(無効なトランザクションを含む)がソートされたと判断した時点で、資金の移動を承認する可能性があるためです。 この例では、攻撃者がロールアップでDeFiプロトコルを悪用し、高速クロスチェーンブリッジを介して別のロールアップに送金することで、資金を迅速に転送できる可能性があります。

コミッションが違反を修正し、無効な取引を復活させる頃には、すでに損害が発生している可能性があります。 DeFiプロトコルとクロスチェーンブリッジの両方のLPは、攻撃のコストを負担することができます。

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

サスペンション機構には、究極的には包括的な問題があります。 アップグレードを承認し、ロールアップを再アクティブ化できる広範なガバナンス システムがあることを前提とする必要があります。 ガバナンスシステムが、Rollup上で動作するオンチェーン投票システムを持つDAOであると仮定すると、トリッキーな実装上の問題が生じます。

たとえば、L2→L1メッセージのクロスチェーンブリッジが一時停止されている場合、DAOの投票結果をロールアップからETH上のネイティブクロスチェーンブリッジに渡すことができず、DAOが承認を送信してアップグレードを実行する別の方法が必要です。

安保理の段階的廃止

コミュニティには、安全委員会を段階的に廃止すべきだと考える人もいますが、私の意見では、これは2つの問題を引き起こします。

誤った安心感。 エクスプロイトに気付いた攻撃者は、セキュリティ委員会が段階的に廃止されるまで待ってから攻撃を実行します。 時間が経つにつれて、システムのセキュリティに対する信頼が損なわれる可能性があります。

回復オプションは限られています。 安全委員会がなければ、コミュニティは攻撃者に反撃できません。 利用可能な唯一の選択肢は、ホワイトハットハックを並行して実行し、うまくいけば資金の一部を取り戻すことです。

私の意見では、安全委員会は常に必要ですが、それらに与えられる権限は徐々に縮小されるべきです。

このことを念頭に置いて、設計上の質問は次のようになります。

ユーザーへの影響を最小限にとどめながら、より広範なコミュニティがバグの修正方法とシステムの再アクティブ化方法の決定に参加できるようにしながら、安全委員会にシステムを一時停止させるにはどうすればよいでしょうか?

言い換えれば、コミュニティが介入してシステムを回復し、安全保障理事会の停止権限を制限できるプログラムが必要です。

レイヤー1ブロックチェーンの分野では、ユーザーが起動するフォークを使用してコミュニティに直接到達できますが、ETH全体をフォークする必要がないため、ETH正方形のスマートコントラクト(ロールアップなど)ではこの方法は機能しません。 場合によっては、2016年のTheDAOのように、ETHコミュニティが集団でロールアップを保存することを決定することもありますが、ロールアップは決してそのような結果に依存したり、期待したりすべきではありません。

これらの方針に沿ったもう一つの興味深いアイデアは、最高裁判所がスマートコントラクトのアップグレードを決定し、ユーザーのアクティベーションと同様のフォークを可能にするETHを実装することです。

前述したように、RollupがDAOにセキュリティを委譲する場合、DAOがETHに直接投票できる実装が必要です。 これは、特に投票プロトコルがロールアップに存在する場合、非常に注意が必要です。

最後に、その必要性をめぐる議論を円滑に進めるために、理事会の対応が必要となり得る状況の種類を包括的に検討する必要があると思います。

マルチシグがある場合、なぜロールアップを心配するのですか?

安全委員会の責任、設計、ニーズを理解するのにかなりの時間を費やしてきましたが、この記事の最初の質問に戻ることが重要です。

ロールアップは単なるマルチシグですか?

答えはノーです。

その理由を理解するには、一歩下がって、ブロックチェーンシステムが本当にやりたいことを理解するのが最善です。

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

このことを念頭に置いて、ブロックチェーンシステムには2つのコンポーネントがあります。

*ブロックチェーンプロトコル。 ソフトウェア、暗号化、および分散システムの組み合わせにより、データベースの整合性に自信が持てます。 *ガバナンスシステム。 すべての利害関係者が協力し、ブロックチェーンプロトコルの変更に合意できるようにする調整メカニズム。

Rollupを含むブロックチェーンシステムの目標は、ブロックチェーンプロトコルが常に99.9999%の非常に信頼性の高い稼働時間で動作するようにすることです。 信頼できるシステム・オペレーターは、システムの日常的な操作にほとんど干渉しないようにする必要があります。 最終的に、ユーザーの残高、スマートコントラクトのコード、および状態を保護するのは、ソフトウェア、暗号化、および分散システムです。

ユーザーの利益を改善するために、ブロックチェーンプロトコルを変更する必要がある場合があります。 コミュニティは、構成の問題を修正したり、新しい機能を追加したり、システムの整合性を脅かす重大な脆弱性に対応したりする場合があります。 これには人間の介入が必要であり、0.0001%の確率でしか呼び出すことができません。

ガバナンスシステムは人間の介入を実装する責任があり、何年にもわたっていくつかのアプローチが登場してきました。

*全体主義政党:一方的な政党は、システムをアップグレードする方法を個別に決定できます(BTCを含む多くのプロジェクトは、この方法で開始されました)。

  • 大まかなコンセンサス:参加者の大多数は、アップグレードを展開し、マーク日を決定し、マーク日(BTC/ETH)にアップグレードを実行する準備ができていると述べました。 *投票合意:すべての当事者が選挙に参加し、エスカレーションを承認するかどうかを明示的に投票します。 *干渉なし:スマートコントラクトは不変であり、システムを変更することはできません。

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

安保理は攻撃を止めない。 これは、ブロックチェーンプロトコルのユーザー資金やシステムの信頼性/パフォーマンスが攻撃されたときに、ガバナンスと並行して機能する受動的なメカニズムです。

最後に

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

これは、システム内の信頼要素の識別、測定、削減/排除に重点を置いたエンジニアリング分野であるトラストエンジニアリングの良い例です。

暗号通貨では、強力なシステムオペレーターからユーザーを保護するだけでなく、最も不利な条件下でも確実に(安全に)運用できるシステムの構築に重点を置いています。

そのため、コミュニティのメンバーが安全委員会の役割に懐疑的であることは健全ですが、緊急時には、ユーザーの資金を事後対応的に保護するために、より良い解決策を考え出す責任があります。

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

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
  • ピン