L2取引の収益認識における異なるフェーズを解説する

2024.01.03

共有先

TechFlow厳選深潮セレクト

L2取引の収益認識における異なるフェーズを解説する

L2取引の実装における全プロセスを紹介し、取引プロセスの各段階におけるセキュリティ性能を分析する。

2024.01.03 - 11:27:07

Web3業界の深掘り報道に専念し潮流を洞察

L2取引の実装における全プロセスを紹介し、取引プロセスの各段階におけるセキュリティ性能を分析する。

執筆：Nic @imToken Labs

いつ、L2（Layer2）のトランザクションがブロックに含まれることが確実になるのでしょうか？また、L2のトランザクションによる収益がRe-orgによって取り消されることがないという確信は、いつ持てるのでしょうか？

本稿では、L2トランザクションの実現プロセス全般を読者に紹介し、各段階における安全性について分析します。

前提知識：

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

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

トランザクションの流れ

ユーザーがトランザクションを作成して署名すると、それがP2Pネットワーク上に送信され、PoWコンセンサス下のMinerまたはPoSコンセンサス下のProposerによってブロックに取り込まれるのを待ちます。ユーザーが自分のトランザクションが最新のブロックに含まれたことを確認しても、それがそのブロックチェーンの履歴に完全に記録されるとは限りません。なぜなら、「Re-org」と呼ばれる状況によりブロックチェーンが再編成される可能性があるためです。したがって、ユーザーは一定時間待つ必要があり、特定のブロックに対するRe-orgの発生確率が十分に低くなった時点で、ようやくトランザクションが確定（Finalized）されたと確信できます。

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

トランザクションがブロックに取り込まれた後でもRe-orgが発生する可能性があり、Re-orgがほとんど起こり得ないと判断できるまで待つことで、トランザクションが最終的に確定したと確信できます。

Re-orgの確率とコストは、チェーンのコンセンサスアルゴリズムや資産の時価総額によって異なりますが、ここではRe-orgのコスト計算方法には触れません。

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

トランザクションの流れ

L2のユーザーがトランザクションを作成して署名すると、通常は直ちにトランザクションの順序付けを行うSequencerに送られます。SequencerがそのトランザクションをL2ブロックに取り込みます。その後、SequencerがL2ブロックのデータをL1上のトランザクションとしてL1に書き戻すと、ユーザーは自分のトランザクションが最新のL2ブロックに含まれていることを確認できます。

ただし注意すべき点は、L2ブロックのデータはL1のトランザクション経由でL1にアップロードされるため、L1側でRe-orgが発生し、そのL2ブロックが最終的にブロックチェーンの履歴に記録されない可能性があります。これはいわゆるL2 Re-orgに相当します。したがって、ユーザーはL1のRe-orgが発生する確率が十分に低くなるまで待つ必要があります。その時点になって初めて、自分のトランザクションがブロックチェーンの履歴に確実に記録されると確信できます。

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

ユーザーはまず、トランザクションがL2ブロックに取り込まれるのを待ち、次にL2ブロックのデータがL1トランザクション経由でL1にアップロードされるのを待ち、最後にL1トランザクションが確定するのを待ちます。

L1トランザクションと比較して、L2トランザクションには「SequencerがL2ブロックに取り込む」までの時間が追加されますが、L2ブロックの容量が大きく、生成速度が速ければ、この待ち時間はごく短くなります。実際の待ち時間の大半はL1トランザクションの取り込み確認にかかっています。全体としては、L1とL2の使用体験は似ています。

しかし、ユーザーがある程度の妥協をするならば、より良い体験を得ることは可能でしょうか？

Pre-Confirmation / Fast Confirmation / Soft Confirmation

ユーザーは、（L2トランザクションを含む）L2ブロックがL1ブロックに取り込まれたことを実際に目で確認し、さらにRe-orgの発生確率が十分に低くなるまで待つ必要があります。それによって初めて、L2トランザクションが確定したと信じることができます。

