Across V4 introduceert een nieuwe en verbeterde crosschain-architectuur. Het systeem combineert intenties en zero-knowledge proofs (ZKPs) om sneller naar meer chains uit te breiden. Hier is de technische uitleg. 🧵

Voorheen gebruikte Across "canonieke bruggen" of ketenspecifieke adapters om berichten van Ethereum's HubPool te verifiëren. Dit werkte goed voor L2's zoals Arbitrum en Optimism, die de Ethereum-gefinaliseerde staat blootstellen. Maar dit ontwerp was beperkend...

Voor niet-EVM-ketens zoals BSC werkt dit model niet. Er is geen canonieke manier om de Ethereum-status te verifiëren. Dit betekende ofwel het bouwen van aangepaste adapters of het helemaal niet ondersteunen van die ketens. Geen van beide is een optimale oplossing. Dus hebben we een betere manier gevonden met behulp van ZKP's.

Hier is het proces: Wanneer relayers crosschain orders invullen, worden de transacties gebundeld in relayer terugbetalingsbundels, die vervolgens worden geverifieerd door de Optimistic Oracle van @UMAProtocol. Dit gebeurt altijd op het Ethereum mainnet.

Zodra een bundel is geverifieerd, activeert de Across HubPool het afhandelingsproces. Het schrijft vervolgens de terugbetalingsbericht-hashes naar het HubPoolStore-contract in specifieke opslagslots. Deze opslaggebeurtenis vindt ook plaats op het Ethereum-hoofdnets.

Elke bericht-hash in het HubPoolStore-contract komt overeen met een intentie om een relayer op een bestemmingsketen terug te betalen. Let op dat L1 → L2-berichten meerdere terugbetalingen kunnen vertegenwoordigen (inclusief langzame vulbeurten). Dit komt omdat ze root-bundels zijn.

Wanneer het HubPoolStore-contract een opgeslagen bericht-hash schrijft, genereert het een StoredCallData-evenement. Dit evenement bevat de bericht-hash en opslagslot. Het evenement + de opgeslagen gegevens vormen het anker voor ZK-verificatie stroomafwaarts.

Een dienst genaamd de finalizer luistert naar die gebeurtenissen. Zodra het een nieuwe detecteert, start het een proces om te bewijzen dat de bericht-hash inderdaad op Ethereum is geschreven. Elk bericht waarvoor de hash is opgeslagen, heeft een doel dat specifiek kan zijn voor zijn keten.

Dit bewijs stelt de boodschap in staat om veilig op de bestemmingsketen te worden uitgevoerd. Maar de finaliteit van Ethereum is niet onmiddellijk. Zodra de finalizer de gegevens naar de ZK API stuurt, wacht de API door de finaliteitsperiode van Ethereum voordat er een bewijs wordt gegenereerd.

Om een geldige ZK-bewijs te genereren, moet de Ethereum sync-commissie goedkeuring geven voor een specifieke gefinaliseerde blok. Als het bericht in of vóór dat blok was opgenomen, worden de vereiste handtekeningen beschikbaar om te beginnen met het genereren van het ZK-bewijs.

De finalizer vraagt de ZK API om een bewijs te genereren dat een specifieke bericht-hash is geschreven naar een bekende HubPoolStore opslagslot in een gefinaliseerd Ethereum-blok. Dit maakt vertrouwenloze verificatie van relayer terugbetalingen op elke bestemmingsketen mogelijk.

De ZK API bereidt bewijsinvoer voor, waaronder (maar niet beperkt tot): - Gefinaliseerde beaconheaders - Handtekeningen van de synchronisatiecommissie - Merkle-bewijzen van opslag uit de uitvoeringslaag van Ethereum Deze vormen de basis voor het genereren van het bewijs.

Across implementeert een generieke stack op bestemmingsketens: - Een Verifier-contract (valideert de ZK-bewijs) - SP1Helios door @Succinct (slaat de gefinaliseerde Ethereum-status op) - UniversalSpokepool-contract (verifieert de authenticiteit van berichten tijdens uitvoering)

Zodra het ZK bewijs is geverifieerd en de staat is bevestigd, kan executeMsg() veilig de payload op de bestemmingsketen uitvoeren. Vertrouweloos. Veilig. Universeel.

Dit betekent dat Across geen aangepaste adapters meer nodig heeft voor elke keten. Slechts één pijplijn die overal werkt: storeMsg() op Ethereum → ZK bewijs → executeMsg() op elke bestemmingsketen die het SP1Helios bewijs kan verifiëren.

Geen vertrouwensassumpties. Geen integratie-overhead. Gewoon Intents + ZK.

Waarom is dit zo'n grote zaak? Het vergroot de reikwijdte van Across dramatisch door ondersteuning te bieden voor long-tail chains die de Ethereum-status niet op een native manier kunnen verifiëren en geen canonieke bruggen hebben. Dit maakt onboarding sneller, veiliger en schaalbaarder.

Across heeft geen canonieke brug nodig voor deze ketens. Het heeft alleen de mogelijkheid nodig om een ZK-bewijs van de Ethereum-status te verifiëren. Dit vermindert de integratie-overhead, vermijdt gecentraliseerd brugrisico en versterkt de rol van Ethereum als de wortel van crosschain waarheid.