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

この記事では、L2トランザクションの実装全体のプロセスを紹介し、トランザクションプロセスの各段階でのセキュリティパフォーマンスを分析します。

Preliminary Knowledge:

• L1（レイヤー1）トランザクションの全プロセス
• Re-orgの発生原因と影響
• 現在のEthereum PBSアーキテクチャにおける役割や動作方法を理解する
• Optimistic RollupとValidity (ZK) Rollupの違い

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

取引プロセス

ユーザーがトランザクションを発行し署名した後、それはP2Pネットワークに送信され、採掘者（Proof of Work（PoW）コンセンサスメカニズムの下で）または提案者（Proof of Stake（PoS）コンセンサスメカニズムの下で）によってブロックに含まれるのを待っています。ユーザーが最新のブロックに自分のトランザクションが含まれたことに気づいたとき、そのトランザクションがブロックチェーンの履歴に永久に記録されるかどうかはまだ確実ではありません。この不確実性は、ブロックチェーン上で「リオーグ」（再編成）が発生する可能性によるものです。ユーザーは、リオーグが十分に低い確率で発生するまで待たなければならず、その時点で自分のトランザクションがブロックチェーンの履歴に永久に記録されることを確信することができます。

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

トランザクションがブロックに含まれた後でも、再編成が発生する可能性があるため、再編成の可能性が低くなった場合にのみ確認が保証されます。

Re-orgの可能性とコストは、各ブロックチェーンのコンセンサスアルゴリズムとそのアセットの時価によって異なります。この文書では、Re-orgコストの計算方法には深入りしません。

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

取引プロセス

L2ユーザーは取引を生成し署名し、通常はそれらを直接シーケンサーに送信し、シーケンサーはこれらの取引をL2ブロックに含めます。その後、シーケンサーがL2ブロックデータをL1トランザクションを介してL1に投稿すると、ユーザーは最新のL2ブロックに自分の取引が含まれているのを見ることができます。

ただし、L2ブロックデータがL1トランザクションを介してL1に投稿されるため、L1 Re-orgが発生する可能性が依然としてあることに注意することは重要です。これにより、L2ブロックがブロックチェーンの履歴に永久に記録されない可能性があります。このシナリオはL2 Re-orgに似ており、したがって、ユーザーはL1 Re-orgの確率が十分に低くなるまで待つ必要があります。そうすることで、自分のトランザクションがブロックチェーンの履歴に永久に記録されることを確信することができます。

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

ユーザーは、まず、トランザクションがL2ブロックに含まれるのを待たなければならず、次に、L2ブロックがL1トランザクションを介してL1に投稿されるのを待たなければならず、最後に、L1トランザクションが完了するのを待たなければなりません。

L2トランザクションは、一般的にL1トランザクションと比較して、シーケンサーによるL2ブロックへの追加待機時間がかかりますが、L2ブロックの容量が大きく、ブロック生成が速い場合は、この待機時間は一般的に短くなります。なぜなら、主な待機期間はL1トランザクションの確認待ちであるためです。そのため、全体的なL1トランザクションとL2トランザクションのユーザーエクスペリエンスは似ています。

事前確認/高速確認/ソフト確認

ユーザーは、L2トランザクションとL2ブロックがL1ブロックに含まれていることを個人で確認し、さらにRe-orgの可能性が十分に低いと信頼できるまで待つ必要があります。

しかし、ユーザーがシーケンサーを信頼することを望んでいる場合はどうなりますか？シーケンサーはL2開発チームまたは信頼できる機関によって運営される可能性があります。シーケンサーがユーザーにその取引を受け取った直後に特定のブロックに含まれることを保証するとすれば、この保証はシーケンサーを信頼することを望む人々にとって十分なものとなるかもしれません。これは、ユーザーがウォレットアプリケーションを信頼し、取引が含まれたことが通知された後にEtherscanを執拗にチェックする必要がないのと似ています。

