Scris de: Vitalik Buterin

Compilat: Mensh, ChainCatcher

Mulțumiri speciale lui Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams și Uma Roy pentru feedback-ul și revizuirile lor.

Una dintre cele mai puternice caracteristici ale blockchain-ului este că oricine poate rula un nod pe propriul computer și valida corectitudinea blockchain-ului. Chiar dacă 9596 de noduri care rulează consensul lanțului (PoW, PoS) ar fi de acord imediat cu modificarea regulilor și ar începe să producă blocuri conform noilor reguli, fiecare persoană care rulează un nod complet validat ar refuza să accepte lanțul. Minerii care nu fac parte din acest grup conspirativ s-ar aduna automat la un lanț care continuă să respecte regulile vechi și continuă să construiască acest lanț, în timp ce utilizatorii complet validați vor urma acest lanț.

Aceasta este diferența cheie între blockchain și sistemele centralizate. Cu toate acestea, pentru a face această caracteristică să funcționeze, rularea unui nod complet validat trebuie să fie într-adevăr fezabilă pentru un număr suficient de oameni. Acest lucru se aplică atât celor care creează, deoarece dacă constructorii nu validează lanțul, ei nu contribuie la respectarea regulilor protocolului, cât și utilizatorilor obișnuiți. Astăzi, este posibil să rulezi un nod pe laptopuri de consum (inclusiv laptopul folosit pentru a scrie acest articol), dar a face acest lucru este destul de dificil. The Verge își propune să schimbe această situație, făcând costurile de calcul pentru a valida complet lanțul să devină accesibile, astfel încât fiecare portofel de telefon, portofel de browser sau chiar smartwatch să efectueze validarea implicit.

Foia de parcurs The Verge 2023

Inițial, „Verge” se referea la transferul stocării stării Ethereum în arborele Verkle - o structură arbore care permite dovezi mai compacte pentru validarea fără stare a blocurilor Ethereum. Nodurile pot valida un bloc Ethereum fără a stoca nicio stare Ethereum (solduri de cont, cod de contract, spații de stocare...), costând câteva sute de KB de date de dovadă și câteva sute de milisecunde de timp suplimentar pentru a valida o dovadă. Astăzi, Verge reprezintă o viziune mai mare, concentrându-se pe realizarea validării cu maximă eficiență a resurselor pentru lanțul Ethereum, care include nu doar tehnici de validare fără stare, ci și utilizarea SNARK-ului pentru a valida toate execuțiile Ethereum.

Pe lângă atenția pe termen lung asupra validării întregului lanț cu SNARK, o altă problemă nouă este dacă arborele Verkle este cea mai bună tehnologie. Arborele Verkle este vulnerabil la atacuri ale calculatoarelor cuantice, așa că, dacă înlocuim arborele Verkle în arborele Merkle Patricia actual, va trebui să-l înlocuim din nou mai târziu. Metoda de auto-substituție a arborelui Merkle este să sărim direct peste utilizarea ramurilor Merkle cu STARK, plasându-le într-un arbore binar. Istoric, această metodă a fost considerată impracticabilă din cauza costurilor și complexității tehnice. Cu toate acestea, recent, am observat că Starkware a utilizat STARK-uri ckcle pe un laptop pentru a demonstra 1,7 milioane de hash-uri Poseidon pe secundă, iar datorită apariției tehnologiilor precum GKB, timpul de demonstrare pentru mai multe hash-uri „tradiționale” se scurtează rapid. Prin urmare, în ultimul an, „Verge” a devenit mai deschis, având mai multe posibilități.

The Verge: obiectivele cheie

  • Client fără stare: spațiul de stocare necesar pentru un client complet validat și pentru un nod marcat nu ar trebui să depășească câțiva GB.

  • (Pe termen lung) validarea completă a lanțului pe smartwatch-uri (consens și execuție). Descarcă câteva date, validează SNARK, finalizează.

În acest capitol

  • Client fără stare: Verkle sau STARK-uri

  • Dovada de validitate a execuției EVM

  • Dovada de validitate a consensului

Validare fără stare: Verkle sau STARK-uri

Ce problemă încercăm să rezolvăm?

În prezent, clienții Ethereum trebuie să stocheze sute de terabytes de date de stare pentru a valida blocuri, iar această cantitate crește anual. Datele de stare originale cresc cu aproximativ 30GB pe an, iar un singur client trebuie să stocheze unele date suplimentare pentru a actualiza eficient tripletele.

Aceasta a redus numărul de utilizatori care pot rula un nod Ethereum complet validat: deși hard disk-uri mari care pot stoca toate stările Ethereum sau chiar istorii extinse sunt disponibile pe scară largă, computerele pe care oamenii le cumpără în mod implicit au adesea doar câteva sute de gigabytes de stocare. Dimensiunea stării aduce de asemenea o frecare imensă în procesul de stabilire a nodurilor: nodul trebuie să descarce întreaga stare, ceea ce poate dura ore sau zile. Acest lucru generează o serie de reacții în lanț. De exemplu, crește semnificativ dificultatea de a actualiza setările nodului de către creatorii de noduri. Din punct de vedere tehnic, este posibil să se finalizeze actualizarea fără a opri nodul - pornind un nou client, așteptând să se sincronizeze, apoi închizând clientul vechi și transferând cheile - dar în practică, aceasta este foarte complex din punct de vedere tehnic.

