ロールアップの観点からクロスチェーンコミュニケーションを探る

著者: Lisa A.、Taiko Labs、翻訳: Jinse Finance xiaozou

この記事では、信頼のないクロスチェーン通信に焦点を当て、ロールアップの観点からさまざまな L2 クロスチェーン メッセージング方法について説明します。直接状態読み取りアプローチ、ライト クライアント アプローチ、およびプルーフ オブ ストレージについて簡単に説明します。また、プルーフ集約メカニズム、信頼できるサードパーティのクロスチェーン メッセージ送信、およびコアとなる ZK クロスチェーン ソリューションについても説明します。最後に、現在さまざまな L2 がクロスチェーン メッセージングをどのように実装しているかを見てみましょう。

1. クロスチェーンメッセージングの概要

クロスチェーン通信の場合、すべての関係者 (L2、L3 など) が最新のイーサリアム状態ルートに直接アクセスできる必要があります。

すべてのデポジット層には、L1 状態ルートにアクセスするために使用できる「組み込み」クロスチェーン メカニズムがあり、デポジット メッセージとして L2 に渡されます。

1**.1** ステートルートへの 2 種類のアクセス

タイプ 1: ステート ルートを直接読み取ります - オペコードまたはプリコンパイルによって実行できます。ただし、これまで実装されていないため、証明は必要ありません。

Brecht Devos は、状態を直接読み取る可能な方法について研究論文で次のように説明しています。「…ターゲット チェーンでスマート コントラクトを直接呼び出すことができるプリコンパイルされたコントラクトを公開できます。これはソース チェーンで直接プリコンパイルされ、別のチェーンのスマート コントラクト コードを挿入して実行します。これにより、スマート コントラクトは効率的かつ簡単に証明できる方法で、利用可能な最新の状態に常にアクセスできるようになります。」

· Optimism の RFP「Remote Static Invocation Proof of Concept」にも記載されています。

タイプ 2: 証明の生成 - つまり、あるブロックチェーンに関するステートメントを別のブロックチェーン上で証明します。

「証明付きクロスチェーンメッセージング」には 2 つのアプローチがあります。

· トラストレスなクロスチェーン通信 — つまり、信頼できるサードパーティが存在しません (ライト クライアントやプルーフ オブ ストレージの使用など)。トラストレスアプローチは、サードパーティが証明を生成する場合と、クロスチェーン通信の参加者が自分で証明を生成する場合の両方に使用できます。

クロスチェーン操作を保証するために、プルーフは異なるロールアップ間で共有されます。この記事ではあまり説明しませんが、このアプローチは現在研究と探索の段階にあり、広く適用できるソリューションとは考えられていません。

1**.2** 「証拠付きクロスチェーンメッセージング」方式

1.2.1 ライトクライアントのクロスチェーンメッセージング

チェーン B のデータを証明する

チェーン B の完全なノード (特定の履歴状態のストレージ証明が必要な場合はアーカイブ アーカイブ ノード) からマークル証明データを取得します。

検証したい状態を含むチェーン B ブロックに対応するブロック ヘッダーと証明データを、呼び出しデータとしてチェーン A の証明者コントラクトに送信します。

証明者コントラクトは、ブロック ヘッダー データに基づいてブロック ハッシュ値を計算し、チェーン A 上のライト クライアント スマート コントラクトにクエリを実行し (チェーン B のブロック ハッシュ値を追跡)、ハッシュ値が有効かどうかを確認します。

証明データは、ブロック ヘッダーの bytes32 状態ルートに対して検証されます。

1**.2.2** 保管証明

Proof of Storage には 2 つの「ワークフロー」オプションがあります。

・保管証明を生成 → オンチェーンで使用

・保管証明を生成→zk証明を生成→チェーン上で使用

エンティティが複数のプルーフのコレクションを 1 つのプルーフ (プルーフ オブ ストレージとプルーフ オブ zk の両方) にパッケージ化することも可能です。これはオプションの最適化ステップであり、まだ説明されていません。