シーケンサーによって提供されるこのような保証は、Pre-Confirmation、Fast Confirmation、またはSoft Confirmationと呼ばれます。これらは取引の含有を「予備的」または「ソフト」な保証と見なされ、L2取引をL1ブロックに含める必要はありません。ただし、これらはシーケンサーからの単なる口頭での確約であり、最悪の場合、バグによって忘れられるか、悪意のあるシーケンサーによって意図的に破られる可能性があり、それが二重支払い攻撃につながる可能性があります。

その後、L2トランザクションの取り込み状況がどのように表示されるかを紹介します。

Arbitrum/Optimism トランザクションの取り込み状況

現在、ArbitrumまたはOptimismのユーザーは、トランザクションを送信した後ほぼすぐにトランザクションの受領を受け取ることができ、トランザクションの実行結果を示します。これは、シーケンサーがすでにトランザクションをローカルでシーケンスし、シミュレートしたことを意味し、ユーザーに事前確認を提供しています。

詳細を学ぶ

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

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

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 Explorerで見られる取引には、事前確認取引も含まれます。つまり、L1にアップロードされていない取引です。以下の図に示す取引では、ブロック番号145353000の横にシーケンサーによって確認されましたという印が見えます。

上の画像は、シーケンサーだけによって確認された取引を示していますが、まだL1にアップロードされていません。

図に示すように、L1にアップロードされた取引であれば、その状態は69 L1ブロック確認に変わり、つまりL1にアップロードされ、取引データを含むLayer1ブロックにはそれに続く69個のブロックがあります。

この取引データを含むL1ブロックにはすでに69個のブロックが続いています。その後に続くブロックが多いほど、それがより安全である。

または、この取引については、以下のスクリーンショットに表示されているように、この取引データを含むL1ブロックにはすでに6174ブロックが続いており、非常に安全です。

しかし、実際には、ここでより良くできることは、L1の最終性情報と組み合わせて提示することです。

ユーザーにL1ブロック確認がいくつあるかを単に伝えるだけでは、ユーザーにとってあまり役に立ちません。なぜなら、ユーザーはそのようなブロック確認の数値によって表されるセキュリティレベルを理解し計算する必要があるからです。また、Layer1（つまりEthereum）はすでにCasper FFGのような最終性メカニズムを持っているため、エクスプローラは実際にLayer1のブロックがLayer1で最終化されているかどうかを直接表示することができます。現在、Optimismのエクスプローラはそのような機能を実装しています。

Optimismでトランザクションレシートのステータスを確認する

Optimism Explorerで表示される取引には、まだレイヤー1（L1）に投稿されていないことを示す事前確認としてマークされたものも含まれる場合があります。以下の図のように、ブロック番号111526300の取引は「シーケンサーによって確認済み」とタグ付けされています。

シーケンサーによってのみ確認された取引がまだL1に投稿されていません

現在、エクスプローラには「Sequencerによって確認済み」という明確な定義が欠けているようです。これは、「Sequencerの確認はL1上の数ブロックの確認に等しい」ということを示唆しています。これは、「Sequencerによって確認済み」であることは、取引がL1に投稿され、それに続く複数のブロックがあることを意味します。

ただし、新しく表示される取引も「シーケンサーによって確認済み」として表示され、さらに数日前の取引も、「チャレンジ期間を過ぎた」にもかかわらず、「シーケンサーによって確認済み」の状態のままです。

数日前の取引はまだ「Sequencerによって確認済み」のステータスです

読み方の注意: この状況は、エクスプローラーがさまざまな場所で異なるステータスインジケーターを表示していることが原因である可能性もあります。 ブロック番号の隣に「シーケンサーによって確認済み」と表示されている場合、そのブロックがシーケンサーによって確認されていることをユーザーに通知します。 L1以降のステータスを確認するには、「L1 State Batch」の詳細など、他の情報を参照する必要があります。

さらに、以下のスクリーンショットに示すように、L1に投稿されたトランザクションには「L1 State Batch Index」と「L1 State Root Submission Tx Hash」という2つの追加情報が含まれています。これらの詳細は、L2トランザクションが含まれるState Batchと、このState BatchがL1に投稿されたL1トランザクションを通じてどのようになされたかを表しています。