Cum funcționează?

Validarea fără stare este o tehnică care permite nodurilor să valideze blocurile fără a deține întreaga stare. În schimb, fiecare bloc vine cu o mărturie care include: (i) valorile, codul, soldurile, stocările de la anumite locații din starea accesată de acest bloc; (ii) o dovadă criptografică că aceste valori sunt corecte.

De fapt, implementarea validării fără stare necesită schimbarea structurii arborelui de stare al Ethereum. Aceasta se datorează faptului că arborele Merkle Patricia actual este extrem de neprietenos pentru implementarea oricărui plan de dovadă criptografică, mai ales în cel mai rău caz. Fie că este vorba de ramuri „pure” Merkle, fie de posibilitatea de a le „împacheta” în STARK, ambele sunt problematice. Dificultățile principale provin din unele slăbiciuni ale MPT-ului:

1. Este un arbore cu șase ramuri (adică fiecare nod are 16 subnoduri). Aceasta înseamnă că într-un arbore de dimensiune N, o dovadă necesită în medie 32*(16-1)*log16(N) = 120* log2(N) bytes, sau aproximativ 3840 bytes într-un arbore cu 2^32 elemente. Pentru un arbore binar, este necesar doar 32*(2-1)*log2(N) = 32* log2(N) bytes, sau aproximativ 1024 bytes.

2. Codul nu a fost Merkleizat. Aceasta înseamnă că, pentru a dovedi orice acces la codul contului, trebuie să se furnizeze întregul cod, până la 24000 de bytes.

Putem calcula cel mai rău caz astfel:

30000000 gaz / 2400 (costul citirii unui cont rece) * (5 * 488 + 24000) = 330000000 bytes

Costul ramurilor a fost ușor redus (folosind 5*480 în loc de 8*480), deoarece partea superioară a ramurii se repetă atunci când există multe ramuri. Dar chiar și așa, volumul de date de descărcat într-un slot este complet nerealist. Dacă încercăm să împachetăm acest lucru cu STARK, ne vom confrunta cu două probleme: (i) KECCAK este relativ neprietenos cu STARK; (ii) 330MB de date înseamnă că trebuie să demonstrăm 5 milioane de apeluri ale funcției round KECCAK, ceea ce ar putea fi imposibil pentru orice hardware care nu este cel mai puternic din clasa de consum, chiar dacă am putea face STARK să demonstreze KECCAK mai eficient.

Dacă am înlocui direct arborele hexazecimal cu un arbore binar și am efectua o prelucrare suplimentară a Merkle asupra codului, cel mai rău caz ar deveni aproximativ 30000000/2400*32*(32-14+8) = 10400000 bytes (14 este o reducere a bitilor redundanți pentru ramurile de 2^14, iar 8 este lungimea dovezii care intră în blocul de cod). Este important de menționat că acest lucru necesita modificarea costurilor de gaz, taxând accesul fiecărui bloc de cod individual; EIP-4762 face exact asta. O capacitate de 10.4 MB este mult mai bună, dar pentru multe noduri, volumul de date de descărcat într-un slot este totuși prea mare. Prin urmare, trebuie să introducem tehnici mai puternice. În acest sens, există două soluții de frunte: arborele Verkle și arborele hash binar STARKed.

Verkle arbore

Arborele Verkle utilizează un angajament vectorial bazat pe curbe eliptice pentru a realiza dovezi mai scurte. Cheia deblocării este că, indiferent de lățimea arborelui, fiecare relație părinte-copil corespunde unei părți a dovezii de 32 de bytes. Singura limitare a lățimii arborelui dovezii este că, dacă arborele dovezii este prea lat, eficiența calculului dovezii se va reduce. Planul propus pentru Ethereum are o lățime de 256.

Astfel, dimensiunea unei ramuri individuale în dovadă devine 32 - 1og256(N) = 4* log2(N) bytes. Prin urmare, dimensiunea maximă teoretică a dovezii este aproximativ 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 bytes (deoarece distribuția blocului de stare nu este uniformă, rezultatul real poate varia ușor, dar ca primă aproximare este acceptabil).

În plus, este important de menționat că în toate exemplele de mai sus, acest „cel mai rău caz” nu este cel mai rău caz: un caz și mai rău este că un atacator ar exploata intenționat două adrese astfel încât acestea să aibă un prefix comun mai lung în arbore, citind date din una dintre adrese, ceea ce ar putea extinde lungimea ramurii în cel mai rău caz cu încă 2 ori. Dar chiar și în această situație, lungimea maximă a dovezii arborelui Verkle este de 2,6MB, ceea ce se aliniază în mod practic cu datele de verificare din cel mai rău caz de acum.