ストレージ証明の「ワークフロー」の 3 つの主要な段階、すなわちストレージ証明の生成、ZK 証明の生成、チェーンでの使用を見てみましょう。

(1) 保管証明の生成

· 保管証明により、機密コミットメントを使用して、特定の情報がブロックチェーン上に存在し、真実であることを証明できます。

1979 年のマークル ツリーの出現以来、Proof-of-Storage は暗号空間の一部となってきました。ただし、バニラのプルーフ オブ ストレージは通常、非常に大きくなります。最新のイノベーションは、証明可能な計算とストレージの証明を組み合わせて、オンチェーンで検証できる簡潔な証明を作成することにあります。

Proof of Storage を生成するには、特定のデータ ブロックと、それに関連付けられたマークル ツリー内のマークル パスまたはバークル パスを提供する必要があります。パスは、同じハッシュ アルゴリズムを使用してルート ハッシュを再構築するために必要な兄弟ハッシュで構成されます。

Proof of Storage を 検証するために、受信者は提供されたデータと Merkle または Verkle パスを使用してルート ハッシュを再計算できます。再計算されたルート ハッシュが既知のルート ハッシュと一致する場合、受信者はデータが本物であり、送信されたデータセットの一部であると確信できます。

(2) ZKP (ゼロ知識証明) の生成

ただし、イーサリアムタイプの Proof of Storage は約 4kb であり、Proof of Storage 全体をターゲット チェーンに投稿するにはかなり大きく、証明の検証には非常にコストがかかるためです。したがって、圧縮に ZKP (ZK-SNARK など) を使用するのが合理的です。これにより、証明が小さくなり、検証コストが安くなります。

（3）A****ロール ZKP

ZKP を獲得した後、ターゲット チェーン上のユーザーは獲得した証明を展開できます (ブロック ヘッダーまたはブロック ハッシュを介して履歴状態にアクセスするなど)。

アンロールは次のように実行できます。

オンチェーン蓄積: プルーフからブロックヘッダーを再構築するプロセス全体は、ブロックチェーン上で直接実行されます。欠点: 高いガス料金、コンピューティング リソースの消費; 利点: ブロックチェーンの外部でプルーフを生成する必要がないため、追加のプルーフ時間なし、低レイテンシ。

オンチェーン圧縮: 冗長または不要な情報をデータから削除するか、スペース効率のために最適化されたデータ構造を使用します。圧縮されたデータはブロックチェーンに送信され、必要に応じて解凍できます。短所: データの圧縮と解凍には追加の計算が必要になる可能性がありますが、この遅延は無視できる程度です。使用される圧縮アルゴリズムはデータのセキュリティに悪影響を与える可能性がありますが、利点: データ コストが削減されます。

オフチェーン ストレージ: データをオフチェーンに保存し、オンデマンドで特定のデータ ブロックをオンチェーンに置きます。これは、何らかの理由で大量のデータを保存する必要があるソリューション (例: ジェネシス ブロックからのイーサリアム アーカイブ ノード) に関連します。短所: オンチェーン圧縮と同じ; 長所: データコストをさらに削減します。

1**.2.3** 信頼できるサードパーティ

完全なクロスチェーン ソリューションには、信頼できるサードパーティ (オラクル、集中型ブリッジなど) とのクロスメッセージング ソリューションも含まれている必要があります。

1**.2.4** 「ユニバーサル」証明システム

共有Proof-of-Aggregation Platformの仕組みの場合、Aggregation Platform内で決済されたブロックハッシュを受け取ることでメッセージングを高速化でき、ここでの決済もメッセージングを処理します（ただし、Aggregation Platformに問題がある場合）何をすべきか？）。

1**.2.5 ZK****クロスチェーンメッセージング**のいくつかの未知の問題

