Across V4 představuje novou a vylepšenou architekturu crosschain. Systém kombinuje záměry a důkazy s nulovou znalostí (ZKP) a rychleji se rozšiřuje na více řetězců. Zde je technický rozpis. 🧵

Dříve Across používal k ověřování zpráv z HubPoolu Etherea "kanonické mosty" nebo adaptéry specifické pro řetězec. To fungovalo dobře pro L2 jako Arbitrum a Optimism, které vystavují stav dokončení Etherea. Tento design byl ale omezující...

U řetězců bez EVM, jako je BSC, se tento model porouchá. Neexistuje žádný kanonický způsob, jak ověřit stav Etherea. To znamenalo buď vytváření vlastních adaptérů, nebo vůbec nepodporu těchto řetězců. Ani jedno z toho není optimálním řešením. Tak jsme přišli na lepší způsob použití ZKP.

Zde je postup: Když relayery vyplní crosschain příkazy, transakce jsou dávkovány do balíčků splácení relayerů, které jsou poté ověřeny optimistickým orákulem @UMAProtocol. To se na mainnetu Etherea děje vždy.

Jakmile je sada ověřena, složka Across HubPool spustí proces vypořádání. Poté zapíše hash zprávy o splácení do kontraktu HubPoolStore do konkrétních slotů úložiště. K této události úložiště dochází také v mainnetu Ethereum.

Každá hodnota hash zprávy v kontraktu HubPoolStore odpovídá záměru splatit zálohu v cílovém řetězci. Všimněte si, že zprávy L1 → L2 mohou představovat více splátek (včetně pomalého plnění). Je to proto, že se jedná o kořenové svazky.

Když kontrakt HubPoolStore zapíše uloženou hodnotu hash zprávy, vygeneruje událost StoredCallData. Tato událost obsahuje hodnotu hash zprávy a slot pro ukládání. Událost + uložená data tvoří kotvu pro ověření ZK v downstreamu.

Služba s názvem finalizační metoda naslouchá těmto událostem. Jakmile zjistí nový, zahájí proces, který prokáže, že hash zprávy byl skutečně zapsán na Ethereu. Každá zpráva, pro kterou je hash uložen, má cíl, který může být specifický pro její řetězec.

Tento důkaz umožňuje bezpečné provedení zprávy v cílovém řetězci. Konečnost Etherea však není okamžitá. Jakmile finalizační metoda odešle data do ZK API, API čeká přes okno finality Etherea, než vygeneruje důkaz.

Aby bylo možné vygenerovat platný důkaz ZK, musí výbor pro synchronizaci Etherea podepsat konkrétní dokončený blok. Pokud byla zpráva zahrnuta do tohoto bloku nebo před něj, budou k dispozici požadované podpisy, aby bylo možné začít generovat důkaz ZK.

Finalizační metoda se dotazuje rozhraní ZK API, aby vygenerovala důkaz, že konkrétní hodnota hash zprávy byla zapsána do známého slotu úložiště HubPoolStore v dokončeném bloku Ethereum. To umožňuje nedůvěryhodné ověřování splátek náhradníka v jakémkoli cílovém řetězci.

ZK API připravuje důkazní vstupy včetně (ale nejen): - Dokončené hlavičky majáků - Synchronizace podpisů výborů - Merkle důkazy o úložišti z prováděcí vrstvy Etherea Ty tvoří základ pro generování důkazu.

Across nasadí obecný zásobník na cílové řetězce: - Smlouvu Verifier (ověřuje důkaz ZK) - SP1Helios od @Succinct (ukládá dokončený stav Ethereum) - Smlouva UniversalSpokepool (ověřuje pravost zpráv během provádění)

Jakmile je důkaz ZK ověřen a stav je potvrzen, executeMsg() může bezpečně spustit datovou část v cílovém řetězci. Bez důvěry. Zajistit. Univerzální.

To znamená, že Across již nepotřebuje vlastní adaptéry pro každý řetězec. Pouze jeden kanál, který funguje všude: storeMsg() na Ethereu → důkaz ZK → executeMsg() na libovolném cílovém řetězci, který může ověřit důkaz SP1Helios.

Žádné předpoklady důvěry. Žádné režijní náklady na integraci. Jen záměry + ZK.

Proč je to tak velký problém? Dramaticky rozšiřuje dosah Across tím, že odemyká podporu pro long-tail chainy, které nemohou nativně ověřit stav Etherea a nemají kanonické mosty. Díky tomu je onboarding rychlejší, bezpečnější a škálovatelnější.

Across nepotřebuje kanonický most pro tyto řetězce. Potřebuje pouze schopnost ověřit důkaz ZK o stavu Ethereum. To snižuje režijní náklady na integraci, zabraňuje centralizovanému překlenovacím riziku a posiluje roli Etherea jako kořene pravdy o crosschainu.