Articolul nou al lui Vitalik: Posibilele viitoruri ale Ethereum, The Splurge

Titlul original: (Posibile viitoruri ale protocolului Ethereum, partea 6: The Splurge)
Autorul original: @VitalikButerin
Compilare originală: zhouzhou, BlockBeats
Iată conținutul original (pentru a facilita citirea și înțelegerea, conținutul original a fost reorganizat):
Unele lucruri sunt greu de încadrat într-o singură categorie, în designul protocolului Ethereum, multe „detalii” sunt extrem de importante pentru succesul Ethereum. De fapt, aproximativ jumătate din conținut se referă la diferite tipuri de îmbunătățiri EVM, în timp ce restul este format din diverse subiecte de nișă, aceasta este semnificația „prosperității”.
Foia de parcurs 2023: Prosperitate
Prosperitate: Obiectiv cheie
Transformă EVM într-o „stare finală” de înaltă performanță și stabilitate
Introducerea abstractizării contului în protocol, permițând tuturor utilizatorilor să beneficieze de conturi mai sigure și mai convenabile
Optimizează economia costurilor de tranzacție, îmbunătățind scalabilitatea și reducând riscurile
Explorarea criptografiei avansate pentru a îmbunătăți semnificativ Ethereum pe termen lung
Conținutul acestui capitol
Îmbunătățiri EVM
Abstractizarea contului
Îmbunătățiri EIP-1559
VDF (funcții verificate de întârziere)
Obfuscația și semnăturile unice: viitorul îndepărtat al criptografiei
Îmbunătățiri EVM
Ce problemă a rezolvat?
În prezent, EVM este greu de analizat static, ceea ce face ca crearea de implementări eficiente, verificarea formală a codului și extinderea ulterioară să fie dificilă. În plus, eficiența EVM este scăzută, ceea ce face dificilă implementarea multor forme de criptografie avansată, decât prin suport explicit pentru precompilare.
Ce este, cum funcționează?
Primul pas în planul actual de îmbunătățire a EVM este formatul obiectului EVM (EOF), care este planificat să fie inclus în următorul hard fork. EOF este o serie de EIP-uri care specifică o nouă versiune de cod EVM, cu multe caracteristici unice, cel mai semnificativ fiind:
Separarea codului (executabil, dar nu poate fi citit din EVM) și datelor (citibile, dar nu executabile)
Interdicția de salt dinamic, permițând doar salturi statice
Codul EVM nu mai poate observa informațiile legate de combustibil
A fost adăugată o nouă mecanism de subroutines explicit
Structura codului EOF
Prosperitate: Îmbunătățiri EVM (continuare)
Contractele vechi vor continua să existe și să fie create, deși vor putea fi treptat abandonate (chiar și forțate să se convertească în cod EOF). Contractele noi vor beneficia de îmbunătățirile de eficiență aduse de EOF - mai întâi printr-un bytecode ușor micșorat datorită caracteristicilor subprogramelor, apoi prin noi funcționalități specifice EOF sau costuri reduse de gaz.
După introducerea EOF, actualizările ulterioare au devenit mai ușor de realizat, dezvoltarea cea mai avansată fiind extinderea aritmeticii modulare a modulelor EVM (EVM-MAX). EVM-MAX a creat un set de operațiuni noi special concepute pentru operațiile modulare și le-a plasat într-un nou spațiu de memorie inaccesibil prin alte coduri de operație, permițând utilizarea optimizărilor precum înmulțirea Montgomery.
O idee mai recentă este de a combina EVM-MAX cu caracteristica SIMD (Single Instruction Multiple Data), SIMD fiind o idee existentă în Ethereum de mult timp, propusă inițial de EIP-616 a lui Greg Colvin. SIMD poate fi folosit pentru a accelera multe forme de criptografie, inclusiv funcții hash, STARKs de 32 de biți și criptografie bazată pe lattice, combinarea EVM-MAX și SIMD face ca aceste două extensii orientate spre performanță să fie o pereche naturală.
Un design aproximativ al unui EIP combinat va începe cu EIP-6690 și apoi:
Permite (i) orice număr impar sau (ii) orice putere de 2 cu un maxim de 2768 ca modul
Pentru fiecare cod de operație EVM-MAX (adunare, scădere, înmulțire), adăugați o versiune care nu mai folosește 3 constante imediate x, y, z, ci folosește 7 constante imediate: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. În codul Python, aceste coduri de operație funcționează similar cu:
for i in range(count):mem[z_start + z_skip * count] = op(mem[x_start + x_skip * count],mem[y_start + y_skip * count])
În implementarea practică, aceasta va fi tratată în mod paralel.
Ar putea fi adăugate XOR, AND, OR, NOT și SHIFT (inclusiv ciclice și non-ciclice), cel puțin pentru modulele care sunt puteri ale lui 2. De asemenea, se adaugă ISZERO (care va împinge rezultatul pe stiva principală a EVM), ceea ce va fi suficient de puternic pentru a realiza criptografia bazată pe curbe eliptice, criptografia de domeniu mic (precum Poseidon, Circle STARKs), funcții hash tradiționale (precum SHA 256, KECCAK, BLAKE) și criptografia bazată pe lattice. Alte actualizări EVM ar putea fi implementate, dar până acum au fost mai puțin discutate.
Linkuri către cercetările existente
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
SIMD: https://eips.ethereum.org/EIPS/eip-616
Lucrări rămase și compromisuri
În prezent, planul EOF este de a fi inclus în următorul hard fork. Deși este întotdeauna posibil să fie eliminat în ultimul moment — în trecut, anumite funcții au fost eliminate temporar în hard fork-uri anterioare, dar a face acest lucru va prezenta mari provocări. Eliminarea EOF înseamnă că orice actualizare viitoare a EVM ar trebui realizată fără EOF, deși este realizabil, ar putea fi mai dificil.
Compromisul principal al EVM se află între complexitatea L1 și complexitatea infrastructurii, EOF este un volum mare de cod care trebuie adăugat la implementarea EVM, iar verificarea statică a codului este de asemenea relativ complexă. Cu toate acestea, în schimb, putem simplifica limbajele de nivel înalt, simplifica implementarea EVM și alte beneficii. S-ar putea spune că prioritizarea continuității îmbunătățirilor Ethereum L1 ar trebui să includă și să se bazeze pe EOF.
O muncă importantă care trebuie realizată este implementarea funcționalităților similare EVM-MAX împreună cu SIMD și benchmarkarea consumului de gaz pentru diverse operații criptografice.
Cum interacționează cu alte părți ale foaie de parcurs?
L1 își ajustează EVM astfel încât L2 să poată realiza ajustări corespunzătoare mai ușor, iar dacă cele două nu sunt ajustate simultan, ar putea duce la incompatibilitate, având efecte negative. În plus, EVM-MAX și SIMD pot reduce costurile de gaz pentru multe sisteme de dovadă, făcând L2 mai eficient. De asemenea, facilitează înlocuirea mai multor precompilări cu cod EVM care poate executa aceleași sarcini, fără a afecta semnificativ eficiența.
Abstractizarea contului
Ce problemă a rezolvat?
În prezent, tranzacțiile pot fi verificate doar într-un singur mod: semnătura ECDSA. Inițial, abstractizarea contului a fost destinată să depășească această limitare, permițând logica de verificare a contului să fie orice cod EVM. Acest lucru poate activa o serie de aplicații:
Trecerea la criptografie rezistentă la cuantum
Rotirea cheilor vechi (considerată pe scară largă ca o practică de securitate recomandată)
Portofele cu semnături multiple și portofele de recuperare socială
Utilizarea unei chei pentru operațiuni de valoare scăzută, utilizând o altă cheie (sau un grup de chei) pentru operațiuni de mare valoare
Permite protocoalelor de confidențialitate să funcționeze fără intermediari, reducând semnificativ complexitatea acestora și eliminând un punct central de dependență.
De la propunerea abstractizării contului în 2015, obiectivele sale s-au extins pentru a include multe „obiective de conveniență”, de exemplu, un cont care nu are ETH, dar deține un anumit ERC 20, ar putea folosi ERC 20 pentru a plăti gazul. Iată un grafic sumar al acestor obiective:
MPC (calcul multiplu) este o tehnologie de 40 de ani folosită pentru a împărți cheile în mai multe părți și a le stoca pe mai multe dispozitive, generând semnături prin tehnici criptografice, fără a combina direct aceste părți de cheie.
EIP-7702 este o propunere care este planificată pentru a fi introdusă în următorul hard fork, EIP-7702 este rezultatul unei recunoașteri crescânde a necesității de a oferi comoditatea abstractizării contului pentru a beneficia toți utilizatorii (inclusiv utilizatorii EOA), având ca scop îmbunătățirea experienței tuturor utilizatorilor pe termen scurt și evitarea divizării în două ecosisteme.
Această muncă a început cu EIP-3074 și a dus în cele din urmă la formarea EIP-7702. EIP-7702 va oferi „funcționalitățile de comoditate” ale abstractizării contului tuturor utilizatorilor, inclusiv utilizatorilor EOA (conturi deținute extern, adică conturi controlate de semnături ECDSA).
Din grafic se poate observa că, deși unele provocări (în special provocările de „conveniență”) pot fi abordate prin tehnici progresive precum calculul multiplu sau EIP-7702, obiectivul principal de securitate pe care l-a avut propunerea de abstractizare a contului inițial poate fi realizat doar prin revenirea și abordarea problemei originale: permiterea codului contractelor inteligente să controleze verificarea tranzacțiilor. Motivele pentru care nu a fost realizat până acum se referă la implementarea sigură, ceea ce reprezintă o provocare.
Ce este, cum funcționează?
Esenta abstractizării contului este simplă: permite contractelor inteligente să inițieze tranzacții, nu doar EOA. Toată complexitatea provine din implementarea acestuia într-un mod care să fie prietenos pentru menținerea rețelei descentralizate și să prevină atacurile de tip denial of service.
O provocare cheie tipică este problema eșecurilor multiple:
Dacă există 1000 de funcții de verificare a conturilor care depind de o singură valoare S, iar valoarea curentă S face ca tranzacțiile din pool-ul de memorie să fie toate valide, atunci o singură tranzacție care inversează valoarea S poate face ca toate celelalte tranzacții din pool-ul de memorie să devină invalide. Aceasta permite atacatorilor să trimită tranzacții de gunoi în pool-ul de memorie cu un cost extrem de scăzut, blocând astfel resursele nodurilor din rețea.
După ani de eforturi, destinat extinderii funcționalității în timp ce limitează riscurile de atacuri de tip denial of service (DoS), soluția finală pentru realizarea „abstractizării contului ideale” a fost dezvoltată: ERC-4337.
Funcționarea ERC-4337 împarte procesarea operațiunilor utilizatorului în două etape: verificare și execuție. Toate verificările sunt procesate mai întâi, toate execuțiile ulterior. În pool-ul de memorie, vor fi acceptate doar operațiunile utilizatorului pentru care etapa de verificare implică doar contul său și nu citește variabile de mediu. Acest lucru poate preveni atacurile de eșec multipl.
ERC-4337 a fost proiectat ca un standard suplimentar (ERC) pentru protocol, deoarece la acel moment dezvoltatorii clienților Ethereum s-au concentrat pe fuziune (Merge), neavând energie suplimentară pentru a se ocupa de alte funcții. Aceasta este motivul pentru care ERC-4337 a folosit un obiect numit operație utilizator, în loc de tranzacții obișnuite. Cu toate acestea, recent am realizat că trebuie să scriem cel puțin o parte din acest conținut în protocol.
Două motive cheie sunt:
1. Inerția înnăscută a contractului EntryPoint: fiecare pachet are o cheltuială fixă de aproximativ 100.000 gaz, plus mii de gaz suplimentare pentru fiecare operațiune a utilizatorului.
2. Asigurarea necesității proprietăților Ethereum: cum ar fi garanțiile de includere create de listele de includere care trebuie transferate către utilizatorii de abstractizare a contului.
În plus, ERC-4337 a extins două funcții:
Agentii de plată (Paymasters): permit unui cont să plătească costurile în numele altui cont, ceea ce încalcă regula conform căreia etapa de verificare poate accesa doar contul trimițător, astfel încât a fost introdus un tratament special pentru a asigura securitatea mecanismului agentului de plată.
Agregatorii (Aggregators): sprijină funcționalitatea de agregare a semnăturilor, cum ar fi agregarea BLS sau agregarea bazată pe SNARK. Aceasta este necesară pentru a realiza cea mai mare eficiență a datelor pe Rollup.
Linkuri către cercetările existente
Vorbe despre istoricul abstractizării contului: https://www.youtube.com/watch?v=iLf8qpOmxQc
ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
Codul BLSWallet (folosind funcționalitatea de agregare): https://github.com/getwax/bls-wallet
EIP-7562 (abstractizarea contului prin scrierea protocolului): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701 (abstractizarea contului prin scrierea protocolului bazat pe EOF): https://eips.ethereum.org/EIPS/eip-7701
Lucrări rămase și compromisuri
Ceea ce trebuie să rezolvăm în prezent este cum să introducem complet abstractizarea contului în protocol, propunerea de scriere a protocolului care a câștigat recent popularitate este EIP-7701, aceasta implementând abstractizarea contului deasupra EOF. Un cont poate avea o secțiune de cod separată pentru verificare, iar dacă contul a setat acea secțiune de cod, aceasta va fi executată în pasul de verificare al tranzacției provenind de la acel cont.
Farmecul acestei metode constă în faptul că arată clar cele două perspective echivalente asupra abstractizării contului locale:
1. Integrarea EIP-4337 ca parte a protocolului
2. Un nou tip de EOA, în care algoritmul de semnătură este executarea codului EVM
Dacă începem prin a stabili limite stricte asupra complexității codului executabil în timpul verificării — fără acces la starea externă, chiar și limitele de gaz stabilite inițial fiind atât de scăzute încât să fie ineficiente pentru aplicațiile criptografice sau de protecție a confidențialității — atunci securitatea acestei metode devine foarte clară: pur și simplu înlocuind verificarea ECDSA cu executarea codului EVM care necesită timp similar.
Cu toate acestea, pe parcursul timpului, va trebui să relaxăm aceste limite, deoarece este extrem de important să permitem aplicațiilor de protecție a confidențialității să funcționeze fără intermediari și să avem rezistență la cuantum. Pentru aceasta, va trebui să găsim o metodă mai flexibilă de a aborda riscurile de atac DoS, fără a necesita ca pașii de verificare să fie extrem de simplificați.
Compromisul principal pare a fi „scrierea rapidă a unei soluții care să mulțumească mai puțini oameni” versus „așteptarea mai mult timp pentru a obține o soluție mai ideală”, metoda ideală fiind probabil un fel de abordare mixtă. O metodă mixtă ar fi să scriem mai repede câteva cazuri de utilizare și să lăsăm mai mult timp pentru a explora alte cazuri de utilizare. O altă metodă ar fi să desfășurăm mai întâi o versiune mai ambițioasă a abstractizării contului pe L2. Totuși, provocarea cu care se confruntă este că echipele L2 trebuie să aibă încredere în munca propunerii pentru a fi dispuse să implementeze, mai ales pentru a se asigura că L1 și/sau alte L2 pot adopta în viitor soluții compatibile.
O altă aplicație pe care trebuie să o luăm în considerare este stocarea cheilor conturilor, aceste conturi stocând starea asociată contului pe L1 sau L2 dedicate, dar putând fi utilizate pe L1 și orice L2 compatibil. Realizarea eficientă a acestui lucru ar putea necesita ca L2 să sprijine codurile de operație precum L1S LOAD sau REMOTESTATICCALL, dar aceasta necesită, de asemenea, ca implementarea abstractizării contului pe L2 să sprijine aceste operații.
Cum interacționează cu alte părți ale foaie de parcurs?
Listele de includere trebuie să sprijine tranzacțiile de abstractizare a contului, în practică, cerințele listei de includere sunt foarte similare cu cerințele memoriei descentralizate, deși pentru lista de includere flexibilitatea este puțin mai mare. În plus, implementarea abstractizării contului ar trebui să fie coordonată între L1 și L2 cât mai mult posibil. Dacă ne așteptăm ca în viitor majoritatea utilizatorilor să folosească Rollup-uri de stocare a cheilor, designul abstractizării contului ar trebui să se bazeze pe acest lucru.
Îmbunătățiri EIP-1559
Ce problemă a rezolvat?
EIP-1559 a fost activat pe Ethereum în 2021, îmbunătățind semnificativ timpul mediu de includere a blocurilor.
Timp de așteptare
Cu toate acestea, implementarea actuală a EIP-1559 nu este perfectă în mai multe privințe:
1. Formula este ușor defectuoasă: nu este orientată către 50% din blocuri, ci către aproximativ 50-53% din blocuri pline, în funcție de variație (aceasta are legătură cu ceea ce matematicienii numesc „inegalitatea mediei aritmetice-geometrice”).
2. Ajustările nu sunt suficient de rapide în cazuri extreme.
Formula folosită ulterior pentru blobs (EIP-4844) este special concepută pentru a rezolva prima problemă, fiind în general mai concisă. Cu toate acestea, EIP-1559 în sine și EIP-4844 nu au încercat să rezolve a doua problemă. Prin urmare, starea actuală este una de confuzie, implicând două mecanisme diferite, iar există o opinie că ambele necesită îmbunătățiri în timp.
În plus, există și alte slăbiciuni în stabilirea prețurilor resurselor Ethereum care nu sunt legate de EIP-1559, dar care pot fi rezolvate prin ajustări ale EIP-1559. Una dintre problemele principale este diferența dintre medie și cel mai rău caz: prețurile resurselor din Ethereum trebuie stabilite pentru a putea face față celui mai rău caz, adică un consum total de gaz al unui bloc care ocupă o resursă, dar utilizarea medie reală este mult sub aceasta, ducând la ineficiență.
Ce este gazul multidimensional, cum funcționează?
Soluția pentru aceste probleme de ineficiență este gazul multidimensional: stabilirea de prețuri și limite diferite pentru resurse diferite. Acest concept este tehnic independent de EIP-1559, dar existența EIP-1559 facilitează implementarea acestei soluții. Fără EIP-1559, optimizarea unui bloc care conține restricții multiple de resurse ar fi o problemă complexă a unui rucsac multidimensional. Cu EIP-1559, majoritatea blocurilor nu vor atinge capacitatea maximă pe nici o resursă, astfel încât un algoritm simplu de „acceptare a oricărei tranzacții care plătește costuri suficiente” este suficient.
În prezent, avem gaz multidimensional pentru executare și blocuri de date; în principiu, putem extinde aceasta la mai multe dimensiuni: precum calldata (datele tranzacției), citirea/scrierea stării și extinderea dimensiunii stării.
EIP-7706 a introdus o nouă dimensiune de gaz, destinat special pentru calldata. În același timp, a simplificat mecanismul multidimensional de gaz prin unificarea a trei tipuri de gaz într-un cadru (stil EIP-4844), rezolvând astfel și deficiențele matematice ale EIP-1559. EIP-7623 este o soluție mai precisă, având în vedere problemele de resurse în medii medii și cele mai proaste cazuri, limitând mai strict calldata maximă, fără a introduce o nouă dimensiune întreagă.
O direcție de cercetare suplimentară este abordarea problemei ratei de actualizare, căutând un algoritm de calcul al costurilor de bază mai rapid, păstrând în același timp variabilele cheie introduse de mecanismul EIP-4844 (adică, pe termen lung, utilizarea medie se apropie de valoarea țintă).
Linkuri către cercetările existente
EIP-1559 FAQ: EIP-1559 FAQ
Analiza empiričă a EIP-1559: Analiza empiričă
Permite propuneri de îmbunătățire rapid adaptabile: Propuneri de îmbunătățire
Partea din FAQ EIP-4844 referitoare la mecanismul costurilor de bază: EIP-4844 FAQ
EIP-7706: EIP-7706
EIP-7623: EIP-7623
Gaz multidimensional: Gaz multidimensional
Ce lucrări rămân și care sunt compromisurile?
Compromisurile principale ale gazului multidimensional sunt două:
1. Creșterea complexității protocolului: introducerea gazului multidimensional va face protocolul mai complex.
2. Creșterea complexității algoritmului optim necesar pentru a umple blocurile: pentru a atinge capacitatea optimă a blocului, algoritmul va deveni complex.
Complexitatea protocolului este relativ mică pentru calldata, dar pentru dimensiunile gazului din interiorul EVM (cum ar fi citirea și scrierea stocării) complexitatea va crește. Problema este că nu doar utilizatorii stabilesc limitele gazului, ci și contractele stabilesc limite atunci când apelează alte contracte. Iar în prezent, singura modalitate prin care stabilesc limitele este unidimensională.
O soluție simplă este de a face gazul multidimensional disponibil doar în interiorul EOF, deoarece EOF nu permite contractelor să stabilească limitele gazului atunci când apelează alte contracte. Contractele non-EOF trebuie să plătească costurile pentru toate tipurile de gaz în timpul operațiunilor de stocare (de exemplu, dacă SLOAD ocupă 0,03% din limita gazului de acces la stocare a unui bloc, utilizatorii non-EOF vor fi taxați și cu 0,03% din costul limitei de execuție a gazului).
Mai multe cercetări asupra gazului multidimensional vor ajuta la înțelegerea acestor compromisuri și la găsirea punctului ideal de echilibru.
Cum interacționează cu alte părți ale foaie de parcurs?
Implementarea cu succes a gazului multidimensional poate reduce semnificativ utilizarea resurselor în anumite „cele mai proaste cazuri”, reducând astfel presiunea pentru optimizarea performanțelor, pentru a sprijini cerințele precum arborele binar bazat pe hash STARKed. Stabilirea unui obiectiv clar pentru creșterea dimensiunii stării va facilita planificarea și estimarea cerințelor pentru dezvoltatorii de clienți în viitor.
Așa cum s-a menționat anterior, existența EOF facilitează implementarea versiunilor mai extreme ale gazului multidimensional, datorită caracteristicilor sale de gaz invizibil.
Funcții verificate de întârziere (VDFs)
Ce problemă a rezolvat?
În prezent, Ethereum folosește aleatoriu bazat pe RANDAO pentru a selecta propunătorii, iar aleatoriu RANDAO funcționează prin cererea ca fiecare propunător să dezvăluie secretul pe care l-a promis anterior și să amestece fiecare secret dezvăluit în aleatoriu.
Fiecare propunător are, astfel, „1 bit de control”: ei pot schimba aleatorul prin neprezentare (cu costuri). Această modalitate este rezonabilă pentru a căuta propunători, deoarece este foarte rar ca să renunți la o oportunitate pentru a obține două noi oportunități de propunere. Dar pentru aplicațiile de lanț care necesită aleatoriu, aceasta nu este ideală. Ideal ar trebui să găsim o sursă de aleatoriu mai robustă.
Ce este VDF, cum funcționează?
Funcțiile verificate de întârziere sunt funcții care pot fi calculate doar secvențial și nu pot fi accelerate prin paralele. Un exemplu simplu este hash-ul repetat: for i in range(10**9): x = hash(x). Rezultatul de ieșire, folosind o dovadă SNARK a corectitudinii, poate fi utilizat ca valoare aleatoare.
Această idee este de a alege informațiile disponibile bazate pe timpul T ca input, iar la timpul T, outputul rămâne necunoscut: outputul va fi disponibil doar după ce cineva a rulat complet calculul, la un moment dat după T. Deoarece oricine poate rula calculul, nu există posibilitatea de a ascunde rezultatele, astfel că nu există abilitatea de a manipula rezultatul.
Riscurile principale ale funcțiilor verificate de întârziere sunt optimizările accidentale: cineva a descoperit că rulează funcția cu o viteză mai mare decât cea așteptată, manipulând astfel informațiile pe care le dezvăluie la timpul T.
Optimizările accidentale pot apărea în două moduri:
1. Accelerarea hardware-ului: cineva a creat un ASIC care rulează cicluri de calcul mai repede decât hardware-ul existent.
2. Paralele accidentale: cineva a găsit o modalitate de a rula funcțiile în paralel pentru a obține viteze mai mari, chiar dacă acest lucru necesită 100 de ori mai multe resurse.
Sarcina de a crea un VDF de succes este de a evita aceste două probleme, menținând în același timp eficiența practică (de exemplu, o metodă bazată pe hash are o problemă: dovedirea SNARK a hash-ului în timp real necesită hardware greu). Accelerarea hardware-ului este de obicei rezolvată printr-un participant de interes public care creează și distribuie un VDF ASIC aproape optim.
Linkuri către cercetările existente
Site-ul de cercetare VDF: vdfresearch.org
Reflecții asupra atacurilor VDF în Ethereum, 2018: Gânduri asupra atacurilor
Atacuri împotriva VDF MinRoot: Atacuri împotriva MinRoot
Care sunt lucrările rămase și compromisul?
În prezent, nu există o construcție VDF care să îndeplinească toate cerințele cercetătorilor Ethereum în toate privințele. Este nevoie de mai multă muncă pentru a găsi o astfel de funcție. Dacă se găsește, compromisul principal este dacă să fie inclus: un compromis simplu între funcționalitate și complexitatea protocolului și riscurile de securitate.
Dacă considerăm că VDF este sigur, dar în cele din urmă nu este, atunci în funcție de modul său de implementare, siguranța va degenera la ipoteza RANDAO (un atacator cu 1 bit de control) sau o situație puțin mai proastă. Așadar, chiar dacă VDF eșuează, nu va distruge protocolul, dar va afecta aplicațiile sau orice caracteristici noi ale protocolului care depind puternic de acesta.
Cum interacționează cu alte părți ale foaie de parcurs?
VDF este o componentă relativ autoconținută în protocolul Ethereum, pe lângă creșterea securității alegerii propunerilor, are aplicații în (i) aplicații de lanț care depind de aleatoriu și (ii) în memoriile criptografice, deși realizarea unei memorii criptografice bazate pe VDF depinde încă de descoperiri criptografice suplimentare care nu au avut loc.
Un punct important de reținut este că, având în vedere incertitudinea hardware-ului, ieșirea VDF va prezenta o anumită „marjă” față de necesitate. Aceasta înseamnă că informația va fi disponibilă cu câteva blocuri înainte. Acesta ar putea fi un cost acceptabil, dar ar trebui să fie luat în considerare în proiectarea finalizării pe un singur slot sau a alegerii comitetului.
Obfuscația și semnăturile unice: viitorul îndepărtat al criptografiei
Ce problemă a rezolvat?
Unul dintre cele mai celebre articole ale lui Nick Szabo este lucrarea sa din 1997 despre „protocolul lui Dumnezeu”. În această lucrare, el subliniază că multe aplicații multiparte depind de „terțe părți de încredere” pentru a gestiona interacțiunile. În opinia sa, rolul criptografiei este de a crea o simulare a unei terțe părți de încredere care să îndeplinească aceeași sarcină, fără a necesita încrederea în vreun participant specific.
Până acum, am reușit doar să implementăm parțial acest ideal. Dacă ceea ce avem nevoie este doar o mașină virtuală de calcul transparentă, a cărei date și calcule nu pot fi oprite, cenzurate sau manipulate, iar confidențialitatea nu este un obiectiv, atunci blockchain-ul poate realiza acest lucru, deși scalabilitatea sa este limitată.
Dacă confidențialitatea este obiectivul, atunci până recent, am putut dezvolta doar câteva protocoale specifice pentru aplicații specifice: semnături digitale pentru autentificare de bază, semnături circulare pentru anonimitate pură și semnături circulare legate, criptografie bazată pe identitate pentru a facilita criptarea în baza unor ipoteze specifice de încredere, și semnături oarbe pentru numerarul electronic de tip Chaum etc. Această abordare necesită multă muncă pentru fiecare aplicație nouă.
În anii 2010, am început să zărim o metodă diferită și mai puternică, bazată pe criptografia programabilă. În loc să creăm un nou protocol pentru fiecare aplicație nouă, putem folosi un nou protocol puternic — și anume ZK-SNARKs — pentru a adăuga garanții criptografice pentru orice program.
ZK-SNARKs permit utilizatorilor să dovedească orice afirmație despre datele pe care le dețin, iar dovada (i) este ușor de verificat și (ii) nu dezvăluie nicio altă informație în afară de afirmația în sine. Aceasta reprezintă un progres uriaș în ceea ce privește confidențialitatea și scalabilitatea, comparându-l cu impactul transformatoarelor din inteligența artificială. Mii de oameni aplică lucrări specifice, fiind înlocuiți brusc de această soluție generică, capabilă să abordeze probleme de o amploare neașteptată.
Cu toate acestea, ZK-SNARKs sunt doar una dintre cele trei primitive extrem de puternice și generice. Aceste protocoale sunt atât de puternice încât atunci când mă gândesc la ele, îmi amintesc de un set de cărți extrem de puternice din (Yu-Gi-Oh) — un joc de cărți și un program TV pe care l-am jucat în copilărie: cărțile zeilor egipteni.
Cardurile zeilor egipteni sunt trei cărți extrem de puternice, iar legenda spune că procesul de fabricare a acestor cărți ar putea fi mortal, iar puterea lor face ca utilizarea lor în dueluri să fie interzisă. În mod similar, în criptografie, avem acest trio de protocoale egiptene:
Ce sunt ZK-SNARKs, cum funcționează?
ZK-SNARKs sunt una dintre cele trei protocoale pe care le avem deja, având un grad ridicat de maturitate. În ultimii cinci ani, viteza demonstratorilor și prietenia cu dezvoltatorii au făcut ca ZK-SNARKs să devină fundamentul strategiilor de scalabilitate și confidențialitate ale Ethereum. Dar ZK-SNARKs au o limitare importantă: trebuie să cunoști datele pentru a le dovedi. Fiecare aplicație ZK-SNARK trebuie să aibă un „proprietar” unic al stării care trebuie să fie prezent pentru a aproba citirea sau scrierea acelei stări.
A doua protocol fără această limitare este criptografia complet homomorfă (FHE), FHE îți permite să efectuezi orice calcul asupra datelor criptate fără a le vizualiza. Aceasta îți permite să calculezi asupra datelor utilizatorilor, pornind de la bunăstarea utilizatorului, menținând în același timp confidențialitatea datelor și algoritmilor.
De asemenea, aceasta îți permite să extinzi sistemele de vot, cum ar fi MACI, pentru a obține aproape perfectă securitate și garanții de confidențialitate. De mult timp, FHE a fost considerat prea ineficient pentru a fi utilizat practic, dar acum a devenit suficient de eficient și încep să apară aplicații practice.
Cursive este o aplicație care utilizează calculul de părți și criptografia complet homomorfă (FHE) pentru a descoperi interese comune cu protecție a confidențialității.
Cu toate acestea, FHE are, de asemenea, limitările sale: orice tehnologie bazată pe FHE trebuie să aibă pe cineva care deține cheia de decriptare. Aceasta poate fi o setare distribuită de M-of-N, poți chiar folosi medii de execuție de încredere (TEEs) pentru a adăuga un al doilea strat de protecție, dar aceasta rămâne o limitare.
Apoi urmează al treilea protocol, care este mai puternic decât combinația primelor două: obfuscația nedistinctivă (indistinguishability obfuscation). Deși această tehnologie este încă departe de maturitate, până în 2020, am obținut protocoale teoretic valide bazate pe ipoteze de securitate standard, iar recent am început să lucrăm la implementarea acestora.
Obfuscația nedistinctivă îți permite să creezi un „program criptat” care execută orice calcul, ascunzând toate detaliile interne ale programului. De exemplu, poți introduce o cheie privată într-un program de obfuscație care îți permite doar să o folosești pentru a semna numere prime și să distribui acest program altora. Acestea pot folosi programul pentru a semna orice număr prim, dar nu pot extrage cheia. Cu toate acestea, capacitatea sa depășește mult aceasta: combinată cu hashing-ul, poate fi folosită pentru a implementa orice alte primitive criptografice și multe altele.
Programul de obfuscație nedistinctivă nu poate face decât un singur lucru: să împiedice autoconstruirea. Totuși, pentru acest lucru, există tehnologii mai puternice la orizont, deși acestea depind de fiecare persoană având un computer cuantic: semnăturile unice cuantice (quantum one-shot signatures).
Prin combinarea obfuscării și semnăturilor unice, putem construi un terț de încredere aproape perfect. Singurul obiectiv care nu poate fi realizat doar prin criptografie, care necesită în continuare blockchain pentru a garanta, este rezistența la cenzură. Aceste tehnici pot face Ethereum mai sigur, dar și mai puternice aplicații pot fi construite pe el.
Pentru a înțelege mai bine cum aceste primitive adaugă capabilități suplimentare, luăm votul ca exemplu cheie. Votul este o problemă interesantă, deoarece necesită îndeplinirea unor proprietăți de securitate complexe, inclusiv o verificabilitate foarte puternică și confidențialitate. Deși protocoalele de vot cu proprietăți de securitate puternice există de zeci de ani, putem să ne complicăm singuri sarcina, cerând să proiectăm soluții capabile să gestioneze orice protocol de vot: cum ar fi votul secundar, finanțarea secundară cu restricții pe perechi, finanțarea secundară prin potrivirea clusterelor etc. Cu alte cuvinte, dorim ca etapa de „numărare” să devină un program arbitrar.
În primul rând, să presupunem că vom publica rezultatul votului pe blockchain. Aceasta ne oferă verificabilitate publică (oricine poate verifica dacă rezultatul final este corect, inclusiv regulile de numărare și regulile de calificare) și rezistență la cenzură (nimeni nu poate împiedica oamenii să voteze). Dar nu avem confidențialitate.
Apoi, am adăugat ZK-SNARKs, acum avem confidențialitate: fiecare vot este anonim, asigurând în același timp că doar alegătorii autorizați pot vota, și fiecare alegător poate vota o singură dată.
Apoi, am introdus mecanismul MACI, voturile fiind criptate pentru cheia de decriptare a serverului central. Serverul central este responsabil pentru procesul de numărare, inclusiv eliminarea voturilor duplicate și publicarea dovezilor ZK-SNARK ale rezultatelor. Aceasta păstrează garanțiile anterioare (chiar dacă serverul trișează!), dar dacă serverul este cinstit, adaugă o garanție de rezistență la constrângere: utilizatorii nu pot dovedi cum au votat, chiar dacă doresc să facă asta. Aceasta se datorează faptului că, deși utilizatorii pot dovedi că au votat, nu pot dovedi că nu au votat pentru a contracara acel vot. Aceasta împiedică mita și alte atacuri.
Executăm votul în FHE și apoi realizăm calculul de decriptare cu prag N/2 din N. Aceasta face ca garanția împotriva constrângerii să crească la N/2 din N, în loc de 1 din 1.
Am obfuscat programul de numărare și am proiectat un program de obfuscație care va produce rezultate doar atunci când este autorizat, iar autorizarea poate fi o dovadă a consensului blockchain, o anumită dovadă a muncii sau o combinație a ambelor. Aceasta face ca garanția împotriva constrângerii să fie aproape perfectă: în cazul consensului blockchain, 51% dintre validatori trebuie să coludeze pentru a o sparge; în cazul dovezii muncii, chiar și atunci când toți coludează, re-numărarea folosind un subset diferit de alegători pentru a încerca să extragă comportamentul unui alegător individual va fi extrem de costisitoare. Putem chiar să ajustăm programul cu o mică modificare aleatoare a rezultatului final al numărării, pentru a crește și mai mult dificultatea de extragere a comportamentului unui alegător individual.
Am adăugat semnăturile unice, care sunt un primitiv bazat pe computația cuantică, permițând semnarea să fie utilizată doar o singură dată pentru un tip specific de informație. Aceasta face ca garanția împotriva constrângerii să devină cu adevărat perfectă.
Obfuscația nedistinctivă susține, de asemenea, alte aplicații puternice. De exemplu:
1. Organizații autonome descentralizate (DAOs), licitații pe lanț și alte aplicații cu stare internă secretă arbitrară.
2. Setare de încredere universală reală: cineva poate crea un program de obfuscație care conține chei și să ruleze orice program, furnizând output, introducând hash(key, program) ca input în program. Dat un astfel de program, oricine poate introduce programul 3 în sine, combinând cheia preexistentă a programului cu cheia lor, extinzând astfel setarea. Acest lucru poate fi folosit pentru a genera o setare de încredere 1-of-N pentru orice protocol.
3. Verificarea ZK-SNARKs necesită doar o semnătură: realizarea acestui lucru este foarte simplă: setează un mediu de încredere, lasă pe cineva să creeze un program de obfuscație, care va folosi cheia pentru a semna mesajul doar în cazul în care ZK-SNARK este valid.
4. Memorie criptată: tranzacțiile criptate devin foarte simple, astfel încât tranzacțiile pot fi decriptate doar atunci când un anumit eveniment de pe lanț se întâmplă în viitor. Aceasta ar putea include chiar și funcțiile verificate de întârziere (VDF) executate cu succes.
Prin intermediul semnăturilor unice, putem proteja blockchain-ul împotriva atacurilor de 51% care inversează finalitatea, deși atacurile de cenzură rămân posibile. Primitivii asemănători semnăturilor unice permit apariția monedei cuantice, rezolvând astfel problema plăților duble fără blockchain, deși multe aplicații mai complexe necesită în continuare un lanț.
Dacă aceste primitive pot deveni suficient de eficiente, atunci cele mai multe aplicații din lume pot deveni descentralizate. Principalul obstacol va fi verificarea corectitudinii implementării.
Iată câteva linkuri către cercetările existente:
1. Protocolul de obfuscație nedistinctivă (2021): Obfuscația nedistinctivă
2. Cum poate ajuta obfuscația Ethereum: Cum poate obfuscația să ajute Ethereum
3. Prima construcție cunoscută a semnăturilor unice: Prima construcție cunoscută a semnăturilor unice
4. Încercarea de implementare a obfuscării (1): Încercarea de implementare a obfuscării (1)
5. Încercarea de implementare a obfuscării (2): Încercarea de implementare a obfuscării (2)
Ce alte lucrări trebuie efectuate, iar compromisul este?
Există încă multe de făcut, obfuscația nedistinctivă este încă foarte imatură, iar viteza de execuție a construcțiilor candidate este surprinzător de lentă (dacă nu chiar mai mult), făcându-le inutilizabile în aplicații. Obfuscația nedistinctivă este cunoscută sub numele de „teoretic” polinomial în timp, dar în aplicațiile practice, timpul de execuție poate fi mai lung decât durata de viață a universului. Protocolele recente au ameliorat timpul de execuție, dar costurile sunt încă prea mari pentru utilizarea obișnuită: un implementator a estimat un timp de execuție de un an.
Calculatoarele cuantice nici măcar nu există încă: toate construcțiile pe care le vezi pe internet sunt fie prototipuri incapabile să efectueze calcule mai mari de 4 biți, fie nu sunt calculatoare cuantice substanțiale, deși ar putea avea componente cuantice, dar nu pot rula calcule semnificative precum algoritmul lui Shor sau algoritmul lui Grover. Recent, au apărut semne că „calculatoarele cuantice reale” nu sunt foarte departe de noi. Totuși, chiar și atunci când „calculatoarele cuantice reale” vor apărea în curând, ar putea dura zeci de ani până când oamenii obișnuiți vor putea folosi calculatoarele cuantice pe laptopurile sau telefoanele lor, în ziua în care instituții puternice vor putea sparge criptografia bazată pe curbe eliptice.
În obfuscația nedistinctivă, un compromis cheie se află în ipoteza de securitate, unde există o proiectare mai radicală care folosește ipoteze speciale. Aceste proiectări au adesea timpi de execuție mai realiști, dar ipotezele speciale sunt uneori distruse în final. În timp, am putea înțelege mai bine lattice-ul și astfel să propunem ipoteze mai greu de distrus. Totuși, această cale este mai riscantă. O abordare mai conservatoare este de a ne menține la protocoalele a căror securitate poate fi dovedită și redusă la ipoteze „standard”, dar acest lucru ar putea necesita un timp mai lung pentru a obține protocoale care rulează suficient de rapid.
Cum interacționează cu alte părți ale foaie de parcurs?
Criptografia extrem de puternică ar putea schimba complet jocul, de exemplu:
1. Dacă verificarea ZK-SNARKs pe care o obținem este la fel de simplă ca semnarea, atunci s-ar putea să nu mai avem nevoie de niciun protocol de agregare; am putea verifica direct pe lanț.
2. Semnăturile unice pot însemna protocoale de dovadă a mizei mai sigure.
3. Multe protocoale complexe de confidențialitate ar putea necesita doar un EVM care protejează confidențialitatea.
4. Memoria criptată devine mai ușor de implementat.
La început, beneficiile vor apărea la nivelul aplicației, deoarece L1 al Ethereum trebuie să rămână conservator în ceea ce privește ipotezele de securitate. Totuși, utilizarea exclusivă a nivelului aplicației ar putea fi disruptivă, așa cum a fost apariția ZK-SNARKs.
Linkul original