クロスチェーン メッセージングは、信頼できるサードパーティ (単一のエンティティまたは複数のエンティティの場合があります) なしで実現できますか?クロスチェーンメッセージパッシングの効率的なメカニズムは何ですか?一般に、イーサリアム L2 (L1 のブロック ハッシュに直接アクセスできる) とイーサリアム自体については、1 つのチェーンがライト クライアントなどを実行できれば、トラストレス クロスチェーン メッセージングには十分です。

クロスチェーンプルーフ生成に使用される ZK 回路は適切にスケーリングされていますか?場合によっては、特にコンセンサス層 (クロスチェーン操作を検証する必要がある) が非常に大きい場合、ZK クロスチェーン メッセージ パッシングに使用される回路は、ロールアップ ストレージやオンチェーン ストレージよりも桁違いに大きくなる可能性があります。計算オーバーヘッドも非常に大きくなります。おそらく、この問題は、より集中化されたアプローチで解決できるでしょう。

2**、クロスチェーンメッセージングソリューションの例**

· Su****ccinct Labs は、ライト クライアントを使用して、ソース チェーンからターゲット チェーンのコンセンサス層までのコンセンサスを検証します。アイデアは、ノードが最終的なブロックチェーン状態のブロックヘッダーを同期できるようにするためのライトクライアントプロトコルが存在するということです。 ZKP はコンセンサス証明を生成するために使用されます。

· La****grange Labs は、非インタラクティブなクロスチェーン状態証明を構築します。ラグランジュは、ネットワークが状態ルートの作成に関与していることを証明します。各 Lagrange ノードには、特定のチェーンの状態を証明するシャードの秘密キーの一部が含まれています。各状態ルートは、特定の時点での特定のチェーンの状態を証明するために使用できる、しきい値で署名された Verkle ルートです。状態ルートは完全に一般的であり、チェーン内の任意の 1 つのコントラクトまたはウォレットの現在の状態を証明するために状態証明に使用できます。

· He****rodotus は、ZKP プルーフ オブ ストレージを使用してスマート コントラクトを提供し、他のイーサリアム レイヤーのチェーン上のデータに同期的にアクセスします。検証のために、ネイティブ L1<>L2 メッセージングを使用して、イーサリアム ロールアップ間でブロック ハッシュを同期します。

=nil; Foundation (Mina、L1) は、イーサリアム上でスマート コントラクトを使用して、Mina 状態の有効性を検証できるようにします。特別目的の状態証明を生成し、イーサリアム上で安価に検証できます (イーサリアム上のローカルのミナ証明は高価です)。仮に（将来的には）アプリケーションは、Mina のプルーフ生成ツールを直接使用して、クロスチェーン トランザクションの有効性をチェックできるようになります。 =nil; Foundation には、ユーザー/プロジェクトが主にトラストレス データ アクセスを可能にする SNARK プルーフを売買できるプルーフ マーケットもあります。

Axiom: Axiom がこれまでに台帳の ZKP を生成した場合 - 特定のブロックの ZKP を生成する必要はありません - この ZKP を (リレーラーとして) チェーンに渡すことができ、さらには、このZKP。

3. L2 クロスチェーン メッセージング

*免責事項: クロスチェーン メッセージングは、L2 の大部分で依然として進化しています。以下のすべての分析はオープンソース情報に基づいています。とはいえ、この記事で言及されているソリューションはまだ調査とテストの段階にある可能性があり、ロールアップでは最終的には他の方法が採用される可能性があります。 *

**（1）**太鼓

Taiko はチェーンごとにブロック ハッシュを保存します。チェーンのペアごとに、互いのハッシュを保存する 2 つのスマート コントラクトをデプロイします。 L2←→L1の例では、Taiko上でL2ブロックが作成されるたびに、L1上の周辺ブロックのハッシュ値がTaikoL2コントラクトに格納されます。 L1←→L2の場合も動作モードは同じです。

ターゲット チェーンに保存されている最新の既知のマークル ルートは、TaikoL1/TaikoL2 コントラクトで getCrossChainBlockHash(0) を呼び出し、検証する値/メッセージを取得することで取得できます。最新の既知のマークル ルートの兄弟ハッシュは、「ソース チェーン」上の標準 RPC を使用して eth_getProof リクエストを呼び出すことで取得できます。

