Un ghid pentru dezvoltatori pentru zkGalaxy

Aceasta este o euristică extrem de utilă pentru a diferenția abordările pentru susținerea unui zkEVM. Cu toate acestea, zkEVM-urile sunt un subset al tuturor modalităților posibile de a construi aplicații cu cunoștințe zero. Pentru un programator care dorește să valorifice proprietățile unice ale calculului zk, și anume succint, cunoștințe zero și corectitudine, un zkEVM poate să nu fie cea mai bună alegere. Prin prezentarea întregului set de instrumente pentru dezvoltatori, sper să ofer un ghid care să ajute în procesul de luare a deciziilor în jurul stivei zk potrivite pentru aplicația dvs.

În ultimii ani sau doi, a existat un progres enorm în instrumentele zk. Ei se apropie de un punct în care dezvoltatorii de software obișnuiți pot valorifica proprietățile puternice ale zk fără o înțelegere profundă a matematicii și ingineriei care stau la baza intimidante. Pe de altă parte, a existat o proliferare a instrumentelor pentru utilizatorii puternici, care oferă experților zk un control extrem de fin asupra stivei zk.

Software-ul modern este construit pe nenumărate straturi de abstractizare pentru a maximiza productivitatea specialistului. Există multe avantaje ale abstracției în inginerie, care sunt oarecum intuitive – un dezvoltator web nu trebuie să înțeleagă cum funcționează sistemele de operare în profunzime. 

Cheia pentru construirea unor straturi de abstractizare bune, reutilizabile este de a încapsula complexitatea unui strat și apoi de a oferi interfețe simple, dar expresive pentru utilizarea straturilor mai înalte în stivă. Făcut corect, acest lucru le permite dezvoltatorilor cu diferite domenii de expertiză și cunoștințe să construiască instrumente utile în întreaga stivă.

Fără a fi surprinzător, aceleași principii se aplică sistemelor zk, iar aceste straturi de abstractizare devin suficient de mature pentru ca un novice zk să înceapă să le folosească și să creeze aplicații astăzi.

Arkworks-rs este un ecosistem de biblioteci Rust care oferă implementări eficiente și sigure ale subcomponentelor unei aplicații zkSNARK. Arkworks furnizează interfețele necesare dezvoltatorilor pentru a personaliza stiva de software pentru o aplicație zk, fără a fi nevoie să reimplementați elementele comune cu alte biblioteci existente.

Înainte de Arkworks, singura modalitate de a crea o nouă aplicație zk era să construiești totul de la zero. Avantajele cheie ale Arkworks-rs față de instrumentele personalizate, integrate vertical sunt nivelul de flexibilitate, reducerea ingineriei duplicate și reducerea efortului de audit. Liniile de interfață sensibile ale Arkworks între componente permit un ritm de actualizare care poate menține stiva relevantă în ritmul vertiginos al inovației în tehnologiile zk, fără a forța echipele să reconstruiască totul de la zero.

Arkworks este pentru proiecte care au nevoie de un control fin asupra întregii stive de software zk, dar nu doresc să construiască toate piesele redundante de la zero. Dacă vă gândiți la o versiune personalizată a unui circuit DSL pentru că, de exemplu, creați prototipul unui nou sistem de probă, dar nu sunteți sigur de schema de angajament sau de curba eliptică corespunzătoare, arkworks vă va permite să schimbați rapid între mai multe opțiuni cu interfețe partajate, mai degrabă decât pornind de la zero.

Pentru a crea o dovadă despre unele calcule, mai întâi acest calcul trebuie să fie exprimat într-o formă pe care un sistem zkSNARK o poate înțelege. Mai multe limbaje specifice domeniului au creat limbaje de programare care permit dezvoltatorilor de aplicații să-și exprime calculul în acest fel. Acestea includ Aztec Noir, de la Starknet Cairo, Circom, ZoKratesși ale lui Aleo Leu printre alții. Sistemul de dovezi de bază și detaliile matematice nu sunt, în general, expuse dezvoltatorului aplicației.

Dezvoltatorii zkApp trebuie să devină competenți în scrierea programelor lor în limbaje specifice domeniului. Unele dintre aceste limbaje seamănă mult cu limbaje de programare familiare, în timp ce altele pot fi destul de dificil de învățat. Să defalcăm câteva dintre acestea:

Cairo – Starkware DSL necesar pentru construirea de aplicații pe Starknet. Compilează în limbajul de asamblare specific Cairo, care poate fi interpretat de zkVM Cairo.

ZoKrates — ZoKrates este un set de instrumente pentru nevoile comune SNARK, inclusiv un limbaj de nivel înalt pentru scrierea circuitelor. ZoKrates are, de asemenea, o oarecare flexibilitate în jurul curbelor, a schemei de demonstrare și a backend-ului, permițând dezvoltatorilor să schimbe la cald prin simplu argument CLI.

Circom — Circom este un limbaj special conceput pentru construirea de circuite. În prezent, este limbajul de facto pentru circuitele în producție. Limbajul nu este deosebit de ergonomic. Limbajul în sine te face să fii conștient de faptul că scrii circuite.

Leu — Leo a fost dezvoltat ca limbaj pentru blockchain-ul Aleo. Leo are o sintaxă asemănătoare Rust și este creat special pentru tranzițiile de stare în interiorul unui blockchain.

Noir – Sintaxă inspirată de rugină. Arhitectat în jurul IR mai degrabă decât în ​​limbajul în sine, ceea ce înseamnă că poate avea o interfață arbitrară. 

Orice dezvoltator de aplicații care dorește să profite de proprietățile unice ale zk în aplicația sa. Unele dintre aceste limbi au fost testate în luptă cu miliarde de dolari deplasându-se prin ele prin lanțuri precum ZCash și Starknet. Deși unele dintre proiectele pe care le vom discuta nu sunt destul de gata pentru utilizare în producție, scrierea circuitelor dvs. într-una dintre aceste limbi este în prezent cea mai bună strategie, cu excepția cazului în care aveți nevoie de controalele mai fine pe care le oferă un set de instrumente precum Arkworks.

Scopul principal al unui zkEVM este de a lua o tranziție de stare Ethereum și de a-și demonstra validitatea folosind o dovadă succintă a corectitudinii cu cunoștințe zero. După cum se menționează în postarea lui Vitalik, există o serie de moduri de a face acest lucru cu diferențe subtile și compromisuri corespunzătoare. 

Principala diferență tehnică dintre toate acestea este exact locul în care calculul este convertit într-o formă (aritmetizare) care poate fi utilizată într-un sistem de demonstrare. În unele zkEVM, acest lucru se întâmplă la limbajele de nivel înalt (Solidity, Vyper, Yul), în timp ce alte abordări încearcă să demonstreze EVM până la nivelul opcode. Compensațiile dintre aceste abordări au fost acoperite profund în postarea lui Vitalik, dar le voi rezuma într-o singură propoziție: cu cât conversia/aritmetizarea are loc în stivă, cu atât penalitatea de performanță este mai mare.

Principala provocare cu crearea de dovezi pentru o mașină virtuală este că dimensiunea circuitului crește proporțional cu dimensiunea TOATE instrucțiunile posibile pentru fiecare instrucțiune executată. Acest lucru se întâmplă deoarece circuitul nu știe ce instrucțiuni vor fi executate în fiecare program, așa că trebuie să le suporte pe toate.

În practică, acest lucru înseamnă că plătiți (în cost de performanță) pentru cea mai scumpă instrucțiune posibilă, chiar și atunci când executați doar cea mai simplă instrucțiune. Acest lucru duce la un compromis direct între generalizare și performanță – pe măsură ce adăugați mai multe instrucțiuni pentru generalizare, plătiți pentru asta pe fiecare instructiunea pe care o dovedesti!

Aceasta este o problemă fundamentală cu circuitele universale, dar cu noile evoluții în tehnologii la fel ca IVC (calcul incremental verificabil), această limitare poate fi ameliorată prin împărțirea calculului în bucăți mai mici, fiecare având subcircuite specializate, mai mici.

Implementările zkEVM de astăzi folosesc strategii diferite pentru a atenua impactul acestei probleme... De exemplu, zkSync scoate operațiunile mai scumpe (în mare parte pre-compilări criptografice, cum ar fi hash-uri și ECDSA) din circuitul principal de verificare a execuției în circuite separate care sunt agregate împreună la se încheie prin recursiunea snark. zkSync a adoptat această abordare după ce și-au dat seama că majoritatea costurilor lor provin din câteva instrucțiuni complexe.

