Gli sviluppatori smentiscono Vitalik: le supposizioni sono sbagliate e RISC-V non è la scelta migliore

Questo articolo è tratto da: Sviluppatore Ethereum levochka.eth

compilation|Odaily Planet Daily (@OdailyChina); @azuma_eth Nota dell'editore

:

ieri, il co-fondatore di Ethereum Vitalik ha pubblicato un articolo radicale sull'aggiornamento del livello di esecuzione di Ethereum (vedi "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), menzionando che spera di sostituirlo con RISC-V EVM come linguaggio di macchina virtuale per contratti intelligenti.

Non appena questo articolo è uscito, ha immediatamente suscitato scalpore nella comunità degli sviluppatori di Ethereum e molti pezzi grossi della tecnica hanno espresso opinioni diverse sul piano. Poco dopo la pubblicazione dell'articolo, lo sviluppatore di Ethereum Tier-1 levochka.eth ha scritto un lungo articolo sotto l'articolo originale confutando l'argomentazione di Vitalik secondo cui Vitalik aveva fatto ipotesi sbagliate sul sistema di prova e sulle sue prestazioni, e che RISC-V potrebbe non essere la scelta migliore perché non poteva bilanciare "scalabilità" e "manutenibilità".

Quello che segue è l'articolo originale su levochka.eth, compilato dal quotidiano Odaily.

Per favore, non farlo.

Questo piano non ha senso, perché stai facendo le ipotesi sbagliate sulla dimostrazione del sistema e delle sue prestazioni.

Ipotesi di validazione

Da quanto ho capito, gli argomenti principali per questo schema sono la "scalabilità" e la "manutenibilità".

Innanzitutto, voglio parlare della manutenibilità.

In effetti, tutte le zk-VM RISC-V richiedono "precompilazioni" per gestire operazioni ad alta intensità di calcolo. L'elenco precompilato di SP 1 può essere trovato nella documentazione di Succinct, e scoprirai che copre quasi tutti gli importanti opcode "computazionali" nell'EVM.

Di conseguenza, tutte le modifiche alle primitive crittografiche del livello base richiedono la scrittura e l'audit di nuovi "circuiti" per queste precompilazioni, il che rappresenta una grave limitazione.

Infatti, se le prestazioni sono sufficientemente buone, può essere relativamente facile eseguire la manutenzione della parte "non-EVM" del client. Non sono sicuro che sia abbastanza buono, ma sono meno fiducioso in questa parte per i seguenti motivi: il

• "calcolo dell'albero degli stati" può effettivamente essere notevolmente accelerato con una pre-compilazione amichevole come Poseidon.

• Tuttavia, non è chiaro se la "deserializzazione" possa essere gestita in modo elegante e manutenibile.
  

• Inoltre, ci sono alcuni dettagli complicati (come la misurazione del gas e vari controlli) che possono rientrare nel "tempo di valutazione del blocco" ma che in realtà dovrebbero essere classificati come parti "non EVM", che tendono ad essere più vulnerabili alla pressione di manutenzione.

In secondo luogo, la parte relativa alla scalabilità.

Devo ribadire che è impossibile per RISC-V gestire carichi EVM senza utilizzare la precompilazione, assolutamente no.

Quindi, l'affermazione nel testo originale che "il tempo di dimostrazione finale sarà dominato dall'attuale operazione di precompilazione" è tecnicamente corretta, ma è eccessivamente ottimistica - presuppone che non ci sarà alcuna precompilazione in futuro, quando in realtà (in questo scenario futuro) la precompilazione esisterà ancora, ed è esattamente la stessa dei codici operativi ad alta intensità di calcolo nell'EVM (come firme, hash e possibilmente analoghi di grandi dimensioni).

È difficile giudicare l'esempio di Fibonacci senza entrare nei dettagli più sottili, ma i vantaggi arrivano almeno in parte:

• la differenza tra l'interpretazione e l'esecuzione in generale;

• Svolgimento ciclico (riducendo il "flusso di controllo" di RISC-V, non è certo se Solidity possa essere implementato, ma anche un singolo opcode può comunque generare un gran numero di accessi al flusso di controllo/memoria a causa di un sovraccarico di interpretazione);

