この記事のレビューに協力してくれた Jon Charbonneau と Conor McMenamin に感謝します。

この時点で、 確認ルールにはロールアップ自体ではなく、セキュリティがあることを知っておく必要があります。 ロールアップが「イーサリアムのセキュリティ」を継承している、または「信頼が最小限に抑えられている」と言うとき、実際には、ロールアップでは、イーサリアムの確認ルールと ほぼ 同じセキュリティを持つ確認ルールを使用できることを意味します。 ただし、ブロックエクスプローラーは、どの確認ルールを参照しているか、またはどのようなセキュリティプロパティを提供しているかの詳細に立ち入らずに、緑色のバッジを表示することに関心があります。

L2BEATでは、この問題に取り組み、誰もがアクセスできるようにしたいと考えています。 特に、二重支払い攻撃に対する最強の確認ルールであるファイナリティに注目したいと思います。

確認ルール: 一貫性と可用性

確認ルールは、特定の仮定の下で、ブロックが確認され、再編成される可能性が低いことを示すアルゴリズムです。 ブロックが確認されると、そのトランザクションに関連するアクションを実行できます。 たとえば、顧客にコーヒーを手渡したり、購入者に車を配達したりすることが含まれます。

確認ルールが異なれば、セキュリティの保証も異なります。 確認ルールのセキュリティは、一貫性と可用性で構成され、基盤となるコンセンサスアルゴリズムに大きく依存します。

• 一貫性 (安全性): 任意の 2 つのノードのビューは、ネットワーク パーティションの下で一貫性があります。
• 可用性(活性):トランザクションは、ノードのかなりの部分がプロトコルへの参加をやめた後でも、一定の時間内に台帳に含まれ続けます。

CAP定理は、ネットワークパーティションの下で一貫性を保ち、動的参加の下で利用可能なコンセンサスアルゴリズムを設計することは不可能であることを示しています:深刻なネットワークパーティションが発生した場合、ノードはブロックを生成し続けて一貫性を失うか、停止して可用性を失うかを決定することができます。ノードは、他のノードが単にオフラインであるか(動的参加)、アクティブであるが到達不能であるか(ネットワークパーティション)を区別する方法がないため、異なる動作をすることはできません。

イブは、ボブが単にオフラインなのか、それとも別のネットワークパーティションにいるのかを知ることができません。

ビットコインのようなブロックチェーンは、ナカモトのようなコンセンサスを利用して、ライブネスを支持し、ネットワーク分割中に両側がブロックを生成し続け、パーティションが解決されると最終的に再編成されますが、Cosmosチェーンのような他のチェーンは、 PBFTのようなコンセンサスを使用して、一貫性を維持するためにネットワークパーティションの下で停止します。

イーサリアムの確認ルール

イーサリアムは、 LMD GHOST アルゴリズムを使用して、ネットワークパーティションでの可用性を優先します。 このアプローチは、正直なノードがチェーンの先端で異なるビューを持ち、同じ高さの異なるブロックを確認する可能性があり、再編成につながる可能性があることを意味します。

また、イーサリアムは、良好なネットワーク条件下で、 Casper FFG プロトコルを使用して、ファイナリティを通じて一貫性を保証することも目指しています。 ファイナリティは、ファイナライズされたブロックを再編成しないというハードコードされたルールを持つノードを持つ、可能な限り強力な確認ルールです。

ファイナライズされたレジャー(緑)は、常にライブレジャー(青)の接頭辞です。

2つの競合するブロックがファイナライズされた場合、ファイナリティの保証が損なわれ、バリデータの1/3以上が悪意を持って行動した場合に発生するイベントです。 しかし、イーサリアムでは、そのような行為には ステークを失うという大きなペナルティが伴います。

ユーザーは、キャスパーFFGを最も安全な確認ルールとして使用するか、LMD GHOSTに頼ってよりライブにするかを選択できます。 LMD GHOSTの確認ルールは、 ビットコインのk-確認ルールと同様に、 セーフブロック確認ルールで指定されているように、トランザクションが台帳に含まれているかどうかを調べるだけでなく、より洗練されたものになる可能性があります。

ロールアップの確認ルール

ロールアップは、原則として、イーサリアムで利用可能なものと同じ確認ルールを使用できます。 ロールアップでトランザクションを送信し、後で同じトランザクションが L1 のファイナライズされたブロックにポストされた場合は、L2 トランザクションを最終トランザクションと見なすこともできます。 話はこれよりもはるかに複雑であることが判明しました。

トランザクション データのロールアップ

