重要なイーサリアムスケーリング計画: 楽観的なロールアップステータスレポート (パート 2)

著者: ダニエル・ゴールドマン フリーランスのソフトウェアエンジニア、技術コンサルタント、ライター 翻訳者: エマ、スノー・ルー 校正者: サミュエル

フルEVM: レイヤー2仮想マシン

レイヤー 2 のスマート コントラクト計算を信頼できない状態に保つには、何らかの形でレイヤー 1 でこの計算を実行するフォールバックが必要です。 ORU は完全な EVM をサポートしており、レイヤー 2 には EVM ベース レイヤーで実行できる独自の仮想マシンが必要であることがわかります。このため、高性能な実装を作成することは容易ではありません。つまり、EVM は単独で動作するようには設計されていません。これらの課題のいくつかについては EIP で読むことができます。EIP では、EVM を変更してこの機能を直接組み込む可能性についても説明されています。また、Kelvin Fitcher による Plamsa の問題の概要も参照してください。

その結果、5 つの完全な EVM プロジェクトすべてが、レイヤー 2 実行用に EVM の独自の修正バージョンを作成しました。不正証明の信頼性と予測可能性を確保するには、VM の実行が決定論的である必要があります。つまり、詐欺を証明する際には、詐欺が最初に発見された状況を正確に再現できなければなりません。したがって、ブロックの高さ、難易度、タイムスタンプのチェックなど、非決定論的な操作は変更するか、完全に削除する必要があります。同様に、このロジックは特別なので、コントラクトの作成または破棄のオペコードも削除する必要があります。したがって、ORU 上のレイヤー 1 契約では、ORU チェーンにデプロイされる前に Solidity コードに若干の変更を加える必要がある場合があります。

詐欺防止

すべての完全な EVM ORU は、不正証明を容易にする方法に関していくつかの基本的な共通点を持っています。ORU チェーンの状態は、状態遷移を実行するものも含め、計算された操作のハッシュと同様に、定期的に順序付けされ、コミットされます。 (すべてのプラクティスにおいて、状態ルート コミットの生成と検証の責任はユーザーではなくオペレーターにあります)。不正証明では、このデータを部分的に使用して、送信された手順によって実際には初期状態が最終状態に正しく変換されなかったことを示します。

完全な EVM 実装間の主な違いは、これらの不正証明をいかにインタラクティブに処理するかです。 ORU には基本的に、不正行為を即座に検出し、最終的にメイン チェーンで合意に達することができるように十分な通話データが含まれている必要があります。ただし、この不正防止を実行するプロセスは、建設ごとに異なります。

単一ラウンド（紛らわしいことに「非インタラクティブ」と呼ばれることもある）の不正防止スキームでは、不正行為は常に単一のトランザクションで証明されるか、または単一の当事者による複数のトランザクションにわたって証明されます。この利点は、紛争を即座に「解決」できること、面倒な運送業者がいないため不正証明者からの保証金が不要であること、操作が簡単であることです。複数ラウンドの不正証明では不正は明らかですが、不正証明者とブロック生成者の間ではいくつかの対話型ステップが必要になります。これの利点は、ガスコストが低くなる（場合によっては大幅に低くなる）ことと、オンチェーンのデータコストが低くなる可能性があることです。

単一ラウンドの不正防止

Nutberry、Optimism、Celer の ORU はすべて、単一ラウンドの不正証明をサポートしています。これには、すべてのトランザクションをシリアル化されたポスト状態ルートにコミットする必要があることが必要です。 Optimism のモデルでは、Celer も直接影響を受けます。不正行為が検出されると、不正証明者はトランザクションの初期状態と最終状態の時間 (スロット) を公開し、メイン チェーンがトランザクションを完全に実行できるようにします。 (このフローは、Ethereum ブロックの検証に使用されるステートレス クライアント モデルと非常によく似ています)。理想的には、不正行為を防止するために、トランザクションには最小限の状態時間 (スロット) が必要です。しかし、原則的には、トランザクションでは大量の状態データの読み取りが必要になる可能性があります。不正証明に大量のデータや計算が必要で、メインチェーンのブロックに配置するのが難しい場合、Optimism は証明を複数のトランザクションに分割できます (これらのトランザクションは依然として不正証明者によって送信されることに注意してください。したがって、ある意味では、この追加ステップは「インタラクション」とはみなされません)。

Nutberry のアプローチも同様ですが、契約を実行するために「ゲート コンピューティング」モデルを使用します。スマート コントラクトにチェックポイントを追加するパッチが適用されました。このモデルでは、トランザクションは複数のより細かい中間状態ルートを送信します。これにより、より多くのデータが必要になる可能性がありますが、不正証明はより小さなチャンクで実行されます。