「State Batch 3480」をクリックすると、その状態は「Finalized」と表示され、それはL1（つまり、Ethereumメインネット）の「Finalized」状態に対応しています。これは、バリデータからの投票を2つのエポックで蓄積した後に達成される非常に安全な状態です。

△ State Batch 3480はL1ブロック18457449に含まれており、ブロック18457449は最終化されました。

ソース: https://etherscan.io/block/18457449

L1で投稿されたがまだ最終決定されていないバッチは、「未確定」として表示されます:

Batch 3494はL1に投稿されましたが、完了していないL1ブロックに含まれています：

Arbitrum Explorerと比較すると、Optimism Explorerはより詳細な情報（State Batch）を提供し、L1 Finality情報をL2 Explorerに直接リンクさせるため、ユーザーはL1ブロックが最終決定されたかどうかを知ることができます。ブロック確認の数に基づいて独自の判断を行う必要はありません。

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

現在、ユーザーがStarkNet上でトランザクションを送信すると、トランザクションレシートをすばやくクエリできます。ただし、レシートにはしばしばトランザクションのステータスが「RECEIVED」と表示されます。このステータスは、ノードがトランザクションを受信し、検証の後、問題がないことを確認したことを示します。トランザクションはSequencerによってL2ブロックに含まれ、実行を待っています。「RECEIVED」ステータスのトランザクションには、まだ実行の結果がありません。ユーザーは、StarkNet Explorerに表示されるトランザクションステータスを確認することで、トランザクションの進捗状況を確認できます。

Reading Tip: シーケンサがトランザクションを十分に速く処理すると、RECEIVED状態をバイパスして直接処理された状態に移行することがあります。StarkNet上のトランザクションプロセスの詳細な紹介については、以下のリンクをブラウザにコピーして公式文書を参照してください。

公式文書:StarkNet トランザクションライフサイクル

Starkscan（StarkNetエクスプローラーで見られるトランザクションは、Pre-Confirmationトランザクションも含まれています。次のトランザクションに示されているように、現在のステータスは「L2で受け入れ済み」となっており、シーケンサーによってL2ブロックにキューイングされていることを示しています。」

"L2”に受け入れられた"とは、シーケンサーによってL2ブロックにキューイングされたことを意味しますが、まだL1にアップロードされていないことを示します。

「Accepted on L2」の前の2つのステータスは、ReceivedとPendingです。「取引が受信され、検証された」と「取引がシーケンサーによって処理されている」を表しています。取引処理の実行が完了すると、「Accepted on L2」ステータスに移動します。

取引は受信され、検証されました。

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

一度トランザクションデータがL1にアップロードされると、ステータスは次のトランザクションで示されるように「L1で受け付け済み」となります。

取引データはL1にアップロードされました。

StarkNetのトランザクションには、処理の進行状況をユーザーに通知するための豊富なステータスセットがありますが、L1へのトランザクションのアップロードには数時間の待ち時間が依然として必要とされる可能性があります（おそらく、ゼロ知識証明の生成には時間がかかるため）。この間、ユーザーはシーケンサーの事前確認に依存しています。

さらに、エクスプローラーは、L1にアップロードされた取引に関しては、「L1で受け入れられました」とのみ表示します。L1の確定またはブロックの確認に関する情報は付属していません。これは、ユーザーが自分自身でL1ブロックに十分な後続ブロックがあるか、または最終処理されたかどうかを確認しなければならないことを意味します。

全体的に、StarkNetのパフォーマンスのボトルネックのため、ユーザーは長期間にわたりPre-Confirmationに依存する必要があり、エクスプローラはL1 Finality情報をサポートしておらず、トランザクション収益確認においてユーザーエクスペリエンスが不十分となっています。これはStarkNetが将来改善する必要がある領域です。

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

StakrNetと同様に、zkSyncにもPENDING状態があり、これはノードがトランザクションを受信し、トランザクションが検証された後に問題がないことを意味します。シーケンサによってL2ブロックに含まれ、実行されるのを待ちます。しかし、PENDING状態ではトランザクションは実行されません。