Am folosit, de asemenea, această observație pentru a face un alt lucru: am redus costul de acces la spațiul de stocare „vecin” la un nivel foarte scăzut: fie multe blocuri de cod din același contract, fie sloturi de stocare adiacente. EIP - 4762 oferă o definiție a adiacenței, permițându-le accesul adiacente doar cu o taxă de gaz de 200. În cazul accesului adiacente, dimensiunea dovezii în cel mai rău caz devine 30000000 / 200*32 - 4800800 bytes, care se află totuși în intervalul de toleranță. Dacă dorim să reducem acest lucru din motive de securitate, putem crește ușor taxa pentru accesul adiacente.

Arborele hash binar STARKed

Principiul acestei tehnologii este evident: pur și simplu construiești un arbore binar, obții o dovadă maximă de 10.4 MB, dovedești valorile din bloc și apoi înlocuiești dovada cu STARK-ul. Astfel, dovada conține doar datele dovedite, plus un cost fix de 100-300kB din STARK-ul real.

Provocarea principală aici este timpul de validare. Putem efectua calculele exact ca cele de mai sus, doar că ceea ce calculăm nu sunt bytes ci valori hash. Un bloc de 10.4 MB înseamnă 330000 hash-uri. Dacă adăugăm și posibilitatea ca un atacator să „exploateze” arborele adreselor având un prefix comun mai lung, atunci în cel mai rău caz numărul de hash-uri va ajunge la aproximativ 660000. Așadar, dacă putem dovedi 200,000 hash-uri pe secundă, nu este o problemă.

Aceste numere au ajuns la laptopuri de consum care folosesc funcția hash Poseidon, care este proiectată special pentru a fi prietenoasă cu STARK. Cu toate acestea, sistemul Poseidon este, de asemenea, relativ imatur, așa că mulți oameni nu au încredere în securitatea sa. Prin urmare, există două căi realiste de avansare:

  1. Analizează rapid Poseidon pentru a efectua o analiză de securitate extinsă și a deveni suficient de familiar cu el pentru a-l implementa în L1.

  2. Folosind o funcție hash „mai conservatoare”, precum SHA256 sau BLAKE.

Dacă dorim să dovedim funcții hash conservatoare, cercul STARK al Starkware putea demonstra 10-30k hash-uri pe secundă pe laptopuri de consum la momentul redactării acestui articol. Cu toate acestea, tehnologia STARK se îmbunătățește rapid. Chiar și astăzi, tehnologia bazată pe GKR arată promisiunea de a crește această viteză la 100-200k.

Cazuri de utilizare ale mărturiei în afara validării blocurilor

Pe lângă validarea blocurilor, există și alte trei cazuri cheie de utilizare care necesită validare fără stare mai eficientă:

  • Mempool: Când tranzacțiile sunt difuzate, nodurile din rețeaua P2P trebuie să verifice validitatea tranzacției înainte de a o retransmite. Astăzi, validarea include verificarea semnăturilor, dar și verificarea dacă soldul este suficient și dacă prefixul este corect. În viitor (de exemplu, folosind abstractizarea conturilor native, cum ar fi EIP-7701, care ar putea implica rularea unui cod EVM care va efectua unele accesări ale stării), dacă nodul este fără stare, tranzacția trebuie să vină cu o dovadă a obiectului de stare.

  • Lista de incluziune: aceasta este o caracteristică propusă care permite (poate la o scară mai mică și mai puțin complexă) validatorilor pentru dovezi de participare să forțeze următorul bloc să includă tranzacții, indiferent de voința constructorului de bloc (posibil la o scară mai mare și mai complexă). Acest lucru ar slăbi capacitatea celor puternici de a manipula blockchain-ul prin întârzierea tranzacțiilor. Cu toate acestea, acest lucru necesită ca validatorii să aibă un mod de a verifica validitatea tranzacțiilor incluse în listă.

  • Client ușor: Dacă dorim ca utilizatorii să acceseze lanțul prin portofele (cum ar fi Metamask, Rainbow, Rabby etc.), pentru a face acest lucru, trebuie să ruleze un client ușor (de exemplu, Helios). Modulul central Helios le oferă utilizatorilor rădăcina de stare verificată. Și pentru a obține o experiență complet fără încredere, utilizatorii trebuie să ofere dovada pentru fiecare apel RPC efectuat (de exemplu, pentru cererile de apel Ethereum utilizatorii trebuie să demonstreze toată starea accesată în timpul apelului).

Toate aceste cazuri de utilizare au un punct comun, și anume că necesită o cantitate considerabilă de dovezi, dar fiecare dovadă este foarte mică. Prin urmare, dovezile STARK nu sunt de mare ajutor pentru acestea; dimpotrivă, cea mai realistă abordare este utilizarea directă a ramurilor Merkle. Un alt avantaj al ramurilor Merkle este actualizarea: având o dovadă a unui obiect de stare X, cu rădăcina blocului B, dacă primim un sub-bloc B2 și mărturia sa, putem actualiza dovada pentru a avea rădăcina B2. Dovezile Verkle sunt, de asemenea, nativ actualizabile.

Ce legături există cu cercetările existente:

  • Arborele Verkle

  • Lucrarea originală a lui John Kuszmaul despre arborele Verkle

  • Starkware

  • Lucrarea Poseidon2

  • Ajtai (o alternativă rapidă de funcție hash bazată pe duritatea rețelelor)

  • Verkle.info

