レイヤー2にとって強制引き出しと脱出口機能はどれほど重要ですか?

この記事では、Loopring Protocol V3 と Arbitrum を例に、テクニカル分析とケース スタディを通じて、レイヤー 2 にセキュリティ設計が必要な理由について説明します。また、ファンドの出入りの分散型方法も分析します。

現実世界では、ほとんどの超高層ビルには欠かせない要素があります:非常口。火災や地震などの予期せぬ出来事が発生した際、これらの出口は人々の安全を守るための命の恩人となります。同様に、資産が数十億ドルを保有するEthereumレイヤー2エコシステムでは、「強制引き出し」機能が重要な施設となり、ユーザーが安全にアセットをレイヤー1に戻すことができるようになっています。

Vitalikは最近の記事「Different Types of Layer 2s」でも、ユーザーがレイヤー2からレイヤー1に資産をスムーズに引き出す能力は非常に重要な安全指標であると強調しています。

ただし、過去にはほとんどの人が「滑らかな出金」という問題を見落としていたようで、多くのレイヤー2プロジェクトチームが「強制出金」や「脱出ハッチ」機能を実装していませんでした。レイヤー2エコシステムがまだ成熟していない時代には、「許可なし出金」を無視することは問題にはならないようでした。しかし、現在はレイヤー2が120億ドル以上の資産を処理している時代であり、それは「失敗してはならないほど大きな」摩天楼となっています。そのような高層ビルに安全出口がないことは想像できません。

読者にレイヤー2の安全リスクについて意識を高めることを目的として、「Geek Web3」では、次のテキストでLoopring Protocol V3とArbitrumを例に挙げ、強制引き出しや脱出ハッチなどの「許可なし引き出し機能」がレイヤー2の不可欠な部分である理由を説明します。


(L2BEATのdYdXブラウザによると、これまでに、dYdXの強制取引/引き出し機能が合計152回使用され、100万ドルを超える大口引き出しが7件ありました)検閲耐性は大きな問題です:シーケンサーが意図的にあなたのリクエストを拒否した場合はどうなりますか?

過去の人気のある科学記事では、レイヤー2に関するものはしばしば1つの問題を抱えていました: それらは主に「セキュリティ」と表面的な「使いやすさ」を強調していましたが、「検閲耐性」を見落としていました。分散型シーケンサーソリューションについて議論する際でも、多くの人が気づいたのはMEVが分散型かどうかであり、検閲耐性の向上ではありませんでした。

言い換えれば、ほとんどの人々は、レイヤー2の状態遷移が効果的かどうか、シーケンサーがコインを盗むことができるか、詐欺の証明/有効性証明システムが採用されているかどうかに焦点を当てがちです。しかし、見落とされてはならないリスクがあります。それは、シーケンサーがあなたの取引リクエストを連続的に拒否した場合、または長期間機能しなくなったり、さらにはシャットダウンした場合、どうなるかというリスクです。

Solanaのダウンタイム中に、資産の清算リスクにより、人々が時間内に担保を追加できない事例があり、数百万ドルの資産が危険にさらされた。ユーザーの要求を拒否することが経済的な大損失につながる可能性があることに留意する価値がある。

たとえ個々の個人がそうした状況に遭遇することがあっても、大口の資金を保有する「クジラ」の一部にそれが起こった場合、市場全体が被害を受ける可能性があります。たとえば、イーサリアムのDeFiレンディングプロトコルで数億ドルの資産を持つ人が1週間以内に清算される可能性があるが、Tornadoの使用によりOFACに制裁を受けているとします。彼らのほとんどの資金はOptimism(OP)にあり、OFACの規制に準拠したOPシーケンサーは彼らの要求を拒否します。

この問題を、Ethereumから独立したAvalancheやPolygonなどのブロックチェーンに投影してみましょう。Avalancheのバリデーターのコンセンサスノードの3分の2以上があなたに対して取引監査を実施することを決定した場合、彼らはあなたの取引をブロックに含めることを拒否したり、あなたの取引が含まれているブロックの認識を拒否したりすることができます。この場合、あなたの資金は実質的にこのチェーンに埋まっており、引き出すことができません。

