Across V4 wprowadza nową i ulepszoną architekturę crosschain. System łączy intencje i dowody zerowej wiedzy (ZKP), aby szybciej rozszerzać się na więcej łańcuchów. Oto techniczne podsumowanie. 🧵

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 dla L2, takich jak Arbitrum i Optimism, które ujawniają stan sfinalizowany przez Ethereum. Jednak ten projekt był ograniczający…

Dla łańcuchów, które nie są EVM, takich jak BSC, ten model przestaje działać. Nie ma kanonicznego sposobu na weryfikację stanu Ethereum. Oznaczało to albo budowanie niestandardowych adapterów, albo całkowite nieobsługiwanie tych łańcuchów. Żadne z tych rozwiązań nie jest optymalne. Dlatego wymyśliliśmy lepszy sposób wykorzystując ZKP.

Oto proces: Gdy relayerzy wypełniają zamówienia międzyłańcuchowe, transakcje są grupowane w pakiety spłat relayerów, które następnie są weryfikowane przez Optymistyczny Oracle @UMAProtocol. To zawsze odbywa się na głównym łańcuchu Ethereum.

Gdy pakiet zostanie zweryfikowany, Across HubPool uruchamia proces rozliczenia. Następnie zapisuje hashe wiadomości spłaty w kontrakcie HubPoolStore w określonych slotach pamięci. To zdarzenie przechowywania ma również miejsce w sieci głównej Ethereum.

Każdy hash wiadomości w kontrakcie HubPoolStore odpowiada zamiarowi spłaty relayera na docelowym łańcuchu. Zauważ, że wiadomości L1 → L2 mogą reprezentować wiele spłat (w tym wolne wypełnienia). Dzieje się tak, ponieważ są to pakiety główne.

Kiedy kontrakt HubPoolStore zapisuje hasz wiadomości, emituje zdarzenie StoredCallData. To zdarzenie zawiera hasz wiadomości oraz slot pamięci. Zdarzenie + zapisane dane stanowią kotwicę dla weryfikacji ZK w dalszym etapie.

Usługa zwana finalizatorem nasłuchuje tych zdarzeń. Gdy tylko wykryje nowe, inicjuje proces, aby udowodnić, że hasz wiadomości rzeczywiście został zapisany na Ethereum. Każda wiadomość, dla której hasz jest przechowywany, ma cel, który może być specyficzny dla jej łańcucha.

Ten dowód pozwala na bezpieczne wykonanie wiadomości na docelowym łańcuchu. Jednak finalność Ethereum nie jest natychmiastowa. Gdy finalizator wyśle dane do ZK API, API czeka przez okno finalności Ethereum, zanim wygeneruje dowód.

Aby wygenerować ważny dowód ZK, komitet synchronizacyjny Ethereum musi zatwierdzić konkretny zfinalizowany blok. Jeśli wiadomość została uwzględniona w tym bloku lub przed nim, wymagane podpisy stają się dostępne do rozpoczęcia generowania dowodu ZK.

Finalizator zapytuje ZK API, aby wygenerować dowód, że konkretny skrót wiadomości został zapisany w znanym slocie pamięci HubPoolStore w sfinalizowanym bloku Ethereum. Umożliwia to bezpieczną weryfikację spłat relayerów na dowolnym łańcuchu docelowym.

ZK API przygotowuje dane wejściowe do dowodu, w tym (ale nie tylko): - Sfinalizowane nagłówki beaconów - Podpisy komitetu synchronizacji - Dowody Merkle'a dotyczące przechowywania z warstwy wykonawczej Ethereum Stanowią one podstawę do generowania dowodu.

Across wdraża ogólny stos na docelowych łańcuchach: - Kontrakt Weryfikatora (waliduje dowód ZK) - SP1Helios od @Succinct (przechowuje sfinalizowany stan Ethereum) - Kontrakt UniversalSpokepool (weryfikuje autentyczność wiadomości podczas wykonania)

Gdy dowód ZK zostanie zweryfikowany, a stan potwierdzony, executeMsg() może bezpiecznie uruchomić ładunek na docelowym łańcuchu. Bez zaufania. Bezpieczne. Uniwersalne.

To oznacza, że Across nie potrzebuje już niestandardowych adapterów dla każdej sieci. Tylko jeden pipeline, który działa wszędzie: storeMsg() na Ethereum → dowód ZK → executeMsg() na dowolnej sieci docelowej, która może zweryfikować dowód SP1Helios.

Brak założeń dotyczących zaufania. Brak dodatkowego obciążenia integracyjnego. Tylko Intencje + ZK.

Dlaczego to jest taka wielka sprawa? Znacząco zwiększa zasięg Across, odblokowując wsparcie dla długich łańcuchów, które nie mogą natywnie weryfikować stanu Ethereum i nie mają kanonicznych mostów. To sprawia, że onboarding jest szybszy, bezpieczniejszy i bardziej skalowalny.

Across nie potrzebuje kanonicznego mostu dla tych łańcuchów. Potrzebuje jedynie możliwości weryfikacji dowodu ZK stanu Ethereum. To zmniejsza obciążenie integracyjne, unika ryzyka centralizacji mostów i wzmacnia rolę Ethereum jako źródła prawdy międzyłańcuchowej.