ユーザーは、zkSync Explorer に表示されているトランザクションの状態を通じて、取引の処理進捗状況を把握することができます。

読書のヒント：シーケンサーが十分に処理されると、PENDING状態を直接スキップして、トランザクションが処理された状態に入ることができるかもしれません。

zkSyncの取引プロセスの詳細な紹介については、以下のリンクをコピーしてブラウザで表示できます: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

zkSyncエクスプローラーで表示される取引には、スクリーンショット下に表示されている取引など、事前確認取引も含まれます。現在の状態がzkSync Era Processedであることから、SequencerによってL2ブロックにキューイングされたことが示されています。

このトランザクションはシーケンサーによってL2ブロックにキューイングされ、現在、L1（イーサリアム送信）にアップロードされるのを待っています

シーケンサーがL2ブロックを完了した後、そのブロックとその中のトランザクションは、それぞれが「ブロックがL1にアップロードされたこと」および「ブロックの妥当性が証明されたこと」を意味する「コミットされた」、「証明された」、「実行された」の3つの段階を経ることになります。そして、「ブロック内のトランザクションが実行された後、L2の状態がL1に更新される」ことになります。以下は、異なる段階にある3つのブロックとトランザクションが示されています。

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

バッチ292700の取引の現在のステータスが、イーサリアムの送信からイーサリアムの検証に変わりました。これは、ゼロ知識証明による検証待ちであり、その妥当性を検証するために待機していることを示しています。

Ethereumの検証アイコンに矢印を動かすと、異なる段階が表示され、前段階（送信）の取引リンクも添付されます。

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

Batch 292000の有効性が証明されたため、それは証明段階に入ります：

バッチが証明されると、それは証明された状態に入り、証明アクションを実行するためのトランザクションリンクが添付されます。

中の取引も、“検証”から“実行”の段階に入り、実行を待っています。

バッチが証明されると、その後、トランザクションを実行し、L1に記録されたL2のステータスを更新するまでの待機期間（公式文書によると約21時間かかるとされています）に入ります。これは、まだアルファステージにある保護措置のためであり、バグが発生した際に適切な対応が取れるようにするためのものです。バッチが実行されると、最終的に実行されたフェーズに入ります。

Batchが実行された後、最終的に実行された状態に入り、Executeアクションを実行するための取引リンクが添付されます。

バッチ内のトランザクションステータスも「実行済」に更新されます。レイヤー 2 (L2) からレイヤー 1 (L1) までを 1 つのステップで完了する StarkNet トランザクションとは異なり、zkSync は L2 から L1 までのトランザクションのプロセスを、コミット→実証済み→実行の 3 つのより詳細な段階に分割します。これにより、保護措置としてトランザクションプロセス全体が約1日に延長されますが、コミット済みステータスにより、ユーザーはシーケンサーへの信頼に継続的に依存することなく、トランザクションが含まれているかどうかをすばやく知ることができます(トランザクションがコミットされたステージに入ると、単なる事前確認ではなくなります)。さらに、zkSync Explorerは、さまざまな段階の包括的で完全なデータ表示を提供し、誰でもトランザクションの最新のステータスを把握し、各段階の移行(コミットから実証済み、実証済みから実行済みなど)でのトランザクションの実行を個人的に確認することもできます。ただし、アルファ段階での保護対策として、zkSync シーケンサーは履歴レコードを変更できることに注意することが重要です。これは、トランザクションが Pre-Confirmation から Committed ステージにすぐに移行できる場合でも、Sequencer は Executed ステージに到達するまで履歴レコードからユーザー トランザクションを削除できることを示しています。そのため、ユーザーは最大で 1 日シーケンサーを信頼する必要があります。

Layer 1は事前確認もサポートできます

