Dezvoltatorii îl resping pe Vitalik: presupunerile sunt greșite, iar RISC-V nu este cea mai bună alegere

Acest articol este din: Ethereum developer levochka.eth

compilation|Odaily Planet Daily (@OdailyChina); @azuma_eth Nota editorului

:

Ieri, co-fondatorul Ethereum, Vitalik, a lansat un articol radical despre actualizarea stratului de execuție al Ethereum (vezi "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), menționând că speră să-l înlocuiască cu RISC-V EVM ca limbaj de mașină virtuală pentru contracte inteligente.

De îndată ce a apărut acest articol, a provocat imediat un scandal în comunitatea dezvoltatorilor Ethereum și mulți mari tehnicieni și-au exprimat opinii diferite cu privire la plan. La scurt timp după publicarea articolului, dezvoltatorul Ethereum de nivel 1 levochka.eth a scris un articol lung sub articolul original, respingând argumentul lui Vitalik că Vitalik a făcut presupuneri greșite despre sistemul de dovezi și performanța acestuia și că RISC-V ar putea să nu fie cea mai bună alegere, deoarece nu a putut echilibra "scalabilitatea" și "mentenabilitatea".

Următorul este articolul original de pe levochka.eth, compilat de cotidianul Odaily.

Vă rog să nu faceți asta.

Acest plan nu are sens, pentru că faci presupuneri greșite despre dovedirea sistemului și a performanței sale.

Ipoteza de validare

După cum am înțeles, principalele argumente pentru această schemă sunt "scalabilitatea" și "menținența".

În primul rând, vreau să vorbesc despre mentenanță.

De fapt, toate ZK-VM-urile RISC-V necesită "precompilări" pentru a gestiona operațiunile de calcul intensive. Lista pre-compilată a SP 1 poate fi găsită în documentația Succinct și veți descoperi că acoperă aproape toate codurile operaționale "computaționale" importante din EVM.

Ca urmare, toate modificările primitivelor criptografice ale stratului de bază necesită noi "circuite" care să fie scrise și auditate pentru aceste precompilații, ceea ce este o limitare serioasă.

Într-adevăr, dacă performanța este suficient de bună, poate fi relativ ușor să efectuați funcționalitatea părții "non-EVM" a clientului. Nu sunt sigur dacă este suficient de bun, dar sunt mai puțin încrezător în această parte din următoarele motive:

• "calculul arborelui de stare" poate fi într-adevăr mult accelerat cu o pre-compilare prietenoasă precum Poseidon.

• Cu toate acestea, nu este clar dacă "deserializarea" poate fi gestionată într-o manieră elegantă și ușor de întreținut.
  

• În plus, există câteva detalii dificile (cum ar fi contorizarea gazului și diverse verificări) care se pot încadra în "timpul de evaluare a blocului", dar ar trebui de fapt clasificate ca piese "non-EVM", care tind să fie mai vulnerabile la presiunea de întreținere.

În al doilea rând, partea despre scalabilitate.

Trebuie să reiterez că este imposibil pentru RISC-V să gestioneze sarcinile EVM fără a utiliza precompilarea, absolut nu.

Deci, afirmația din textul original că "timpul de demonstrație finală va fi dominat de operațiunea curentă de precompilare" este corectă din punct de vedere tehnic, dar este prea optimistă - presupune că nu va exista precompilare în viitor, când de fapt (în acest scenariu viitor) precompilarea va mai exista și este exact aceeași cu codurile de operare intensive din EVM (cum ar fi semnături, hash-uri și, eventual, analogi mari).

Este greu să judeci exemplul Fibonacci fără a intra în cele mai subtile detalii, dar avantajele vin cel puțin parțial:

• diferența dintre interpretare și execuție;

• Derulare ciclică (reducând "fluxul de control" al RISC-V, este incert dacă Solidity poate fi implementat, dar chiar și un singur cod operațional poate genera un număr mare de fluxuri de control/accese de memorie din cauza supraîncărcării de interpretare);

• utilizați tipuri de date mai mici;

Aici aș dori să subliniez că pentru a realiza beneficiile punctului 1 și al punctului 2, trebuie eliminată "cheltuielile generale de interpretare". Acest lucru este în conformitate cu filozofia RISC-V, dar acesta nu este RISC-V despre care discutăm în prezent, ci mai degrabă un "(?)RISC-V" similar - necesită anumite capabilități suplimentare, cum ar fi suportul pentru concepte contractuale.

Aici intervine problema

, deci există unele probleme aici.

• Pentru a îmbunătăți mentenabilitatea, aveți nevoie de un RISC-V (cu precompilare) care compilează EVM - cam atât.

• Pentru a îmbunătăți scalabilitatea, este nevoie de ceva complet diferit – o nouă arhitectură care ar putea fi similară cu RISC-V, care înțelege conceptul de "contracte", este compatibilă cu limitările de rulare Ethereum și poate executa codul de contract direct (fără "supraîncărcarea de interpretare").

Presupun acum că vă referiți la al doilea caz (deoarece restul articolului pare să implice asta). Trebuie să vă atrag atenția asupra faptului că tot codul din afara acestui mediu va fi în continuare scris în actualul limbaj RISC-V zkVM, ceea ce are un impact semnificativ asupra întreținerii.

Ca alternativă,

putem compila codul de octeți din codul de operare EVM de nivel înalt. Compilatorul este responsabil pentru a se asigura că constructorul rămâne invariant, cum ar fi să nu se confrunte cu o "depășire a stivei". Mi-ar plăcea să văd acest lucru arătat într-un EVM normal. SNARK-urile compilate corespunzător pot fi furnizate cu instrucțiuni de implementare a contractului.

De asemenea, putem construi o "dovadă formală" care dovedește că unii invarianți sunt păstrați. Din câte îmi dau seama, această abordare (nu "virtualizarea") a fost folosită în unele contexte de browser. Prin generarea SNARK-urilor acestei demonstrații formale, puteți obține rezultate similare. 

Desigur, cea mai ușoară opțiune este să muști glonțul și să faci ......

Construirea unui MMU minim "înlănțuit",

pe care îl puteți exprima implicit în articol, dar permiteți-mi să avertizez că, dacă doriți să eliminați supraîncărcarea virtualizării, trebuie să executați codul compilat direct - ceea ce înseamnă că trebuie să împiedicați cumva contractul (acum executabil) să scrie în memoria kernelului (nu o implementare EVM).

Prin urmare, avem nevoie de un fel de "unitate de gestionare a memoriei" (MMU). Mecanismul de paginare al computerelor tradiționale poate să nu fie necesar, deoarece spațiul de memorie "fizic" este aproape infinit. Acest MMU ar trebui să fie cât mai suplu posibil (deoarece este la același nivel de abstractizare ca și arhitectura în sine), dar unele caracteristici precum atomicitatea tranzacțiilor pot fi mutate în acest strat.

În acest moment, EVM demonstrabil devine programul kernel care rulează pe această arhitectură.

Interesant este că

, în toate aceste condiții, cea mai bună "arhitectură de set de instrucțiuni" (ISA) pentru această sarcină poate să nu fie RISC-V, ci ceva similar cu EOF-EVM din următoarele motive:

• codurile operaționale "mici" duc de fapt la mult acces la memorie, ceea ce este dificil de gestionat eficient pentru metodele de atestare existente.

• Pentru a reduce supraîncărcarea ramificării, am arătat cum să dovedim codul "salturi statice" (EOF) cu performanțe la nivel de precompilare în lucrarea noastră recentă, Morgana.

Sugestia mea este să construim o nouă arhitectură prietenoasă cu dovezile cu o MMU minimă care să permită contractului să ruleze ca un executabil separat. Nu cred că ar trebui să fie RISC-V, ci mai degrabă un nou ISA optimizat pentru limitările protocolului SNARK, și chiar și un ISA care moștenește parțial un subset de coduri de operare EVM ar putea fi mai bun - după cum știm, precompilarea este aici pentru a rămâne, fie că ne place sau nu, așa că RISC-V nu aduce nicio simplificare aici.