L2（レイヤー2）トランザクションがブロックに含まれることが確実になるのはいつですか？L2トランザクションからの収益がリオーダーにより破棄されないことが確実になるのはいつですか？

この記事では、L2取引実装の全プロセスを読者に紹介し、取引プロセスの各段階でのセキュリティパフォーマンスを分析します。

前提知識：

1. L1（レイヤー1）トランザクションの全プロセス

2. Re-orgsの原因と影響

3. 現在のイーサリアムのPBSアーキテクチャにおける役割と運用方法を理解する

4. Optimistic RollupとValidity(ZK) Rollupの違いを理解する

L1トランザクションの理解

取引プロセス

ユーザーがトランザクションを発行し署名すると、それはピアツーピアネットワークに送信され、PoWコンセンサスメカニズムの下でマイナーまたはPoSコンセンサスメカニズムの下でプロポーザーがブロックに含めるのを待ちます。ユーザーが最新のブロックに自分のトランザクションが含まれていることに気付いたとき、そのトランザクションがそのブロックチェーンの履歴に永久に記録されることを100％確認することはできません。これは、「Re-org」として知られるブロックチェーンイベントの可能性に起因しています。ユーザーは、特定のブロックでRe-orgが発生する可能性が十分に低くなるまで待たなければなりません。その時、自分のトランザクションがブロックチェーンの履歴に記録されることを確信することができます。

L1 トランザクションプロセスのイラスト

ブロックに取引が含まれた後でも、リオーガニゼーションが発生する可能性があります。取引が最終確定されたことを確信するには、リオーガニゼーションが発生する可能性が低いまで待つ必要があります。

Re-orgの確率とコストは、チェーンの合意アルゴリズムとその資産の市場価値によって異なります。Re-orgのコストを計算する方法については、ここでは詳しくは議論しません。

L2トランザクションの理解

取引プロセス

L2 ユーザーがトランザクションを生成して署名すると、通常、トランザクションの注文を担当する Sequencer に直接送信されます。その後、Sequencer はこのトランザクションを L2 ブロックに含めます。その後、Sequencer が L1 トランザクションを介して L2 ブロック データを L1 に書き戻すと、ユーザーはトランザクションが最新の L2 ブロックに含まれていることを確認できます。ただし、L2 ブロック データは L1 トランザクションを介して L1 にアップロードされるため、L1 再編成が発生する可能性があることに注意してください。このシナリオでは、L2ブロックがブロックチェーン履歴に含まれず、事実上L2再編成が発生する可能性があります。したがって、ユーザーは、L1 Re-orgの可能性が十分に低くなるまで待ってから、トランザクションがブロックチェーン履歴に記録されることを確信する必要があります。

L2トランザクションプロセスのイラスト

ユーザーはまず、トランザクションがL2ブロックに含まれるのを待ち、次にL2ブロックがL1トランザクションを介してL1にアップロードされるのを待ち、最後にL1トランザクションが確定するのを待ちます。L2ブロックがシーケンサーによって含まれるまで待つというステップがL1トランザクションと比較して追加されますが、L2ブロックの容量が大きく、ブロック生成速度が速い場合、この待ち時間は一般的に重要ではありません。実際、待ち時間のほとんどはL1トランザクションの確認に費やされます。したがって、全体的には、L1トランザクションとL2トランザクションのユーザー体験は類似しています。しかし、ユーザーはより良い体験のために何か譲歩することができますか？

Pre-Confirmation/Fast Confirmation/Soft Confirmation

ユーザーは、理想的には、L2トランザクション（L2ブロックに含まれる）がL1ブロックに含まれるのを目撃し、再編の可能性が十分に低くなるまで待つべきです。その後で、自分のL2トランザクションが含まれたことを信頼することができます。しかし、ユーザーがシーケンサーを信頼することを望む場合はどうでしょうか？シーケンサーがL2開発チームまたは信頼性のある機関によって運営されていると仮定しましょう。シーケンサーがトランザクションを受け取ったら、即座にまたはXブロック目に含まれることをユーザーに保証する場合、それはシーケンサーを信頼するユーザーにとって十分な保証となるかもしれません。これは、ウォレットアプリを信頼し、ウォレットがトランザクションが含まれたことを通知した後にEtherscanを繰り返しチェックしないユーザーに似ています。