誰がブロックを生成するかが事前にわかっている場合、L1は事前確認もサポートできます。イーサリアムを例にとると、実際のブロックプロデューサーはビルダーであり、ビルダーは事前確認サービスを提供し、ユーザーにトランザクションの包含を保証することができます。しかし、ビルダーは必ずしも特定のブロックを生産する権利を持っているわけではなく、各ブロックを生産する権利を入札しなければならないため、事前確認の効果が弱くなる可能性があります。さらに、ビルダーの競争力を考慮する必要があります。ビルダーの競争力が十分でない場合、ブロックを製造する権利を確保することは困難であり、事前確認サービスの信頼性が大幅に低下します。これらの問題を回避するには、通常、どの提案者がどのブロックを提案するかがあらかじめ決められており、確実であるため、提案者が事前確認サービスを提供できるようにするのがより良いアプローチです。しかし、現在のPBSアーキテクチャでは、提案者はブロックの提案のみを行い、実際のブロック生成やコンテンツの意思決定はビルダーが行うため、提案者はブロックに直接トランザクションを挿入したり、ビルダーに要求したりすることはできません。将来、PBSアーキテクチャが変更された場合、たとえば、インクルージョンリストを追加したり、提案者がブロック生成に参加できるようにしたりした場合、提案者は事前確認サービスを提供する機会を持つ可能性があります。PBSの詳細については、提供されているリンクをご覧ください。

Pre-Confirmationの改善:

Pre-Confirmationは、BuildersまたはL2 Sequencersによる単なる口頭の約束であり、その約束を果たす義務や非履行のためのペナルティメカニズムはありません。ただし、スマートコントラクトを使用してBuildersまたはSequencersを標準化することで、この約束をより信頼性のあるものにすることが可能です。彼らはスマートコントラクトに保証金を預けながらPre-Confirmationサービスを提供し、取引の含有を約束する際に内容に署名することができます。ユーザーがBuildersまたはSequencersが約束を果たしていないことを見つけた場合、約束内容と署名をスマートコントラクトに提出し、その約束が守られているかどうかを検証することができます。前述の契約の適用シナリオはまだ概念実証段階にありますが、以下のリンクはそのような契約の適用例のプレゼンテーションビデオを示しています。

概要:

L1 トランザクションが L1 ブロックに含まれると、再編成の確率は低下し、トランザクションの包含に対するユーザーの信頼度は徐々に高まります。L2 トランザクションには、L1 トランザクションと比較して、「L2 トランザクションは L2 ブロックに含まれ、L1 へのアップロードを待機する」という追加のワークフローがあります。ただし、この段階ではデータが L1 にアップロードされていないため、差異の可能性が残るため、この段階でユーザーがトランザクションの包含について得ることができる保証は、事前確認または高速確認/ソフト確認と呼ばれるシーケンサーからの口頭でのコミットメントです。Sequencer が悪意のあるものであったり、単にバグに遭遇したりした場合、Sequencer の Promise が破られ、ユーザーの L2 トランザクションの確認が欠如する可能性があります。現在、ほとんどのL2は、Arbitrum/OptimismのConfirmed by SequencerやStarkNetのAccepted on L2など、事前確認ステータスを含むトランザクションステータスをExplorerに表示しています。このような情報を見るときは、提供されるトランザクション包含保証の時間効果に注意を払うことが重要です。シーケンサーの事前確認に頼りたくない場合は、L1 にアップロードされる L2 データに関する L2 Explorer の情報を確認する必要があります。事前確認は、シーケンサーが約束を破った場合にスマートコントラクトを通じてペナルティを課すなど、経済的なインセンティブメカニズムを組み込むことができ、ユーザーにより明確な保護を提供します。以下の表は、トランザクション プロセスのさまざまな段階で L1 および L2 トランザクションによって提供されるトランザクション インクルージョンの保証と対応するリスク シナリオを示しています。

免責事項：

1. この記事は[から転載されていますaicoin]. All copyrights belong to the original author [Foresight News]. If there are objections to this reprint, please contact the Gate Learnチームはすぐに対処します。
2. 責任の免除: この記事で表現されている意見は著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learnチームによって他の言語に行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。