バリデーターのうち三分の二未満が検証攻撃に関与するよう説得するか、ソーシャルコンセンサスを通じてアバランチをフォークさせることができる場合を除いて、この時点でアバランチから資金を迅速に引き出す方法がまだあります。ただし、特定のアドレスに対するトランザクション検証を開始するために三分の二以上のバリデーターが団結し、時間がかかることを考慮する必要があります。これにより、検証対象のユーザーは‘逃走’する十分な時間を与えられます。

しかし、レイヤー2では状況がかなり異なる可能性があります。レイヤー2のシーケンサーは一般的に公式チームによって運営されています。シーケンサーがあなたに対して監査攻撃を開始したい場合、「レイヤー2であなたの資産を凍結する」ことができ、L2からL1への資産の移動リクエストを拒否することができます。L2の運営メカニズムによれば、シーケンサーをバイパスして引き出しを実行することができない場合、シーケンサーがL2であなたの資産を凍結し、それらの移動を阻止する可能性が完全にあります。

では、この問題はどのように解決できるのでしょうか?単純に言えば、SequencerやLayer 2プロジェクトチームの監視下にある場合でも、ユーザーが安全に資産をLayer 1に引き出すことができる「許可なし」の引き出し機能をどのように実装できるのでしょうか?一部のプロジェクトチームは、分散型のSequencerのアイデアを提案していますが、これは表面的な解決策です。これらの限られた数のSequencerが協力して監視しようとしても、依然としてあなたの資産を「凍結」することができます。さらに、Proof of Stake(PoS)ノードにおけるSybil攻撃の問題も(Multichainで見られるように)問題です。

最も効果的な解決策は、レイヤー2でシーケンサーからの応答を受け取らない場合に、ユーザーがレイヤー1ブロックチェーン上に専用の「出口」を設定し、このL1出口を介して資金を引き出すことを可能にすることです。

Loopring Protocolのバージョン3の文脈では、ユーザーイニシエートの強制引き出しについて2つの異なるシナリオが示されています。最初のシナリオは次のとおりです。

ユーザーは、ExchangeV3契約内のforcedWithdraw機能を使用して、レイヤー1で強制引き出しを直接開始できます。レイヤー2のアカウントとLoopringプロトコル内のTokenを宣言する必要があります。その後、ExchangeV3契約は、誰かが強制引き出しリクエストを開始したことを示すブロックチェーンイベントを発行します。シーケンサーを含むLoopringプロトコル内のすべてのノードは、Gethクライアントを実行しているため、イーサリアムブロックデータから強制引き出しと対応するブロックチェーンイベントについて通知されます。

強制出金はすぐには処理されず、代わりにpendingForcedWithdrawalsキューに入れられ、処理を待つことに注意することが重要です。レイヤー 1 で開始された強制引き出しに気付くと、Sequencer は通常 15 日以内に ExchangeV3 コントラクトの Process 関数をトリガーします。この機能は、イーサリアムチェーン上のトークンを出金のイニシエーター(イーサリアムチェーン上のレイヤー2プロジェクトのデポジットアドレスから出金者へ)に転送します。

シーケンサーがユーザーの強制引き出しリクエストに15日間応答しない場合、ユーザーはnotifyForcedRequestTooOld関数を呼び出すことができます。このアクションにより、ExchangeV3契約がWithdrawalModeActivatedというイベントを発行し、ループリングプロトコル内のすべてのノードに破産清算モードがアクティブになったことを通知します。

破産清算モードがアクティブ化されると、Sequencerによって提出された新しいL2ブロックの受け付けを中止します。これは、Loopring Protocol全体がこの時点で操作を停止することを意味します。このプロセスは少なくとも30日間続きます。

しかし、破産清算モードでは、ユーザーは引き続きレイヤー1で資産を引き出すことができますが、資産の状態/ステータスを証明するためにMerkle証明を提出する必要があります。これは、L2ステータスツリーで確認できます。(引き出しを開始したときに宣言した金額とレイヤー2の資産残高が一致していることを証明します。)