このシーケンサーによって提供される保証は、Pre-Confirmation、Fast Confirmation、またはSoft Confirmationと呼ばれます。これらは、"早すぎる"または"柔らかい"トランザクションの包含保証として理解することができます。L2トランザクションがL1ブロックに含まれるのを待つ必要はありませんが、それらは単なるシーケンサーからの口頭の約束です。シーケンサーは、バグのために約束を忘れるか、悪意のあるシーケンサーが約束を破る可能性があり、ユーザーにとって無駄な時間を生じさせるか、最悪の場合、「二重支払い攻撃」にさらされる可能性があります。

次に、L2トランザクションの包含状況を提示するいくつかの異なる方法を紹介します。

Arbitrum/Optimism上の取引包含状況

現在、ユーザーがArbitrumまたはOptimismでトランザクションを送信した後、ユーザーがArbitrumまたはOptimismでトランザクションを実行すると、トランザクションの実行結果を含むトランザクションレシートをほぼ即座に受信できます。これは、シーケンサーがすでにトランザクションの実行をローカルで順序付けてシミュレートしており、トランザクションのレシートがユーザーの事前確認として機能していることを示します。

Arbitrumの詳細な取引ライフサイクルに関する情報については、公式ドキュメントを参照してください: https://docs.arbitrum.io/tx-lifecycle

Optimism上の取引ライフサイクルの詳細な説明については、公式ドキュメントを参照してください: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Arbitrumでのトランザクションの含まれ具合をチェック

Arbitrumエクスプローラーに表示される取引には、Pre-Confirmationを含むものがあります。つまり、まだL1にアップロードされていない取引です。次の画像に示すように、ブロック番号145353000の取引は「シーケンサーによって確認済み」とマークされており、シーケンサーによって確認されていますが、まだL1にアップロードされていません。

[Sequencerによって確認された取引がL1にアップロードされていません]

一方、次の画像はすでにL1にアップロードされた取引を示しており、状態は「69 L1ブロック確認」です。これは、この取引データを含むL1ブロックにはそれに続く69ブロックがあることを意味し、より高いセキュリティレベルを示しています。

[画像は、69ブロック確認のL1でのトランザクションを示しています]

別の例は、以下に示すように、6174 L1ブロック確認を伴うトランザクションであり、これは非常に安全であると考えられています。

ただし、この表示にL1ファイナリティ情報が統合されているともっと良いでしょう。ユーザーにL1ブロック確認の数を単に伝えるだけでは、その数値が表すセキュリティレベルを理解して計算しなければならないため、あまり役に立ちません。Layer 1（Ethereum）にはCasper FFGのようなファイナリティメカニズムがありますので、エクスプローラーはLayer 1ブロックが最終決定されたかどうかを直接表示することができます。現在、Optimismのエクスプローラーはこの機能を実装しています。

Optimismでのトランザクションの含まれ具合をチェックする

Optimism Explorerに表示される取引には、Pre-Confirmationを持つものも含まれます。つまり、まだL1にアップロードされていない取引も含まれます。次の画像に示すように、ブロック番号111526300の取引は「Sequencerによって確認済み」とマークされています。

[画像は、シーケンサーによってのみ確認され、L1にはアップロードされていない取引を示しています]

ただし、Explorerは「Sequencerによって確認済み」という言葉の意味を明確に定義していません。それは、「Sequencerの確認はL1上の数ブロックの確認に相当し、『Sequencerによって確認済み』とマークされたトランザクションはL1にアップロードされ、それに続くいくつかのブロックがあることを示しています。」

[最近の取引が「シーケンサによって確認済み」として表示されています]

数日前の取引でも、チャレンジ期間を過ぎても、「Sequencerによって確認済み」という状態が表示されます：

[Image shows transactions from days ago still marked as “Confirmed by Sequencer”]