Ce altceva se poate face?

Lucrările principale rămase sunt

1. O analiză mai detaliată a consecințelor EIP-4762 (modificări ale costului de gaz fără stare)

2. Mai multă muncă pentru a finaliza și testa programele de tranziție, care reprezintă principala parte a complexității oricărei soluții fără naționalitate.

3. Analiza de securitate suplimentară pentru funcțiile hash Poseidon, Ajtai și alte funcții „prietenoase cu STARK”

4. Dezvoltarea de protocoale STARK ultra-eficiente pentru „conservatoare” (sau „tradiționale”) hash-uri, cum ar fi conceptele bazate pe Binius sau GKR.

În plus, în curând vom decide asupra uneia dintre cele trei opțiuni: (i) arborele Verkle, (ii) funcții hash prietenoase cu STARK și (iii) funcții hash conservatoare. Caracteristicile lor pot fi rezumate în tabelul de mai jos:

Pe lângă aceste „numere de titlu”, există și alte câteva considerații importante:

  • Astăzi, codul arborelui Verkle este deja destul de matur. Pe lângă Verkle, utilizarea oricărui alt cod ar întârzia implementarea, cel mai probabil ar întârzia un hard fork. Acest lucru nu este neapărat o problemă, mai ales dacă avem nevoie de timp suplimentar pentru analiza funcțiilor hash sau implementarea validatorilor, sau dacă avem alte caracteristici importante pe care dorim să le integrăm mai devreme în Ethereum.

  • Actualizarea rădăcinii de stare folosind valori hash este mai rapidă decât utilizarea arborelui Verkle. Aceasta înseamnă că metoda bazată pe hash-uri poate reduce timpul de sincronizare pentru nodurile complete.

  • Arborele Verkle are proprietăți interesante de actualizare a mărturiei - mărturia arborelui Verkle este actualizabilă. Această proprietate este utilă pentru mempool, listele de includere și alte cazuri de utilizare și ar putea ajuta, de asemenea, la îmbunătățirea eficienței implementării: dacă obiectul de stare este actualizat, se poate actualiza mărturia din penultimul strat fără a citi conținutul ultimului strat.

  • Arborele Verkle este mai greu de dovedit cu SNARK. Dacă dorim să reducem dimensiunea dovezilor la câteva mii de bytes, dovezile Verkle vor prezenta unele dificultăți. Acest lucru se datorează faptului că verificarea dovezilor Verkle introduce un număr mare de operații de 256 de biți, ceea ce necesită fie o mulțime de costuri, fie o structură internă personalizată care conține o parte de dovadă Verkle de 256 de biți. Acest lucru nu este o problemă în sine pentru fără stare, dar va aduce mai multe dificultăți.

Dacă dorim să obținem actualizabilitatea mărturiei Verkle într-un mod sigur din punct de vedere cuantitic și rezonabil de eficient, o altă posibilă abordare ar fi arborele Merkle bazat pe lattice.

Dacă, în cel mai rău caz, eficiența sistemului de dovezi nu este suficient de ridicată, putem folosi acest instrument neașteptat al gazului multidimensional pentru a compensa acest deficit: stabilirea unor limite separate pentru gaz pentru (i) calldata; (ii) calcul; (iii) accesarea stării și posibil alte resurse diferite. Gazul multidimensional crește complexitatea, dar în schimb, limitează mai strict raportul dintre medie și cel mai rău caz. Cu gazul multidimensional, numărul maxim de ramuri care trebuie dovedite ar putea fi redus de la 12500 la, de exemplu, 3000. Acest lucru ar face ca BLAKE3 să fie (chiar și astăzi) suficient.

Gazul multidimensional permite limitarea resurselor blocului să fie mai aproape de limitările resurselor hardware de bază.

Un alt instrument neașteptat este amânarea calculării rădăcinii de stare până în slotul de după bloc. Astfel, avem 12 secunde întregi pentru a calcula rădăcina de stare, ceea ce înseamnă că chiar și în cele mai extreme cazuri, timpul de dovadă de 60000 de hash-uri pe secundă este suficient, ceea ce ne face să credem că BLAKE3 poate să îndeplinească cerințele.

Dezavantajul acestei metode este că va crește întârzierea clientului ușor într-un slot, dar există tehnici mai ingenioase care pot reduce această întârziere la doar întârzierea generării dovezii. De exemplu, dovada poate fi difuzată pe rețea imediat după ce este generată de orice nod, fără a aștepta următorul bloc.

Cum interacționează cu alte părți ale foii de parcurs?

Rezolvarea problemei de validare fără stare crește semnificativ dificultatea punctului unic. Dacă există tehnologie care poate reduce soldul minim pentru punctul unic, cum ar fi Orbit SSF sau strategii la nivel de aplicație, cum ar fi punctele de echipă, ar putea deveni mai fezabil.

Dacă se introduce EOF în același timp, analiza gazului multidimensional devine mai ușoară. Acest lucru se datorează faptului că principala complexitate de execuție a gazului multidimensional provine din gestionarea apelurilor secundare care nu transmit toate gazele apelurilor părinte, iar EOF ar putea să facă astfel de apeluri ilegale, făcând această problemă neglijabilă (iar abstractizarea conturilor native va oferi o alternativă în protocol pentru utilizarea principală a gazului).