この記事では、Loopring Protocolの破産清算モデルについて説明しており、これはL2BEAT上の“Escape Hatch”メカニズムとしても知られています。このモデルは、特定の条件下でトリガーされます。例えば、シーケンサが指定された時間内にユーザーの強制引き出し要求に応答しない場合や、シーケンサが長期間の機能不全やシャットダウンを経験した場合などです。このような場合、ユーザーは手動でプロセスをトリガーし、Rollup契約を凍結または停止状態にします。ユーザーはその後、Layer 2上の資産状況を示すMerkle Proofを構築し、Layer 1上のLayer 2プロジェクトの入金アドレスから自分の資産の一部を引き出すことができます。

StarkExのドキュメントには、このプロセスを示す特定の図があります。レイヤー2ユーザーのLayer 1に提出された強制引き出し要求に対して、シーケンサーから7日間のウィンドウ内に応答がない場合、ユーザーは「凍結要求」機能を呼び出してレイヤー2の凍結期間を開始できます。この期間中、レイヤー2シーケンサーはレイヤー1でレイヤー2の状態を更新することができません。レイヤー2の凍結状態は、解凍されるまで1年間続きます。その後、ユーザーはMerkle証明を提出して資金を引き出すことができます。


しかし、Merkle Proofを構築するには、まず完全なL2ステートツリーを取得する必要があります。つまり、L2フルノードからデータを取得する必要があります。さらに、Merkle Proofを生成するために特定のコードが必要であり、ある程度の技術的な障壁が明確に提示されています。これを多くのユーザーにとって容易にするために、L2BEATは以前にLayer 2が一連のオープンアクセスおよびオープンソースのフルノードを設定するべきであると述べており、これによりユーザーがL2上のすべてのアカウントの状態(残高、取引数など)を取得するのに役立ちます。この動きは、強制的な引き出しと脱出ハッチメカニズムの重要性も強調しています。

Arbitrumの'Forced Transaction Inclusion'機能

ただし、強制的な引き出し/脱出ポッドが唯一の対検閲ソリューションではないようです。例えば、Arbitrumでは、ユーザーが最初にレイヤー1(L1)の遅延したInbox契約に処理する必要がある取引/引き出しを送信できる '強制トランザクションの含有' 方法を採用しています。シーケンサが24時間以内にそれらを処理できない場合、ユーザーはL1シーケンサInbox契約でForce Inclusion機能を呼び出すことができ、トランザクションを直接Arbitrumのトランザクションシーケンスに含めることができます(遅れたInboxに記録された複数のトランザクションをL2台帳に含める必要があることをArbitrumノードに通知するオンチェーンイベントを投げることで)。

この文章では、異なるブロックチェーンプロトコルが取引を処理するアプローチについて、特にArbitrumをLoopringやStarkExと比較して論じています。

「他のものと比較して、Arbitrumの方法はやや単純ですが、それでも欠点があります。それは、シーケンサーに無視されたいくつかの取引がL2の最長チェーンに含まれる必要があることをArbitrumノードに通知するためにオンチェーンイベントを単に発行するだけであり、LoopringプロトコルやStarkExの破産モード/脱出ポッドのように、ユーザーが直接L1で資金を引き出すことを可能にします。Arbitrumのチャレンジャーノードが検閲攻撃を開始するために共謀する場合、L2でユーザーの資金を凍結する可能性があるようです。」

したがって、Arbitrumの強制的な包含メカニズムは完全に許可されていません。1つの正直なノードでも、シーケンサーによって無視された強制的な包含リクエストを指摘する詐欺証拠を公開することができますが、これには少なくともわずかな信頼の前提が導入されています。

より具体的には、'強制的な含蓄が必要な取引'は少なくとも1つのARBチャレンジャーノードによって認識されなければなりません。現在、これらのノードは9つあり、L2とL1の間のクロスチェーンメッセージを承認する権限があり、また、詐欺証明を発行できる唯一の存在です。これらの9つのノードが共謀すると、理論的にはユーザーの'強制取引'を無効にすることができます。

したがって、現在のアービトラムにおける強制的な含蓄もしくは取り消し取引は、ループリングやStarkExの破産清算モードほど許可されていない。しかし、L2BEATは依然としてこのアービトラムのアプローチを高く評価しています。将来的には、アービトラムはBOLDという許可されていない詐欺証明公開メカニズムを立ち上げ、挑戦者ノードが共謀することが困難になるかもしれません(現在でもすでに難しいことです)。

