Textul integral al propunerii pe termen lung a lui Vitalik pentru nivelul executiv L1: înlocuirea EVM cu RISC-V

Sursa: Vitalik Buterin

Compilație: KarenZ, Foresight News

Pe 20 aprilie, Vitalik Buterin a prezentat o propunere importantă pe platforma Ethereum Magicians pentru stratul de execuție L1 pe termen lung al Ethereum. El a propus înlocuirea EVM (Ethereum Virtual Machine) existentă cu arhitectura RISC-V ca limbaj de mașină virtuală pentru scrierea de contracte inteligente, cu scopul de a îmbunătăți fundamental eficiența operațională a stratului de execuție al Ethereum, de a depăși unul dintre blocajele majore actuale de scalare și de a simplifica foarte mult simplitatea stratului de execuție.

Foresight News a compilat textul integral al propunerii pentru a ajuta cititorii să înțeleagă această viziune tehnică. Următoarea este o compilație a propunerii inițiale:

Această lucrare prezintă o idee radicală despre viitorul stratului de execuție al Ethereum, nu mai puțin ambițioasă decât inițiativele Beam Chain ale stratului de consens. Propunerea își propune să îmbunătățească dramatic eficiența stratului de execuție al Ethereum, să abordeze unul dintre blocajele majore de scalare și să simplifice semnificativ stratul de execuție – de fapt, aceasta poate fi singura modalitate de a realiza acest lucru.

Ideea de bază: Înlocuirea EVM cu RISC-V ca limbaj de mașină virtuală pentru contractele inteligente.

Note importante:

• Concepte precum sistemul de conturi, apelarea între contracte, stocarea etc., vor fi păstrate pe deplin. Aceste modele abstracte funcționează bine și dezvoltatorii sunt obișnuiți să le folosească. CODURILE OPERAȚIONALE PRECUM SLOAD, SSTORE, BALANCE, CALL ETC., SUNT CONVERTITE ÎN APELURI DE SISTEM RISC-V.

• În acest mod, contractele inteligente pot fi scrise în Rust, dar mă aștept ca majoritatea dezvoltatorilor să continue să scrie contracte în Solidity (sau Vyper), care se va adapta la RISC-V ca nou backend. Pentru că contractele inteligente scrise în Rust sunt de fapt mai puțin lizibile, în timp ce Solidity și Vyper sunt mai clare și mai ușor de citit. Experiența de dezvoltare poate fi abia afectată, iar dezvoltatorii ar putea nici măcar să nu observe schimbarea.

• Vechiul contract EVM va continua să funcționeze și este pe deplin compatibil bidirecțional cu noul contract RISC-V. Există mai multe moduri de a face acest lucru, care vor fi discutate mai detaliat mai târziu în acest articol.

Nervos CKB VM a stabilit un precedent și este în esență o implementare RISC-V.

De ce?

Pe termen scurt, viitoarele EIP (de exemplu, liste de acces la nivel de bloc, execuție amânată, stocare distribuită a istoricului și EIP-4444) vor aborda blocajele majore de scalare ale Ethereum L1. Mai multe probleme vor fi rezolvate pe termen mediu cu apatridia și ZK-EVM. Pe termen lung, principalii factori limitativi pentru scalarea Ethereum L1 vor deveni:

1. Stabilitatea datelor privind disponibilitatea datelor, eșantionarea și protocoalele de stocare istorică

2. Menținerea cererii de concurență pe piața de producție de blocuri

3. Dovada ZK-EVM

Voi argumenta că înlocuirea ZK-EVM cu RISC-V poate rezolva blocajele cheie din (2) și (3).

Următorul tabel ilustrează numărul de cicluri necesare pentru fiecare pas al stratului de execuție Succinct ZK-EVM Proof EVM:

Descrierea diagramei: Cele patru segmente principale consumatoare de timp sunt deserialize_inputs, initialize_witness_db, state_root_computation și block_execution

initialize_witness_db și state_root_computation sunt legate de arborii de stare și deserialize_inputs implică procesul de conversie a datelor de bloc și martori în reprezentări interne – dintre care mai mult de 50% sunt de fapt proporționale cu dimensiunea datelor martorilor.

