著者: Faust, Geek Web3
現実の世界では、ほとんどすべての高層ビルには、安全出口という不可欠な要素があります。 火災や地震などの緊急事態が発生したとき、安全出口は人々の生活の安全を確保するための命の恩人です。 数百億ドルの資産を保有するイーサリアムのレイヤー2カストディプラットフォームシステムにおいて、ユーザーが安全にレイヤー1に資産を引き出すことができる「強制出金」機能は、必要不可欠かつ必要な施設となっています。
Vitalik氏は、最近の記事「さまざまなタイプのレイヤー2」で、ユーザーがレイヤー2からレイヤー1に資産をスムーズに引き出す能力が非常に重要なセキュリティ指標であることも強調しています。
しかし、「スムーズな撤退」の問題は、これまで多くの人からあまり注目されていなかったようで、多くのレイヤー2プロジェクトでさえ、「強制撤退」や「脱出ポッド」機能を開始していません。 L2エコシステムが本格化していない時代には、「パーミッションレスな出金」を無視することは問題にならないようです。 しかし、レイヤー2の資産が120億ドルを超えるようになった今、レイヤー2は「大きすぎて潰せない」建物になっています。 そのような超高層ビルに安全出口がない場合、その結果は想像を絶します。
「Geek Web3」では、レイヤー2のセキュリティリスクに読者に注意を喚起する目的で、Loopring Protocol V3とArbitrumを例に挙げ、強制ドローやエスケープハッチなどの「パーミッションレスな引き出し機能」がレイヤー2に不可欠な理由を以下に説明します。
(L2BEAT dYdXブラウザによると、dYdXの強制取引/出金機能はこれまでに152回利用されており、100万ドル以上の大口出金が7回ありました。
これまで、レイヤー2に関するポピュラーサイエンスの記事は、表面的には「セキュリティ」や「ユーザビリティ」に焦点が当てられ、「検閲への抵抗」は無視されることがほとんどでした。 分散型シーケンサーソリューションについて話すときでさえ、多くの人はMEVが検閲への抵抗ではなく、分散型であるかどうかに注目しています。
言い換えれば、ほとんどの人は、レイヤー2の状態遷移が有効かどうか、シーケンサーがコインを盗むことができるかどうか、不正/有効性の証明システムが使用されているかどうかに焦点を当てる傾向がありますが、見過ごしてはならないリスクを無視しています:シーケンサーがトランザクションリクエストを拒否し続けたり、単に長期間失敗したり、ダウンしたりした場合はどうなるでしょうか? **
ご存じのように、Solanaの停止時には、資産が清算に直面し、数百万ドルの資産が危険にさらされたため、ポジションを時間内にカバーできなかった人がいました。 **ユーザーの要求が拒否されると、引き起こされる経済的損失は無視できません。
たとえ少数の人しかこのような状況に陥ったとしても、それが大金を持つクジラに落ちれば、市場全体が打撃を受ける可能性があります(例えば、イーサリアムのDefiレンディングプロトコルに数億ドルの資産があり、1週間で清算される可能性があるが、その人がトルネードを使用したとしてOFACの制裁リストに載っているとします)。 この人物の資金の大部分はOPにあり、OPシーケンサーはOFACと連携してその要求を拒否します)
この問題を、イーサリアムから独立したアバランチやポリゴンなどのパブリックチェーンに投影したほうがいいかもしれません。 Avalancheのバリデーターコンセンサスノードの2/3以上があなたのトランザクションを検閲することを決定した場合、彼らはあなたのTxnをブロックに含めることを拒否したり、あなたのTxnを含むブロックを認識しなかったりすることができます。 このとき、あなたのお金は基本的にこのチェーンに埋もれていて、外に出ることができません:**
検閲攻撃に関与するバリデーターの2/3未満になるように一部のバリデーターを採用するか、社会的コンセンサスを通じてAvalancheをフォークするよう一部の人々に呼びかけることができない限り。 明らかに、この時点では、Avalancheから資金を迅速に引き出す方法がまだあり、バリデータの2/3以上が協力して特定のアドレスのトランザクションレビューを開始し、それ自体が達成に時間がかかり、検閲されたユーザーが「逃げる」のに十分な時間を残すことを考慮する必要があります。
しかし、レイヤ 2 では、状況が大きく異なる可能性があります。 レイヤー2シーケンサーは通常、オフィシャル自身によって運営されており、シーケンサーがあなたに検閲攻撃を仕掛けたい場合、「レイヤー2であなたのお金を凍結する」、つまり、L2からL1に資産をクロスするためのトランザクションリクエストを完全に拒否することができます。 明らかに、L2の操作メカニズムによると、シーケンサーをバイパスして引き出し操作を実行できない場合、シーケンサーがL2の資産を凍結して転送できない可能性は十分にあります。
では、この種の問題を解決するにはどうすればよいでしょうか。 実際、単刀直入に言うと、「パーミッションレス」の出金機能を実装して、シーケンサーやレイヤー2のプロジェクト関係者によるレビューを受けたときに、ユーザーが害を及ぼすことなくレイヤー1に資産を出金できるようにするにはどうすればよいでしょうか? 分散型シーケンサーを提案したプロジェクトもありますが、これは緩和的な解決策ではなく、非常に限られた数のシーケンサーが力を合わせてレビューした場合でも、アセットを「凍結」することができ、POSノードのアンチウィッチもトリッキーな問題です(マルチチェーンイベントを参照)。
これを行う最も効果的な方法は、L1チェーンに直接「出口」を設定し、シーケンサーから長時間応答がない場合に、ユーザーがL1の専用出口を介してL2から資金を引き出すことができるようにすることです。 **
ここでは、LoopringプロトコルのV3バージョンを例にとり、ユーザーが開始した強制引き出しの2つの異なるシナリオをリストアップしています。
ユーザーは、ExchangeV3コントラクトのforcedWithr関数を使用してレイヤー1で直接強制引き出しを開始し、LoopringプロトコルでどのL2アカウントを持っているか、どのような種類のトークンを引き出したいかを宣言できます。 その後、ExchangeV3コントラクトはオンチェーンイベントをスローして、誰かが強制引き出しリクエストを開始したことを示します。 Loopringプロトコルのすべてのノード(シーケンサーを含む)はGethクライアントを実行しているため、イーサリアムブロックから、誰かが強制引き出しを開始し、対応するオンチェーンイベントをトリガーしたことがわかっています。
強制出金はすぐには処理されず、pendingForcedWithdrawalsキューに入れられ、保留されていることに注意することが重要です。 **シーケンサーは、誰かがレイヤー1で強制出金を開始した後、15日以内にExchangeV3コントラクトのProcess関数がトリガーされ、イーサリアムチェーン上の出金イニシエーターにトークンを転送します(イーサリアムチェーン上のL2プロジェクト当事者のデポジットアドレスから、出金者に送金します)。
Sequencer が 15 日以内にユーザーの強制引き出し要求に応答しない場合、ユーザーは notifyForcedRequestTooOld 関数を呼び出して、ExchangeV3 コントラクトに WithdrawalModeActivated というイベントをスローさせ、破産清算モードがアクティブになったことを Loopring プロトコルのフルノードに通知させることができます。 **
**清算モードが有効な場合、Loopring V3はシーケンサーから送信された新しいL2ブロックの受信を停止し、Loopringプロトコル全体が機能しなくなります。 このプロセスは少なくとも30日間続きます。
ただし、破産清算モードでは、ユーザーはレイヤー1で資産を引き出すことができますが、L2ステートツリーで確認できる資産ステータス/ステータスを証明するマークルプルーフを提出する必要があります。 (レイヤー2の資産残高が、引き出しを開始したときに申告した金額と一致していることを証明します)
このLoopring Protocolの破産清算モデルは、L2BEATのEscape Hatchメカニズムとしても知られています。 このモードは、シーケンサーが指定された時間内にユーザーの強制引き出し要求に応答しない場合、またはシーケンサーに長期的な障害またはダウンタイムがある場合にトリガーされます。 この時点で、ユーザーはロールアップ契約を手動でトリガーしてフリーズモードにしたり、実行を停止したりできます。 その後、ユーザーはレイヤー2で資産を証明するマークルプルーフを構築し、L1のL2プロジェクト当事者の預金アドレスから自分の資産を引き出すことができます。 **
StarkExのドキュメントには、このプロセスの専用の回路図も描かれています。 L2 ユーザーが L1 で強制引き出し要求を送信したときに、L2 ユーザーが 7 日間のウィンドウの終了時にシーケンサー応答を受信しない場合、L2 ユーザーは凍結要求関数を呼び出して、L2 を凍結期間に突入させることができます。 この場合、L2シーケンサーはL1上のL2の状態を更新できず、L2の状態が凍結されてから凍結解除されるまでに1年かかります。 その後、ユーザーはマークルプルーフを提出し、お金を引き出すことができます。
しかし、マークルプルーフを構築するためには、まず完全なL2ステートツリーを知る必要があり、つまり、データを求めるためのL2フルノードを見つける必要があり、同時にマークルプルーフを生成するためのコードが必要であり、これには明らかに一定の技術的閾値が必要です。 大多数のユーザーの便宜のために、L2BEATは以前、レイヤー2がオープンな権限とオープンソースコードを備えた多数のフルノードをセットアップして、ユーザーがL2上のすべてのアカウントのステータス(残高、トランザクション数などを含む)を把握できるようにする必要があると述べています。 この動きは、強制的な撤退と脱出ポッドのメカニズムの重要性も示しています。
しかし、強制撤退/脱出ポッドは、検閲に強い唯一の解決策ではないようです。 例えば、Arbitrumは「トランザクションのインクルージョンを強制する」という方法を用いており、ユーザーはまず、L1の遅延受信箱コントラクトでシーケンサーで処理する必要があるTxn/withdrawalを送信し、シーケンサーが24時間以上処理していない場合、ユーザーはL1のシーケンサー受信箱コントラクトの強制インクルージョン機能を呼び出すことができる。 TxnをArbitrumのトランザクションシーケンスに直接含めます**(オンチェーンイベントをスローして、受信トレイレコードが数件遅れたTxnをL2レジャーに含める必要があることをArbitrumのフルノードに通知します)。
対照的に、Arbitrumのアプローチはよりシンプルですが、それでも少し物足りないです:Loopring ProtocolやStarkExの破産モード/エスケープポッドのようにユーザーがL1で直接お金を引き出すことを許可するのではなく、シーケンサーが無視するいくつかのトランザクションをL2最長チェーンに含める必要があることをArbitrumノードに通知するオンチェーンイベントをスローするだけです。 Arbitrumのチャレンジャーノードが団結して検閲攻撃を仕掛けたとしても、L2でユーザーのお金を凍結することは可能だと思われます。 **
したがって、Arbitrumのforce Inclusionはパーミッションレスではなく、不正の証拠を投稿する意思のある誠実なノードがいる限り、シーケンサーはユーザーのforceInclusionリクエストを無視したと言っても良いことですが、これは程度は低いものの、ある程度の信頼の仮定を導入します。
より正確には、「強制的に含める必要があるトランザクション」は、少なくとも1つのARBチャレンジャーノードによって認識されるべきであり、現在、どのL2-L1クロスチェーンメッセージを許可するかを決定する権利を持つ9つのノードがあり、現在、それらのみが不正証明を発行することができます。 **これら9つのノードが共謀している限り、理論的にはユーザーの「強制トランザクション」は無効にすることができます。 **
したがって、Arbitrumに取引/出金を含めることが義務付けられているのは、L2ノードの許可を必要としないLoopringやStarkExの破産清算モデルとは異なります。 しかし、L2BEATは、このソリューションに対してArbitrumに高い評価を与えました。 というのも、将来的にはArbitrumがBOLDというパーミッションレスの不正防止リリースの仕組みを立ち上げる予定で、その時点でチャレンジャーノードが共謀することは困難または不可能だからです(今は実際に共謀しにくいです)。
L2BEATによると、現在のTVLは5,000万ドルを超えており、シーケンサーの障害や提案者の障害(**OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、Metis)のいずれにも対応していません。 これらの L2 により、極端な場合にはユーザー資産が L2 で凍結される可能性があります。 **
したがって、明らかに、強制撤退または破産清算モデルにはその必要性がありますが、現時点では、カウンターパーティゲームとしてユーザーシーケンサーに依存しているだけで、実際には「撤退する準備ができている」わけではありません(Arbitrumには24時間の遅延があり、失敗する可能性があります、Loopringには最大15日間の遅延、StarkExには最大7日間の遅延があります)が、「何もないよりはまし」であることは明らかです。 また、強制撤退の遅延の問題は、今後、より高度なメカニズム設計**によって適切に解決されると考えられています(現時点では、一部のMEV科学者がforceInclusionを使用してフロントランニングトランザクションを開始する可能性があるため、遅延を導入する必要があることが主な原因です)。 詳細については、主要なL2プロジェクト関係者の公式文書を参照してください。
分散型シーケンサーがますます多くのL2ロードマップに組み込まれ、ヴィタリックが率いるイーサリアム財団がレイヤー2セキュリティについて人々を教育し続けることで、強制引き出しなどの検閲に強いトランザクション機能がますます注目されるようになり、イーサリアムのレイヤー2システムは検閲に強く、信頼できない金融インフラシステムに近づくでしょう。 レイヤー2が資金へのトラストレスアクセスを実装すれば、より多くのマーケットメーカーや流動性プロバイダーがL2インフラに参入し、web3全体の大量導入がさらに一歩進むと考えられています。
24.44K 人気度
49.42K 人気度
16.21K 人気度
11.53K 人気度
99.74K 人気度
レイヤー2の強制撤退と脱出ポッド機能はどの程度重要ですか?
著者: Faust, Geek Web3
現実の世界では、ほとんどすべての高層ビルには、安全出口という不可欠な要素があります。 火災や地震などの緊急事態が発生したとき、安全出口は人々の生活の安全を確保するための命の恩人です。 数百億ドルの資産を保有するイーサリアムのレイヤー2カストディプラットフォームシステムにおいて、ユーザーが安全にレイヤー1に資産を引き出すことができる「強制出金」機能は、必要不可欠かつ必要な施設となっています。
Vitalik氏は、最近の記事「さまざまなタイプのレイヤー2」で、ユーザーがレイヤー2からレイヤー1に資産をスムーズに引き出す能力が非常に重要なセキュリティ指標であることも強調しています。
しかし、「スムーズな撤退」の問題は、これまで多くの人からあまり注目されていなかったようで、多くのレイヤー2プロジェクトでさえ、「強制撤退」や「脱出ポッド」機能を開始していません。 L2エコシステムが本格化していない時代には、「パーミッションレスな出金」を無視することは問題にならないようです。 しかし、レイヤー2の資産が120億ドルを超えるようになった今、レイヤー2は「大きすぎて潰せない」建物になっています。 そのような超高層ビルに安全出口がない場合、その結果は想像を絶します。
「Geek Web3」では、レイヤー2のセキュリティリスクに読者に注意を喚起する目的で、Loopring Protocol V3とArbitrumを例に挙げ、強制ドローやエスケープハッチなどの「パーミッションレスな引き出し機能」がレイヤー2に不可欠な理由を以下に説明します。
(L2BEAT dYdXブラウザによると、dYdXの強制取引/出金機能はこれまでに152回利用されており、100万ドル以上の大口出金が7回ありました。
検閲への耐性が大きな問題:シーケンサーが故意にリクエストを拒否した場合の対処法****
これまで、レイヤー2に関するポピュラーサイエンスの記事は、表面的には「セキュリティ」や「ユーザビリティ」に焦点が当てられ、「検閲への抵抗」は無視されることがほとんどでした。 分散型シーケンサーソリューションについて話すときでさえ、多くの人はMEVが検閲への抵抗ではなく、分散型であるかどうかに注目しています。
言い換えれば、ほとんどの人は、レイヤー2の状態遷移が有効かどうか、シーケンサーがコインを盗むことができるかどうか、不正/有効性の証明システムが使用されているかどうかに焦点を当てる傾向がありますが、見過ごしてはならないリスクを無視しています:シーケンサーがトランザクションリクエストを拒否し続けたり、単に長期間失敗したり、ダウンしたりした場合はどうなるでしょうか? **
ご存じのように、Solanaの停止時には、資産が清算に直面し、数百万ドルの資産が危険にさらされたため、ポジションを時間内にカバーできなかった人がいました。 **ユーザーの要求が拒否されると、引き起こされる経済的損失は無視できません。
たとえ少数の人しかこのような状況に陥ったとしても、それが大金を持つクジラに落ちれば、市場全体が打撃を受ける可能性があります(例えば、イーサリアムのDefiレンディングプロトコルに数億ドルの資産があり、1週間で清算される可能性があるが、その人がトルネードを使用したとしてOFACの制裁リストに載っているとします)。 この人物の資金の大部分はOPにあり、OPシーケンサーはOFACと連携してその要求を拒否します)
この問題を、イーサリアムから独立したアバランチやポリゴンなどのパブリックチェーンに投影したほうがいいかもしれません。 Avalancheのバリデーターコンセンサスノードの2/3以上があなたのトランザクションを検閲することを決定した場合、彼らはあなたのTxnをブロックに含めることを拒否したり、あなたのTxnを含むブロックを認識しなかったりすることができます。 このとき、あなたのお金は基本的にこのチェーンに埋もれていて、外に出ることができません:**
検閲攻撃に関与するバリデーターの2/3未満になるように一部のバリデーターを採用するか、社会的コンセンサスを通じてAvalancheをフォークするよう一部の人々に呼びかけることができない限り。 明らかに、この時点では、Avalancheから資金を迅速に引き出す方法がまだあり、バリデータの2/3以上が協力して特定のアドレスのトランザクションレビューを開始し、それ自体が達成に時間がかかり、検閲されたユーザーが「逃げる」のに十分な時間を残すことを考慮する必要があります。
しかし、レイヤ 2 では、状況が大きく異なる可能性があります。 レイヤー2シーケンサーは通常、オフィシャル自身によって運営されており、シーケンサーがあなたに検閲攻撃を仕掛けたい場合、「レイヤー2であなたのお金を凍結する」、つまり、L2からL1に資産をクロスするためのトランザクションリクエストを完全に拒否することができます。 明らかに、L2の操作メカニズムによると、シーケンサーをバイパスして引き出し操作を実行できない場合、シーケンサーがL2の資産を凍結して転送できない可能性は十分にあります。
では、この種の問題を解決するにはどうすればよいでしょうか。 実際、単刀直入に言うと、「パーミッションレス」の出金機能を実装して、シーケンサーやレイヤー2のプロジェクト関係者によるレビューを受けたときに、ユーザーが害を及ぼすことなくレイヤー1に資産を出金できるようにするにはどうすればよいでしょうか? 分散型シーケンサーを提案したプロジェクトもありますが、これは緩和的な解決策ではなく、非常に限られた数のシーケンサーが力を合わせてレビューした場合でも、アセットを「凍結」することができ、POSノードのアンチウィッチもトリッキーな問題です(マルチチェーンイベントを参照)。
これを行う最も効果的な方法は、L1チェーンに直接「出口」を設定し、シーケンサーから長時間応答がない場合に、ユーザーがL1の専用出口を介してL2から資金を引き出すことができるようにすることです。 **
Loopring Protocol V3 強制出金および破産清算モデル
ここでは、LoopringプロトコルのV3バージョンを例にとり、ユーザーが開始した強制引き出しの2つの異なるシナリオをリストアップしています。
ユーザーは、ExchangeV3コントラクトのforcedWithr関数を使用してレイヤー1で直接強制引き出しを開始し、LoopringプロトコルでどのL2アカウントを持っているか、どのような種類のトークンを引き出したいかを宣言できます。 その後、ExchangeV3コントラクトはオンチェーンイベントをスローして、誰かが強制引き出しリクエストを開始したことを示します。 Loopringプロトコルのすべてのノード(シーケンサーを含む)はGethクライアントを実行しているため、イーサリアムブロックから、誰かが強制引き出しを開始し、対応するオンチェーンイベントをトリガーしたことがわかっています。
強制出金はすぐには処理されず、pendingForcedWithdrawalsキューに入れられ、保留されていることに注意することが重要です。 **シーケンサーは、誰かがレイヤー1で強制出金を開始した後、15日以内にExchangeV3コントラクトのProcess関数がトリガーされ、イーサリアムチェーン上の出金イニシエーターにトークンを転送します(イーサリアムチェーン上のL2プロジェクト当事者のデポジットアドレスから、出金者に送金します)。
Sequencer が 15 日以内にユーザーの強制引き出し要求に応答しない場合、ユーザーは notifyForcedRequestTooOld 関数を呼び出して、ExchangeV3 コントラクトに WithdrawalModeActivated というイベントをスローさせ、破産清算モードがアクティブになったことを Loopring プロトコルのフルノードに通知させることができます。 **
**清算モードが有効な場合、Loopring V3はシーケンサーから送信された新しいL2ブロックの受信を停止し、Loopringプロトコル全体が機能しなくなります。 このプロセスは少なくとも30日間続きます。
ただし、破産清算モードでは、ユーザーはレイヤー1で資産を引き出すことができますが、L2ステートツリーで確認できる資産ステータス/ステータスを証明するマークルプルーフを提出する必要があります。 (レイヤー2の資産残高が、引き出しを開始したときに申告した金額と一致していることを証明します)
このLoopring Protocolの破産清算モデルは、L2BEATのEscape Hatchメカニズムとしても知られています。 このモードは、シーケンサーが指定された時間内にユーザーの強制引き出し要求に応答しない場合、またはシーケンサーに長期的な障害またはダウンタイムがある場合にトリガーされます。 この時点で、ユーザーはロールアップ契約を手動でトリガーしてフリーズモードにしたり、実行を停止したりできます。 その後、ユーザーはレイヤー2で資産を証明するマークルプルーフを構築し、L1のL2プロジェクト当事者の預金アドレスから自分の資産を引き出すことができます。 **
StarkExのドキュメントには、このプロセスの専用の回路図も描かれています。 L2 ユーザーが L1 で強制引き出し要求を送信したときに、L2 ユーザーが 7 日間のウィンドウの終了時にシーケンサー応答を受信しない場合、L2 ユーザーは凍結要求関数を呼び出して、L2 を凍結期間に突入させることができます。 この場合、L2シーケンサーはL1上のL2の状態を更新できず、L2の状態が凍結されてから凍結解除されるまでに1年かかります。 その後、ユーザーはマークルプルーフを提出し、お金を引き出すことができます。
しかし、マークルプルーフを構築するためには、まず完全なL2ステートツリーを知る必要があり、つまり、データを求めるためのL2フルノードを見つける必要があり、同時にマークルプルーフを生成するためのコードが必要であり、これには明らかに一定の技術的閾値が必要です。 大多数のユーザーの便宜のために、L2BEATは以前、レイヤー2がオープンな権限とオープンソースコードを備えた多数のフルノードをセットアップして、ユーザーがL2上のすべてのアカウントのステータス(残高、トランザクション数などを含む)を把握できるようにする必要があると述べています。 この動きは、強制的な撤退と脱出ポッドのメカニズムの重要性も示しています。
Arbitrumの「強制インクルードトランザクション」機能
しかし、強制撤退/脱出ポッドは、検閲に強い唯一の解決策ではないようです。 例えば、Arbitrumは「トランザクションのインクルージョンを強制する」という方法を用いており、ユーザーはまず、L1の遅延受信箱コントラクトでシーケンサーで処理する必要があるTxn/withdrawalを送信し、シーケンサーが24時間以上処理していない場合、ユーザーはL1のシーケンサー受信箱コントラクトの強制インクルージョン機能を呼び出すことができる。 TxnをArbitrumのトランザクションシーケンスに直接含めます**(オンチェーンイベントをスローして、受信トレイレコードが数件遅れたTxnをL2レジャーに含める必要があることをArbitrumのフルノードに通知します)。
対照的に、Arbitrumのアプローチはよりシンプルですが、それでも少し物足りないです:Loopring ProtocolやStarkExの破産モード/エスケープポッドのようにユーザーがL1で直接お金を引き出すことを許可するのではなく、シーケンサーが無視するいくつかのトランザクションをL2最長チェーンに含める必要があることをArbitrumノードに通知するオンチェーンイベントをスローするだけです。 Arbitrumのチャレンジャーノードが団結して検閲攻撃を仕掛けたとしても、L2でユーザーのお金を凍結することは可能だと思われます。 **
したがって、Arbitrumのforce Inclusionはパーミッションレスではなく、不正の証拠を投稿する意思のある誠実なノードがいる限り、シーケンサーはユーザーのforceInclusionリクエストを無視したと言っても良いことですが、これは程度は低いものの、ある程度の信頼の仮定を導入します。
より正確には、「強制的に含める必要があるトランザクション」は、少なくとも1つのARBチャレンジャーノードによって認識されるべきであり、現在、どのL2-L1クロスチェーンメッセージを許可するかを決定する権利を持つ9つのノードがあり、現在、それらのみが不正証明を発行することができます。 **これら9つのノードが共謀している限り、理論的にはユーザーの「強制トランザクション」は無効にすることができます。 **
したがって、Arbitrumに取引/出金を含めることが義務付けられているのは、L2ノードの許可を必要としないLoopringやStarkExの破産清算モデルとは異なります。 しかし、L2BEATは、このソリューションに対してArbitrumに高い評価を与えました。 というのも、将来的にはArbitrumがBOLDというパーミッションレスの不正防止リリースの仕組みを立ち上げる予定で、その時点でチャレンジャーノードが共謀することは困難または不可能だからです(今は実際に共謀しにくいです)。
L2BEATによると、現在のTVLは5,000万ドルを超えており、シーケンサーの障害や提案者の障害(**OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、Metis)のいずれにも対応していません。 これらの L2 により、極端な場合にはユーザー資産が L2 で凍結される可能性があります。 **
したがって、明らかに、強制撤退または破産清算モデルにはその必要性がありますが、現時点では、カウンターパーティゲームとしてユーザーシーケンサーに依存しているだけで、実際には「撤退する準備ができている」わけではありません(Arbitrumには24時間の遅延があり、失敗する可能性があります、Loopringには最大15日間の遅延、StarkExには最大7日間の遅延があります)が、「何もないよりはまし」であることは明らかです。 また、強制撤退の遅延の問題は、今後、より高度なメカニズム設計**によって適切に解決されると考えられています(現時点では、一部のMEV科学者がforceInclusionを使用してフロントランニングトランザクションを開始する可能性があるため、遅延を導入する必要があることが主な原因です)。 詳細については、主要なL2プロジェクト関係者の公式文書を参照してください。
分散型シーケンサーがますます多くのL2ロードマップに組み込まれ、ヴィタリックが率いるイーサリアム財団がレイヤー2セキュリティについて人々を教育し続けることで、強制引き出しなどの検閲に強いトランザクション機能がますます注目されるようになり、イーサリアムのレイヤー2システムは検閲に強く、信頼できない金融インフラシステムに近づくでしょう。 レイヤー2が資金へのトラストレスアクセスを実装すれば、より多くのマーケットメーカーや流動性プロバイダーがL2インフラに参入し、web3全体の大量導入がさらに一歩進むと考えられています。