しかし、ユーザーがSequencerを信用することにすればどうでしょうか？SequencerがL2開発チームや有名な機関によって運営されている場合、Sequencerがユーザーのトランザクションを受け取った時点で「すぐに取り込まれる」「X番目のブロックで取り込まれる」と保証すれば、それを信用するユーザーにとってはその保証で十分かもしれません。まるでユーザーが使用しているウォレットを信用している場合、ウォレットがトランザクションを取り込んだと通知した後に、Etherscanで何度も確認しないのと同じです。

このようなSequencerによる取り込み保証は、Pre-Confirmation、Fast Confirmation、Soft Confirmationと呼ばれます。これらは「事前の」「ソフトな」取り込み保証と理解できます。L2トランザクションがL1ブロックに取り込まれるのを待つ必要はありませんが、Sequencerの口頭的な約束にすぎず、バグによりSequencerが約束を忘れたり、悪意のあるSequencerが約束を破ることもあります。軽ければユーザーの時間を無駄にし、重ければ「二重支出攻撃」の被害に遭う可能性があります。

以下では、いくつかの異なるL2トランザクション取り込み状態の表示方法を紹介します。

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

現在、ユーザーがArbitrumやOptimism上でトランザクションを送信すると、ほぼ即座にトランザクションレシート（Transaction Receipt）を受け取ります。これはトランザクションの実行結果を示しています。つまり、Sequencerがローカルでトランザクションを並べ替え、シミュレーション実行済みであることを意味します。このトランザクションレシートは、ユーザーへのPre-Confirmationとなります。

Arbitrumの詳細なトランザクションライフサイクルについては、以下のリンクをブラウザにコピーして公式ドキュメントを参照してください：
https://docs.arbitrum.io/tx-lifecycle
Optimismの詳細なトランザクションライフサイクルについては、以下のリンクをブラウザにコピーして公式ドキュメントを参照してください：
https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Arbitrum でのトランザクション取り込み状態の確認

Arbitrum Explorerで表示されるトランザクションには、L1にアップロードされていないPre-Confirmation状態のトランザクションも含まれます。下図のトランザクションのように、Block Number 145353000の横に「Confirmed by Sequencer」というラベルが付いています。

上図：Sequencerによってのみ確認され、まだL1にアップロードされていないトランザクション

下図のように、すでにL1にアップロードされたトランザクションの場合、ステータスは「69 L1 Block Confirmations」となります。これは、L1にアップロードされ、そのトランザクションデータを含むL1ブロックの後に69個のブロックが生成されたことを意味します。

該当L1ブロックの後ろに69個のブロックが接続されています。多いほど安全です。

あるいは、下図のトランザクションのように、該当トランザクションデータを含むL1ブロックの後ろにはすでに6174個のブロックが生成されており、非常に安全です。

しかし、ここで改善できる点として、L1の確定性（Finality）情報を組み合わせて表示することが挙げられます。

単に「何個のL1ブロック確認があるか」をユーザーに伝えるだけでは限界があります。ユーザーはその数値がどの程度の安全性を意味するのかを自分で理解・計算しなければなりません。一方、L1（つまりEthereum）はCasper FFGという確定性メカニズムを持っているため、Explorerは直接「対象のL1ブロックが既にFinalizedされたか」を表示できます。現在、OptimismのExplorerはすでにこの機能を実装しています。

Optimism でのトランザクション取り込み状態の確認

Optimism Explorerで表示されるトランザクションも、L1にアップロードされていないPre-Confirmation状態のトランザクションを含んでいます。下図のトランザクションのように、Block Number 111526300の横に「Confirmed by Sequencer」というラベルが付いています。

Sequencerによってのみ確認され、まだL1にアップロードされていないトランザクション

ただし、現在のExplorerでは「Confirmed by Sequencer」の正確な意味が明確に定義されていません。「Sequencer confirmations are equivalent to a few block confirmations on L1.」と説明しており、これは「L1にアップロードされ、数個のブロックが後続している」ことを意味しているように見えます。

