*原題:Exploring Eclipse's Canonical Ethereum Bridge and Proving System

Canonical Bridgeの概要

Eclipse は 3 つのレイヤーで構成されています。

1. 実行:SVMトランザクション実行のためのSolana Labsクライアント(v1.17)のフォーク
2. 決済:Eclipseのフォーク選択ルールを定義する標準的なブリッジはイーサリアム上に存在し、そこでは不正の証拠も提出されます
3. データの可用性:Eclipseは、不正の証拠を作成するために必要なデータをCelestia上のデータブロブとして公開します

以下の図は、これらのモジュールがどのように相互作用するかを示しています。

この記事の残りの部分では、図に示すように、Eclipseのイーサリアムブリッジに焦点を当てます。 Blobstream は、Celestia のバリデーター セットによって署名された証明を中継し、Eclipse のスロットのバッチのデータが正しく公開されたことを Ethereum に証明します。 これにより、Eclipseのブリッジは、Celestiaからの署名されたデータルートに対して、不正防止のために提供されたデータを検証できます。 このセクションの残りの部分では、次のプロセスの概要を説明します。

1. 資金はブリッジを介して入金され、
2. EclipseのブロックのバッチのデータブロブがCelestiaに投稿され、
3. ブリッジ経由の出金が処理され、
4. 不正の証拠は、最悪のシナリオで生成されます。

EclipseのネイティブEthereumブリッジを介した入金

ユーザーがネイティブのイーサリアムブリッジを介してEclipseに入金するときの流れは、次のように要約されます。

1. ユーザーがイーサリアム上でEclipseの Deposit Bridgeコントラクト を呼び出す
2. EclipseのSVMエグゼキュータ[1]内から、リレイヤー[2]はユーザーのデポジットと宛先アドレスを監視します
3. 次に、リレイヤーは、ユーザーの預金を該当する宛先アドレスに転送する役割を担うSVMブリッジプログラムを呼び出します
4. リレイヤーは、zk-lightクライアント(実装予定)を介して入金トランザクションを検証します
5. 最後に、その後の入金後の送金トランザクションを含むブロックが確定され、Solana Geyser Pluginを介して公開されます

下の図は、上記の入金フロー中のEthereum、Celestia、SVM Executor間の相互作用を示しています。

EclipseのスロットをデータBLOBとしてCelestiaに公開する

EclipseのスロットのバッチをデータBLOBとしてCelestiaに公開するフローを以下にまとめます。

1. SVM Executor は、Geyser を介して各 Eclipse スロットをメッセージキューに公開します
2. SVM Executor は、Eclipse のスロットのバッチをデータ BLOB として Celestia に投稿します
3. Celestiaバリデーターセットは、送信されたデータBLOBへの コミットメント を生成し、データルートに対するEclipseのチェーンにトランザクションが含まれていることを証明するために使用できます
4. すべてのCelestiaブロックヘッダーに含まれるデータルートは、Blobstreamを介してEthereum上のEclipseのブリッジコントラクトに中継されます

以下のCelestiaの図は、特定のCelestiaブロック内のデータのコミットメントがブロックヘッダーにどのように格納されるかを示しています。

EclipseのEthereum Bridgeへの不正証明の引き出しと提出

不正証明を使用する他のL2(Arbitrum、Fuelなど)と同様に、Eclipseからの引き出しには、無効な状態遷移の場合に検証者が不正証明を提出できるチャレンジ期間が必要です。

1. SVMエグゼキューターは、定期的に、Eclipseのスロットのエポック(所定のバッチ数)へのコミットメントを、担保とともにイーサリアムに投稿します
2. Eclipseのブリッジコントラクトは、投稿されたデータが整形式であることを確認するために、いくつかの基本的なチェックを行います(Fraud Proof Designのセクションで説明されています)
3. 送信されたバッチがこれらの基本チェックに合格すると、バッチ コミットメントが無効な状態遷移を意味する場合に、検証者が不正証明を投稿できる事前定義されたウィンドウがあります
4. 検証者が不正証明を成功裏に投稿すると、エグゼキューターの担保を獲得し、投稿されたバッチは拒否され、Eclipse L2の正規状態は最後の有効なバッチコミットメントにロールバックされます。 この場合、Eclipseのガバナンスは、新しいエグゼキューターを選出する権限を持つことになります
5. 不正の証拠がないまま異議申し立て期間が経過した場合、遺言執行者は報酬とともに担保を回収します
6. その結果、Eclipseブリッジコントラクトは、ファイナライズされたバッチに含まれていたすべての引き出しトランザクションを完了するようになります

