Across V4 introduce o arhitectură crosschain nouă și îmbunătățită.
Sistemul combină intenții și dovezi zero-knowledge (ZKP) pentru a se extinde mai rapid la mai multe lanțuri.
Iată defalcarea tehnică. 🧵
Anterior, Across folosea "punți canonice" sau adaptoare specifice lanțului pentru a verifica mesajele de la HubPool de la Ethereum.
Acest lucru a funcționat bine pentru L2 precum Arbitrum și Optimism, care expun starea finală a Ethereum.
Dar acest design a fost limitativ...
Pentru lanțurile non-EVM, cum ar fi BSC, acest model se defectează.
Nu există o modalitate canonică de a verifica starea Ethereum. Acest lucru a însemnat fie să construiască adaptoare personalizate, fie să nu suporte deloc acele lanțuri.
Niciuna dintre acestea nu este o soluție optimă. Așa că ne-am dat seama de o modalitate mai bună de a folosi ZKP-urile.
Iată procesul:
Când relayer-urile completează comenzile crosschain, tranzacțiile sunt grupate în pachete de rambursare, care sunt apoi verificate de Optimistic Oracle de la @UMAProtocol.
Acest lucru se întâmplă întotdeauna pe rețeaua principală Ethereum.
Odată ce un pachet este verificat, Across HubPool declanșează procesul de decontare.
Apoi scrie hash-urile mesajului de rambursare în contractul HubPoolStore în anumite sloturi de stocare.
Acest eveniment de stocare se întâmplă și pe rețeaua principală Ethereum.
Fiecare hash de mesaj din contractul HubPoolStore corespunde unei intenții de a rambursa un relayer pe un lanț de destinație.
Rețineți că mesajele L1 → L2 pot reprezenta mai multe rambursări (inclusiv completări lente). Acest lucru se datorează faptului că sunt mănunchiuri de rădăcini.
Când contractul HubPoolStore scrie un hash de mesaj stocat, emite un eveniment StoredCallData.
Acest eveniment conține hash-ul mesajului și slotul de stocare.
Evenimentul + datele stocate formează ancora pentru verificarea ZK în aval.
Un serviciu numit finalizator ascultă acele evenimente.
Odată ce detectează unul nou, inițiază un proces pentru a dovedi că hash-ul mesajului a fost într-adevăr scris pe Ethereum.
Fiecare mesaj, pentru care este stocat hash-ul, are o țintă care poate fi specifică lanțului său.
Această dovadă permite executarea în siguranță a mesajului pe lanțul de destinație.
Dar finalitatea Ethereum nu este instantanee.
Odată ce finalizatorul trimite datele către API-ul ZK, API-ul așteaptă prin fereastra de finalitate a Ethereum înainte de a genera o dovadă.
Pentru a genera o dovadă ZK validă, comitetul de sincronizare Ethereum trebuie să semneze un anumit bloc finalizat.
Dacă mesajul a fost inclus în sau înainte de acel bloc, semnăturile necesare devin disponibile pentru a începe generarea dovezii ZK.
Finalizatorul interoghează API-ul ZK pentru a genera o dovadă că un anumit hash de mesaj a fost scris într-un slot de stocare HubPoolStore cunoscut într-un bloc Ethereum finalizat.
Acest lucru permite verificarea fără încredere a rambursărilor de retransmisie pe orice lanț de destinație.
ZK API pregătește date de probă, inclusiv (dar fără a se limita la):
- Anteturi de baliză finalizate
- Sincronizarea semnăturilor comitetului
- Dovezile Merkle de stocare din stratul de execuție al Ethereum
Acestea formează baza pentru generarea dovezii.
Across implementează o stivă generică pe lanțurile de destinație:
- Un contract de verificare (validează dovada ZK)
- SP1Helios de @Succinct (stochează starea Ethereum finalizată)
- Contractul UniversalSpokepool (verifică autenticitatea mesajelor în timpul execuției)
Odată ce dovada ZK este verificată și starea este confirmată, executeMsg() poate rula în siguranță sarcina utilă pe lanțul de destinație.
Fără încredere. Sigur. Universal.
Aceasta înseamnă că Across nu mai are nevoie de adaptoare personalizate pentru fiecare lanț.
O singură conductă care funcționează peste tot:
storeMsg() pe Ethereum → ZK proof → executeMsg() pe orice lanț de destinație care poate verifica dovada SP1Helios.
Fără presupuneri de încredere.
Fără cheltuieli generale de integrare.
Doar intenții + ZK.
De ce este mare lucru?
Extinde dramatic acoperirea Across, deblocând suportul pentru lanțurile cu coadă lungă care nu pot verifica starea Ethereum nativ și nu au punți canonice.
Acest lucru face ca integrarea să fie mai rapidă, mai sigură și mai scalabilă.
Across nu are nevoie de o punte canonică pentru aceste lanțuri. Are nevoie doar de capacitatea de a verifica o dovadă ZK a stării Ethereum.
Acest lucru reduce cheltuielile generale de integrare, evită riscul de punte centralizată și întărește rolul Ethereum ca rădăcină a adevărului crosschain.
12,1 K
62
Conținutul de pe această pagină este furnizat de terți. Dacă nu se menționează altfel, OKX nu este autorul articolului citat și nu revendică niciun drept intelectual pentru materiale. Conținutul este furnizat doar pentru informare și nu reprezintă opinia OKX. Nu este furnizat pentru a fi o susținere de nicio natură și nu trebuie să fie considerat un sfat de investiție sau o solicitare de a cumpăra sau vinde active digitale. În măsura în care AI-ul de generare este utilizat pentru a furniza rezumate sau alte informații, astfel de conținut generat de AI poate să fie inexact sau neconsecvent. Citiți articolul asociat pentru mai multe detalii și informații. OKX nu răspunde pentru conținutul găzduit pe pagini terțe. Deținerile de active digitale, inclusiv criptomonedele stabile și NFT-urile, prezintă un grad ridicat de risc și pot fluctua semnificativ. Trebuie să analizați cu atenție dacă tranzacționarea sau deținerea de active digitale este adecvată pentru dumneavoastră prin prisma situației dumneavoastră financiare.