複数回の不正証明

証明者は、複数回の不正証明が真実であるかどうかを判断するために、複数のステップで不正証明者と対話する必要があります。 ORU が定義する鍵は、十分なデータを公開して、正直な参加者や観察者が最初からどちらの当事者が真実を語っているかを判断し、チャレンジ期間の結果を予測できるようにすることです。

Interstate One の場合、トランザクションには状態ルートが含まれており、公開されると、ステップ自体ではなく、実行されたステップに Merkle ルートがコミットされます。ある意味では、この提案は第 2 レベルの「楽観的な」仮定です。バリデーターが質問した場合にのみ、オペレーターは通話データに EVM メッセージ スタックを投稿します。バリデーターはこれを使用して不正行為を簡単に証明できます。最悪の場合、このプロセスには合計 3 ラウンドかかり、関係するトランザクションのステップ数に比例した通話データが必要になります (すべてのケースで線形データを必要とする単一ラウンドの不正証明と比較して)。

強化されたインタラクティブ性という点で最も進んでいるのは、オンチェーンのフットプリントを最小限に抑える Offchain Labs の Arbitrum Rollup です。 Arbitrum では、トランザクションではなくブロックのみが状態ルートをコミットする必要があります。 Interstate と同様に、これらにはコミット ハッシュの計算も含まれます。両当事者が相反する主張をした場合、両当事者は紛争に突入し、無効に実行された個々の計算ステップを相互に特定しようとします (不正行為があった場合、原則として少なくとも 1 つの無効なステップが存在する必要があります)。

彼らは、不正行為が特定されるまでスタック全体を効率的に二分探索することでこれを行います。つまり、不正行為証明者はスタック全体を走査し、途中の時点で状態ハッシュを要求し、次にスタックを二分して、無効であることがわかっている半分を繰り返します。このプロセスは、無効な操作が 1 つだけ残るまで繰り返され、無効な操作がチェーン上で実行されます。したがって、最悪の場合、このプロセスには (n) ログ ステップ (n は操作の数) が必要となり、レイヤー 1 の計算は最小限で済みます。

このアプローチの驚くべき特性は、紛争が進行中でもシステムの残りの部分を停止する必要がないことです。ユーザーとブロックプロデューサーは通常通り取引を継続できます。 「論争」を可能性の木の枝として考えてみましょう。誠実なユーザーは、どちらの当事者が誠実であるかを検証して判断し、それに基づいて紛争が最終的にどのように解決されるかを理解できます。したがって、紛争の継続によってシステムの残りの部分が遅延することはありません。詳細については、「Arbitrum Rollup の仕組み」を参照してください。

アプリケーション固有のロールアップ

ORU プロジェクトは、トークン支払い、分散型取引所、プライベート支払い、大量移行など、より具体的なユースケースに合わせて最適化を図りながら、より限定された機能をサポートします。 4 つのプロトコルはそれぞれ異なるため、個別に説明します。

Fuel（「ブロックチェーン上のビットコイン」）

Fuel は、ビットコインに似たデータ モデルを使用して、支払い中心の UTXO ベースの ORU サイドチェーンを実装しています。この設計では、シンプルさと検証および不正防止のコスト削減を優先して、スマート コントラクトのいくつかの機能のバランスを取る必要があります。実際、Fuel と完全な EVM ORU のトレードオフに関するアイデアの多くは、Bitcoin と Ethereum のトレードオフに似ています。

Bitcoin と同様に、Fuel チェーンの状態は、すべての未使用のトランザクション出力のセットとして暗黙的に定義されます。状態ルートのシリアル化は必要ありません。簡潔な詐欺証明をサポートするモデルは、2014 年に Greg Maxwell が Bitcoin 向けに最初に提案したモデル (2019 年に John Adler が別途再発見) に似ています。トランザクションはビットコインのトランザクションと非常に似ていますが、各入力が処理される場所を指定する追加のデータ領域が含まれています。このデータ領域を使用すると、すべての不正ケース（二重支払い攻撃、誤った入力など）を 1 ラウンドで 1 つまたは 2 つの包含証明で証明できます。 UTXO モデルは、低コストの不正証明に加えて、より優れた状態アクセス パターンと並列処理の余裕 (同期的に実行される検証 EVM 実行と比較して) など、より高性能な検証も約束します。

Fuel は、ビットコインのカラード コイン提案を反映したモデルを使用して、ERC20 および ERC721 転送をサポートします。また、HTLC のアトミック スワップなど、特定の特殊なトランザクション タイプもサポートします。最終的には、Bitcoin Script と機能的に類似した、より強力なステートレス述語スクリプト言語をサポートする予定です。

