Across V4 wprowadza nową i ulepszoną architekturę crosschain. System łączy intencje i dowody z wiedzą zerową (ZKP), aby szybciej rozszerzyć się na więcej łańcuchów. Oto zestawienie techniczne. 🧵

Wcześniej Across używał "mostów kanonicznych" lub adapterów specyficznych dla łańcucha do weryfikacji wiadomości z HubPool Ethereum. Działało to dobrze w przypadku L2, takich jak Arbitrum i Optimism, które ujawniają stan sfinalizowany przez Ethereum. Ale ten projekt był ograniczający...

W przypadku łańcuchów innych niż EVM, takich jak BSC, ten model się psuje. Nie ma kanonicznego sposobu weryfikacji stanu Ethereum. Oznaczało to albo budowanie niestandardowych adapterów, albo w ogóle nie obsługiwanie tych łańcuchów. Żadne z tych rozwiązań nie jest optymalne. Wymyśliliśmy więc lepszy sposób na wykorzystanie ZKP.

Here’s the process: When relayers fill crosschain orders, the transactions are batched into relayer repayment bundles, which are then verified by @UMAProtocol’s Optimistic Oracle. This always happens on Ethereum mainnet.

Po zweryfikowaniu pakietu Across HubPool uruchamia proces rozliczania. Następnie zapisuje skróty komunikatów o spłacie do kontraktu HubPoolStore w określonych miejscach przechowywania. To zdarzenie związane z przechowywaniem odbywa się również w sieci głównej Ethereum.

Każdy skrót wiadomości w kontrakcie HubPoolStore odpowiada zamiarowi spłaty przekaźnika w łańcuchu docelowym. Należy pamiętać, że wiadomości L1 → L2 mogą reprezentować wiele spłat (w tym powolne wypełnianie). Dzieje się tak, ponieważ są to wiązki główne.

Gdy kontrakt HubPoolStore zapisuje przechowywany skrót komunikatu, emituje zdarzenie StoredCallData. To zdarzenie zawiera skrót komunikatu i miejsce magazynu. Zdarzenie + zapisane dane tworzą kotwicę do dalszej weryfikacji ZK.

Usługa o nazwie finalizator nasłuchuje tych zdarzeń. Gdy wykryje nowy, inicjuje proces mający na celu udowodnienie, że skrót wiadomości rzeczywiście został napisany na Ethereum. Każda wiadomość, dla której przechowywany jest skrót, ma cel, który może być specyficzny dla jej łańcucha.

Ten dowód pozwala na bezpieczne wykonanie wiadomości w łańcuchu docelowym. Ale ostateczność Ethereum nie jest natychmiastowa. Gdy finalizator wyśle dane do API ZK, API czeka przez okno ostateczności Ethereum przed wygenerowaniem dowodu.

Aby wygenerować ważny dowód ZK, komitet ds. synchronizacji Ethereum musi zatwierdzić określony sfinalizowany blok. Jeśli wiadomość została zawarta w tym bloku lub przed nim, wymagane podpisy stają się dostępne, aby rozpocząć generowanie dowodu ZK.

Finalizator wysyła zapytanie do interfejsu API ZK w celu wygenerowania dowodu, że określony skrót wiadomości został zapisany w znanym gnieździe pamięci masowej HubPoolStore w sfinalizowanym bloku Ethereum. Umożliwia to niewymagającą zaufania weryfikację spłat przesyłek w dowolnym łańcuchu docelowym.

ZK API przygotowuje dane wejściowe dowodu, w tym (ale nie wyłącznie): - Sfinalizowane nagłówki beaconów - Synchronizacja podpisów komisji - Dowody przechowywania Merkle z warstwy wykonawczej Ethereum Stanowią one podstawę do wygenerowania dowodu.

Across deploys a generic stack on destination chains: - A Verifier contract (validates the ZK proof) - SP1Helios by @Succinct (stores finalized Ethereum state) - UniversalSpokepool contract (verifies the authenticity of messages during execution)

Po zweryfikowaniu dowodu ZK i potwierdzeniu stanu, executeMsg() może bezpiecznie uruchomić ładunek w łańcuchu docelowym. Bez zaufania. Zabezpieczyć. Uniwersalny.

Oznacza to, że Across nie potrzebuje już niestandardowych adapterów dla każdego łańcucha. Tylko jeden potok, który działa wszędzie: storeMsg() na Ethereum → dowód ZK → wykonać Msg() w dowolnym łańcuchu docelowym, który może zweryfikować dowód SP1Helios.

Założenia braku zaufania. Brak narzutu na integrację. Tylko intencje + ZK.

Dlaczego to wielka sprawa? Znacznie rozszerza zasięg Across, odblokowując wsparcie dla łańcuchów z długim ogonem, które nie mogą natywnie zweryfikować stanu Ethereum i nie mają mostów kanonicznych. Dzięki temu onboarding jest szybszy, bezpieczniejszy i bardziej skalowalny.

Across nie potrzebuje mostu kanonicznego dla tych łańcuchów. Potrzebuje tylko możliwości zweryfikowania dowodu stanu Ethereum ZK. Zmniejsza to koszty ogólne integracji, pozwala uniknąć scentralizowanego ryzyka pomostowego i wzmacnia rolę Ethereum jako źródła prawdy crosschain.