În esență, motivul pentru care demonstrarea unui set de instrucțiuni mai echivalent cu EVM este mai costisitoare este că EVM nu a fost proiectat pentru calcule zk. Abandonarea EVM mai devreme în stivă permite zkEVM-urilor să ruleze pe seturi de instrucțiuni care sunt mai optimizate pentru zk și, prin urmare, mai ieftin de demonstrat.

Clienții ideali pentru un zkEVM sunt aplicațiile smart contract care au nevoie de tranzacții mult mai ieftine decât cele disponibile pe L1 Ethereum. Acești dezvoltatori nu au neapărat expertiza sau lățime de bandă pentru a scrie aplicații zk de la zero. Prin urmare, preferă să-și scrie aplicațiile în limbi de nivel superior cu care sunt familiarizați, cum ar fi Solidity. 

Scalare Ethereum este în prezent cea mai solicitată aplicație a tehnologiei zk.

Un zkEVM este o soluție de scalare Ethereum care atenuează fără frecare problema congestiei care restricționează dezvoltatorii dApp L1.

Scopul unui zkEVM este de a sprijini o experiență de dezvoltator care este cât mai apropiată de dezvoltarea actuală Ethereum. Suportul complet Solidity înseamnă că echipele nu trebuie să construiască și să mențină mai multe baze de cod. Acest lucru este oarecum impractic de făcut perfect, deoarece zkEVM-urile trebuie să schimbe o anumită compatibilitate pentru a putea genera dovezi de dimensiune rezonabilă într-un interval de timp rezonabil.

Diferența principală dintre zkSync și Scroll este unde/când în stivă efectuează aritmetizarea - adică locul în care se convertesc din constructele EVM normale într-o reprezentare prietenoasă cu SNARK. Pentru zkSync, acest lucru se întâmplă atunci când convertesc bytecode YUL în propriul set de instrucțiuni zk personalizate. Pentru Scroll, acest lucru se întâmplă la sfârșit, când următorul real de execuție este generat cu codurile operaționale EVM reale.

Deci, pentru zkSync, totul este la fel ca interacțiunea cu EVM până când este generat bytecode zk. Pentru Scroll, totul este la fel până când este executat bytecode real. Aceasta este o diferență subtilă, care schimbă performanța cu suport. De exemplu, zkSync nu va accepta instrumente EVM bytecode, cum ar fi un depanator din cutie, deoarece este un bytecode complet diferit. Deși Scroll va avea mai multe dificultăți în obținerea unei performanțe bune dintr-un set de instrucțiuni, acesta nu a fost conceput pentru zk. Există argumente pro și contra pentru ambele strategii și, în cele din urmă, există o mulțime de factori exogeni care vor afecta succesul lor relativ.

???? În ciuda denumirii sale, LLVM nu este o VM (mașină virtuală). LLVM este numele unui set de instrumente de compilare care este ancorat de o reprezentare intermediară (IR) care este independentă de limbaj.

= zero; Fundație (despre nume, este un Glumă cu injecție SQL dacă vă întrebați) construiește un compilator care poate converti orice limbaj frontend LLVM într-o reprezentare intermediară care poate fi dovedită într-un SNARK. zkLLVM este proiectat ca o extensie a infrastructurii LLVM existente, un lanț de instrumente standard din industrie care acceptă multe limbaje de nivel înalt precum Rust, C, C++ etc.

Un utilizator care dorește să demonstreze anumite calcule ar implementa pur și simplu acel calcul în C++. zkLLVM preia acest cod sursă de nivel înalt care este suportat de compilatorul lor de clang modificat (în prezent C++) și generează o reprezentare intermediară a circuitului. În acest moment, circuitul este gata să fie dovedit, dar utilizatorul poate dori să demonstreze circuitul pe baza unor intrări dinamice. Pentru a gestiona intrările dinamice, zkLLVM are o componentă suplimentară denumită asignator, care generează un tabel de atribuire cu toate intrările și martorii complet preprocesate și gata să fie dovedite alături de circuit.

