L2トランザクションの全プロセスの分析:各段階でのセキュリティ分析

L2取引はL1取引と比べて重要なステップが1つ増えます: L2ブロックがL1にアップロードされるのを待つことです。この段階では、データがまだL1にアップロードされていないため、不確実性が存在し、ユーザーはSequencerが提供する「口頭の約束」、つまりPre-Confirmationに依存するしかありません。

主流L2ソリューションの取引確認プロセスは次のとおりです:

アービトラム/オプティミズム

取引が送信されると、ユーザーはほぼ即座に取引の領収書を受け取ります。これは、Sequencerがローカルで順序付けてシミュレーション実行したことを示しています。これはPre-Confirmationの一種です。

Arbitrum Explorerは以下を表示します。

• "Sequencerに確認済み": Sequencerによってのみ確認され、L1にはアップロードされていません
• "X L1 ブロック確認": L1がアップロードされ、後続のX個のブロック

Optimism Explorer には、次の情報が表示されます。

• "Sequencerによって確認されました":Sequencerが確認しました
• L1 State Batch Index と L1 State Root Submission Tx Hash: L1 情報をバッチでアップロードします。
• Finalized: L1 の Finalized ステータスを示します。

! L2トランザクション実装の全プロセスの解釈:各ステージのセキュリティパフォーマンスは?

スタークネット

取引状態のプロセス:

1. 受信:取引は受信され、検証されました
2. 保留中: シーケンサーが処理中
3. L2で受け入れられました: L2ブロックに入っています
4. L1で受け入れられました: データがL1にアップロードされました

ゼロ知識証明の生成に時間がかかるため、L1のアップロードには4-5時間の待機が必要であり、ユーザーは長時間Pre-Confirmationに依存しています。

! L2トランザクション実装の全プロセスの解釈:各ステージのセキュリティパフォーマンスは?

zkSyncの

取引ステータスプロセス:

1. PENDING: Sequencer が処理するのを待ちます
2. zkSync Era Processed:L2ブロックが入力されました
3. コミット: ブロックがL1にアップロードされました
4. Proven:ブロックの有効性が証明されました
5. 実行済み:L2ステータスがL1に更新されました

zkSyncはL2からL1へのプロセスを3つの段階に分け、より詳細な状態表示を提供します。

! L2トランザクション実装の全プロセスの解釈:各ステージのセキュリティパフォーマンスは?

まとめ

• L2取引では「L1のアップロード待ち」というステップが増えました
• この段階では、ユーザーはシーケンサーの事前確認に頼ります
• ほとんどのL2エクスプローラーは、事前確認ステータスを表示します
• 完全確認にはL2データのL1へのアップロードを待つ必要があります
• プレ確認に経済的インセンティブメカニズムを追加して信頼性を向上させることができます

異なる段階の取引確認保証およびリスク:

| ステージ | L1トランザクション | L2取引 | |------|--------|--------| | 取引を発行 | 保証なし | 保証なし | | メモリプールに入る | 軽微な保証 | 軽微な保証(がある場合) | | プレ確認 | - | シーケンサーの約束 | | ブロックに入る | 強力な保証 | L2強力な保証 | | L1をアップロード | - | L1の強い保証 | | 複数確認 | 非常に強力な保証 | 非常に強力な保証 | | ファイナライズ | 最強保証 | 最強保証 |

! L2トランザクション実装の全プロセスの解釈:各ステージのセキュリティパフォーマンスは?