イーサリアムでは、ブロックにはトランザクションのリストと提案されたステートルートの両方がブロックヘッダーに含まれます。 トランザクションの実行がルートが表す状態に至らなかった場合、後で別の順序で他のブロックに追加できるトランザクションを含め、ブロック全体が破棄されます。

ロールアップでは、パブリッシュ データとルートのアクションが分離されているため、対応する状態ルートの有効性に応じてトランザクションを破棄する必要はありません。 この分離を考えると、状態ルートのファイナライズを待たずにトランザクションがファイナライズされているかどうかを確認し、オプティミスティック ロールアップの 7 日間のチャレンジ期間などの追加の遅延をバイパスするだけで十分です。

状態差分のロールアップ

状態差分は状態遷移関数の出力であり、それらが実際に有効であることを検証するには、ZK証明を待つ必要があります。 ZKプルーフの生成には時間がかかり、さらに、プルーフの生成と検証のコストをより適切に償却するために、1つのプルーフにより多くのトランザクションを含めるためにさらに遅らせるインセンティブがあります。

配達確認集計手法は、確認時間とコストの償却の間のこのトレードオフに対する解決策を提供します:ロールアップで最小限のアクティビティが発生した場合でも、よりアクティブなロールアップからのトランザクションを同じ証明に含めることで、償却の恩恵を受けることができます。 このアプローチの一例は、Starkwareの SHARP で、現在、Starknet、Paradex、StarkExのロールアップ(dYdX、さらにはValidiumsなど)のプルーフを集約しています。

物事が複雑になる場所

ロールアップ導出仕様

ロールアップが 基づいていない場合、バッチの導出順序はロールアップ シーケンサーによって定義でき、L1 で異なる順序でパブリッシュされる可能性があります。

たとえば、OP スタック チェーンは、前のバッチのハッシュを使用してリンクされたバッチを L1 に発行します。 これらのバッチは時系列で公開する必要がないため、ノードが欠落している可能性のあるトランザクションを待機する 12 時間の シーケンス ウィンドウ になります。 トランザクションは、L1で公開されているという理由だけで含まれていると見なされるべきではありません:バッチがまだバッチの正規チェーンに接続されていない場合、異なる順序またはトランザクションのセットを持つ代替フォークが構築されるリスクがあります。

OPスタックチェーンでは、ブロック時間は2秒で、各イーサリアムブロック内に6つのブロックがあります。 このイーサリアムブロック間の6つのブロックのグループを「エポック」と呼びます。 L1 経由で送信された L1 から L2 へのメッセージは、指定された L1 ブロックの対応するエポックの最初のブロックの最初の部分に含まれます。 これらのトランザクションは、シーケンシングウィンドウが経過するのを待たずに確認されたと見なすことができますが、導出時のL2台帳内の順序がわかっているため、先行するバッチがない場合、ノードはこれらのメッセージを含むブロックの計算を開始しないことに注意することが重要です。 これは、完全なシーケンスがないと状態を計算できないため、状態ルートも L1 で公開されないためです。

この結果、オンチェーンデータを調べるだけでは、L1の確認時間を追跡するには不十分です。 また、ロールアップ ノード ソフトウェア自体を調べて、L2 ブロックが L1 データからどのように派生するかを理解する必要もあります。

許可型関数

スクロールは、トランザクションデータを投稿するZKロールアップであり、原則として、トランザクションが最終的であると見なすためにZKプルーフを待つ必要はありません。 これは、まだ証明されていないバッチを削除する関数を実装していなければ、当てはまるでしょう。

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

zkSync EraとzkSync Liteは、状態差分を投稿する3つのステップで、まず、プルーフなしでデータをコミットし、次にプルーフを提供し、24時間の遅延の後、ルートを実行して出金を処理できるようになります。 理論的には、証明が提供されると、トランザクションの順序が固定されるため、実行の遅延が経過するのを待つ必要はありません。 ただし、zkSyncはこれらのブロックを元に戻すことができます。

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

zkSync Eraではブロックが元に戻されたことはありませんが、zkSync Liteでは 8回元に戻されました。

ファイナリティの可観測性

ロールアップ投稿状態の差分はトランザクションデータを投稿していないため、トランザクションが実際に含まれていることをどのように追跡できますか? 確かに、アカウントのナンスのような効果を追跡することはできますが、一般的なケースは厄介です。 一ヶ月前、私は次の質問をしました。

返信の一部を見てみましょう。

これは、シーケンサーがあなたに応答する意思があり、あなたがそれを信頼している場合に機能するソリューションです。 そうでない場合はどうなりますか? または、信頼できても信頼できない場合はどうなりますか? 主張が正しいことをどのように確認しますか?

