イーサリアムの重要な拡張計画: 楽観的なロールアップ状況レポート (中)
完全な EVM: レイヤ 2 仮想マシン
レイヤ 2 スマート コントラクトの計算がトラストレスであり続けるためには、何らかの形式でレイヤ 1 でそのような計算を実行するためのフォールバックが必要です。 ORU は完全な EVM をサポートしており、レイヤー 2 には EVM の基本レイヤーで実行できる独自の仮想マシンが必要であることがわかります。このための高パフォーマンスの作成と実装は簡単な作業ではありません。つまり、EVM は単独で実行するように設計されていません。からダウンロードできますEIPこれらの課題の一部については、EVM を変更してこの機能を直接組み込む可能性についても説明されている を参照してください。Plamsa におけるこの問題に関する Kelvin Fitcher の概要。
したがって、5 つの完全な EVM プロジェクトはすべて、レイヤ 2 実装用に独自の修正バージョンの EVM を作成します。信頼性と予測可能な不正行為の証明を保証するには、VM の実行が決定的である必要があります。つまり、証明の時点で、不正行為が最初に発見された状況を正確に再現できなければなりません。したがって、ブロックの高さ、難易度、タイムスタンプのチェックなど、非決定的な操作は完全に変更または削除する必要があります。同様に、コントラクトの作成または破棄のオペコードも、このロジックが特殊であるため、削除する必要があります。したがって、ORU 上のレイヤー 1 コントラクトは、ORU チェーンに展開する前に、Solidity コードに若干の変更を加える必要がある場合があります。
詐欺の証拠
すべての完全な EVM ORU は、不正行為の証明を容易にする方法においていくつかの基本的な共通点を共有しています。つまり、ORU チェーンの状態は、状態遷移の実行を含む計算操作のハッシュと同様に、定期的にソートおよびコミットされます。 (すべての実践において、ステートルートの生成と検証に対するコミット責任はユーザーではなくオペレーターにあります)。不正行為の証明では、このデータを部分的に使用して、送信されたステップが実際には初期状態を最終状態に正しく変換しなかったことを示します。
完全な EVM 実践における主な違いは、これらの不正証明をどのように対話的に処理するかです。 ORU には基本的に、不正行為を即座に検出し、最終的にメイン チェーンのコンセンサスを得ることができるように、十分な通話データが含まれている必要があります。ただし、この不正証明を実行するプロセスは建設ごとに異なります。
シングルラウンド (紛らわしく「非対話型」と呼ばれることもあります) 不正行為防止スキームでは、不正行為は常に 1 回の取引または単一当事者による複数の取引で証明できます。この利点は、紛争が即座に「解決」できること、面倒なベクトルがないため、詐欺的な証明者に保釈金が必要ないこと、そして操作が簡単であることです。不正行為は複数回の不正行為証明で明らかですが、不正行為の証明者とブロック作成者の間にはいくつかの対話手順が必要です。この利点は、ガスコストが低くなり (場合によっては低くなり)、チェーン上のデータコストも低くなる可能性があることです。
単一ラウンドの不正行為の防止
Nutberry、Optimism、および Celer の ORU はすべて、単一ラウンドの不正行為証明をサポートしています。これには、すべてのトランザクションがシリアル化されたポストステートのルートにコミットされる必要があります。 Optimismのモデルでは、Celerも直接影響を受けており、不正が検出された場合、不正証明者はトランザクションの初期状態と最終状態の時間(スロット)を公開し、メインチェーンにトランザクションを完全に実行させます。 (このフローは、イーサリアム ブロックの検証に使用されるステートレス クライアントに似ていますstateless clientモデルは非常に似ています)。理想的には、トランザクションが不正であることを証明するために必要な状態時間 (スロット) は最小限だけです。ただし、原則として、トランザクションでは大量の状態データを読み取る必要がある場合があります。不正行為の証明がデータや計算量が多く、メイン チェーン ブロックに載せるのが難しい場合、オプティミズムは証明を複数のトランザクションに分割できます (これらのトランザクションは依然として不正証明者によって送信されることに注意してください。つまり、ある意味では、この追加の手順は「対話型」とは言えません)。
Nutberry のアプローチも似ていますが、「ゲート計算 (gated computing)」モデルを使用してコントラクトを実行します。スマート コントラクトにはチェックポイントが含まれるようにパッチが適用されます。このモデルでは、トランザクションは複数のより詳細な中間状態のルートにコミットし、より多くのデータが必要になる可能性がありますが、より小さなチャンクで不正行為の証明を実行します。
複数回にわたる不正行為の証明
証明者は、複数回の不正証明が真実であるかどうかを判断するために、複数のステップで不正証明者と対話する必要があります。 ORU が定義するように、鍵となるのは、正直な参加者や観察者が最初からどちらの側が真実を語っているかを判断できる十分なデータを公開し、それによってチャレンジ期間の結果を予測することです。
Interstate One の場合、トランザクションには状態ルートが含まれており、マークル ルートは公開時にステップ自体ではなく、対応する実行ステップに送信されます。ある意味、この提案は二次的な「楽観的な」仮定です。検証者が質問した場合にのみ、オペレータは通話データに EVM メッセージ スタックを投稿し、検証者はこれを使用して不正行為を簡単に証明できます。最悪の場合、このプロセスには合計 3 ラウンドがかかり、関連するトランザクションのステップ数に比例したコール データが必要になります (すべてのケースで線形データが必要な 1 ラウンドの不正証明と比較して)。
インタラクティブ性を強化するための最新技術は Offchain Labs の Arbitrum Rollup で、オンチェーンのフットプリントを最小限に抑えます。 Arbitrum では、トランザクションではなくブロックのみをステート ルートにコミットする必要があります。 Interstate と同様に、これらにはコミット ハッシュの計算も含まれます。 2 つの当事者が矛盾する主張をする場合、無効に実行された単一の計算ステップを対話的に発見する紛争を開始します (不正行為がある場合は、原則として少なくとも 1 つの無効なステップが存在する必要があります)。
これは、不正行為が分離されるまでスタック内で効率的なバイナリ検索を実行することによって行われます。つまり、不正行為証明者はスタックを調べ、途中の点で状態ハッシュを要求し、その後スタックを二分して、無効であることがわかっている半分を繰り返します。このプロセスは、無効な操作が 1 つだけ残るまで繰り返され、その後、その操作がオンチェーンで実行されます。したがって、最悪の場合、このプロセスには (n) 対数ステップ (n はオペランドの数) が必要で、最小限のレイヤー 1 計算が必要になります。
このアプローチの驚くべき特性は、紛争が続いているにもかかわらず、システムの残りの部分を一時停止する必要がないことです。ユーザーとブロックプロデューサーは通常どおり取引を続けることができます。 「論争」は可能性の木の枝として考えることができます。誠実なユーザーは、どちらの当事者が誠実であるかを検証して判断し、それに基づいて紛争が最終的にどのように解決されるかを確認できます。したがって、紛争の継続期間によってシステムの残りの部分が遅れることはありません。詳細については、「」を参照してください。How Arbitrum Rollup Works。
アプリケーション固有のロールアップ
ORU プロジェクトは、より限定された機能をサポートする一方で、トークン化された支払い、分散型取引所、プライベート支払い、大規模な移行など、より具体的なユースケースに合わせた最適化を目指しています。 4 つのプロトコルはそれぞれ異なるため、個別に説明します。
燃料 (「ブロックチェーン上のビットコイン」)
Fuel は、ビットコインに似たデータ モデルを使用して、支払い中心の UTXO ベースの ORU サイドチェーンを実装しています。この設計では、シンプルさと低コストの検証および不正防止を優先して、いくつかのスマート コントラクト機能のバランスを取る必要があります。実際、燃料と完全な EVM ORU のトレードオフに関する考えの多くは、ビットコインとイーサリアムのトレードオフと似ています。
ビットコインと同様、Fuel チェーンの状態は、すべての未使用のトランザクション出力のコレクションとして暗黙的に定義され、状態ルートのシリアル化は必要ありません。 2014 年の Greg Maxwell による簡潔な不正証明をサポートするモデルGreg Maxwell in 2014もともとビットコインのために提案されたモデルも同様です(2019年にジョン・アドラー単独によって再び発見されました)and independently rediscovered by John Adler in 2019); トランザクションはビットコイン トランザクションに非常に似ていますが、各入力が処理される場所を指定する追加のデータ フィールドが含まれています。このデータ領域を使用すると、1 つまたは 2 つの包含証明を使用して、1 ラウンド内のすべての不正ケース (二重支払い攻撃、偽入力など) を証明できます。低コストの不正行為の証明に加えて、UTXO モデルは、より高いパフォーマンスの検証、つまりより優れた状態アクセス パターンと並列処理 (同期的に実行される検証 EVM 実行と比較して) も約束します。
ここここ)。
ANON の ZK-Optimistic-Rollup (「ブロックチェーン上の ZCash」)
ここここ); 基金の請求は UTXO スタイルの「発行」の形式をとり、支払いにより新たな発行が行われ、その発行が将来の二重支出を防ぐために使用されたことを記録する「無効化要因」が作成されます。トランザクションには、実際にオブザーバーに詳細を明らかにすることなく、すべての有効性条件を満たすことが証明できる ZK-SNARK も含まれます。
簡潔な不正証明を維持するために、ZK-ORU には ZCash にはない機能があります。失効通知はスパース マークル ツリーに保存され、新しい ORU ブロックごとに更新されます。これにより、メンバーシップ (コミット済み) と非メンバーシップ (コミットされていない) を証明することが簡単になります。他のすべての ORU と同様に、SNARKS 自体の検証を含め、計算は楽観的に遅延します。無効な SNARK を含むすべての詐欺事件は、わずか 1 ステップで証明できます。
SNARK を生成する負担はユーザーにあることに注意してください。ANON では、クライアントが SNARK を生成するのに 10 ~ 30 秒かかると想定しています。
(名前やコンポーネントは似ていますが、ZK-Optimistic-Rollup は、必ずしもプライバシー保護を提供するわけではなく、不正行為の証明を使用せず、有効性を証明するためにオペレーターが生成した SNARK を使用するという点で、実際には ZK-Rollup とは異なることにも注意してください。暗号通貨に。)
WCL の ORU ハブ
この ORU 操作は、ロールアップ チェーン間のバッチ トランザクションの標準となることを目的としており、ユーザーが自主的に資金を移行して契約をアップグレードするための手段です。
運用自体はシンプルなアカウントのみの支払いベースのチェーンであり、Fuel と同様に、安価な不正行為の証明とデータ検証を提供します。この構築の主な目的は、異なるチェーン間で直接送金できる、つまり、あるチェーンから資金を引き出して別のチェーンに再入金する必要なく、標準アーキテクチャを確立することです。これは、バッチ デポジットをサポートし、チェーン間に一方向の相互接続を確立することで実現できます。宛先チェーンのバリデーターが発信元チェーンでの不正行為を検出するとすぐに、支払いは追加の遅延なく最終的なものとみなされます。これはETH 2.0のクロスシャード通信に関する研究と一致しています。ETH 2.0 cross shard communicationロジックも同様です。
計画されている主なユースケースはアップグレード可能ですが、このメカニズムの他のユースケースとして考えられるのは、別個の異なるライブ ロールアップ チェーン間の移行であり、これについてはさらに研究する必要があります。ロールアップのチェーン間移行の正確なプロトコルと確認が必要な正規チェーンの詳細はまだ公開されておらず、将来的にここにリンクされる予定です。
IDEX 2.0
IDEX のユニークな特徴は、本番環境に導入されたプロジェクトの最適な拡張バージョンとして ORU を使用することです。IDEX コントラクトは現在メイン ネットワーク上で実行されています。IDEX コントラクトで使用される状態モジュール (state) 他のイーサリアム アプリケーションよりも優れています。
IDEX 2.0のロールアップチェーンは、登録注文型の分散型取引所機能をサポートしており、この特定のユースケースを中心に構築されています。チェーンは、注文の実行、ユーザー残高の維持、より高度な注文タイプ、自動取引エンジンなどの他の機能を実行するためのセットアップを可能にする責任があります。
IDEX の ORU のバリデーターは IDEX トークンを持っている必要があります。バリデーターは、公開されたブロックを証明する領収書を提出し、有効なブロックへの署名と有効な不正証明の発行に基づいて報酬やペナルティを受け取ります (完全な「リスク」検証を受け入れることを選択した場合)。報酬は取引手数料の一部と独自のトークンを使用して支払われます (暗号経済モデルの分析はこの記事の範囲外です。詳細については、IDEX 2.0 ホワイト ペーパーを参照してください)DEX 2.0 whitepaper)。
このプロトコルでは、ブロックプロデューサーは初期入力としてブロックのマークルルートのみをアップロードし、チャレンジされた場合にのみブロックコンテンツを呼び出しデータにパブリッシュします。ロールアップ ブロック データの可用性はチェーン上で保証できないため、これは上記の「オプティミスティック ロールアップ」の定義に完全には当てはまりません。実際、彼らはこれを「最適化ロールアップ」と呼んでいます。Optimized Optimistic Rollup通話データが公開されると、詐欺を証明するための追加のステップが 1 つか 2 つあります。このアプローチの信頼性とセキュリティへの影響については、以下で説明します。
著者: Daniel Goldman (ダニエル ゴールドマン) フリーランス ソフトウェア エンジニア、技術コンサルタント、作家
校正:サミュエル
校正:サミュエル


