Optimism Explorer に表示されるトランザクションには、事前確認トランザクション、つまり L1 にまだアップロードされていないトランザクションも含まれます。 次の図に示すように、ブロック番号111526300の横に [Confirmed by Sequencer] 記号があることがわかります。
しかし、ExplorerにはConfirmed by Sequencerが何を意味するのか明確な仕様がないようで、「Sequencer confirmations are equivalent to a few block confirmations on L1.」と表示され、Confirmed by SequencerはL1にアップロードされ、その後にいくつかのブロックが続いていることを示しています。
しかし、実際には、最新のトランザクションも Confirmed by Sequencer と表示され、数十日前でも、チャレンジ期間を過ぎたトランザクションのステータスは Confirmed by Sequencer のままです。
数十日前、トランザクションのステータスは「Confirmed by Sequencer」のままでした
読み方のヒント: 上記の状況では、Explorer がさまざまな場所で異なる状態をマークしている場合もあります: ブロック番号の後の Confirmed By Sequencer は、ブロックがシーケンサーによって確認されたことをユーザーに通知し、ユーザーは L1 にアップロードした後、後述の「L1 State Batch」情報などの他の情報を使用して状態を確認する必要があります。
さらに、以下のスクリーンショットに示すように、L1 にアップロードされたトランザクションには、「L1 State Batch Index」と「L1 State Root Submission Tx Hash」の 2 つの追加情報があります。 次の 2 つの情報は、L2 トランザクションが含まれた状態バッチと、状態バッチが L1 にアップロードされた L1 トランザクションを表します。
この約束をより確実にすることは可能ですか? 実際、ブロックの作成責任者と彼の約束の内容(例:「1,350,000ブロックで収益トランザクション」)は、条件チェックとして記述できるためです。 したがって、スマートコントラクトを使用してビルダーまたはシーケンサーを規制し、スマートコントラクトで預金を担保する際に事前確認サービスの提供を依頼し、取引収入の約束を与えるときにコンテンツに署名し、ユーザーがビルダーまたはシーケンサーがコミットメントを履行していないことに気付いた場合、約束されたコンテンツと相手の署名をスマートコントラクトに送信し、スマートコントラクトはコミットメントが履行されたかどうかを確認できます(「最初の 1,350,000 Block Revenue for this transaction」を参照してください。
L2トランザクション実装の全プロセスを解釈する:各段階のセキュリティパフォーマンスは?
著者: Nic@ imToken Labs
L2トランザクションがブロックに含まれることを確信できるのはいつですか? L2 トランザクションからの収益が再編成によって破棄されないのはいつですか?
本記事では、L2トランザクション実装の全プロセスを紹介し、トランザクションプロセスの各段階のセキュリティパフォーマンスを分析します。
前提 条件：
L1 トランザクションの詳細
トランザクション プロセス
L1 トランザクション フローの図
再編成はトランザクション収入ブロック後も可能であり、トランザクションが完了したと確信するには、再編成が発生する可能性が低いまで待つ必要があります。
再編成の確率とコストは、チェーンのコンセンサスアルゴリズムと資産の時価総額によって異なりますが、ここでは再編成コストの計算は紹介しません。
L2 トランザクションについて学ぶ
トランザクション プロセス
L2 ユーザーがトランザクションを生成して署名すると、通常、トランザクションのソートを担当するシーケンサーに直接送信され、シーケンサーはトランザクションを L2 ブロックに収集します。 その後、Sequencer が L1 トランザクションを介して L2 ブロック データを L1 に書き戻すと、ユーザーはトランザクションが最新の L2 ブロックに含まれていることを確認できます。
ただし、L2ブロックのデータはL1トランザクションを介してL1にアップロードされるため、L1 Re-orgが発生し、L2ブロックが最終的にブロックチェーンの履歴に書き込まれない、つまりL2 Re-orgと同等になるという状況が発生する可能性があるため、ユーザーは、L1 Re-orgの確率が十分に低くなり、トランザクションがブロックチェーンの履歴に書き込まれることを確認する必要があることに注意してください。
L2のトランザクションフローの図
ユーザーは、最初にトランザクションが L2 ブロックに含まれるのを待ち、次に L1 トランザクションを介して L2 ブロックが L1 にアップロードされるのを待ち、最後に L1 トランザクションがファイナライズされるのを待ちます。
L1トランザクションと比較すると、L2トランザクションは、SequencerによってL2トランザクションがL2ブロックに含まれるのを待つ時間が長くなりますが、実際には、L2ブロックサイズが十分に大きく、ブロック生成速度が十分に速い場合、待ち時間は主にL1トランザクションを収益の認識に費やすため、この待ち時間はそれほど時間はかかりません。
しかし、ユーザーがいくらかの犠牲を払っても構わないと思っているなら、それをより良い体験と交換することはできるのでしょうか?
事前確認/高速確認/ソフト確認
ユーザーは、L2 ブロック (L2 トランザクションを含む) が L1 ブロックに含まれていることを確認し、再編成が発生する確率が十分に低くなり、L2 トランザクションが獲得されたと信じられるまで待つ必要があります。
しかし、ユーザーが Sequencer を信頼したい場合はどうすればよいでしょうか。 Sequencer は L2 開発チームによって運営され、評判の良い組織によって運営されており、Sequencer が X 番目のブロックでトランザクションがすぐに支払われることをユーザーに保証する場合、この保証は Sequencer を信頼する意思のあるユーザーにとって十分です。 ユーザーが使用しているウォレットを信頼している場合と同様に、ウォレットがトランザクションが支払われたことを警告した後、不審に思ってEtherscanに行って再確認することはありません。
このシーケンサーが提供する取引収益保証は、事前確認、高速確認、またはソフト確認と呼ばれ、「早期」または「ソフト」取引収益保証として理解できます。 L2トランザクションがL1ブロックに含まれるのを待つ必要はありませんが、Sequencerが口頭で与える約束に過ぎず、Sequencerがバグや悪意あるSequencerが直接約束に違反して元の約束を忘れてしまうことがあり、ユーザーの時間を浪費したり、「二重支払い攻撃」になったりする可能性があります。
次に、L2トランザクションの収益ステータスを表示するさまざまな方法をいくつか紹介します。
Arbitrum/Optimismの取引収益状況
現在、ArbitrumまたはOptimismでトランザクションを送信したユーザーは、トランザクション実行の結果であるトランザクションレシートをほぼ即座に取得できます。 つまり、Sequencer は既にトランザクションの実行をローカルで順序付けしてシミュレートしており、このトランザクション レシートはユーザーの事前確認です。
Arbitrumでのトランザクション収益ステータスの確認
Arbitrum Explorer に表示されるトランザクションには、事前確認トランザクション、つまり L1 にまだアップロードされていないトランザクションが含まれます。次の図に示すように、[Block Number] 145353000の横に [Confirmed by Sequencer] インジケータがあることがわかります。
上の画像は、Sequencer によって確認されただけで、まだ L1 にアップロードされていないトランザクションを示しています
次の図に示すように、トランザクションが L1 にアップロードされた場合、そのステータスは 69 L1 Block Confirmations に変わり、L1 にアップロードされ、トランザクション データ ブロックが含まれ、その背後に 69 ブロックがあることを意味します。
このトランザクションデータを含むL1ブロックの背後には、すでに69個のブロックがあり、それに続くブロックが多いほど、安全性が高くなります。
または、下のスクリーンショットに示されているトランザクションでは、このトランザクションデータを含むL1ブロックの背後には6174ブロックがあり、すでに非常に安全です。
しかし、ここで改善できるのは、L1ファイナリティ情報を組み合わせることです。
L1 ブロック確認の数をユーザに伝えるだけでは、ユーザはそのような数のブロック確認によって表されるセキュリティ レベルを理解して計算する必要があるため、ユーザへの支援は限られています。 また、レイヤー1(イーサリアム)にはすでにCasper FFGなどのファイナリティメカニズムがあるため、エクスプローラーはレイヤー1ブロックが現在レイヤー1でファイナライズされているかどうかを直接示すことができます。 現在、Optimismのエクスプローラーにはそのような機能が実装されています。
楽観主義で取引の収益状況を確認する
Optimism Explorer に表示されるトランザクションには、事前確認トランザクション、つまり L1 にまだアップロードされていないトランザクションも含まれます。 次の図に示すように、ブロック番号111526300の横に [Confirmed by Sequencer] 記号があることがわかります。
Sequencer によって確認されただけで、まだ L1 にアップロードされていないトランザクション
しかし、ExplorerにはConfirmed by Sequencerが何を意味するのか明確な仕様がないようで、「Sequencer confirmations are equivalent to a few block confirmations on L1.」と表示され、Confirmed by SequencerはL1にアップロードされ、その後にいくつかのブロックが続いていることを示しています。
しかし、実際には、最新のトランザクションも Confirmed by Sequencer と表示され、数十日前でも、チャレンジ期間を過ぎたトランザクションのステータスは Confirmed by Sequencer のままです。
数十日前、トランザクションのステータスは「Confirmed by Sequencer」のままでした
読み方のヒント: 上記の状況では、Explorer がさまざまな場所で異なる状態をマークしている場合もあります: ブロック番号の後の Confirmed By Sequencer は、ブロックがシーケンサーによって確認されたことをユーザーに通知し、ユーザーは L1 にアップロードした後、後述の「L1 State Batch」情報などの他の情報を使用して状態を確認する必要があります。
さらに、以下のスクリーンショットに示すように、L1 にアップロードされたトランザクションには、「L1 State Batch Index」と「L1 State Root Submission Tx Hash」の 2 つの追加情報があります。 次の 2 つの情報は、L2 トランザクションが含まれた状態バッチと、状態バッチが L1 にアップロードされた L1 トランザクションを表します。
「3480」ステートバッチをクリックすると、そのステートがFinalizedであり、これはL1(つまりEthereum Mainnet)のFinalizedステートに対応しており、2つのEpochバリデーターの投票を正常に蓄積した非常に安全なステートであることがわかります。
△ L1ブロック18457449でステートバッチ3480を取得し、ブロック18457449が確定しました。
ソース：
バッチがアップロードされているが、L1 でファイナライズされていない場合は、Unfinalized: と表示されます。
状態バッチ 3494 は L1 にアップロードされていますが、バッチに含まれる L1 ブロックはまだファイナライズされていません。
Arbitrum Explorerと比較して、Optimism Explorerはトランザクションにより多くの情報(State Batch)を提供し、L1ファイナリティ情報をL2 Explorerに直接文字列化するため、ユーザーはブロック確認の数に対応するセキュリティの程度を判断するのではなく、L1ブロックがファイナライズされたかどうかを直接知ることができます。
StarkNetのトレーディング収益状況
現状では、ユーザーがStarkNetでトランザクションを送信した後、トランザクションのレシートを迅速に照会できますが、レシートに表示されるトランザクションステータスは、通常、ノードがトランザクションを受信し、トランザクションの検証後に問題がないことを意味し、Sequencer L2 Blockがトランザクションを受信して実行されるのを待ち、RECEIVED状態のトランザクションにはトランザクションの実行結果がありません。 ユーザーは、StarkNet Explorerに表示されるトランザクションステータスを通じて、トランザクションの進行状況を確認できます。
読み方のヒント: Sequencer の処理速度が十分に速い場合は、RECEIVED 状態をスキップして、トランザクションが既に処理されている状態に進むことができます。 StarkNetの取引プロセスの詳細については、以下のリンクをコピーして、ブラウザで公式ドキュメントを表示できます。
StarkNet Explorer である Starkscan に表示されるトランザクションには、次の図に示すように、事前確認トランザクションも含まれており、ステータスが現在 L2 で受け入れられていること、つまりシーケンサーによって L2 ブロックにランク付けされていることがわかります。
「Accepted on L2」は、シーケンサーによって L2 ブロックに配置されているが、まだ L1 にアップロードされていないことを意味します
L2 での Accepted の最初の 2 つの状態は Received と Pending で、これは “トランザクションが受信され、検証されました” と “トランザクションは Sequencer によって処理されています” を意味し、トランザクションの実行後にトランザクションは L2 で Accepted の状態になります。
トランザクションが受信され、検証されます
トランザクションは Sequencer によって処理されています
トランザクション データが L1 にアップロードされると、次の図に示すように、ステータスが L1 で [承認済み] に変わります。
トランザクション データが L1 にアップロードされました
StarkNetのトランザクションは、ユーザーがトランザクションの進行状況を知ることができるリッチな状態ですが、トランザクションがL1にアップロードされるまでに4〜5時間かかる場合があるため(おそらくゼロ知識証明の生成に時間がかかるため)、この間のユーザーはシーケンサーの事前確認に依存しています。
また、エクスプローラーはL1にアップロードされたトランザクションについてのみL1でAcceptedと表示され、L1でのファイナリティやブロック確認の情報がないため、ユーザーはL1ブロックに十分なブロックがあるか、ファイナライズされているかどうかを確認する必要があります。
全体として、StarkNet自体のパフォーマンスのボトルネックにより、ユーザーは事前確認に長期間依存する必要があり、ExplorerはL1ファイナリティ情報をサポートしていないため、StarkNetトランザクション収益認識のエクスペリエンスが低下し、StarkNetは将来的に改善する必要があります。
zkSyncのトランザクション収益状況
StakrNetと同様に、zkSyncもPENDING状態であり、Nodeがトランザクションを受信し、トランザクションが問題なく検証されたことを意味し、トランザクションがブロックされてSequencer L2によって実行されるのを待ちますが、PENDING状態のトランザクションはトランザクションの実行結果を持ちません。
ユーザーは、zkSync Explorerに表示されるトランザクションステータスを通じて、トランザクションの進行状況を知ることができます。
読み方のヒント: シーケンサーの処理速度が十分であれば、PENDING 状態をスキップして、トランザクションが既に処理されている状態に移行することができます。
zkSync Explorerに表示されるトランザクションには、以下のスクリーンショットのような事前確認トランザクションも含まれており、ステータスは現在zkSync Era Processedであり、シーケンサーによってL2ブロックにランク付けされていることがわかります。
このトランザクションはシーケンサーによってL2ブロックに配置され、現在L1(イーサリアム送信)にアップロードされるのを待っています
Sequencer が L2 ブロックを作成した後、ブロックとその中のトランザクションは、Committed、Proven、uted の 3 つのフェーズを順番に通過し、「ブロックが L1 にアップロードされた」、「ブロックの有効性が証明された」、「ブロック トランザクションが実行された後、L2 ステータスが L1 に更新された」ことを示します。 異なる段階でのブロックとトランザクションを以下に示します。
バッチ 292700 は L1 にアップロードされ、コミット済みフェーズにあります。 ソース：
バッチ 292700 のトランザクションの現在の状態は、Ethereum Sending から Ethereum Validating に変更され、ゼロ知識証明による検証を待っていることを示しています。
イーサリアム検証アイコンの上に矢印を移動すると、さまざまなステージも表示され、前のステージ(送信)のトランザクションリンクも添付されます。
このトランザクションは「検証中」ステージに入り、前のステージ(送信中)でバッチをL1にアップロードしたトランザクションへのリンクもここで確認できます。
バッチ 292000 の有効性が証明されたので、実証済みフェーズに入ります。
バッチが証明されると、Prove アクションを実行するトランザクションへのリンクを含む Proven 状態になります。
また、トランザクションは「validating」から「uting」、つまり実行を待機します。
バッチが証明されると、内部のトランザクションが実行され、L1に記録されたL2の状態が更新されるまでの待機期間(公式文書では約21時間)に入ります。 これは主に、発生したバグに対応するのに十分な時間を確保するためにアルファフェーズで追加されたセーフガードによるものです。 バッチが実行されると、最終フェーズに入ります。
バッチが実行されると、バッチは、uteアクションを実行するトランザクションリンクを使用して、最終的なuted状態になります。
Batch のトランザクション ステータスも “uted” に更新されました
L2 から L1 へのトランザクションが 1 つのステップで完了する StarkNet とは対照的に、zkSync の L2 から L1 への移行プロセスは、コミット→実証済み→ uted の 3 つのより詳細な段階に分かれています。
セーフガードとしてトランザクション プロセス全体が約 1 日程度に延長されますが、コミット済み状態により、ユーザーはトランザクションが獲得されたかどうかをすばやく知ることができます (トランザクションがコミットされると、単なる事前確認ではなくなります)。
さらに、zkSync Explorerは、さまざまなステージの豊富で完全なデータ表示を提供するため、誰でもエクスプローラーを介してトランザクションの最新ステータスを把握でき、各ステージの移行(コミットから実証済み、実証済みから実証済みなど)のトランザクションの実行を個人的に確認することもできます。
ただし、アルファフェーズの保護対策として、この時点ではzkSync Sequencerで履歴を変更できることに注意が必要です。
これは、トランザクションが事前確認からコミットされたフェーズにすばやく移行できる場合でも、Sequencer は、トランザクションが統合フェーズに入る前に、実際には履歴からユーザー トランザクションを削除できることを示唆しています。 そのため、コンシューマーは最大 1 日間 Sequencer を信頼する必要があります。
L1 は事前確認もサポートできます
誰がブロックを生成するかを事前に知ることができれば、L1は事前確認もサポートできます。
イーサリアムを例にとると、実際にブロックを生成するのはビルダーであり、ビルダーはユーザーに取引収入を保証する事前確認サービスを提供することができます。 しかし、ビルダーは必ずしも特定のアウトプットと特定のブロックに対する権利を取得するわけではなく、各ブロックのアウトプットに対する権利を入札しなければならないため、この事前確認の有効性は比較的低く、ビルダーの強さを考慮する必要があります。 サービスは大幅に損なわれます。
上記のような問題を避けたいのであれば、「どの提案者が最初のブロックを提案するか」は、通常、事前に計算された決定論的な状況であるため、提案者に事前確認サービスを提供してもらうのが良いでしょう。
しかし、現在のPBSアーキテクチャでは、ProposerはBlockの役割を提案するだけで、実際にBlockを作成してブロックの内容を決定する役割はBuilderであるため、Proposerは直接ブロックにトランザクションを詰め込んだり、Builderにトランザクションを詰めるように依頼したりすることはできません。 インクルージョンリストの追加や提案者のブロック生成への参加の許可など、PBSアーキテクチャが将来変更された場合、提案者は事前確認サービスを提供する機会があります。
事前確認の改善
事前確認は、ビルダーまたはL2シーケンサーによる口頭での約束にすぎず、相手方は約束を履行する義務を負わず、不履行に対するペナルティメカニズムはありません。
この約束をより確実にすることは可能ですか? 実際、ブロックの作成責任者と彼の約束の内容(例:「1,350,000ブロックで収益トランザクション」)は、条件チェックとして記述できるためです。 したがって、スマートコントラクトを使用してビルダーまたはシーケンサーを規制し、スマートコントラクトで預金を担保する際に事前確認サービスの提供を依頼し、取引収入の約束を与えるときにコンテンツに署名し、ユーザーがビルダーまたはシーケンサーがコミットメントを履行していないことに気付いた場合、約束されたコンテンツと相手の署名をスマートコントラクトに送信し、スマートコントラクトはコミットメントが履行されたかどうかを確認できます(「最初の 1,350,000 Block Revenue for this transaction」を参照してください。
上記契約の適用シナリオはまだ概念実証の段階ですが、以下のリンクに示されているプレゼンテーションビデオは、契約申請の一例を示していますので、以下のリンクをコピーして、ブラウザで詳細を確認してください。
まとめ
以下の表は、取引プロセスのさまざまな段階でのL1取引とL2取引によって提供される取引収益保証と対応するリスクシナリオを示しています。