L2BEATのデータによると、現在、レイヤー2(L2)プラットフォームの総ロック量(TVL)が5000万USDを超えるものの、シーケンサーフェイルアやプロポーザーフェイルアを解決する措置を提供していないのは、OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、およびMetisが含まれます。これらのL2プラットフォームは、極端なケースでは、ユーザーの資産が凍結され、L2から引き出すことができなくなる可能性があります。

そのため、強制引き出しや破産清算モードなどのメカニズムが必要であることが明らかです。現在は主にユーザーとソーター(オーダープロデューサー)の間のゲーム理論に依存しており、「いつでも引き出し可能」とは真に考えられない状況です(Arbitrumは24時間の遅延があり、失敗する可能性があります。Loopringは最大15日の遅延があります。StarkExは最大7日の遅延があります)。これらのメカニズムを持っていることは、全く持っていないよりも明らかに良いことです。強制引き出しの遅延の問題は、将来的により洗練されたメカニズム設計によって解決される可能性があります。現在の設計では、forceInclusionを通じた潜在的なMEV(最大採取可能価値)の搾取が考慮され、遅延の導入が必要とされています。詳細については、さまざまなL2プロジェクトの公式文書を参照してください。

多くのL2ロードマップに分散型シーケンサーが増加し、Vitalik Buterin率いるEthereum Foundationなどの機関によるLayer 2セキュリティの啓発活動が継続される中、強制引き出しにおける反検閲取引機能のような特徴が注目される可能性が高いでしょう。これにより、Ethereum Layer 2エコシステムは検閲耐性のある、信頼度を最小限に抑えた金融インフラに一歩近づくことになります。Layer 2が資金の出し入れを信頼度を最小限に抑えた方法で実現すると、より多くの市場メーカーや流動性提供者がL2インフラに参入し、web3の大規模採用に向けて一歩前進することが期待されています。

免責事項:

  1. この記事は[から転載されましたFaust,极客Web3]. すべての著作権は元の著者に帰属します [Faust,ギークWeb3]. If there are objections to this reprint, please contact the ゲート レイヤー2チームが迅速に対応します。
  2. 責任の免除: この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、あるいは盗用は禁止されています。

レイヤー2にとって強制引き出しと脱出口機能はどれほど重要ですか?

中級1/29/2024, 2:51:44 PM
この記事では、Loopring Protocol V3 と Arbitrum を例に、テクニカル分析とケース スタディを通じて、レイヤー 2 にセキュリティ設計が必要な理由について説明します。また、ファンドの出入りの分散型方法も分析します。

現実世界では、ほとんどの超高層ビルには欠かせない要素があります:非常口。火災や地震などの予期せぬ出来事が発生した際、これらの出口は人々の安全を守るための命の恩人となります。同様に、資産が数十億ドルを保有するEthereumレイヤー2エコシステムでは、「強制引き出し」機能が重要な施設となり、ユーザーが安全にアセットをレイヤー1に戻すことができるようになっています。

Vitalikは最近の記事「Different Types of Layer 2s」でも、ユーザーがレイヤー2からレイヤー1に資産をスムーズに引き出す能力は非常に重要な安全指標であると強調しています。

ただし、過去にはほとんどの人が「滑らかな出金」という問題を見落としていたようで、多くのレイヤー2プロジェクトチームが「強制出金」や「脱出ハッチ」機能を実装していませんでした。レイヤー2エコシステムがまだ成熟していない時代には、「許可なし出金」を無視することは問題にはならないようでした。しかし、現在はレイヤー2が120億ドル以上の資産を処理している時代であり、それは「失敗してはならないほど大きな」摩天楼となっています。そのような高層ビルに安全出口がないことは想像できません。

読者にレイヤー2の安全リスクについて意識を高めることを目的として、「Geek Web3」では、次のテキストでLoopring Protocol V3とArbitrumを例に挙げ、強制引き出しや脱出ハッチなどの「許可なし引き出し機能」がレイヤー2の不可欠な部分である理由を説明します。


(L2BEATのdYdXブラウザによると、これまでに、dYdXの強制取引/引き出し機能が合計152回使用され、100万ドルを超える大口引き出しが7件ありました)検閲耐性は大きな問題です:シーケンサーが意図的にあなたのリクエストを拒否した場合はどうなりますか?