次に、それらを送信して、「ターゲット チェーン」のリストに保存されている最新の既知のブロック ハッシュと照合して検証するだけです。バリデーターは値 (マークル ツリーのリーフ) と兄弟ハッシュを取得してマークル ルートを再計算し、それがターゲット チェーンのブロック ハッシュのリストに格納されているルートと一致することを確認します。

**（2）**スタークネット

Starknet は、トラストレスなクロスチェーン メッセージングに Proof of Storage を使用します。

L2→L1 メッセージング プロトコル

· Starknet トランザクションの実行中、Starknet 上のコントラクトは L2→L1 メッセージを送信します。

次に、メッセージ パラメーター (L1 上の受信者コントラクトおよび関連データを含む) が、関連する状態更新 (メイン ストレージ ツリー) に追加されます。

· L2 メッセージはスマート コントラクトの L1 に保存されます。

· L1 でイベントを発行します (メッセージ パラメーターを格納)。

L1 上の受信者アドレスは、メッセージ パラメーターを再提供することで、L1 トランザクションの一部としてメッセージにアクセスし、使用できます。

· クロスチェーンメッセージはトランクツリーに保存されます。

L2 → L1

L1 → L2

**（3）**楽観主義

L1 と L2 間の通信は、「メッセンジャー」と呼ばれる 2 つの特別なスマート コントラクトによって実装されます。

· Optimism (L2) から Ethereum (L1) へのトランザクションの場合、ステート ルートが書き込まれた後、L1 上のメッセージのマークル証明を提供する必要があります。この証明トランザクションが L1 チェーンの一部になった後、エラー チャレンジ期間が始まります。この待機期間の後、ユーザーはイーサリアム上で 2 番目のトランザクションをトリガーし、ターゲットの L1 コントラクトにメッセージを送信することでトランザクションを「完了」できます。

· クロスチェーンメッセージはトランクツリーに保存されます。

（4）アル****ビトルム

再試行可能なチケットは、Arbitrum が L1 から L2 へのメッセージング、つまり L2 で実行されるメッセージを初期化する L1 トランザクションを作成するために使用する標準的な方法です。 Retryable は、固定料金 (呼び出しデータのサイズのみに応じて) で L1 に送信できます。メインの状態ツリーは、スマート コントラクトにおけるカスタム データ形式のクロスチェーン通信に使用されます。 L1 での再試行可能なチケットの送信は、L2 での実行から分離可能または非同期です。再試行可能により、クロスチェーン操作間のアトミック性が提供されます。 L1 トランザクション リクエストが正常に送信された場合 (つまり、ロールバックなしで)、L2 での再試行可能な実行には、最終的に成功するという強力な保証があります。

Arbitrum には 2 つのトランクがあります。 Nitro チェーンは、イーサリアムの状態ツリー形式であるマークル ツリーで維持されます。アサーションツリーには、イーサリアム上で確認されたアービトラムチェーンの状態が「アサーション」によって保存されます。 Arbitrum チェーンを進めるルールは決定的です。これは、チェーンの状態といくつかの新しい入力値が与えられた場合、有効な出力は 1 つだけであることを意味します。したがって、プルーフ ツリーに複数のリーフが含まれる場合、有効なチェーン状態を表すことができるのは最大でも 1 つのリーフです。

Arbitrum のアウトボックス システムでは、L2 から L1 へのコントラクト コールが可能です。つまり、メッセージは L2 から開始され、最終的に L1 で実行されます。 L2 から L1 へのメッセージ (別名「送信メッセージ」) は、Arbitrum の L1 から L2 メッセージ (再試行可能) と多くの共通点がありますが、いくつかの顕著な違いがあります。 Arbitrum チェーンの L2 状態の一部 (つまり、各 RBlock で証明される部分) は、チェーン履歴内のすべての L2 から L1 メッセージのマークル ルートです。証明された RBlock が確認された後 (通常、証明から約 1 週間後)、マークル ルートが送信ボックス コントラクトに含まれ、L1 に公開されます。 Outbox コントラクトにより、ユーザーはメッセージを実行できるようになります。