注：エクスプローラーは異なる場所で異なる状態を表示する場合があります。「ブロック番号の横に「シーケンサーによって確認済み」と表示されている場合、そのブロックはシーケンサーによって確認されたことを示します。L1にアップロードされた後の状態を確認するには、「以下で言及されている「L1ステートバッチ」など、他の情報を探す必要があります。

次のスクリーンショットに示すように、L1にすでにアップロードされているトランザクションには、追加情報が含まれています。“L1 State Batch Index”および“L1 State Root Submission Tx Hash”という情報は、L2トランザクションが含まれているState Batchと、このState BatchをL1にアップロードしたL1トランザクションを示しています。

[画像には、L1 State Batch情報を持つ取引が表示されています]

ステートバッチ“3480”をクリックすると、そのステータスはFinalizedであることが明らかになります。このFinalizedのステータスは、イーサリアムのメインネットに対応しており、有効なバリデーターの投票を2エポック正常に蓄積した非常に安全な状態を示しています。

[画像は、L1ブロック18457449でファイナライズされた状態バッチ3480を示しています]

Source: https://etherscan.io/block/18457449

L1にまだ最終承認されていないバッチがアップロードされている場合、未最終化として表示されます:

[Image shows a State Batch uploaded to L1 but not yet finalized]

Arbitrumエクスプローラーと比較すると、Optimismエクスプローラーはより多くの情報（State Batch）を提供し、L1 Finality情報をL2エクスプローラーに直接統合しており、ユーザーがセキュリティのためにブロック確認の数を解釈する必要なく、L1ブロックが確定されたかどうかを知らせています。

StarkNet トランザクション収益状況

現在、ユーザーがStarkNet上でトランザクションを送信すると、トランザクション受領書にすばやくアクセスできます。ただし、受領書に表示されるステータスはよく「RECEIVED」と表示され、ノードがトランザクションをエラーなく受信および検証したことを示しています。その後、SequencerによるL2ブロックへの含まれ、実行を待ちます。RECEIVEDステータスのトランザクションにはまだ実行結果がありません。ユーザーはStarkNet Explorerで表示されるステータスを通じてトランザクションの進行状況を監視できます。

Note: シーケンサーがトランザクションを十分に高速処理する場合、RECEIVEDステータスをスキップし、直接処理された状態に移行する可能性があります。StarkNetのトランザクションプロセスの詳細な紹介については、公式ドキュメントを参照してください。https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

Starkscan、StarkNet Explorer では、Pre-Confirmation を含むトランザクションが表示されます。例えば、「L2 で受け入れ済み」と表示されるトランザクションは、L2 ブロックにシーケンスされたことを示しています。

「L2で受け入れられました」とは、取引がL2ブロックにシーケンス化されましたが、まだL1にアップロードされていないことを意味します。

上記の 2 つの状態 (受信済み と 保留中) は、"トランザクションの受信と検証" と "シーケンサーによって処理中のトランザクション" を表します。処理後、ステータスは L2 で [Accepted] に変わります。

取引を受信し、検証しました

トランザクションはシーケンサーによって処理されています

取引データがL1にアップロードされると、この取引の下の図に示すように、L1で状態が受け入れられたと表示されます。

トランザクションデータはL1にアップロードされました

StarkNetトランザクションにはより豊富なステータスがあり、ユーザーがトランザクションの進行状況を把握できるようになりましたが、L1へのアップロードには、ゼロ知識証明を生成するために必要な時間が主な理由として数時間かかることがあります。そのため、この期間中はユーザーがシーケンサーの事前確認に依存しています。

StarkNet Explorerは、L1ステータスでの受け入れのみを表示し、L1最終性やブロック確認に関する情報がないため、ユーザーは、トランザクションがL1上で行われた後に十分なブロックが追加されたか、または最終確定されたかどうかを確認する必要があります。

StarkNetのパフォーマンス制限、Pre-Confirmationへの長期依存、およびExplorerでのL1ファイナリティ情報のサポートの欠如により、StarkNet上での取引取り込み確認のユーザーエクスペリエンスが改善が必要です。

zkSyncトランザクション包含ステータス