過去の人気のある科学記事では、レイヤー2に関するものはしばしば1つの問題を抱えていました: それらは主に「セキュリティ」と表面的な「使いやすさ」を強調していましたが、「検閲耐性」を見落としていました。分散型シーケンサーソリューションについて議論する際でも、多くの人が気づいたのはMEVが分散型かどうかであり、検閲耐性の向上ではありませんでした。

言い換えれば、ほとんどの人々は、レイヤー2の状態遷移が効果的かどうか、シーケンサーがコインを盗むことができるか、詐欺の証明/有効性証明システムが採用されているかどうかに焦点を当てがちです。しかし、見落とされてはならないリスクがあります。それは、シーケンサーがあなたの取引リクエストを連続的に拒否した場合、または長期間機能しなくなったり、さらにはシャットダウンした場合、どうなるかというリスクです。

Solanaのダウンタイム中に、資産の清算リスクにより、人々が時間内に担保を追加できない事例があり、数百万ドルの資産が危険にさらされた。ユーザーの要求を拒否することが経済的な大損失につながる可能性があることに留意する価値がある。

たとえ個々の個人がそうした状況に遭遇することがあっても、大口の資金を保有する「クジラ」の一部にそれが起こった場合、市場全体が被害を受ける可能性があります。たとえば、イーサリアムのDeFiレンディングプロトコルで数億ドルの資産を持つ人が1週間以内に清算される可能性があるが、Tornadoの使用によりOFACに制裁を受けているとします。彼らのほとんどの資金はOptimism(OP)にあり、OFACの規制に準拠したOPシーケンサーは彼らの要求を拒否します。

この問題を、Ethereumから独立したAvalancheやPolygonなどのブロックチェーンに投影してみましょう。Avalancheのバリデーターのコンセンサスノードの3分の2以上があなたに対して取引監査を実施することを決定した場合、彼らはあなたの取引をブロックに含めることを拒否したり、あなたの取引が含まれているブロックの認識を拒否したりすることができます。この場合、あなたの資金は実質的にこのチェーンに埋まっており、引き出すことができません。

バリデーターのうち三分の二未満が検証攻撃に関与するよう説得するか、ソーシャルコンセンサスを通じてアバランチをフォークさせることができる場合を除いて、この時点でアバランチから資金を迅速に引き出す方法がまだあります。ただし、特定のアドレスに対するトランザクション検証を開始するために三分の二以上のバリデーターが団結し、時間がかかることを考慮する必要があります。これにより、検証対象のユーザーは‘逃走’する十分な時間を与えられます。

しかし、レイヤー2では状況がかなり異なる可能性があります。レイヤー2のシーケンサーは一般的に公式チームによって運営されています。シーケンサーがあなたに対して監査攻撃を開始したい場合、「レイヤー2であなたの資産を凍結する」ことができ、L2からL1への資産の移動リクエストを拒否することができます。L2の運営メカニズムによれば、シーケンサーをバイパスして引き出しを実行することができない場合、シーケンサーがL2であなたの資産を凍結し、それらの移動を阻止する可能性が完全にあります。

では、この問題はどのように解決できるのでしょうか?単純に言えば、SequencerやLayer 2プロジェクトチームの監視下にある場合でも、ユーザーが安全に資産をLayer 1に引き出すことができる「許可なし」の引き出し機能をどのように実装できるのでしょうか?一部のプロジェクトチームは、分散型のSequencerのアイデアを提案していますが、これは表面的な解決策です。これらの限られた数のSequencerが協力して監視しようとしても、依然としてあなたの資産を「凍結」することができます。さらに、Proof of Stake(PoS)ノードにおけるSybil攻撃の問題も(Multichainで見られるように)問題です。

最も効果的な解決策は、レイヤー2でシーケンサーからの応答を受け取らない場合に、ユーザーがレイヤー1ブロックチェーン上に専用の「出口」を設定し、このL1出口を介して資金を引き出すことを可能にすることです。

Loopring Protocolのバージョン3の文脈では、ユーザーイニシエートの強制引き出しについて2つの異なるシナリオが示されています。最初のシナリオは次のとおりです。

