Across V4 では、新しく改善されたクロスチェーン アーキテクチャが導入されています。 このシステムは、インテントとゼロ知識証明 (ZKP) を組み合わせて、より多くのチェーンに、より迅速に拡張します。 技術的な内訳は次のとおりです。🧵

以前、Across は「正規ブリッジ」またはチェーン固有のアダプターを使用して、イーサリアムの HubPool からのメッセージを検証していました。 これは、イーサリアムのファイナライズされた状態を公開する Arbitrum や Optimism などの L2 ではうまく機能しました。 しかし、この設計には限界がありました...

BSC のような非 EVM チェーンの場合、このモデルは故障します。 イーサリアムの状態を検証する正規の方法はありません。これは、カスタム アダプターを構築するか、それらのチェーンをまったくサポートしないことを意味します。 どちらも最適なソリューションではありません。そこで、ZKP を使用するより良い方法を見つけました。

プロセスは次のとおりです。 リレーがクロスチェーン注文を満たすと、トランザクションはリレー返済バンドルにバッチ処理され、@UMAProtocolのオプティミスティック オラクルによって検証されます。 これは常にイーサリアムのメインネットで発生します。

バンドルが検証されると、Across HubPoolが決済プロセスをトリガーします。 次に、返済メッセージハッシュを特定のストレージスロットのHubPoolStoreコントラクトに書き込みます。 このストレージ イベントは、イーサリアム メインネットでも発生します。

HubPoolStoreコントラクト内の各メッセージハッシュは、宛先チェーンのリレイヤーに返済する意図に対応しています。 L1 → L2 メッセージは、複数の返済 (スロー フィルを含む) を表す可能性があることに注意してください。これは、ルートバンドルであるためです。

HubPoolStore コントラクトは、保存されたメッセージハッシュを書き込むと、StoredCallData イベントを発行します。 このイベントには、メッセージ ハッシュとストレージ スロットが含まれます。 イベント + 保存されたデータは、下流の ZK 検証のアンカーを形成します。

ファイナライザーと呼ばれるサービスは、これらのイベントをリッスンします。 新しいハッシュを検出すると、メッセージハッシュが実際にイーサリアムに書き込まれたことを証明するプロセスを開始します。 ハッシュが格納されているすべてのメッセージには、そのチェーンに固有のターゲットがあります。

この証明により、メッセージを宛先チェーンで安全に実行できます。 しかし、イーサリアムのファイナリティは瞬時に行われるものではありません。 ファイナライザーがデータを ZK API に送信すると、API は証明を生成する前にイーサリアムのファイナリティ ウィンドウを待ちます。

有効な ZK 証明を生成するには、イーサリアム同期委員会が特定の最終ブロックを承認する必要があります。 メッセージがそのブロックまたはそのブロック以前に含まれていた場合、ZK プルーフの生成を開始するために必要な署名が使用可能になります。

ファイナライザーは ZK API にクエリを実行して、特定のメッセージ ハッシュがファイナライズされたイーサリアム ブロック内の既知の HubPoolStore ストレージ スロットに書き込まれたという証明を生成します。 これにより、任意の宛先チェーンでの中継者返済のトラストレスな検証が可能になります。

ZK API は、以下を含む (ただしこれらに限定されない) 証明入力を準備します。 - 最終的なビーコンヘッダー - 委員会の署名を同期する - イーサリアムの実行層からのストレージのマークル証明 これらは、証明を生成するための基礎を形成します。

Across は、宛先チェーンに汎用スタックをデプロイします。 - 検証者コントラクト (ZK 証明を検証します) - SP1Helios by @Succinct (最終的なイーサリアムの状態を保存) - UniversalSpokepool コントラクト (実行中にメッセージの信頼性を検証します)

ZK 証明が検証され、状態が確認されると、executeMsg() は宛先チェーン上でペイロードを安全に実行できます。 トラストレス。牢。万国。

これは、Across がチェーンごとにカスタム アダプターを必要としなくなったことを意味します。 どこでも機能するパイプラインは 1 つだけです。 storeMsg() → SP1Helios 証明を検証できる任意の宛先チェーン上の ZK 証明→ executeMsg() です。

信頼の前提はありません。 統合のオーバーヘッドはありません。 インテント + ZK だけです。

なぜこれが大きな問題なのでしょうか? イーサリアムの状態をネイティブに検証できず、正規ブリッジを持たないロングテールチェーンのサポートを解除することで、Across の範囲を劇的に拡大します。 これにより、オンボーディングがより速く、より安全で、よりスケーラブルになります。

Cross は、これらのチェーンに正規のブリッジを必要としません。必要なのは、イーサリアムの状態の ZK 証明を検証する機能だけです。 これにより、統合のオーバーヘッドが削減され、集中型ブリッジング リスクが回避され、クロスチェーンの真実のルーツとしてのイーサリアムの役割が強化されます。