StarkNetに類似して、zkSyncにもPENDINGステータスがあります。これは、ノードがトランザクションを受信し、検証したことを示し、問題がないことを示します。その後、トランザクションはSequencerによってL2ブロックに含まれ、実行を待ちます。PENDINGステータスのトランザクションにはまだ実行結果がありません。

ユーザーは、zkSyncエクスプローラーに表示される状態を通じて、取引の進捗状況を追跡することができます。

リーディングのヒント：シーケンサーがトランザクションを十分に迅速に処理する場合、PENDINGステータスをバイパスし、トランザクションがすでに処理されている状態に直接移行する可能性があります。

zkSyncの取引プロセスの詳細な紹介については、このリンクをご覧ください: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

zkSyncエクスプローラで表示される取引には、以下のスクリーンショットにあるもののように、Pre-Confirmation取引も含まれます。ステータスは現在、「zkSync Era Processed」であり、これはシーケンサーによってL2ブロックに配置されたことを示しています。

トランザクションはシーケンサーによってL2ブロックに配置され、現在L1（Ethereum Sending）にアップロードされるのを待っています。

シーケンサーがL2ブロックを完了すると、ブロックとそのトランザクションは3つの段階を経る：コミット、プルーブン、実行。これらはそれぞれ「ブロックがL1にアップロードされたことを示す」、「ブロックの妥当性が証明されたことを示す」、「ブロック内のトランザクションの実行後のL2状態がL1に更新されたことを示す」。以下はこれらの異なる段階でのブロックとトランザクションの例です。

バッチ292700がL1にアップロードされ、Committedステージに入りました。ソース：https://explorer.zksync.io/batch/292700

バッチ292700の取引のステータスが、イーサリアムの送信からイーサリアムの検証に変わり、それらが有効性のゼロ知識証明の検証を待っていることを示しています。

Ethereum検証アイコンの上に矢印を移動すると、さまざまなステージと、前のステージ（送信）の取引リンクも表示されます。

この取引は「検証中」段階に入りました。前の段階（送信中）でのL1へのバッチアップロードの取引リンクもここで直接確認できます。

バッチ292000は有効性が証明されたため、証明された段階に入ります：

バッチが証明されると、Proven状態に入り、Proveアクションを実行するトランザクションへのリンクが付きます。

トランザクションは次に「検証中」から「実行中」に移動します。つまり、実行を待っています。

バッチが証明された後、そのバッチ内のトランザクションを実行し、L1に記録されたL2状態を更新するまでには、待機期間があります（公式文書によると約21時間）。これは、バグの場合に備えて十分な反応時間を確保するためのアルファフェーズでの保護措置です。バッチが実行されると、最終的に実行された段階に入ります。

実行後、バッチは最終的な実行済みの状態に入り、Executeアクションを実行するトランザクションへのリンクがあります。

バッチ内の取引の状況も「実行済み」に更新されます。

StarkNetと比較すると、トランザクションがL2からL1に一気に移動するのに対し、zkSyncはL2からL1へのプロセスを「Committed → Proven → Executed」という3つのより詳細な段階に分解しています。全体のトランザクションプロセスに約1日かかるという防護手段として、Committedの状態では、ユーザーがトランザクションが含まれているかどうかを迅速に確認できます（Committed後、Pre-Confirmationだけでない）。さらに、zkSync Explorerは各段階について包括的なデータを提供し、誰もがトランザクションの最新のステータスを追跡したり、段階間の遷移を検証したりできます（例：CommittedからProvenへ、ProvenからExecutedへ）。

ただし、Alphaフェーズにおける保護措置として、zkSync Sequencerは現在、履歴レコードを変更することができることに注意することが重要です。つまり、取引が素早くPre-ConfirmationからCommittedステージに移動することができるとしても、Sequencerは取引がExecutedステージに達するまで、履歴レコードからユーザー取引を削除することができます。したがって、ユーザーは引き続き最大1日間、Sequencerを信頼する必要があります。

L1も事前確認をサポートすることができます