私のお気に入りの返信。

実際に機能する解決策は、ここで提案されました。

これは機能しますが、状態差分を使用するという技術的な決定がアプリケーションロジックに漏れることを意味し、ロールアップがEVMと同等であっても、プロジェクトはこの考慮事項に契約を適応させる必要があります。

部分的な解決策は、トランザクションルートを投稿し、ZKプルーフ内でその有効性を確認することです。 ただし、この場合でも、必要なマークルパスを取得するためにシーケンサーに依存する必要があり、これは評判の良い中央集権型シーケンサーでは妥当かもしれませんが、パーミッションレスの設定ではトリッキーになります。

活性度メトリック

L2BEATでは、ロールアップトランザクションのファイナリティまでの時間を追跡するための最初のステップとして、特にトランザクションバッチ(該当する場合)と状態ルート間の間隔について、活性メトリクスの追跡を開始しました。 その根拠は、たとえば、ロールアップが L1 と 1 か月に 1 回だけやり取りする場合、ユーザーは完了までの時間が分単位になることを期待できないためです。 ライブネスメトリクスは、ファイナリティまでの時間の下限指標と考えることができます:トランザクションデータのロールアップが2分ごとにバッチをポストし、L2トランザクションの分布が均一であると仮定すると、ファイナリティまでの予想時間は1分以上です。

以下は、zkSync Era(状態更新)とOPメインネット(txバッチ)で追跡しているデータの例です。

9月のzkSync時代の活性度指標。

9月のOPメインネットの稼働率指標。

予想通り、ZKプルーフは生成に時間がかかり、1つのプルーフにより多くのトランザクションを含めるインセンティブがあるため、zkSync EraはOPメインネットよりもライブネスメトリクスが悪くなります。 前のセクションで説明したように、ライブネスメトリクスはファイナリティの考慮事項に直接変換されないことを覚えておくことが重要です:最悪の場合、OPメインネットはシーケンスウィンドウのためにファイナリティまでの時間が実際には長くなります。

これで、L2BEATのほとんどのロールアップのLivenessメトリクスを調べることができます。

活性の追跡に関する制限事項

活性度はファイナリティの下限指標と見なすことができますが、非常に悪い指標になることもあります。 ブロック時間が4秒のロールアップを想像してみてください、つまり、各イーサリアムブロックに対して3つのロールアップブロックがあることを意味します。 ロールアップオペレーターがL1ブロックごとに2つのL2ブロックしか投稿していない場合、イーサリアムの観点からロールアップが非常にライブであったとしても、L2ソフトコンファメーションにますます遅れをとり、ファイナリティまでの時間がますます悪化します。 これは極端なシナリオですが、ロールアップで考慮する必要があります。

実際の例はStarknetで、状態の更新間隔は平均32秒ですが、ファイナリティまでの時間は実際には6時間近くです。

出典: starkscan.co

これは、Starknet が L1 の各 L2 ブロックの状態ルート更新を発行するためです。 ただし、これを行うには、通常約 30 分に 1 回投稿される SHARP プルーフを参照する必要があります。 さらに、これらのプルーフは、L2ソフトコンファームチェーンの先端から約6時間遅れています。

ソフト確認

ソフト確認は、安全保証を犠牲にして L2 での確認時間を短縮するために使用される確認ルールです。 現在、すべての場合において、ソフト確認は、中央集中型オペレータが L1 に異なる tx を投稿しないことを信頼することを意味します。 誤ったソフトコンファメーションは原因となる障害であるため、シーケンサーのレピュテーションをオフチェーンまたはオンチェーンで追跡するメカニズムを実装できます。 Nethermind社と共同で、これらのセキュリティ特性を推定し、任意の時点でリスクにさらされている価値の量を追跡する予定です。

左:スラッシングメカニズムによって確保されたソフトコンファメーションを持っていた場合のStarknetの経済的保証。 右: 時間の経過とともに再編成されるリスクのある合計値。

今後の予定

最終決定までの時間の追跡は複雑な作業です。 最初のステップは、ZK ロールアップの証明送信の間隔を監視することですが、これは、状態ルートの送信間隔と比較して、ファイナリティまでの時間に高い下限を課します。 これに続いて、プロジェクトごとの履歴データを表示するチャートを導入する予定です。 その後、私たちの研究は、最終的に最終決定までの時間のリアルタイム指標を達成するために考慮する必要があるすべての追加メカニズムに焦点を当てます。 乞うご期待!

免責事項：

1. この記事は[medium]からの転載です。 すべての著作権は原作者【ルカ・ドンノ】に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。