Across V4 führt eine neue und verbesserte Crosschain-Architektur ein. Das System kombiniert Intents und Zero-Knowledge-Proofs (ZKPs), um schneller auf mehr Chains zu expandieren. Hier ist die technische Aufschlüsselung. 🧵

Früher verwendete Across "kanonische Brücken" oder ketten-spezifische Adapter, um Nachrichten aus Ethereum's HubPool zu verifizieren. Das funktionierte gut für L2s wie Arbitrum und Optimism, die den von Ethereum finalisierten Zustand offenlegen. Aber dieses Design war einschränkend…

Für nicht-EVM-Ketten wie BSC funktioniert dieses Modell nicht. Es gibt keinen kanonischen Weg, den Ethereum-Zustand zu verifizieren. Das bedeutete entweder, benutzerdefinierte Adapter zu erstellen oder diese Ketten überhaupt nicht zu unterstützen. Keine dieser Lösungen ist optimal. Also haben wir einen besseren Weg mit ZKPs gefunden.

Hier ist der Prozess: Wenn Relayer Crosschain-Orders ausführen, werden die Transaktionen in Rückzahlungsbündel für Relayer gebündelt, die dann von @UMAProtocol's Optimistic Oracle verifiziert werden. Das geschieht immer im Ethereum-Hauptnetz.

Sobald ein Bundle verifiziert ist, löst der Across HubPool den Abrechnungsprozess aus. Er schreibt dann die Rückzahlungsnachricht-Hashes in die HubPoolStore-Vertrag in spezifische Speicherplätze. Dieses Speicherereignis findet ebenfalls im Ethereum-Hauptnetz statt.

Jeder Nachrichten-Hash im HubPoolStore-Vertrag entspricht einer Absicht, einen Relayer auf einer Zielkette zurückzuzahlen. Beachten Sie, dass L1 → L2-Nachrichten mehrere Rückzahlungen (einschließlich langsamer Füllungen) darstellen können. Dies liegt daran, dass sie Wurzelbündel sind.

Wenn der HubPoolStore-Vertrag einen gespeicherten Nachrichten-Hash schreibt, wird ein StoredCallData-Ereignis ausgelöst. Dieses Ereignis enthält den Nachrichten-Hash und den Speicherplatz. Das Ereignis + die gespeicherten Daten bilden den Anker für die ZK-Überprüfung im Nachgang.

Ein Dienst namens der Finalizer hört auf diese Ereignisse. Sobald er ein neues erkennt, initiiert er einen Prozess, um zu beweisen, dass der Nachrichten-Hash tatsächlich auf Ethereum geschrieben wurde. Jede Nachricht, für die der Hash gespeichert ist, hat ein Ziel, das spezifisch für ihre Kette sein kann.

Dieser Nachweis ermöglicht es, die Nachricht sicher auf der Zielkette auszuführen. Aber die Finalität von Ethereum ist nicht sofort. Sobald der Finalisierer die Daten an die ZK-API sendet, wartet die API durch das Finalitätsfenster von Ethereum, bevor sie einen Nachweis generiert.

Um einen gültigen ZK-Beweis zu erzeugen, muss das Ethereum-Sync-Komitee einen bestimmten finalisierten Block absegnen. Wenn die Nachricht in diesem Block oder davor enthalten war, werden die erforderlichen Unterschriften verfügbar, um mit der Generierung des ZK-Beweises zu beginnen.

Der Finalizer fragt die ZK-API an, um einen Beweis zu generieren, dass ein bestimmter Nachrichten-Hash in einem bekannten HubPoolStore-Speicherplatz in einem finalisierten Ethereum-Block geschrieben wurde. Dies ermöglicht eine vertrauenslose Überprüfung der Rückzahlungen von Relayern auf jeder Zielkette.

Die ZK-API bereitet Beweiseingaben vor, einschließlich (aber nicht beschränkt auf): - Abgeschlossene Beacon-Header - Unterschriften des Synchronisationsausschusses - Merkle-Beweise für den Speicher aus der Ausführungsschicht von Ethereum Diese bilden die Grundlage für die Generierung des Beweises.

Across implementiert einen generischen Stack auf Zielketten: - Ein Verifier-Vertrag (validiert den ZK-Beweis) - SP1Helios von @Succinct (speichert den finalisierten Ethereum-Zustand) - UniversalSpokepool-Vertrag (überprüft die Authentizität von Nachrichten während der Ausführung)

Sobald der ZK-Beweis verifiziert und der Zustand bestätigt ist, kann executeMsg() sicher die Nutzlast auf der Zielkette ausführen. Vertrauenslos. Sicher. Universell.

Das bedeutet, dass Across keine benutzerdefinierten Adapter mehr für jede Kette benötigt. Nur eine Pipeline, die überall funktioniert: storeMsg() auf Ethereum → ZK-Beweis → executeMsg() auf jeder Zielkette, die den SP1Helios-Beweis verifizieren kann.

Keine Vertrauensannahmen. Kein Integrationsaufwand. Nur Intents + ZK.

Warum ist das eine große Sache? Es erweitert die Reichweite von Across erheblich, indem es Unterstützung für Long-Tail-Blockchains freischaltet, die den Ethereum-Zustand nicht nativ verifizieren können und keine kanonischen Brücken haben. Das macht das Onboarding schneller, sicherer und skalierbarer.

Across benötigt keine kanonische Brücke für diese Chains. Es benötigt lediglich die Fähigkeit, einen ZK-Beweis des Ethereum-Zustands zu verifizieren. Dies reduziert den Integrationsaufwand, vermeidet das Risiko zentralisierter Brücken und verstärkt die Rolle von Ethereum als Wurzel der crosschain Wahrheit.