事前に誰がブロックの生成者であるかを知ることができれば、L1もPre-Confirmationをサポートすることが可能です。Ethereumを例に取ると、実際のブロック生成者はビルダーであり、Pre-Confirmationサービスを提供することができ、ユーザーに取引の確約を提供します。ただし、ビルダーは特定のブロックを生成する権利を保証されておらず、各ブロックの生成権を入札しなければならないため、このPre-Confirmationの効果は比較的弱いです。さらに、ビルダーの強さも考慮する必要があります。競争力に欠けるビルダーの場合、ブロックの生成権を獲得することが難しくなり、Pre-Confirmationサービスの価値が低下します。

これらの問題を回避するためのより良い解決策は、通常、どの提案者がどのブロックを提案するかは予め決まっているため、提案者が事前確認サービスを提供することです。ただし、現在のPBS（提案者-ビルダー分離）アーキテクチャでは、提案者はブロックの提案のみを担当し、ビルダーがブロックの内容を決定します。したがって、提案者は直接トランザクションをブロックに挿入したり、ビルダーにそのようにするように依頼することはできません。提案者が事前確認サービスを提供できるようにPBSアーキテクチャが将来変更される可能性があります。これには、インクルージョンリストの追加や提案者がブロック製造に参加できるようにするなどの変更が含まれます。

読書のヒント: PBSに関する詳細情報については、以下のリンクをブラウザにコピーしてお読みください: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

事前確認の改善

Pre-Confirmationは、BuilderまたはL2 Sequencerからの口頭の約束であり、それを果たす義務や不履行のための罰則はありません。この約束をより信頼性の高いものにすることは可能ですか？はい、なぜなら、ブロックを生成する責任者が行うコミットメントの内容（例：“この取引をブロック1350000に含める”）は条件付きのチェックとして書かれることができます。したがって、Pre-Confirmationサービスを提供する際にBuildersまたはSequencersにスマートコントラクトに担保を預けるよう要求し、コミットメントの内容に署名するよう求めることができます。ユーザーがBuildersまたはSequencersが約束を守っていないことに気づいた場合、コミットメントと署名をスマートコントラクトに提出して検証することができます。

Although the application of such contracts is still in the proof-of-concept stage, the following link to a presentation video showcases one example of contract application:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

概要

L1トランザクションがL1ブロックに含まれると、Re-orgの確率は徐々に低下し、ユーザーのトランザクションが含まれる可能性に対する信頼が高まります。

L2トランザクションは、L1トランザクションと比較して追加のワークフローを持っています：「L2トランザクションがL2ブロックに含まれ、L1にアップロードされるのを待つ」という段階。この段階では、データがまだL1にアップロードされていないため、変更の可能性がまだあるため、トランザクションが含まれることについてユーザーが持っている唯一の保証は、シーケンサーからの口頭での確約であり、それはPre-Confirmation、Fast Confirmation、またはSoft Confirmationとして知られています。

シーケンサーが悪意を持っているかバグに遭遇すると、そのコミットメントが壊れる可能性があり、ユーザーのL2トランザクションの確認が不足する可能性があります。

現在、ほとんどのL2は、Pre-Confirmationステータスを含むトランザクションの状態をエクスプローラーで表示しています。例えば、Arbitrum/Optimismの「Confirmed by Sequencer」やStarkNetの「Accepted on L2」などです。これらのステータスが提供するトランザクションの含まれる保証の時間的有効性について、ユーザーは認識しておく必要があります。

ユーザーがシーケンサーの事前確認を信頼したくない場合、L2エクスプローラーが提供する情報を通じてL2データがL1にアップロードされることについて検証するために、より長く待つ必要があります。

Pre-Confirmationには、Sequencersが約束を破った場合のペナルティなど、経済的インセンティブメカニズムが含まれる場合があります。これにより、ユーザーへのより明確な保護が提供されます。

以下の表は、L1およびL2トランザクションの異なる段階における取引の含有保証と対応するリスクシナリオを示しています：[翻訳されたテーブルは提供されていませんので、ご了承ください。]

免責事項：

1. この記事は[から転載されましたimToken Labs]. すべての著作権は元の著者に帰属します [Nic]. If there are objections to this reprint, please contact the Gate Learnチームはすぐに対処します。
2. 責任の免責事項：本記事に表現されている意見は著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、ゲートラーニングチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。