Across V4 introduce una nuova e migliorata architettura crosschain. Il sistema combina intenti e prove a zero conoscenza (ZKP) per espandersi a più catene, più velocemente. Ecco il dettaglio tecnico. 🧵

In precedenza, Across utilizzava "ponti canonici" o adattatori specifici per la catena per verificare i messaggi dal HubPool di Ethereum. Questo funzionava bene per L2 come Arbitrum e Optimism, che espongono lo stato finalizzato di Ethereum. Ma questo design era limitante…

Per le catene non EVM come BSC, questo modello si rompe. Non esiste un modo canonico per verificare lo stato di Ethereum. Questo significava o costruire adattatori personalizzati o non supportare affatto quelle catene. Nessuna di queste è una soluzione ottimale. Quindi abbiamo trovato un modo migliore utilizzando ZKP.

Ecco il processo: Quando i relayer completano ordini crosschain, le transazioni vengono raggruppate in pacchetti di rimborso per i relayer, che vengono poi verificati dall'Optimistic Oracle di @UMAProtocol. Questo avviene sempre sulla mainnet di Ethereum.

Una volta che un pacchetto è verificato, l'Across HubPool attiva il processo di liquidazione. Scrive quindi gli hash dei messaggi di rimborso nel contratto HubPoolStore in slot di archiviazione specifici. Questo evento di archiviazione avviene anche sulla mainnet di Ethereum.

Ogni hash di messaggio nel contratto HubPoolStore corrisponde a un'intenzione di rimborsare un relayer su una catena di destinazione. Nota che i messaggi L1 → L2 possono rappresentare più rimborsi (inclusi i riempimenti lenti). Questo perché sono bundle radice.

Quando il contratto HubPoolStore scrive un hash di messaggio memorizzato, emette un evento StoredCallData. Questo evento contiene l'hash del messaggio e lo slot di memorizzazione. L'evento + i dati memorizzati formano l'ancora per la verifica ZK a valle.

Un servizio chiamato finalizer ascolta quegli eventi. Una volta che rileva un nuovo evento, avvia un processo per dimostrare che l'hash del messaggio è stato effettivamente scritto su Ethereum. Ogni messaggio, per il quale l'hash è memorizzato, ha un obiettivo che può essere specifico per la sua catena.

Questa prova consente al messaggio di essere eseguito in modo sicuro sulla catena di destinazione. Ma la finalità di Ethereum non è istantanea. Una volta che il finalizzatore invia i dati all'API ZK, l'API attende attraverso la finestra di finalità di Ethereum prima di generare una prova.

Per generare una prova ZK valida, il comitato di sincronizzazione di Ethereum deve approvare un blocco finalizzato specifico. Se il messaggio è stato incluso in quel blocco o prima, le firme richieste diventano disponibili per iniziare a generare la prova ZK.

Il finalizzatore interroga l'API ZK per generare una prova che un determinato hash di messaggio è stato scritto in uno slot di archiviazione HubPoolStore noto in un blocco Ethereum finalizzato. Questo consente la verifica senza fiducia dei rimborsi dei relayer su qualsiasi catena di destinazione.

L'API ZK prepara gli input della prova, inclusi (ma non limitati a): - Intestazioni beacon finalizzate - Firme del comitato di sincronizzazione - Prove Merkle di archiviazione dal layer di esecuzione di Ethereum Questi formano la base per generare la prova.

Across distribuisce uno stack generico su catene di destinazione: - Un contratto Verifier (valida la prova ZK) - SP1Helios di @Succinct (memorizza lo stato finale di Ethereum) - Contratto UniversalSpokepool (verifica l'autenticità dei messaggi durante l'esecuzione)

Una volta che la prova ZK è verificata e lo stato è confermato, executeMsg() può eseguire in sicurezza il payload sulla catena di destinazione. Senza fiducia. Sicuro. Universale.

Questo significa che Across non ha più bisogno di adattatori personalizzati per ogni catena. Solo un pipeline che funziona ovunque: storeMsg() su Ethereum → prova ZK → executeMsg() su qualsiasi catena di destinazione che può verificare la prova SP1Helios.

Nessuna assunzione di fiducia. Nessun sovraccarico di integrazione. Solo Intents + ZK.

Perché è un grande affare? Espande drammaticamente la portata di Across sbloccando il supporto per catene a lungo termine che non possono verificare lo stato di Ethereum in modo nativo e non hanno ponti canonici. Questo rende l'onboarding più veloce, sicuro e scalabile.

Across non ha bisogno di un ponte canonico per queste catene. Ha solo bisogno della capacità di verificare una prova ZK dello stato di Ethereum. Questo riduce il sovraccarico di integrazione, evita il rischio di bridging centralizzato e rafforza il ruolo di Ethereum come radice della verità crosschain.