不正防止設計

この最後のセクションでは、 Anatoly Yakovenko 氏と John Adler氏に触発されたEclipseの不正防止システム設計について詳しく説明します。 一般に、不正の証拠のために、検証者は次のことを行う必要があります。

1. 無効な状態遷移を含むトランザクションを特定する
2. 無効な状態遷移を含むトランザクションへの入力を提供します
3. 指定されたインプットで当該トランザクションを再実行すると、オンチェーンでコミットされたものと等しくないアウトプットが得られることを実証します

Eclipseの場合、(1)Celestiaは、EclipseのSVMエグゼキュータが投稿するブロックのバッチのブロブをマークリゼーションし、Merklewitnessを介してトランザクションの包含証明を可能にします。 (2)については、マークルルートをグローバルステートツリーにポストするEVMベースのL2とは異なり、パフォーマンス上の理由から、Eclipseはトランザクションごとにグローバルステートツリーを更新しませんが、入力の正確性を保証する方法を以下で詳しく説明します。 最後に、(3)の場合、Eclipseのベリファイアは、EVMベースのL2で一般的な インタラクティブな検証ゲームのアプローチ とは異なり、特定のトランザクションの出力のzkプルーフを生成します。

すべてのEclipseトランザクションは、入力アカウントのリストを取得し、トランザクションを実行し、結果の出力アカウントのリストを生成するものとして表すことができます。

当社の不正防止設計における重要な観察は、トランザクションの実行のためには、S_InputAccountが以前のトランザクションのS_OutputAccountでなければならないということです。 これにより、グローバルステートツリーにマークルの証人を提供する代わりに、特定のインプットアカウントを生成したチェーン内の最後のトランザクションを参照することができます。 設計の結果として、前のトランザクションへの参照が有効でなかったり、入力アカウントが後のトランザクションですでに「使用」されていたりするなど、追加の不正告発タイプが導入されています。 このプロセスについて、以下で詳しく説明します。

Celestiaに転記されたトランザクション入力

1. トランザクション データ (シーケンサーによって転記)
2. トランザクションデータ(SVM Executor によってポストされる)には、次の情報が含まれます。
   1. トランザクション数 [3]
   2. トランザクションデータのCelestia名前空間の場所
   3. 各入力のアカウントハッシュ [4] で、トランザクション数は
   4. 使用される sysvar とそれぞれの値のリスト、およびトランザクション数がそれぞれになる (該当する場合) [5]
   5. トランザクション出力 (トランザクションが成功した場合)。それ以外の場合は、トランザクションが失敗したことを示すインジケーター (解析に失敗したか、実行できなかったため)

イーサリアムブリッジに投稿されたバッチコミットメント

さらに、Celestiaに投稿されたトランザクションデータのバッチは、そのコミットメントがイーサリアムコントラクトに中継されます。 コミットメントは以下で構成されます。

1. バッチに含まれる最後のトランザクションのトランザクションデータの Celestia 名前空間の場所
2. 含まれるすべてのトランザクションの実行データ [6] の Celestia 名前空間の場所
3. 入金、出金、および上書きのリストで、それぞれに関連する Eclipse トランザクションのトランザクション数が含まれています

無効なバッチの基準

上記で説明したように、バッチが正しくないことがわかる方法はいくつかあります。

1. リンクされた Celestia 名前空間の場所の 1 つが形式が正しくないか、必要な型のデータを指していません
2. Celestiaには、関連する実行データのないトランザクションがありますが、これには2つの理由が考えられます。
   1. バッチ内で最新のトランザクションであるはずのトランザクションには、実行データが関連付けられていません。
      1. このような場合、検証者はこれが事実であることを確認し、イーサリアムブリッジコントラクトは実行データリストの最新のエントリが正しいトランザクションデータに対応していないことを確認します
   2. 別のトランザクションの実行データが欠落している
      1. ベリファイアは、問題のあるトランザクションのトランザクションデータのCelestia名前空間の場所と、正常に実行された順序で前後のトランザクションを投稿します。 これに続いて、ブリッジ コントラクトは、このトランザクションがスキップされたことを確認します
