Testo completo della proposta a lungo termine di Vitalik per il livello esecutivo L1: sostituzione dell'EVM con RISC-V

Fonte: Vitalik Buterin

Compilazione: KarenZ, Notizie di previsione

Il 20 aprile, Vitalik Buterin ha presentato un'importante proposta sulla piattaforma Ethereum Magicians per il livello di esecuzione L1 a lungo termine di Ethereum. Ha proposto di sostituire l'EVM (Ethereum Virtual Machine) esistente con l'architettura RISC-V come linguaggio di macchina virtuale per la scrittura di contratti intelligenti, con l'obiettivo di migliorare fondamentalmente l'efficienza operativa del livello di esecuzione di Ethereum, superare uno degli attuali principali colli di bottiglia di scalabilità e semplificare notevolmente la semplicità del livello di esecuzione.

Foresight News ha compilato il testo completo della proposta per aiutare i lettori a comprendere questa visione tecnica. Quella che segue è una raccolta della proposta originale:

Questo documento presenta un'idea radicale sul futuro del livello di esecuzione di Ethereum, non meno ambiziosa delle iniziative Beam Chain del livello di consenso. La proposta mira a migliorare notevolmente l'efficienza del livello di esecuzione di Ethereum, affrontare uno dei principali colli di bottiglia di scalabilità e semplificare significativamente il livello di esecuzione: in effetti, questo potrebbe essere l'unico modo per raggiungere questo obiettivo.

Idea di base: sostituire EVM con RISC-V come linguaggio di macchina virtuale per gli smart contract.

Note importanti:

• Concetti come il sistema di account, le chiamate cross-contract, l'archiviazione, ecc., saranno completamente mantenuti. Questi disegni astratti funzionano bene e gli sviluppatori sono abituati a usarli. GLI OPCODE COME SLOAD, SSTORE, BALANCE, CALL, ECC., VENGONO CONVERTITI IN CHIAMATE DI SISTEMA RISC-V.

• In questa modalità, gli smart contract possono essere scritti in Rust, ma mi aspetto che la maggior parte degli sviluppatori continui a scrivere contratti in Solidity (o Vyper), che si adatterà a RISC-V come nuovo backend. Perché gli smart contract scritti in Rust sono in realtà meno leggibili, mentre Solidity e Vyper sono più chiari e facili da leggere. L'esperienza di sviluppo potrebbe essere leggermente influenzata e gli sviluppatori potrebbero non notare nemmeno il cambiamento.

• Il vecchio contratto EVM continuerà a funzionare ed è completamente compatibile in modo bidirezionale con il nuovo contratto RISC-V. Esistono diversi modi per eseguire questa operazione, che verranno discussi più dettagliatamente più avanti in questo articolo.

Nervos CKB VM ha stabilito un precedente ed è essenzialmente un'implementazione RISC-V.

Perché?

A breve termine, le prossime EIP (ad esempio, elenchi di accesso a livello di blocco, esecuzione differita, archiviazione della cronologia distribuita e EIP-4444) affronteranno i principali colli di bottiglia di scalabilità di Ethereum L1. Altri problemi saranno risolti a medio termine con l'apolidia e la ZK-EVM. Sul lungo periodo, i principali fattori limitanti per lo scaling di Ethereum L1 saranno:

1. Stabilità della disponibilità dei dati, del campionamento e dei protocolli di archiviazione cronologici

2. Mantenere la domanda di concorrenza nel mercato della produzione di blocchi

3. Prova dello ZK-EVM

Sosterrò che la sostituzione di ZK-EVM con RISC-V può risolvere i principali colli di bottiglia in (2) e (3).

La tabella seguente illustra il numero di cicli necessari per ogni fase del livello di esecuzione EVM di prova ZK-EVM succinta:

Descrizione del diagramma: I quattro segmenti principali che richiedono molto tempo sono deserialize_inputs, initialize_witness_db, state_root_computation e block_execution

initialize_witness_db e state_root_computation sono correlati agli alberi di stato e deserialize_inputs implicano il processo di conversione dei dati di blocco e di testimone in rappresentazioni interne, oltre il 50% delle quali è effettivamente proporzionale alle dimensioni dei dati di testimonianza.