Aceste 2 componente sunt tot ceea ce este necesar pentru a genera o dovadă. În mod teoretic, un utilizator poate genera el însuși o dovadă, dar deoarece aceasta este o sarcină de calcul oarecum specializată, ar putea dori să plătească pe altcineva, care are hardware-ul, să o facă pentru el. Pentru acest mecanism de descoperire a contrapartidei, =nil; Fundația a înființat, de asemenea, o „piață a dovezilor” în care probatorii concurează pentru a dovedi calcularea utilizatorilor care îi vor plăti pentru a face acest lucru. Această dinamică a pieței libere va conduce la probatori să optimizeze cele mai valoroase sarcini de proba.

Deoarece fiecare sarcină de calcul care trebuie dovedită este unică și generează un circuit diferit, există un număr infinit de circuite pe care probatorii vor trebui să le poată gestiona. Această generalizare forțată face ca optimizarea circuitelor individuale să fie dificilă. Introducerea unei piețe a probelor permite specializarea pe circuitele pe care piața le consideră valoroase. Fără această piață, ar fi o provocare să convingi un probator să optimizeze acest circuit din cauza acestei probleme naturale de pornire la rece.

Celălalt compromis este abstractizarea clasică vs control. Utilizatorii care sunt dispuși să utilizeze această interfață ușor de utilizat renunță la controlul asupra primitivelor criptografice subiacente. Pentru mulți utilizatori, acesta este un compromis foarte valid, deoarece este adesea mai bine să lăsați experții în criptografie să ia aceste decizii pentru dvs.

Un zkVM descrie supersetul tuturor mașinilor virtuale zk, în timp ce un zkEVM este un tip specific de zkVM, care a meritat să fie discutat ca subiect separat din cauza prevalenței sale în prezent. Există alte câteva proiecte care lucrează la construirea de zkVM-uri mai generalizate, care se bazează pe ISA-uri, în afară de VM-urile cripto personalizate.

În loc să dovedească EVM, sistemul ar putea dovedi o arhitectură diferită a seturilor de instrucțiuni (ISA), cum ar fi RISC-V sau WASM într-o nouă VM. Două proiecte care lucrează la aceste zkVM-uri generalizate sunt RISC Zero și zkWASM. Să ne aruncăm puțin în RISC Zero pentru a demonstra cum funcționează această strategie și câteva dintre avantajele/dezavantajele sale. 

RISC Zero este capabil să demonstreze orice calcul care este executat pe o arhitectură RISC-V. RISC-V este un standard de arhitectură de set de instrucțiuni (ISA) open-source care a câștigat popularitate. Filosofia RISC (computer cu set de instrucțiuni redus) este de a construi un set de instrucțiuni extrem de simplu, cu o complexitate minimă. Aceasta înseamnă că dezvoltatorii de la nivelurile superioare ale stivei ajung să preia o sarcină mai mare în implementarea instrucțiunilor folosind această arhitectură, simplificând în același timp implementarea hardware.

Această filozofie se aplică și calculului general, cipurile ARM au folosit seturi de instrucțiuni în stil RISC și au început să domine piața cipurilor mobile. Se pare că seturile de instrucțiuni mai simple au, de asemenea, o energie mai mare și o eficiență a zonei matriței.

Această analogie se aplică destul de bine pentru eficiența generării de dovezi zk. După cum s-a discutat anterior, atunci când dovediți o urmărire de execuție în zk, plătiți pentru suma costului tuturor instrucțiunilor pentru fiecare element din urmărire, astfel încât mai puține instrucțiuni totale este mai bine.

Din perspectiva dezvoltatorului, utilizarea RISC Zero pentru a gestiona dovezile zk este la fel ca utilizarea funcțiilor AWS Lambda pentru a gestiona arhitectura serverului de backend. Dezvoltatorii interacționează cu RISC Zero sau AWS Lambda prin simpla scriere a codului, iar serviciul se ocupă de toată complexitatea backend-ului.

Pentru RISC Zero, dezvoltatorii scriu Rust sau C++ (eventual orice vizează RISC-V). Apoi, sistemul preia fișierul ELF generat în timpul compilării și îl folosește ca cod de intrare pentru circuitul VM. Dezvoltatorii apelează pur și simplu probe care returnează o chitanță (care conține dovada zk a urmării execuției) obiect pe care oricine îl poate apela `verify` de oriunde. Din punctul de vedere al dezvoltatorului, nu este nevoie să înțelegem cum funcționează zk, sistemul de bază se ocupă de toată această complexitate.