• utilizzare tipi di dati più piccoli;

Qui vorrei sottolineare che per realizzare i benefici del punto 1 e del punto 2, il "sovraccarico di interpretazione" deve essere eliminato. Questo è in linea con la filosofia di RISC-V, ma non si tratta del RISC-V di cui stiamo discutendo attualmente, ma piuttosto di un simile "(?)RISC-V" - richiede alcune capacità aggiuntive, come il supporto per i concetti di contratto.

Ecco che arriva il problema

, quindi, ci sono alcuni problemi qui.

• Per migliorare la manutenibilità, è necessario un RISC-V (con precompilazione) che compili l'EVM: questo è praticamente tutto.

• Per migliorare la scalabilità, è necessario qualcosa di completamente diverso: una nuova architettura che potrebbe essere simile a RISC-V che comprende il concetto di "contratti", è compatibile con le limitazioni di runtime di Ethereum e può eseguire direttamente il codice del contratto (senza il "sovraccarico di interpretazione").

Ora presumo che tu ti stia riferendo al secondo caso (dato che il resto dell'articolo sembra implicare questo). Devo attirare la vostra attenzione sul fatto che tutto il codice al di fuori di questo ambiente sarà ancora scritto nell'attuale linguaggio zkVM RISC-V, che ha un impatto significativo sulla manutenzione.

In alternativa,

possiamo compilare il bytecode dal codice operativo EVM di alto livello. Il compilatore è responsabile di garantire che il builder rimanga invariante, ad esempio non si verifichi un "overflow dello stack". Mi piacerebbe vederlo mostrato in un normale EVM. Gli SNARK compilati correttamente possono essere forniti con le istruzioni per la distribuzione del contratto.

Possiamo anche costruire una "prova formale" che dimostri che alcuni invarianti sono conservati. Per quanto ne so, questo approccio (non la "virtualizzazione") è stato utilizzato in alcuni contesti di browser. Generando SNARK di questa dimostrazione formale, è possibile ottenere risultati simili. 

Naturalmente, l'opzione più semplice è stringere i denti e fare ......

Costruire una MMU "concatenata" minima

, che si può implicitamente esprimere nell'articolo, ma lasciatemi avvertire che se si vuole eliminare il sovraccarico di virtualizzazione, è necessario eseguire direttamente il codice compilato, il che significa che è necessario in qualche modo impedire al contratto (ora eseguibile) di scrivere sulla memoria del kernel (non un'implementazione EVM).

Pertanto, abbiamo bisogno di una sorta di "unità di gestione della memoria" (MMU). Il meccanismo di paging dei computer tradizionali potrebbe non essere necessario perché lo spazio di memoria "fisico" è quasi infinito. Questa MMU dovrebbe essere il più snella possibile (perché è allo stesso livello di astrazione dell'architettura stessa), ma alcune funzionalità come l'atomicità delle transazioni possono essere spostate su questo livello.

A questo punto, l'EVM dimostrabile diventa il programma del kernel in esecuzione su questa architettura.

È

interessante notare che, in tutte queste condizioni, la migliore "architettura del set di istruzioni" (ISA) per questa attività potrebbe non essere RISC-V, ma qualcosa di simile a EOF-EVM per i seguenti motivi:

• I codici operativi "piccoli" in realtà comportano un grande accesso alla memoria, che è difficile da gestire in modo efficiente per i metodi di attestazione esistenti.

• Per ridurre il sovraccarico di diramazione, abbiamo mostrato come dimostrare il codice EOF (Static Jumps) con prestazioni a livello di precompilazione nel nostro recente articolo, Morgana.

Il mio suggerimento è di costruire una nuova architettura proof-friendly con una MMU minima che consenta al contratto di funzionare come eseguibile separato. Non credo che dovrebbe essere RISC-V, ma piuttosto un nuovo ISA ottimizzato per le limitazioni del protocollo SNARK, e anche un ISA che eredita parzialmente un sottoinsieme di opcode EVM potrebbe essere migliore - come sappiamo, la precompilazione è qui per restare, che ci piaccia o no, quindi RISC-V non porta alcuna semplificazione qui.