Există, de asemenea, o sinergie importantă între validarea fără stare și expirarea istorică. În prezent, clienții trebuie să stocheze aproape 1 TB de date istorice; aceste date sunt de mai multe ori mai mari decât datele de stare. Chiar dacă clientul este fără stare, cu excepția cazului în care putem elimina responsabilitatea clientului de a stoca datele istorice, visul unui client aproape fără stocare va rămâne imposibil de realizat. Primul pas în această direcție este EIP-4444, care implică, de asemenea, stocarea datelor istorice în torrente sau în rețeaua Portal.

Dovada de validitate a execuției EVM

Ce problemă încercăm să rezolvăm?

Obiectivul pe termen lung al validării blocurilor Ethereum este clar - ar trebui să putem valida blocurile Ethereum prin: (i) descărcarea blocului, sau chiar doar descărcarea unei părți mici a eșantionării disponibilității datelor din bloc; (ii) validarea unui mic dovadă că blocul este valid. Aceasta va fi o operațiune cu un consum extrem de scăzut de resurse, care poate fi realizată pe clienți mobili, portofele de browser și chiar pe un alt lanț (fără partea de disponibilitate a datelor).

Pentru a atinge acest lucru, este necesară o dovadă SNARK sau STARK pentru (i) stratul de consens (adică dovada participării) și (ii) stratul de execuție (adică EVM). Prima este o provocare în sine și ar trebui rezolvată în timpul îmbunătățirii continue a stratului de consens (de exemplu, în ceea ce privește finalizarea pe un singur slot). Cea de-a doua necesită dovezi de execuție EVM.

Ce este și cum funcționează?

Din punct de vedere formal, EVM este definit ca o funcție de tranziție a stării: ai o stare anterioară S, un bloc B, și calculezi o stare ulterioară S' = STF(S, B). Dacă utilizatorul utilizează un client ușor, ei nu dețin complet S și S', nici E; în schimb, au o rădăcină a stării anterioare R, o rădăcină a stării ulterioare R' și un hash de bloc H.

  • Intrare publică: rădăcina stării anterioare R, rădăcina stării ulterioare R', hash-ul blocului H

  • Intrare privată: corpul blocului de program B, obiectele din starea accesată de blocul de program Q, aceleași obiecte după execuția blocului de program Q', dovada stării (cum ar fi ramura Merkle) P

  • Afirmatia 1: P este o dovadă validă, care demonstrează că Q conține anumite părți ale stării reprezentate de R

  • Afirmatia 2: Dacă se execută STF pe Q, (i) procesul de execuție accesează doar obiectele interne ale Q, (ii) blocul de date este valid, (iii) rezultatul este Q'

  • Afirmatia 3: Dacă se recalculează noua rădăcină a stării utilizând informațiile din Q' și P, se va obține R'

Dacă există o astfel de situație, ar putea exista un client ușor complet care validează execuția EVM Ethereum. Aceasta face ca resursele clientului să fie deja destul de reduse. Pentru a realiza un client Ethereum complet validat, trebuie să se facă același lucru în ceea ce privește consensul.

Implementarea dovezilor de validitate pentru calculul EVM există deja și este utilizată pe scară largă în L2. Cu toate acestea, pentru a face dovezile de validitate EVM viabile în L1, mai este mult de lucru.

Ce legături există cu cercetările existente?

  • EFPSE ZK-EVM (acum dezactivat din cauza unor opțiuni mai bune)

  • Zeth, care funcționează prin compilarea EVM în RISC-0 ZK-VM

  • Proiectul de verificare formală ZK-EVM

Ce altceva se poate face?

Astăzi, dovezile de validitate ale sistemelor de contabilitate electronice au deficiențe în două domenii: securitate și timp de validare.

O dovadă de validitate sigură și eficientă trebuie să garanteze că SNARK a verificat într-adevăr calculul EVM-ului și că nu există vulnerabilități. Cele două tehnici principale pentru creșterea securității sunt multi-verificatorii și verificarea formală. Multi-verificatorii se referă la implementări multiple și independente ale dovezilor de validitate, la fel cum există mai mulți clienți, astfel încât, dacă un bloc este dovedit de un subset suficient de mare dintre aceste implementări, clientul va accepta acel bloc. Verificarea formală implică utilizarea unor instrumente de obicei folosite pentru a demonstra teoreme matematice, cum ar fi Lean4, pentru a demonstra că dovezile de validitate acceptă doar execuții corecte ale specificației EVM-ului de bază (de exemplu, semantica EVM K sau specificația stratului de execuție Ethereum (EELS) scrisă în Python).

Timpul de validare suficient de rapid înseamnă că orice bloc Ethereum poate fi validat în mai puțin de 4 secunde. Astăzi, suntem încă departe de acest obiectiv, deși ne apropiem mai mult decât ne-am imaginat acum doi ani. Pentru a atinge acest obiectiv, trebuie să facem progrese în trei direcții:

  • Paralelizarea - cel mai rapid validatoare EVM de astăzi poate dovedi un bloc Ethereum în medie în 15 secunde. Acest lucru se realizează prin paralelizarea pe sute de GPU-uri și apoi agregarea muncii lor în final. Din punct de vedere teoretic, știm exact cum să construim un validator EVM care poate demonstra calculul în O(log(N)) timp: să lăsăm un GPU să finalizeze fiecare pas și apoi să facem un „arbore de agregare”.