Pentru unele circuite de bază și reutilizabile care sunt deosebit de utile pentru aplicațiile blockchain sau în altă parte, este posibil ca echipele să fi construit și optimizat deja aceste circuite pentru dvs. Puteți furniza doar intrarea pentru cazul dvs. de utilizare particular. O dovadă a includerii Merkle, de exemplu, este ceva care este necesar în mod obișnuit în aplicațiile cripto (liste de airdrop, Tornado Cash etc.). În calitate de dezvoltator de aplicații, puteți oricând să reutilizați aceste contracte testate în luptă și doar să modificați straturile de deasupra pentru a crea o aplicație unică.

De exemplu, circuitele Tornado Cash pot fi reutilizate pentru a aplicație de airdrop privată sau un cerere de vot privat. Manta și Semaphore construiesc un întreg set de instrumente de gadgeturi de circuit obișnuite ca acesta, care pot fi utilizate în contractele Solidity, cu o înțelegere mică sau deloc a matematicii lunare zk subiacente.

După cum am discutat pe larg, există o multitudine de opțiuni diferite pentru dezvoltarea unei aplicații zk, toate cu propriul lor set unic de compromisuri. Acest grafic vă va ajuta să rezumați această matrice de decizie, astfel încât, pe baza nivelului dvs. de expertiză zk și a nevoilor de performanță, să puteți alege cel mai bun instrument pentru job. Aceasta nu este o listă cuprinzătoare, plănuiesc să o adaug pe viitor, pe măsură ce devin conștientă de mai multe instrumente care apar în spațiu.

zk este la vârful mai multor tehnologii, iar construirea lui necesită o înțelegere profundă a matematicii, criptografiei, informaticii și ingineriei hardware. Cu toate acestea, cu tot mai multe straturi de abstractizare disponibile în fiecare zi, dezvoltatorii de aplicații pot valorifica puterea zk fără un doctorat. Deoarece limitările timpilor de probă sunt eliminate încet în timp prin optimizări la toate nivelurile stivei, probabil că vom vedea instrumente și mai simple pentru dezvoltatorul mediu.

Sper că te-am convins pe tine, curiosul dezvoltator de software, că poți începe să folosești zk în aplicațiile tale astăzi. Hacking fericit 🙂

Dezvaluiri: Blockchain Capital este un investitor în mai multe dintre protocoalele menționate mai sus.

Părerile exprimate în fiecare postare pe blog pot fi părerile personale ale fiecărui autor și nu reflectă neapărat punctele de vedere ale Blockchain Capital și ale afiliaților săi. Nici Blockchain Capital și nici autorul nu garantează acuratețea, adecvarea sau caracterul complet al informațiilor furnizate în fiecare postare de blog. Nicio reprezentare sau garanție, expresă sau implicită, nu este făcută sau oferită de către sau în numele Blockchain Capital, autor sau orice altă persoană cu privire la acuratețea și exhaustivitatea sau corectitudinea informațiilor conținute în orice postare de blog și nu este acceptată nicio responsabilitate sau răspundere. pentru orice astfel de informații. Nimic din conținutul fiecărei postări de blog nu constituie sfaturi de investiții, de reglementare, juridice, de conformitate sau fiscale sau alte sfaturi și nici nu trebuie să se bazeze pe el în luarea unei decizii de investiție. Postările de pe blog nu trebuie privite ca recomandări sau solicitări actuale sau trecute ale unei oferte de cumpărare sau vânzare de valori mobiliare sau de adoptare a oricărei strategii de investiții. Postările de blog pot conține proiecții sau alte declarații prospective, care se bazează pe convingeri, ipoteze și așteptări care se pot schimba ca urmare a multor evenimente sau factori posibili. Dacă apare o schimbare, rezultatele reale pot varia semnificativ de cele exprimate în declarațiile prospective. Toate declarațiile prospective vorbesc numai de la data la care aceste declarații sunt făcute și nici Blockchain Capital și nici fiecare autor nu își asumă obligația de a actualiza astfel de declarații, cu excepția cazului în care este cerut de lege. În măsura în care orice documente, prezentări sau alte materiale produse, publicate sau distribuite în alt mod de Blockchain Capital sunt menționate în orice postare de blog, astfel de materiale trebuie citite cu atenție la orice declinare a răspunderii furnizate în acestea.