ANON の ZK-Optimistic-Rollup（「ブロックチェーン上の ZCash」）

もう 1 つのユニークな ORU プロジェクトは、ANON の ZK-Optistic-Rollup です。これは、ZCash プライバシー アドレスと同じプライバシー保証を備えた E RC-20 および ERC-721 支払いトランザクションをサポートします。デザインは ZCash 自体と多くの共通点があります。資金に対する請求権は、UTXO 形式の「発行」の形をとります。支払いにより新たな発行が生成され、将来の二重支払いを防ぐために発行を記録する「無効化」が作成されます。トランザクションには ZK-SNARK も含まれており、これは、観察者に詳細を実際に公開することなく、すべての有効条件を満たしていることを証明します。

簡潔な不正証明を維持するために、ZK-ORU には ZCash にはない機能があります。失効通知はスパース マークル ツリーに保存され、新しい ORU ブロックごとに更新されます。これにより、メンバーシップ (コミット済み) と非メンバーシップ (非コミット) の証明が容易になります。他のすべての ORU と同様に、SNARKS 自体の検証を含め、計算は楽観的に遅延されます。無効な SNARK を含むすべての不正シナリオを、たった 1 つのステップで証明できます。

SNARK を生成する負担はユーザー側にあることに注意してください。 ANON は、クライアントが SNARK を生成するのに 10 ～ 30 秒かかると見積もっています。

(また、名前とコンポーネントが類似しているにもかかわらず、ZK-Optimistic-Rollup は実際には ZK-Rollup とは異なります。ZK-Rollup は必ずしもプライバシーを提供しず、不正証明を使用せず、オペレーターが生成した SNARK を使用して有効性を証明します。暗号通貨の世界へようこそ。)

WCL の ORU ハブ

ORU 操作は、ロールアップ チェーン間のトランザクションをバッチ処理するための標準となることを目的としており、ユーザーが自発的に資金をアップグレードされた契約に移行するための手段です。

操作自体はシンプルで、アカウントベースの支払いのみのチェーンであり、Fuel と同様に、安価な不正証明とデータ検証を提供します。この構築の主な目的は、異なるチェーン間で直接送金を可能にする標準アーキテクチャを確立することです。つまり、あるチェーンから資金を引き出し、別のチェーンに再度入金する必要がなくなります。これは、バッチ入金をサポートし、チェーン間の一方向のクロス接続を確立することで実現できます。宛先チェーンのバリデータが発信元チェーンで不正行為を検出する限り、支払いは追加の遅延なく最終的なものとみなされます。これは、ETH 2.0 のクロスシャード通信ロジックに関する研究に似ています。

計画されている主な使用例はアップグレード可能性ですが、このメカニズムの別の潜在的な使用例は、別個の異なるライブ ロールアップ チェーン間の移行であり、これについてはさらに調査する必要があります。ロールアップチェーン間移行の正確なプロトコルと確認が必要な正規チェーンについての詳細はまだ公開されていませんが、後でここにリンクが添付されます。

IDEX 2.0

IDEX がユニークなのは、すでに運用中のプロジェクトの最もスケーラブルなバージョンとして ORU を使用していることです。 IDEX コントラクトは現在メインネット上で実行されており、他のどの Ethereum アプリケーションよりも多くの状態モジュールを使用しています。

IDEX 2.0 のロールアップ チェーンは、注文登録された分散型取引機能をサポートし、この特定のユース ケースを中心に構築されています。このチェーンは、注文の実行、ユーザー残高の維持、より高度な注文タイプ、自動取引エンジンなどの他の機能の設定を許可する役割を担います。

IDEX の ORU のバリデーターは IDEX トークンを持っている必要があります。バリデータは、公開されたブロックを証明する領収書を提出し、有効なブロックへの署名と有効な不正証明の発行（完全な「リスク」検証を受け入れることを選択した場合）に基づいて報酬が与えられ、または罰則が科せられます。報酬は、取引手数料の一部と独自のトークンを使用して支払われます (暗号経済モデルの分析はこの記事の範囲外です。詳細については、IDEX 2.0 のホワイトペーパーを参照してください)。

このプロトコルでは、ブロックプロデューサーはブロックの Merkle ルートのみを初期入力としてアップロードし、要求された場合にのみブロックの内容を呼び出しデータに公開します。ロールアップブロックデータの可用性はオンチェーン上で保証できないため、これは上記の「楽観的ロールアップ」の定義を完全には満たしません。実際、彼らはそれを「最適化されたロールアップ」と呼んでいます。通話データが公開されると、詐欺を証明するための追加の手順が 1 つまたは 2 つあります。このアプローチの信頼性とセキュリティへの影響については以下で説明します。

第三部は近日公開予定です。