Există provocări în implementarea acestui lucru. Chiar și în cel mai rău caz, unde o tranzacție foarte mare ocupă întregul bloc, divizarea calculelor nu poate fi făcută pe apeluri, ci trebuie făcută pe opcode-uri (cum ar fi opcode-uri EVM sau RISC-V). Asigurarea că „memoria” virtuală rămâne consistentă între diferitele părți ale dovezii este o provocare cheie în procesul de implementare. Totuși, dacă putem realiza această dovadă recursivă, știm că, chiar și fără alte îmbunătățiri, problema întârzierii doveditorului a fost rezolvată.

  • Optimizarea sistemului de dovezi - noi sisteme de dovezi, precum Orion, Binius, GRK și multe altele, vor duce cel mai probabil la o scurtare semnificativă a timpului de validare pentru calculul general.

  • Alte modificări ale costurilor de gaz EVM - multe lucruri din EVM pot fi optimizate pentru a fi mai favorabile pentru doveditori, în special în cel mai rău caz. Dacă un atacator poate construi un bloc care blochează doveditorul timp de zece minute, atunci doar a putea dovedi un bloc Ethereum în 4 secunde nu este suficient. Modificările necesare EVM pot fi aproximativ împărțite în următoarele categorii:

  • Modificări ale costurilor de gaz - dacă o operațiune necesită mult timp pentru a fi dovedită, atunci chiar și cu o viteză de calcul relativ rapidă, ar trebui să aibă un cost de gaz ridicat. EIP-7667 este o EIP propusă pentru a aborda cele mai grave probleme în această privință: aceasta crește semnificativ costul de gaz pentru funcțiile hash „tradiționale”, deoarece opcode-urile și precompilările acestor funcții sunt relativ ieftine. Pentru a compensa aceste creșteri ale costurilor de gaz, putem reduce costurile de gaz pentru opcode-urile EVM care au un cost de dovadă relativ mai scăzut, menținând astfel un throughput mediu constant.

  • Înlocuirea structurilor de date - pe lângă înlocuirea arborelui de stare cu o metodă mai prietenoasă cu STARK, trebuie să înlocuim și lista de tranzacții, arborele de chitanțe și alte structuri costisitoare. Propunerea lui Etan Kissling de a muta structurile de tranzacții și chitanțe în EIP SSZ este un pas în această direcție.

În plus, cele două instrumente menționate în secțiunea precedentă (gaz multidimensional și rădăcină de stare întârziată) pot ajuta în acest sens. Cu toate acestea, este important de menționat că, spre deosebire de validarea fără stare, utilizarea acestor două instrumente înseamnă că avem deja tehnologia suficientă pentru a finaliza lucrările necesare în prezent, iar chiar și cu aceste tehnici, validarea completă ZK-EVM necesită mai multă muncă - doar că munca necesară este mai puțin.

Un punct care nu a fost menționat anterior este hardware-ul doveditorului: generarea mai rapidă a dovezilor folosind GPU-uri, FPGA-uri și ASIC-uri. Fabric Cryptography, Cysic și Accseal sunt trei companii care au realizat progrese în acest domeniu. Aceasta este extrem de valoroasă pentru L2, dar este puțin probabil să devină un factor decisiv pentru L1, deoarece se dorește în mod clar ca L1 să rămână extrem de descentralizat, ceea ce înseamnă că generarea dovezilor trebuie să fie în limitele rezonabile pentru utilizatorii Ethereum și nu ar trebui să fie restricționată de hardware-ul unei singure companii. L2 poate face compromisuri mai agresive.

În aceste domenii, mai este mult de lucru:

  • Paralelizarea dovezilor necesită ca diferitele părți ale sistemului de dovezi să poată „partaja memorie” (de exemplu, tabele de căutare). Știm cum să facem acest lucru tehnic, dar trebuie implementat.

  • Trebuie să facem mai multe analize pentru a identifica setul ideal de variații ale costului de gaz, astfel încât să maximizăm timpul de validare în cel mai rău caz.

  • Trebuie să lucrăm mai mult la sistemul de dovezi.

Costurile posibile sunt:

  • Securitate și timpul validatorilor: alegerea unei funcții hash mai agresive, a unui sistem de dovezi mai complex sau a unor ipoteze de securitate mai îndrăznețe sau alte scheme de design poate reduce timpul validatorilor.

  • Decentralizare și timpul dovadelor: comunitatea trebuie să ajungă la un consens asupra specificațiilor hardware-ului pentru dovezi. Este acceptabil să cerem ca dovada să fie o entitate de mari dimensiuni? Vrem ca laptopurile de consum de înaltă performanță să poată dovedi un bloc Ethereum în 4 secunde? Între cele două extreme?

  • Gradul de compatibilitate înapoi: deficiențele din alte domenii pot fi compensate prin modificări mai agresive ale costului de gaz, dar este mai probabil ca acestea să crească disproporționat costurile pentru anumite aplicații, forțând dezvoltatorii să rescrie și să redeployeze codul pentru a menține viabilitatea economică. La fel, aceste două instrumente au propriile lor complexități și dezavantaje.