ユーザーは、ExchangeV3契約内のforcedWithdraw機能を使用して、レイヤー1で強制引き出しを直接開始できます。レイヤー2のアカウントとLoopringプロトコル内のTokenを宣言する必要があります。その後、ExchangeV3契約は、誰かが強制引き出しリクエストを開始したことを示すブロックチェーンイベントを発行します。シーケンサーを含むLoopringプロトコル内のすべてのノードは、Gethクライアントを実行しているため、イーサリアムブロックデータから強制引き出しと対応するブロックチェーンイベントについて通知されます。

強制出金はすぐには処理されず、代わりにpendingForcedWithdrawalsキューに入れられ、処理を待つことに注意することが重要です。レイヤー 1 で開始された強制引き出しに気付くと、Sequencer は通常 15 日以内に ExchangeV3 コントラクトの Process 関数をトリガーします。この機能は、イーサリアムチェーン上のトークンを出金のイニシエーター(イーサリアムチェーン上のレイヤー2プロジェクトのデポジットアドレスから出金者へ)に転送します。

シーケンサーがユーザーの強制引き出しリクエストに15日間応答しない場合、ユーザーはnotifyForcedRequestTooOld関数を呼び出すことができます。このアクションにより、ExchangeV3契約がWithdrawalModeActivatedというイベントを発行し、ループリングプロトコル内のすべてのノードに破産清算モードがアクティブになったことを通知します。

破産清算モードがアクティブ化されると、Sequencerによって提出された新しいL2ブロックの受け付けを中止します。これは、Loopring Protocol全体がこの時点で操作を停止することを意味します。このプロセスは少なくとも30日間続きます。

しかし、破産清算モードでは、ユーザーは引き続きレイヤー1で資産を引き出すことができますが、資産の状態/ステータスを証明するためにMerkle証明を提出する必要があります。これは、L2ステータスツリーで確認できます。(引き出しを開始したときに宣言した金額とレイヤー2の資産残高が一致していることを証明します。)

この記事では、Loopring Protocolの破産清算モデルについて説明しており、これはL2BEAT上の“Escape Hatch”メカニズムとしても知られています。このモデルは、特定の条件下でトリガーされます。例えば、シーケンサが指定された時間内にユーザーの強制引き出し要求に応答しない場合や、シーケンサが長期間の機能不全やシャットダウンを経験した場合などです。このような場合、ユーザーは手動でプロセスをトリガーし、Rollup契約を凍結または停止状態にします。ユーザーはその後、Layer 2上の資産状況を示すMerkle Proofを構築し、Layer 1上のLayer 2プロジェクトの入金アドレスから自分の資産の一部を引き出すことができます。

StarkExのドキュメントには、このプロセスを示す特定の図があります。レイヤー2ユーザーのLayer 1に提出された強制引き出し要求に対して、シーケンサーから7日間のウィンドウ内に応答がない場合、ユーザーは「凍結要求」機能を呼び出してレイヤー2の凍結期間を開始できます。この期間中、レイヤー2シーケンサーはレイヤー1でレイヤー2の状態を更新することができません。レイヤー2の凍結状態は、解凍されるまで1年間続きます。その後、ユーザーはMerkle証明を提出して資金を引き出すことができます。


しかし、Merkle Proofを構築するには、まず完全なL2ステートツリーを取得する必要があります。つまり、L2フルノードからデータを取得する必要があります。さらに、Merkle Proofを生成するために特定のコードが必要であり、ある程度の技術的な障壁が明確に提示されています。これを多くのユーザーにとって容易にするために、L2BEATは以前にLayer 2が一連のオープンアクセスおよびオープンソースのフルノードを設定するべきであると述べており、これによりユーザーがL2上のすべてのアカウントの状態(残高、取引数など)を取得するのに役立ちます。この動きは、強制的な引き出しと脱出ハッチメカニズムの重要性も強調しています。

Arbitrumの'Forced Transaction Inclusion'機能

ただし、強制的な引き出し/脱出ポッドが唯一の対検閲ソリューションではないようです。例えば、Arbitrumでは、ユーザーが最初にレイヤー1(L1)の遅延したInbox契約に処理する必要がある取引/引き出しを送信できる '強制トランザクションの含有' 方法を採用しています。シーケンサが24時間以内にそれらを処理できない場合、ユーザーはL1シーケンサInbox契約でForce Inclusion機能を呼び出すことができ、トランザクションを直接Arbitrumのトランザクションシーケンスに含めることができます(遅れたInboxに記録された複数のトランザクションをL2台帳に含める必要があることをArbitrumノードに通知するオンチェーンイベントを投げることで)。