3. 実行データが正しくないトランザクションがあり、次の原因が考えられます。
   1. アカウントハッシュまたはsysvarに関連付けられたトランザクションカウントは、要求された出力を生成しません。
      1. この場合、ベリファイアは、指定されたトランザクションの実行データのCelestia名前空間の場所を対応するカウントとともにポストし、ブリッジコントラクトは指定された値が正しくないことを確認します。
   2. アカウントハッシュまたはsysvarに関連付けられているトランザクション数が古くなっています
      1. ベリファイアは、新しいトランザクションの実行データのCelestia名前空間の場所を投稿し、問題の値を変更し、ブリッジコントラクトはこれが実際に新しいことを確認します。
   3. トランザクション出力が正しくないか、トランザクションがリストされていない入力を使用しています。
      1. この場合、トランザクションが正しく実行されていることを示す zk プルーフ、またはトランザクションがリストされていない入力を使用していることを示す zk プルーフが必要です。 これは、次の 2 つの方法で取得できます。
         1. 検証者が配達確認を投稿する、または
         2. 検証者は不正であると主張されたトランザクションのインデックスを投稿し、Eclipseブリッジコントラクトはこれを使用してRISC ZeroのBonsaiからzk-proofを要求します
   4. Nバッチ以上前にイーサリアムからのデポジットがありましたが、N個の過去のバッチのトランザクションリスト(ブリッジコントラクトに投稿されたバッチコミットメントに含まれる)に対応するデポジットはありません。 あるいは、関連するイーサリアムの入金トランザクションがないトランザクションリストに入金があるか、トランザクションは存在するが、すでに別のEclipseバッチに含まれている場合です
      1. これらすべてのケースでブリッジ コントラクトは、これが発生したと判断し、そのようなバッチを無効と見なすことができます
   5. トランザクションリストに対応するエントリがない状態で実行された入出金があります
      1. このような場合、ベリファイアは指定された実行データのCelestia名前空間の場所を投稿し、ブリッジコントラクトはこの事実をチェックしてトランザクションを無効と判断します
   6. トランザクション・リストに、関連する Eclipse トランザクションが予期されるアクションを実行していないか、またはトランザクション・カウントが予期されるトランザクション・カウント範囲内にない入出金があります。 このような場合、次のいずれかが発生します。
      1. ブリッジは、これが当てはまると自動的に判断し、対応するバッチを拒否します
      2. 検証者は無効な状態遷移に気付き、問題のあるトランザクションの証明を投稿し、ブリッジ コントラクトによって検証されます

コミットメント・バッチが不正確であることが判明した場合、Eclipse ブリッジ・コントラクトは、ブリッジを最後の証明可能な正しいバッチ・コミットメントのブリッジにロールバックします。 不正の場合でも、トランザクションはチェーンから削除されないため、再計算する必要があるのはコミットメントのみであることに注意してください。

別れの想い

この記事は、イーサリアム上のEclipseの信頼最小化ブリッジの概要ガイドを提供し、不正防止設計の詳細を説明することを目的としています。 L2のモジュール性とテクノロジースタックの初期段階を考えると、今後数週間のうちにEclipseのさまざまな側面に関する記事やドキュメントをリリースし続ける予定です。

Eclipse Testnetに参加するには、 こちらの指示に従ってください。 TwitterまたはDiscordで、テストネット、ブリッジ、または技術的な質問に関する具体的な質問をすることができます。

脚注

[1]: SVM トランザクションの結果を計算し、最終的な出力を Eclipse の新しい状態に適用するノード

[2]: イーサリアムとエクリプスの間でオンチェーンイベントを渡すオペレーター

[3]: シーケンサーではなく、エグゼキューターがこれをポストすることに注意してください。 シーケンサーによって投稿されたデータに含まれていると、シーケンサーがカウントをスキップして、エグゼキューターが正しくジョブを実行できなくなるという複雑さが加わります。 これは、不正防止設計で補うことができますが、複雑さが増します。 エグゼキューターのみがカウントをポストすることの2つ目の利点は、必要に応じてトランザクションのオーバーライドをCelestiaにポストすることを容易にすることです。

[4]: SVM アカウントは一意のハッシュで表すことができます。 このハッシュを変更する唯一の方法は、トランザクションを使用することです。

[5]: 過度なハッシュ化を行わずにこれを行うために、実行された各プログラムに対してトレースを実行して、使用されている各 sysvar のどの部分が実際にアクセスされているかを確認します。 これは可能ですが、SolanaのBPFインタプリタを変更する必要があります。

[6]: これには、実行に失敗したトランザクションのデータが含まれます。

免責事項：

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