しかし、最新のトランザクションも同様に「Confirmed by Sequencer」と表示されます。数十日前にチャレンジ期間も終了したトランザクションのステータスも依然として「Confirmed by Sequencer」です。

数十日前のトランザクションも「Confirmed by Sequencer」のまま

参考： 上記の状況は、Explorerが異なるステータスを別々の場所に表示している可能性もあります。Block Numberの後の「Confirmed by Sequencer」は「そのブロックがSequencerによって確認された」ことを示しており、L1へのアップロード後のステータスは、以下の「L1 State Batch」などの情報からユーザー自身が確認する必要があります。

また、下図のようにL1にアップロードされたトランザクションには、「L1 State Batch Index」と「L1 State Root Submission Tx Hash」という2つの追加情報があります。これらは、そのL2トランザクションがどのState Batchに含まれているか、そしてそのState BatchがどのL1トランザクションでL1にアップロードされたかを示しています。

「3480」というState Batchをクリックすると、そのステータスがFinalizedであることがわかります。この「Finalized」はL1（Ethereumメインネット）のFinalized状態に対応しており、2つのEpochの検証者投票が完了した非常に安全な状態です。

△ State Batch 3480はL1 Block 18457449で取り込まれており、このブロックはすでにFinalizedされています。

出典：https://etherscan.io/block/18457449

L1にアップロードされたが、まだL1でFinalizedされていないBatchはUnfinalizedと表示されます。

State Batch 3494はL1にアップロードされていますが、それを取り込んだL1ブロックはまだFinalizedされていません。

Arbitrum Explorerと比較して、Optimism Explorerはより多くの情報（State Batch）を提供しており、L1のFinality情報を直接L2 Explorerに統合することで、ユーザーがL1ブロックがFinalizedされたかどうかを自ら判断する必要なく、直感的に理解できます。

StarkNet のトランザクション取り込み状態

現在、ユーザーがStarkNetでトランザクションを送信すると、すぐにトランザクションレシートを照会できますが、レシートに表示されるステータスは通常「RECEIVED」です。これはノードがトランザクションを受け取り、検証に問題がないことを意味し、SequencerによってL2ブロックに取り込まれて実行されるのを待っている状態です。この「RECEIVED」状態のトランザクションには、まだ実行結果は反映されません。ユーザーはStarkNet Explorerに表示されるステータスで処理進捗を確認できます。

参考： Sequencerの処理が十分に速ければ、「RECEIVED」状態をスキップして、直接処理済み状態に移行する可能性があります。StarkNetの詳細なトランザクションフローについては、以下のリンクをブラウザにコピーして公式ドキュメントを参照してください。

公式ドキュメント：https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

StarkscanというStarkNet Explorerで表示されるトランザクションにも、Pre-Confirmation状態のトランザクションが含まれます。下図のトランザクションのように、Statusが「Accepted on L2」となっており、SequencerによってL2ブロックに取り込まれたことを示しています。

「Accepted on L2」はSequencerによってL2ブロックに取り込まれたが、まだL1にアップロードされていないことを意味する

「Accepted on L2」の前の2つのステータスは「Received」と「Pending」で、「トランザクション受信済み・検証済み」と「Sequencerが処理中」を意味します。処理が完了すると「Accepted on L2」になります。

トランザクションが受信され、検証済み

トランザクションがSequencerによって処理中

トランザクションデータがL1にアップロードされると、ステータスは「Accepted on L1」に変わります。下図のトランザクションをご覧ください。

トランザクションデータがL1にアップロード済み

StarkNetのトランザクションは豊富なステータスを持ち、ユーザーは処理進捗を把握できますが、L1へのアップロードまでに4〜5時間かかることがあります（ゼロ知識証明の生成に時間がかかるため）。この間、ユーザーはSequencerのPre-Confirmationに依存せざるを得ません。

また、ExplorerはL1にアップロードされたトランザクションについても「Accepted on L1」のみを表示し、L1のFinalityやブロック確認数の情報を併記していないため、ユーザーは自らL1ブロックが十分に深いか、Finalizedされているかを確認する必要があります。