**（5）**ポリゴンzkEVM

· この zkEVM のブリッジ SC は、通信または資産トランザクションに参加するネットワークごとに、出口ツリーと呼ばれる特別なマークル ツリーを使用します。

これはマークル ルート (別の状態ツリー内) を使用しており、ブリッジ アーキテクチャ図は github で見つけることができます。

zkEVM Bridge SC の展開では、Ethereum 2.0 デポジット契約に基づいていくつかの変更が加えられました。たとえば、特別に設計された追加専用のマークル ツリーを使用しますが、イーサリアム 2.0 のデポジット コントラクトと同じロジックを使用します。その他の違いは、ベース ハッシュとリーフ ノードに関連します。

Polygon zkEVM Bridge スマート コントラクトの主な機能は、Exit Tree とグローバル Exit Tree の使用です。グローバル Exit Tree のルートは、真理状態の主なソースです。したがって、L1 と L2 には 2 つの異なるグローバル出口ルート マネージャーがあり、ブリッジ SC には別のロジックがあります。

（6）ス****スクロール

· イーサリアムとスクロールに展開されたブリッジ コントラクトにより、ユーザーは L1 と L2 の間で任意のメッセージを渡すことができます。このメッセージング プロトコルに加えて、ユーザーが L1 と L2 の間で ERC-20 資産をブリッジできるようにするトラストレス ブリッジング プロトコルも構築しました。 Ethereum から Scroll にメッセージまたは資金を送信するには、ユーザーは Bridge コントラクトで sendMessage トランザクションを呼び出します。中継器は、このトランザクションを L1 でインデックス付けし、L2 ブロックに含めるために注文者に送信します。 L2 ブリッジ コントラクトでは、Scroll back から Ethereum にメッセージを送信するプロセスは同様です。

· クロスチェーン メッセージは通常のメッセージ キューに保存されます。順序付け者は、このキューからクロスチェーン メッセージを取り込み、通常のトランザクションとしてチェーンに追加します。

**（7）**zksync時代

*免責事項: このセクションの内容は zksync Era に関するものであり、ソブリン ZK スーパーチェーンを構築するためのモジュール式フレームワークである ZK スタック上のクロスチェーン メッセージングとは異なる場合があります。 *

· 各トランザクション パッケージには、単一の L2->L1 メッセージがあります。

・L2からL1へ直接トランザクションを送信することはできません。ただし、zkSync Era からイーサリアムに任意の長さのメッセージを送信し、L1 スマート コントラクトを使用してイーサリアム上で受信したメッセージを処理することができます。 zkSync Era には、メッセージが L1 に正常に送信されたかどうかを示すブール値パラメーターを返すリクエストプルーフ機能があります。 Ethereum を観察するか、zksync-web3 API の zks_getL2ToL1LogProof メソッドを使用して、メッセージに含まれるマークル証明を取得します。

· L1→L2の場合、zkSync Eraスマートコントラクトにより、送信者はイーサリアムL1でトランザクションをリクエストし、データをzkSync Era L2に渡すことができます。

・ブリッジ契約：

4 結論

クロスチェーン通信は、ブロックチェーンの大量導入に「必須」のアプリケーション (Vitalik の記事で説明されているクロスチェーン ソーシャル リカバリ ウォレットなど) に不可欠です。現在使用されているクロスチェーン ソリューションのほとんどは、出金機能をカバーするために L1←→L2 向けに設計されています。これらのソリューションは、より多くのブロックチェーンに拡張できます。しかし同時に、まったく証拠のない「直接読み取り状態」や信頼のない「ストレージの証明」など、より高度なクロスチェーン通信ソリューションを実装することもできます。ほとんどの L2 では、クロスチェーン通信にはまだ改善の余地があります。