Queste sezioni possono essere notevolmente ottimizzate sostituendo l'attuale albero di Merkle patricia keccak 16-ary con un albero binario che utilizza una funzione hash facile da dimostrare. Se usiamo Poseidon, possiamo dimostrare 2 milioni di hash al secondo su un laptop (rispetto ai circa 15.000 hash/sec per keccak). Oltre a Poseidone, ci sono molte altre opzioni. Nel complesso, c'è molto spazio per l'ottimizzazione di questi componenti. Inoltre, possiamo eliminare accrue_logs_bloom rimuovendo la fioritura.

Il block_execution rimanente rappresenta circa la metà degli attuali cicli di lievitazione. Per ottenere un aumento di 100 volte dell'efficienza di prova complessiva, è necessaria un'efficienza di prova EVM di almeno 50 volte. Una soluzione consiste nel creare un'implementazione di prova più efficiente per l'EVM, mentre l'altra consiste nel notare che l'attuale prover ZK-EVM compila effettivamente l'EVM in RISC-V per la prova, fornendo agli sviluppatori di smart contract l'accesso diretto alla macchina virtuale RISC-V.

Alcuni dati mostrano che in determinate situazioni possono verificarsi guadagni di efficienza superiori a 100 volte:

In pratica, il tempo di prover rimanente può essere per lo più occupato dall'operazione di precompilazione corrente. Con RISC-V come macchina virtuale primaria, la pianificazione del gas rifletterà il tempo di prova effettivo e la pressione economica spingerà gli sviluppatori a ridurre l'uso della precompilazione ad alto costo. Anche in questo caso, i guadagni non saranno così significativi, ma abbiamo buone ragioni per credere che saranno sostanziali.

(Vale la pena notare che anche il tempo impiegato per le "operazioni EVM" e le "altre operazioni" nell'esecuzione normale dell'EVM è vicino al 50/50, quindi assumiamo intuitivamente che la rimozione dell'EVM come "strato intermedio" porterà un guadagno altrettanto significativo.)

Dettagli di implementazione

Esistono diversi modi per attuare questa proposta. La soluzione meno dirompente consiste nel supportare entrambe le macchine virtuali e consentire la scrittura del contratto in una di esse. Entrambi i tipi di contratti hanno accesso alle stesse funzionalità: archiviazione persistente (SLOAD/SSTORE), capacità di detenere saldi ETH, avviare/ricevere chiamate e altro ancora. I contratti EVM e RISC-V possono essere chiamati l'uno all'altro - dal punto di vista RISC-V, chiamare il contratto EVM equivale a eseguire una chiamata di sistema con parametri speciali; Il contratto EVM che riceve il messaggio lo interpreterà come una CALL.

Un approccio più radicale dal punto di vista del protocollo consiste nel convertire un contratto EVM esistente in una chiamata a un contratto interprete EVM scritto in RISC-V per eseguire il codice EVM esistente. Ovvero, se un contratto EVM ha il codice C e l'interprete EVM si trova all'indirizzo X, il contratto verrà sostituito con la logica di primo livello che, quando viene chiamata dall'esterno con un argomento di chiamata D, chiama X e passa (C, D), quindi attende il valore restituito e inoltra. Se l'interprete EVM stesso chiama il contratto, chiedendo di eseguire CALL o SLOAD/SSTORE, il contratto esegue queste operazioni.

Il compromesso è la seconda opzione, ma con un supporto esplicito al concetto di "interprete di macchina virtuale" attraverso un protocollo che richiede che la sua logica sia scritta in RISC-V. EVM sarà la prima istanza, con il supporto per altre lingue in futuro (Move potrebbe essere un candidato).

Il vantaggio principale della seconda e della terza opzione è che semplificano notevolmente la specifica del livello di esecuzione. DATA LA DIFFICOLTÀ DI RIMUOVERE ANCHE SOLO LE SEMPLIFICAZIONI INCREMENTALI COME L'AUTODISTRUZIONE, QUESTA LINEA DI PENSIERO POTREBBE ESSERE L'UNICA STRADA PERCORRIBILE PER SEMPLIFICARE. Tinygrad aderisce alla rigida regola di "non più di 10.000 righe di codice" e la blockchain sottostante ottimale dovrebbe essere in grado di soddisfare facilmente questo limite e semplificarlo ulteriormente. L'iniziativa Beam Chain promette di semplificare notevolmente il livello di consenso di Ethereum, e un cambiamento così radicale potrebbe essere l'unico modo per ottenere una spinta simile a livello di esecuzione.