Cum interacționează cu alte părți ale foii de parcurs?

Tehnologiile fundamentale necesare pentru a implementa dovezile de validitate EVM L1 sunt în mare parte comune cu celelalte două domenii:

  • Dovezile de validitate L2 (adică „ZK rollup”)

  • Metoda de „dovadă binară hash fără stare STARK”

Odată ce dovezile de validitate EVM sunt implementate cu succes în L1, se va putea în cele din urmă facilita stocarea ușoară a persoanelor fizice: chiar și cele mai slabe calculatoare (inclusiv telefoanele mobile sau smartwatch-urile) vor putea să participe. Aceasta va crește și valoarea de a rezolva alte restricții asupra stocării personale, cum ar fi limita minimă de 32ETH.

În plus, dovezile de validitate EVM din L1 pot îmbunătăți semnificativ limitele de gaz L1.

Dovada de validitate a consensului

Ce problemă încercăm să rezolvăm?

Dacă vrem să validăm complet un bloc Ethereum cu SNARK, atunci execuția EVM nu este singura parte pe care trebuie să o demonstrăm. De asemenea, trebuie să demonstrăm consensul, adică părțile sistemului care se ocupă de depozite, retrageri, semnături, actualizări ale soldurilor validatorilor și alte elemente din partea de dovezi a Ethereum.

Consensul este mult mai simplu decât EVM, dar provocarea cu care se confruntă este că nu avem convoluții EVM L2, deci, în orice caz, cea mai mare parte a muncii trebuie să fie realizată. Astfel, orice implementare a dovezilor de consens Ethereum trebuie să fie „de la zero”, deși sistemul de dovezi în sine poate fi construit pe baza muncii comune.

Ce este și cum funcționează?

Lanțul de semnal este definit ca o funcție de tranzitie a stării, la fel ca EVM. Funcția de tranziție a stării se compune din trei părți principale:

  • ECADD (pentru validarea semnăturilor BLS)

  • Pereche (pentru validarea semnăturilor BLS)

  • SHA256 hash (pentru citirea și actualizarea stării)

În fiecare bloc, avem nevoie de dovezi pentru 1-16 ECADD-uri BLS12-381 pentru fiecare validator (posibil mai mult de unul, deoarece semnătura poate fi inclusă în mai multe seturi). Acest lucru poate fi compensat prin tehnica de pre-calculare a sub-seturilor, astfel încât putem spune că fiecare validator trebuie să dovedească doar un ECADD BLS12-381. În prezent, fiecare slot are 30000 de semnături de validator. În viitor, odată cu implementarea finalizării pe un singur slot, această situație poate varia în două direcții: dacă urmăm abordarea „brută”, numărul validatorilor pe fiecare slot poate crește până la 1 milion. În același timp, dacă adoptăm Orbit SSF, numărul validatorilor va rămâne la 32768 sau chiar se va reduce la 8192.

Cum funcționează agregarea BLS: validarea semnăturii totale necesită un ECADD pentru fiecare participant, nu un ECMUL. Totuși, 30000 de ECADD-uri sunt încă o cantitate mare de dovezi.

În ceea ce privește perechile, în prezent, fiecare slot are un maxim de 128 de dovezi, ceea ce înseamnă că trebuie verificate 128 de perechi. Prin ElP-7549 și modificări ulterioare, fiecare slot poate fi redus la 16. Numărul de perechi este mic, dar costul este extrem de mare: timpul de execuție (sau de dovadă) pentru fiecare pereche este de mii de ori mai lung decât ECADD.

O provocare majoră în dovedirea operațiunilor BLS12-381 este că nu există curbe convenabile cu un ordin de curba egal cu dimensiunea câmpului BLS12-381, ceea ce adaugă un cost considerabil pentru orice sistem de dovezi. Pe de altă parte, arborele Verkle propus pentru Ethereum este construit pe curba Bandersnatch, ceea ce face ca BLS12-381 să fie în sine o curbă proprie utilizată pentru a dovedi ramurile Verkle în sistemul SNARK. O implementare mai simplă poate dovedi 100 G1 adunări pe secundă; pentru ca viteza dovadă să fie suficient de rapidă, va necesita cu siguranță tehnici ingenioase precum GKR.

În cazul hash-ului SHA256, cel mai rău caz este blocul de tranziție a epocii, unde întregul arbore de solduri scurt ale validatorilor și multe solduri ale validatorilor vor fi actualizate. Fiecare arbore de solduri scurt al unui validator are doar un byte, deci 1 MB de date vor trebui re-hashuite. Aceasta este echivalentă cu 32768 apeluri SHA256. Dacă soldul a o mie de validatori este mai mare sau mai mic decât un prag, va trebui să actualizăm soldurile valide în înregistrările validatorilor, ceea ce este echivalent cu o mie de ramuri Merkle, deci este posibil să avem nevoie de zece mii de hash-uri. Mecanismul de amestecare necesită 90 de biți pentru fiecare validator (deci este nevoie de 11 MB de date), dar aceasta poate fi calculată în orice moment al unei epoci. În cazul finalizării pe un singur slot, aceste numere pot varia în funcție de circumstanțe. Amestecarea devine inutilă, deși Orbit ar putea în unele măsuri să reînvie această necesitate.