総じて、StarkNetのパフォーマンスボトルネックによりユーザーが長時間Pre-Confirmationに依存せざるを得ず、かつExplorerがL1 Finality情報をサポートしていないため、StarkNetのトランザクション確認体験は劣っており、今後の改善点です。

zkSync のトランザクション取り込み状態

StarkNetと同様に、zkSyncも「PENDING」状態を持ちます。これはノードがトランザクションを受け取り、検証に問題がないことを意味し、SequencerによってL2ブロックに取り込まれて実行されるのを待っています。この状態では、実行結果はまだありません。

ユーザーはzkSync Explorerに表示されるステータスで処理進捗を確認できます。

参考： Sequencerの処理が十分に速ければ、「PENDING」状態をスキップして、直接処理済み状態に移行する可能性があります。

zkSyncの詳細なトランザクションフローについては、以下のリンクをブラウザにコピーして参照してください：
https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

zkSync Explorerで表示されるトランザクションにも、Pre-Confirmation状態のトランザクションが含まれます。下図のトランザクションのように、Statusが「zkSync Era Processed」となっており、SequencerによってL2ブロックに取り込まれたことを示しています。

このトランザクションはSequencerによってL2ブロックに取り込まれており、L1へのアップロード（Ethereum Sending）を待っている

SequencerがL2ブロックを作成した後、そのブロックと内部のトランザクションは「Committed」「Proven」「Executed」の3段階を経ます。それぞれ「ブロックがL1にアップロードされた」「ブロックの有効性が証明された」「ブロック内のトランザクション実行後のL2状態がL1に更新された」を意味します。以下に、異なる段階にあるブロックとトランザクションをそれぞれ示します。

Batch 292700 はL1にアップロードされ、「Committed」段階に入りました。出典：https://explorer.zksync.io/batch/292700

Batch 292700 内のトランザクションのステータスは「Ethereum Sending」から「Ethereum Validating」に変化。ゼロ知識証明による有効性検証待ち。

マウスを「Ethereum Validating」アイコンに合わせると、さらに細かい段階が表示され、前段階（Sending）のトランザクションリンクも表示されます。

このトランザクションは「Validating」段階に入り、前段階（Sending）のL1へのBatchアップロードトランザクションリンクも表示。

Batch 292000 の有効性が証明されたため、「Proven」段階に入りました。

Batchが証明され「Proven」状態に。Prove操作のトランザクションリンク付き。

内部のトランザクションも「Validating」から「Executing」段階に。実行待ち。

Batchが証明された後、約21時間の待機期間を経て、内部のトランザクションが実行され、L1に記録されたL2状態が更新されます。これは現在Alpha段階であるための保護措置であり、バグが発生した際に十分な対応時間を確保するためです。Batchが実行されると、最終的な「Executed」段階に入ります。

Batchが実行され、最終的な「Executed」状態に。Execute操作のトランザクションリンク付き。

Batch内のトランザクションステータスも「Executed」に更新

StarkNetではL2からL1へのプロセスが一括で行われるのに対し、zkSyncではそれを「Committed → Proven → Executed」という3つの詳細な段階に分割しています。

保護措置として、全体のプロセス時間が約1日程度に延びていますが、「Committed」状態により、ユーザーはすぐに自分のトランザクションが取り込まれたかどうかを知ることができ（Committed以降はPre-Confirmationではなくなります）、Sequencerへの信頼に長く依存する必要がありません。

また、zkSync Explorerは各段階に対して豊富で完全なデータを提供しており、誰でもExplorerを通じて最新のトランザクション状態を把握でき、各段階の遷移（例：CommittedからProven、ProvenからExecuted）を自ら検証することも可能です。

ただし注意点として、Alpha段階の保護措置として、現在のzkSync Sequencerは履歴を改変できる権限を持っています。

これは、トランザクションがPre-Confirmationを早く抜け出してCommitted段階に入ったとしても、Executed段階に入るまでは、Sequencerが履歴からユーザーのトランザクションを削除できる可能性があることを意味します。したがって、ユーザーは依然として約1日間Sequencerを信用し続ける必要があります。