Aceste secțiuni pot fi mult optimizate prin înlocuirea actualului arbore de patricia Merkle cu un arbore binar care folosește o funcție hash ușor de dovedit. Dacă folosim Poseidon, putem dovedi 2 milioane de hash-uri pe secundă pe un laptop (comparativ cu aproximativ 15.000 hash/sec pentru keccak). Pe lângă Poseidon, există multe alte opțiuni. În general, există mult loc de optimizare pentru aceste componente. În plus, putem elimina accrue_logs_bloom prin eliminarea înfloririi.

Restul block_execution reprezintă aproximativ jumătate din ciclurile actuale de testare. Pentru a obține o creștere de 100 de ori a eficienței generale proof, este necesară o eficiență EVM proof de cel puțin 50x. O soluție este de a crea o implementare de dovadă mai eficientă pentru EVM, iar cealaltă este de a observa că actualul demonstrator ZK-EVM compilează de fapt EVM la RISC-V pentru dovadă, oferind dezvoltatorilor de contracte inteligente acces direct la mașina virtuală RISC-V.

Unele date arată că în anumite situații pot apărea creșteri de eficiență de peste 100 de ori:

În practică, timpul rămas poate fi ocupat în mare parte de operațiunea curentă de precompilare. Cu RISC-V ca VM principal, programul de gaze va reflecta timpul real de verificare, iar presiunea economică va determina dezvoltatorii să reducă utilizarea precompilării cu costuri ridicate. Chiar și atunci, câștigurile nu vor fi atât de semnificative, dar avem motive întemeiate să credem că vor fi substanțiale.

(Este demn de remarcat faptul că timpul necesar pentru "operațiunile EVM" și "alte operațiuni" în execuția EVM obișnuită este, de asemenea, aproape de 50/50, așa că presupunem intuitiv că eliminarea EVM ca "strat intermediar" va aduce un câștig la fel de semnificativ.)

Detalii de implementare

Există mai multe modalități de a pune în aplicare această propunere. Soluția cea mai puțin perturbatoare este să susțineți ambele mașini virtuale și să permiteți scrierea contractului într-una dintre ele. Ambele tipuri de contracte au acces la aceleași caracteristici: stocare persistentă (SLOAD/SSTORE), capacitatea de a păstra solduri ETH, de a iniția/primi apeluri și multe altele. Contractele EVM și RISC-V pot fi apelate unul la celălalt - din perspectiva RISC-V, apelarea contractului EVM este echivalentă cu executarea unui apel de sistem cu parametri speciali; Contractul EVM care primește mesajul îl va interpreta ca un APEL.

O abordare mai radicală din perspectiva protocolului este de a converti un contract EVM existent într-un apel la un contract de interpret EVM scris în RISC-V pentru a rula codul EVM existent. Adică, dacă un contract EVM are codul C și interpretorul EVM se află la adresa X, atunci contractul va fi înlocuit cu o logică de nivel superior care, atunci când este apelată din exterior cu un argument de apel D, apelează X și transmite (C, D), apoi așteaptă valoarea returnată și redirecționează. Dacă interpretul EVM însuși apelează contractul, cerând să ruleze CALL sau SLOAD/SSTORE, atunci contractul efectuează aceste operațiuni.

Compromisul este a doua opțiune, dar cu suport explicit pentru conceptul de "interpret de mașină virtuală" printr-un protocol care necesită ca logica sa să fie scrisă în RISC-V. EVM va fi prima instanță, cu suport pentru alte limbi în viitor (Move poate fi un candidat).

Avantajul principal al celei de-a doua și a treia opțiuni este că simplifică foarte mult specificația stratului de execuție. AVÂND ÎN VEDERE DIFICULTATEA DE A ELIMINA SIMPLIFICĂRILE INCREMENTALE, CUM AR FI AUTODISTRUGEREA, ACEASTĂ LINIE DE GÂNDIRE POATE FI SINGURA CALE VIABILĂ DE SIMPLIFICARE. Tinygrad aderă la regula strictă de "nu mai mult de 10.000 de linii de cod", iar blockchain-ul optim ar trebui să poată îndeplini cu ușurință această limită și să o eficientizeze în continuare. Inițiativa Beam Chain promite să simplifice dramatic stratul de consens al Ethereum, iar o astfel de schimbare radicală poate fi singura modalitate de a obține un impuls similar la nivelul de execuție.