この文章では、異なるブロックチェーンプロトコルが取引を処理するアプローチについて、特にArbitrumをLoopringやStarkExと比較して論じています。

「他のものと比較して、Arbitrumの方法はやや単純ですが、それでも欠点があります。それは、シーケンサーに無視されたいくつかの取引がL2の最長チェーンに含まれる必要があることをArbitrumノードに通知するためにオンチェーンイベントを単に発行するだけであり、LoopringプロトコルやStarkExの破産モード/脱出ポッドのように、ユーザーが直接L1で資金を引き出すことを可能にします。Arbitrumのチャレンジャーノードが検閲攻撃を開始するために共謀する場合、L2でユーザーの資金を凍結する可能性があるようです。」

したがって、Arbitrumの強制的な包含メカニズムは完全に許可されていません。1つの正直なノードでも、シーケンサーによって無視された強制的な包含リクエストを指摘する詐欺証拠を公開することができますが、これには少なくともわずかな信頼の前提が導入されています。

より具体的には、'強制的な含蓄が必要な取引'は少なくとも1つのARBチャレンジャーノードによって認識されなければなりません。現在、これらのノードは9つあり、L2とL1の間のクロスチェーンメッセージを承認する権限があり、また、詐欺証明を発行できる唯一の存在です。これらの9つのノードが共謀すると、理論的にはユーザーの'強制取引'を無効にすることができます。

したがって、現在のアービトラムにおける強制的な含蓄もしくは取り消し取引は、ループリングやStarkExの破産清算モードほど許可されていない。しかし、L2BEATは依然としてこのアービトラムのアプローチを高く評価しています。将来的には、アービトラムはBOLDという許可されていない詐欺証明公開メカニズムを立ち上げ、挑戦者ノードが共謀することが困難になるかもしれません(現在でもすでに難しいことです)。

L2BEATのデータによると、現在、レイヤー2(L2)プラットフォームの総ロック量(TVL)が5000万USDを超えるものの、シーケンサーフェイルアやプロポーザーフェイルアを解決する措置を提供していないのは、OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、およびMetisが含まれます。これらのL2プラットフォームは、極端なケースでは、ユーザーの資産が凍結され、L2から引き出すことができなくなる可能性があります。

そのため、強制引き出しや破産清算モードなどのメカニズムが必要であることが明らかです。現在は主にユーザーとソーター(オーダープロデューサー)の間のゲーム理論に依存しており、「いつでも引き出し可能」とは真に考えられない状況です(Arbitrumは24時間の遅延があり、失敗する可能性があります。Loopringは最大15日の遅延があります。StarkExは最大7日の遅延があります)。これらのメカニズムを持っていることは、全く持っていないよりも明らかに良いことです。強制引き出しの遅延の問題は、将来的により洗練されたメカニズム設計によって解決される可能性があります。現在の設計では、forceInclusionを通じた潜在的なMEV(最大採取可能価値)の搾取が考慮され、遅延の導入が必要とされています。詳細については、さまざまなL2プロジェクトの公式文書を参照してください。

多くのL2ロードマップに分散型シーケンサーが増加し、Vitalik Buterin率いるEthereum Foundationなどの機関によるLayer 2セキュリティの啓発活動が継続される中、強制引き出しにおける反検閲取引機能のような特徴が注目される可能性が高いでしょう。これにより、Ethereum Layer 2エコシステムは検閲耐性のある、信頼度を最小限に抑えた金融インフラに一歩近づくことになります。Layer 2が資金の出し入れを信頼度を最小限に抑えた方法で実現すると、より多くの市場メーカーや流動性提供者がL2インフラに参入し、web3の大規模採用に向けて一歩前進することが期待されています。

免責事項:

  1. この記事は[から転載されましたFaust,极客Web3]. すべての著作権は元の著者に帰属します [Faust,ギークWeb3]. If there are objections to this reprint, please contact the ゲート レイヤー2チームが迅速に対応します。
  2. 責任の免除: この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、あるいは盗用は禁止されています。
Comece agora
Inscreva-se e ganhe um cupom de
$100
!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.