L1 も Pre-Confirmation をサポート可能

ブロック生成者が誰か事前にわかれば、L1でもPre-Confirmationをサポートできます。

Ethereumを例にすると、現在実際にブロックを生成するのはBuilderであり、BuilderがPre-Confirmationサービスを提供し、ユーザーに取り込み保証を与えることができます。しかし、Builderが必ずしも特定のブロック生成権を得られるわけではなく、各ブロック生成権を競標で獲得する必要があるため、このPre-Confirmationの信頼性は低くなります。また、Builderの競争力も考慮する必要があります。もしBuilderの競争力が弱ければ、ブロック生成権を獲得しづらくなるため、そのBuilderが提供するPre-Confirmationサービスの価値も低下します。

上記の問題を回避するには、ProposerがPre-Confirmationサービスを提供するのがより良い方法です。なぜなら、「どの番号のブロックをどのProposerが提案するか」は通常予め計算されており、決定的だからです。

しかし、現在のPBSアーキテクチャでは、Proposerはブロックを提案する役割に過ぎず、実際にブロックを作成し内容を決定するのはBuilderです。そのため、Proposerは特定のトランザクションをブロックに直接挿入したり、Builderに挿入を要求したりできません。将来、PBSアーキテクチャが変更され、Inclusion Listが導入されたり、Proposerがブロック作成に参加できるようになれば、ProposerがPre-Confirmationサービスを提供する可能性が出てきます。

参考：PBSの詳細については、以下のリンクをブラウザにコピーして閲覧してください：
https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss

Pre-Confirmation の改善

Pre-ConfirmationはBuilderやL2 Sequencerの口頭的約束にすぎず、履行義務もなく、不履行に対する罰則もありません。

この約束をより確かなものにできないでしょうか？実は可能です。なぜなら、ブロック生成者とその約束内容（例：「1350000番目のブロックでこのトランザクションを取り込む」）は条件としてプログラム可能だからです。スマートコントラクトを利用して、BuilderやSequencerにPre-Confirmationサービスを提供させる際、デポジットを預けてもらい、取り込み約束をする際に内容に署名させることができます。ユーザーがBuilderやSequencerが約束を履行しなかった場合、その約束内容と相手の署名をスマートコントラクトに提出すれば、コントラクトが自動的に履行の有無を検証できます（例：「1350000番目のブロックで取り込まれたか」）。

上述のコントラクトの応用はまだ概念実証段階ですが、以下のリンクの動画でその一例が紹介されています。詳細はリンクをブラウザにコピーしてご確認ください：
https://www.youtube.com/watch?v=Uw5HxSYXwYo

まとめ

L1トランザクションがL1ブロックに取り込まれた後、Re-orgの確率は徐々に低下し、ユーザーの取り込み確信度は高まります。
L2トランザクションはL1に比べて、「L2トランザクションがL2ブロックに取り込まれ、L1にアップロードされるのを待つ」という追加の工程があります。
この追加工程では、データがまだL1にアップロードされておらず、変数が存在する可能性があるため、ユーザーが得られる取り込み保証はSequencerの口頭的約束（Pre-Confirmation / Fast Confirmation / Soft Confirmation）にとどまります。
Sequencerが悪意を持っていたり、バグが発生した場合、約束が破られ、L2トランザクションが取り込まれない可能性があります。
現在、多くのL2のExplorerはPre-Confirmation状態を表示しており、例えばArbitrum/Optimismの「Confirmed by Sequencer」、StarkNetの「Accepted on L2」などがあります。このような情報を目にした際は、その取り込み保証の有効期間に注意してください。
SequencerのPre-Confirmationを信用しない場合は、もう少し待って、L2 Explorerが提供するL1へのアップロード情報を通じて検証する必要があります。
Pre-Confirmationに経済的インセンティブを組み込むことも可能で、Sequencerが約束を破った場合、スマートコントラクトで罰則を科すことで、ユーザーにより明確な保証を与えることができます。