O altă provocare este necesitatea de a recupera toate stările validatorilor, inclusiv cheile publice, pentru a valida un bloc. Pentru 1 milion de validatori, citirea cheilor publice necesită 48 de milioane de bytes, plus ramurile Merkle. Acest lucru necesită hash-uri în milioane pentru fiecare epocă. Dacă trebuie să demonstrăm validitatea PoS-ului, o abordare realistă este o formă de calcul verificabil incremental: stocarea unei structuri de date separate în sistemul de dovezi, care este optimizată pentru a permite căutări eficiente și a dovedi actualizările acestei structuri.

Pe scurt, provocările sunt multe. Pentru a face față acestor provocări cât mai eficient posibil, este foarte probabil că va fi necesară o revizuire profundă a lanțului de semnal, ceea ce ar putea coincide cu tranziția către finalizarea pe un singur slot. Caracteristicile acestei revizuiri ar putea include:

  • Modificări ale funcțiilor hash: în prezent, se utilizează funcția hash SHA256 „completă”, așa că din cauza umplerii, fiecare apel corespunde de două ori apelurilor de funcție de compresie de bază. Dacă am folosi funcția de compresie SHA256, am putea obține cel puțin un câștig de 2 ori. Dacă am folosi Poseidon, am putea obține un câștig de 100 de ori, rezolvând astfel toate problemele noastre (cel puțin în ceea ce privește hash-urile): la 1,7 milioane de hash-uri pe secundă (54MB), chiar și un milion de înregistrări de validare ar putea fi „citite” în câteva secunde.

  • Dacă este Orbit, atunci stocăm pur și simplu înregistrările validatorilor amestecate: dacă alegem un anumit număr de validatori (de exemplu, 8192 sau 32768) ca o comisie pentru un slot dat, atunci îi plasăm direct în starea adiacente, astfel încât să fie necesare cele mai puține hash-uri pentru a citi toate cheile publice ale validatorilor în dovadă. Acest lucru de asemenea permite actualizări eficiente ale soldurilor.

  • Agregarea semnăturilor: orice schemă de agregare a semnăturilor de înaltă performanță va implica o formă de dovadă recursivă, în care diferitele noduri din rețea vor face dovadă intermediară pentru un subset de semnături. Acest lucru împarte natural volumul de muncă de dovadă între mai multe noduri din rețea, reducând astfel semnificativ volumul de muncă pentru „doveditorul final”.

  • Alte scheme de semnături: pentru semnătura Lamport+ Merkle, avem nevoie de 256 + 32 de hash-uri pentru a valida semnătura; înmulțit cu 32768 de semnatari, obținem 9437184 de hash-uri. Optimizarea schemei de semnături poate îmbunătăți acest rezultat cu un factor constant mic. Dacă folosim Poseidon, putem dovedi în cadrul unui singur slot. Dar, de fapt, utilizarea schemei de agregare recursive ar fi mai rapidă.

Ce legături există cu cercetările existente?

  • Dovada concisă a consensului Ethereum (doar pentru comisia de sinteză)

  • Helios în SP1 concis

  • BLS12-381 precompilare concisă

  • Verificarea semnăturilor setului BLS bazate pe Halo2

Ce lucrări mai sunt de făcut și cum se face compromis?

De fapt, ne va lua câțiva ani pentru a obține dovezi de validitate pentru consensul Ethereum. Acest lucru este aproximativ la fel de mult timp cât va dura să implementăm finalizarea pe un singur slot, Orbit, modificările schemei de semnătură și analiza de securitate necesară, iar analiza de securitate necesită suficientă încredere pentru a utiliza funcții hash „îndrăznețe” precum Poseidon. Prin urmare, cea mai înțeleaptă abordare este să rezolvăm aceste alte probleme și să avem în vedere prietenia cu STARK în timp ce le rezolvăm.

Compromisul principal este cel mai probabil în ordinea operațiunilor, între o abordare mai progresivă a reformării stratului de consens Ethereum și o abordare mai radicală de „a schimba multe lucruri deodată”. Pentru EVM, abordarea progresivă este rațională, deoarece minimizează interferența cu compatibilitatea înapoi. Pentru stratul de consens, impactul asupra compatibilității înapoi este mai mic, iar o revizuire mai „cuprinzătoare” a diverselor detalii referitoare la modul de construire a lanțului de semnal pentru a optimiza cel mai bine prietenia cu SNARK este de asemenea benefică.

Cum interacționează cu alte părți ale foii de parcurs?

În redeschiderea pe termen lung a Ethereum PoS, prietenia cu STARK trebuie să fie o prioritate, în special în ceea ce privește finalizarea pe un singur slot, Orbit, modificările schemei de semnături și agregarea semnăturilor.