Ethereum potrebbe affrontare il più grande upgrade della sua storia: EVM fuori servizio, RISC-V prende il controllo

Titolo originale: Goodbye EVM, Hello RISC-V

Autore originale: jaehaerys.eth, ricercatore crypto

Traduzione originale: TechFlow

Sommario

Ethereum si sta preparando per la trasformazione architettonica più importante dalla sua nascita: sostituire EVM con RISC-V.

La ragione è semplice: in un futuro incentrato sulle zero-knowledge (ZK), EVM è diventato un collo di bottiglia per le prestazioni:

· Gli attuali zkEVM si basano su interpreti, causando un rallentamento delle prestazioni da 50 a 800 volte;

· I moduli precompilati rendono il protocollo più complesso e aumentano i rischi;

· Il design dello stack a 256 bit è estremamente inefficiente nella generazione delle prove.

Soluzioni di RISC-V:

· Design minimalista (circa 47 istruzioni di base) + ecosistema LLVM maturo (supporto per Rust, C++, Go e altri linguaggi);

· È diventato lo standard de facto per zkVM (adottato dal 90% dei progetti);

· Dispone di una specifica SAIL formale (rispetto al vago Yellow Paper) → consente una verifica rigorosa;

· Percorso di prova hardware (ASICs/FPGAs) già in fase di test (SP1, Nervos, Cartesi, ecc.).

Il processo di migrazione si divide in tre fasi:

· Sostituzione dei moduli precompilati con RISC-V (test a basso rischio);

· Era della doppia VM: EVM e RISC-V coesistono e sono completamente interoperabili;

· Reimplementazione di EVM all'interno di RISC-V (strategia Rosetta).

Impatto sull'ecosistema:

· Gli Optimistic Rollup (come Arbitrum e Optimism) dovranno ricostruire il meccanismo di prova delle frodi;

· Gli ZK Rollup (come Polygon, zkSync, Scroll) otterranno enormi vantaggi → più economici, più veloci, più semplici;

· Gli sviluppatori potranno utilizzare direttamente librerie di linguaggi come Rust, Go e Python su L1;

· Gli utenti beneficeranno di costi di prova circa 100 volte inferiori → verso un Gigagas L1 (circa 10.000 TPS).

Alla fine, Ethereum evolverà da una "macchina virtuale per smart contract" a uno strato di fiducia minimalista e verificabile per Internet, con l'obiettivo finale di "ZK-Snarkizzare tutto".

Il bivio di Ethereum

Vitalik Buterin ha detto: "Il punto d'arrivo include... ZK-Snarkizzare tutto."

Il destino delle zero-knowledge proof (ZK) è ormai inevitabile, e il suo argomento centrale è semplice: Ethereum si sta ricostruendo da zero, basandosi sulle zero-knowledge proof. Questo segna il punto finale tecnico del protocollo: raggiungere la sua forma definitiva attraverso una ricostruzione di L1, guidata da un'alta prestazione zkVM supportata dai core team di sviluppo (come Succinct).

Con questa visione come obiettivo finale, Ethereum si trova al crocevia della più importante trasformazione architettonica dalla sua nascita. La discussione non riguarda più aggiornamenti incrementali, ma una ricostruzione completa del suo nucleo computazionale: la sostituzione della Ethereum Virtual Machine (EVM). Questa mossa è la pietra angolare della più ampia visione di "Lean Ethereum".

La visione di Lean Ethereum mira a semplificare sistematicamente l'intero protocollo, suddividendolo in tre moduli principali: Lean Consensus, Lean Data e Lean Execution. Al centro della Lean Execution, la questione chiave è: l'EVM, motore della rivoluzione degli smart contract, è diventato il principale collo di bottiglia per il futuro sviluppo di Ethereum?

Come afferma Justin Drake della Ethereum Foundation, l'obiettivo a lungo termine di Ethereum è sempre stato "Snarkify everything", uno strumento potente che può rafforzare tutti gli strati del protocollo. Tuttavia, per molto tempo questo obiettivo è sembrato un "blueprint irraggiungibile", poiché richiedeva il concetto di real-time proving. Ora che la prova in tempo reale sta diventando realtà, l'inefficienza teorica dell'EVM è diventata un problema pratico urgente da risolvere.

Questo articolo analizza in profondità gli argomenti tecnici e strategici per la migrazione di Ethereum L1 all'architettura di set di istruzioni RISC-V (ISA). Questa mossa promette non solo di sbloccare una scalabilità senza precedenti, ma anche di semplificare la struttura del protocollo e allineare Ethereum al futuro del calcolo verificabile.

Cosa è realmente cambiato?

Prima di discutere il "perché", bisogna chiarire "cosa" sta cambiando.

L'EVM (Ethereum Virtual Machine) è l'ambiente di esecuzione degli smart contract di Ethereum, definita come il "computer mondiale" che elabora le transazioni e aggiorna lo stato della blockchain. Per anni, il suo design è stato rivoluzionario, ponendo le basi per la nascita della DeFi e dell'ecosistema NFT. Tuttavia, questa architettura personalizzata di quasi dieci anni fa ha ora accumulato un enorme debito tecnico.

Al contrario, RISC-V non è un prodotto, ma uno standard aperto: un "alfabeto" di design del processore gratuito e generico. Come sottolineato da Jeremy Bruestle alla conferenza Ethproofs, i suoi principi chiave lo rendono una scelta eccellente per questo ruolo:

· Minimalismo: Il set di istruzioni di base di RISC-V è estremamente semplice, con solo circa 40-47 istruzioni. Come dice Jeremy, questo lo rende "quasi perfetto per il caso d'uso di una macchina universale super minimalista di cui abbiamo bisogno".

· Design modulare: Funzionalità più complesse vengono aggiunte tramite estensioni opzionali. Questa caratteristica è cruciale perché consente al nucleo di rimanere semplice, espandendo le funzionalità solo quando necessario, senza imporre complessità inutili al protocollo di base.

· Ecosistema aperto: RISC-V dispone di una vasta e matura toolchain di supporto, incluso il compilatore LLVM, che consente agli sviluppatori di utilizzare linguaggi di programmazione mainstream come Rust, C++ e Go. Come menzionato da Justin Drake: "Gli strumenti attorno ai compilatori sono molto ricchi, e costruire compilatori è estremamente difficile... quindi avere queste toolchain di compilatori è di valore inestimabile." RISC-V permette a Ethereum di ereditare gratuitamente questi strumenti pronti all'uso.

Il problema dell'overhead dell'interprete

La spinta a sostituire l'EVM non deriva da un singolo difetto, ma dalla convergenza di molteplici limiti fondamentali, che nel contesto di un futuro incentrato sulle zero-knowledge proof non possono più essere ignorati. Questi limiti includono i colli di bottiglia delle prestazioni nei sistemi di zero-knowledge proof e i rischi derivanti dalla crescente complessità interna del protocollo.

Il motore più urgente di questa trasformazione è l'inefficienza intrinseca dell'EVM nei sistemi di zero-knowledge proof. Con Ethereum che si sta gradualmente spostando verso un modello in cui lo stato di L1 è verificato tramite prove ZK, le prestazioni dei prover diventano il principale collo di bottiglia.

Il problema risiede nel modo in cui funzionano gli attuali zkEVM. Non provano direttamente l'EVM tramite zero-knowledge, ma provano l'interprete dell'EVM, che a sua volta è compilato in RISC-V. Vitalik Buterin ha sottolineato chiaramente questo problema centrale:

"...Se l'implementazione di zkVM consiste nel compilare l'esecuzione dell'EVM in codice che alla fine diventa RISC-V, perché non esporre direttamente RISC-V agli sviluppatori di smart contract? Così si elimina completamente l'overhead della VM esterna."

Questo strato interpretativo aggiuntivo comporta una perdita di prestazioni enorme. Le stime indicano che, rispetto alla prova di un programma nativo, questo strato può causare un rallentamento da 50 a 800 volte. Anche ottimizzando altri colli di bottiglia (come passando all'algoritmo di hash Poseidon), questa "esecuzione del blocco" rappresenta ancora l'80-90% del tempo di prova, rendendo l'EVM l'ostacolo finale e più difficile per scalare L1. Rimuovendo questo strato, Vitalik prevede un aumento dell'efficienza di esecuzione fino a 100 volte.

La trappola del debito tecnico

Per compensare le carenze di prestazioni dell'EVM in alcune operazioni crittografiche, Ethereum ha introdotto i contratti precompilati: funzioni specializzate codificate direttamente nel protocollo. Sebbene questa soluzione fosse pragmatica all'epoca, oggi ha portato a una situazione che Vitalik Buterin definisce "disastrosa":

"Le precompilate sono state disastrose per noi... hanno enormemente gonfiato la base di codice trusted di Ethereum... e hanno causato gravi problemi che hanno quasi portato a fallimenti di consenso."

Questa complessità è impressionante. Vitalik spiega che il codice wrapper di una singola precompilata (come modexp) è più complesso dell'intero interprete RISC-V, e la logica delle precompilate è ancora più intricata. Aggiungere nuove precompilate richiede un processo di hard fork lento e politicamente controverso, ostacolando gravemente l'innovazione delle applicazioni che necessitano di nuovi primitivi crittografici. Vitalik ne trae una conclusione chiara:

"Penso che dovremmo smettere di aggiungere nuove precompilate a partire da oggi."

Il debito tecnico architetturale di Ethereum

Il design centrale dell'EVM riflette le priorità di un'epoca passata, ma non è più adatto alle esigenze del calcolo moderno. L'EVM ha scelto un'architettura a 256 bit per gestire valori crittografici, ma per gli interi a 32 o 64 bit comunemente usati negli smart contract, questa architettura è estremamente inefficiente. Questa inefficienza è particolarmente costosa nei sistemi ZK. Come spiega Vitalik:

"Quando si usano numeri più piccoli, in realtà non si risparmia alcuna risorsa per numero, ma la complessità aumenta da due a quattro volte."

Inoltre, l'architettura dello stack dell'EVM è meno efficiente dell'architettura a registri di RISC-V e delle moderne CPU. Richiede più istruzioni per completare la stessa operazione e rende più complessa l'ottimizzazione del compilatore.

Questi problemi—collo di bottiglia delle prestazioni nelle prove ZK, complessità delle precompilate e scelte architetturali obsolete—costituiscono una ragione convincente e urgente: Ethereum deve andare oltre l'EVM e abbracciare un'architettura tecnologica più adatta al futuro.

Blueprint RISC-V: ricostruire il futuro di Ethereum su basi più solide

I vantaggi di RISC-V non risiedono solo nelle carenze dell'EVM, ma anche nella forza intrinseca della sua filosofia di design. La sua architettura offre una base robusta, semplice e verificabile, ideale per un ambiente ad alto rischio come Ethereum.

Perché uno standard aperto è meglio di un design personalizzato?

A differenza degli ISA personalizzati che richiedono la costruzione di un intero ecosistema software da zero, RISC-V è uno standard aperto e maturo con tre vantaggi chiave:

Ecosistema maturo

Adottando RISC-V, Ethereum può sfruttare decenni di progressi collettivi nel campo dell'informatica. Come spiega Justin Drake, questo offre a Ethereum l'opportunità di utilizzare direttamente strumenti di livello mondiale:

"C'è un componente infrastrutturale chiamato LLVM, una toolchain di compilatori che consente di compilare linguaggi di alto livello in uno dei vari backend. Uno dei backend supportati è RISC-V. Quindi, se supporti RISC-V, puoi automaticamente supportare tutti i linguaggi di alto livello supportati da LLVM."

Questo abbassa notevolmente la barriera d'ingresso, consentendo a milioni di sviluppatori che conoscono Rust, C++ e Go di iniziare facilmente.

Filosofia di design minimalista Il minimalismo di RISC-V è una caratteristica intenzionale, non una limitazione. Il suo set di istruzioni di base contiene solo circa 47 istruzioni, mantenendo il nucleo della VM estremamente semplice. Questa semplicità offre vantaggi significativi in termini di sicurezza, poiché una base di codice trusted più piccola è più facile da auditare e verificare formalmente.

Standard di fatto nel campo delle zero-knowledge proof Ancora più importante, l'ecosistema zkVM ha già fatto la sua scelta. Come sottolinea Justin Drake, dai dati di Ethproofs emerge una tendenza chiara:

"RISC-V è l'ISA leader come backend per zkVM."

Dei dieci zkVM in grado di provare i blocchi di Ethereum, nove hanno scelto RISC-V come architettura target. Questa convergenza di mercato invia un segnale forte: adottando RISC-V, Ethereum non sta facendo una scommessa speculativa, ma si sta allineando a uno standard già validato e riconosciuto dai progetti che stanno costruendo il futuro zero-knowledge.

Nato per la fiducia, non solo per l'esecuzione

Oltre all'ampio ecosistema, l'architettura interna di RISC-V è particolarmente adatta per costruire sistemi sicuri e verificabili. Innanzitutto, RISC-V dispone di una specifica formale e leggibile dalla macchina—SAIL. Rispetto alla specifica dell'EVM (principalmente testuale nel Yellow Paper), questo è un enorme passo avanti. Il Yellow Paper presenta alcune ambiguità, mentre la specifica SAIL offre uno "standard aureo" che supporta prove di correttezza matematica, essenziali per proteggere protocolli di grande valore. Come menzionato da Alex Hicks della Ethereum Foundation (EF) alla conferenza Ethproofs, questo consente ai circuiti zkVM di essere verificati direttamente "contro la specifica ufficiale di RISC-V". In secondo luogo, RISC-V include un'architettura privilegiata, una caratteristica spesso trascurata ma cruciale per la sicurezza. Definisce diversi livelli operativi, principalmente la modalità utente (per applicazioni non trusted come gli smart contract) e la modalità supervisor (per il "kernel di esecuzione" trusted). Diego di Cartesi lo spiega in dettaglio:

"Il sistema operativo stesso deve proteggersi dal codice esterno. Deve isolare i vari programmi tra loro, e tutti questi meccanismi fanno parte dello standard RISC-V."

Nell'architettura RISC-V, gli smart contract che girano in User Mode non possono accedere direttamente allo stato della blockchain. Devono invece inviare una richiesta tramite una speciale istruzione ECALL al kernel trusted che gira in Supervisor Mode. Questo meccanismo costruisce un confine di sicurezza imposto dall'hardware, molto più robusto e facilmente verificabile rispetto al modello EVM che si basa solo su sandbox software.

La visione di Vitalik

Questa trasformazione è concepita come un processo graduale e a più fasi, per garantire stabilità e retrocompatibilità del sistema. Come spiegato dal fondatore di Ethereum, Vitalik Buterin, questo approccio mira a un'evoluzione "evolutiva" piuttosto che a una rivoluzione totale.

Primo passo: sostituzione delle precompilate

La fase iniziale adotta l'approccio più conservativo, introducendo funzionalità limitate della nuova VM. Come suggerisce Vitalik Buterin: "Possiamo iniziare ad usare la nuova VM in scenari limitati, come sostituire le funzioni precompilate." In pratica, questo sospenderà l'aggiunta di nuove precompilate EVM, sostituendole con programmi RISC-V approvati tramite whitelist. Questo metodo consente di testare la nuova VM in mainnet in un ambiente a basso rischio, con i client Ethereum che fungono da intermediari tra i due ambienti di esecuzione.

Secondo passo: coesistenza delle doppie VM

La fase successiva "aprirà la nuova VM direttamente agli utenti". Gli smart contract potranno indicare tramite un flag se il loro bytecode è EVM o RISC-V. La caratteristica chiave sarà l'interoperabilità senza soluzione di continuità: "I due tipi di contratti potranno chiamarsi a vicenda." Questa funzione sarà implementata tramite chiamate di sistema (ECALL), consentendo alle due VM di collaborare nello stesso ecosistema.

Terzo passo: EVM come contratto simulato (strategia "Rosetta")

L'obiettivo finale è la massima semplificazione del protocollo. In questa fase, "implementeremo l'EVM come una delle implementazioni della nuova VM." L'EVM normalizzato diventerà uno smart contract formalmente verificato che gira nativamente su RISC-V L1. Questo garantirà il supporto permanente per le vecchie applicazioni, consentendo ai client di mantenere un solo motore di esecuzione semplificato, riducendo drasticamente la complessità e i costi di manutenzione.

L'effetto domino sull'ecosistema

La transizione da EVM a RISC-V non è solo una trasformazione del protocollo core, ma avrà un impatto profondo su tutto l'ecosistema Ethereum. Questa trasformazione rimodellerà l'esperienza degli sviluppatori, cambierà radicalmente la competizione tra soluzioni Layer-2 e sbloccherà nuovi modelli di validazione economica.

Il riposizionamento dei Rollup: la sfida tra Optimistic e ZK

L'adozione di RISC-V come livello di esecuzione su L1 avrà effetti molto diversi sui due principali tipi di Rollup.

Gli Optimistic Rollup (come Arbitrum, Optimism) affrontano sfide architetturali. Il loro modello di sicurezza si basa sulla riesecuzione delle transazioni contestate su L1 EVM per risolvere le prove di frode. Se l'EVM di L1 viene sostituito, questo modello crolla. Questi progetti dovranno scegliere tra una massiccia revisione ingegneristica per progettare un sistema di prove di frode per la nuova VM L1, oppure abbandonare completamente il modello di sicurezza di Ethereum.

Al contrario, gli ZK Rollup otterranno un enorme vantaggio strategico. La stragrande maggioranza degli ZK Rollup ha già adottato RISC-V come architettura ISA interna. Un L1 che "parla la stessa lingua" consentirà un'integrazione più stretta ed efficiente. Justin Drake ha presentato la visione futura dei "Rollup nativi": L2 diventa di fatto un'istanza specializzata dell'ambiente di esecuzione di L1, utilizzando la VM integrata di L1 per una settlement senza soluzione di continuità. Questo allineamento porterà ai seguenti cambiamenti:

· Semplificazione dello stack tecnologico: I team L2 non dovranno più costruire complessi bridge tra l'ambiente di esecuzione RISC-V interno e l'EVM.

· Riutilizzo di strumenti e codice: I compilatori, i debugger e gli strumenti di verifica formale sviluppati per l'ambiente RISC-V L1 potranno essere utilizzati direttamente su L2, riducendo drasticamente i costi di sviluppo.

· Allineamento degli incentivi economici: Le commissioni Gas di L1 rifletteranno più accuratamente i costi reali della verifica ZK basata su RISC-V, creando un modello economico più razionale.

Una nuova era per sviluppatori e utenti

Per gli sviluppatori Ethereum, questa trasformazione sarà graduale, non distruttiva.

Per gli sviluppatori, potranno accedere a un ecosistema di sviluppo software più ampio e maturo. Come sottolinea Vitalik Buterin, gli sviluppatori "potranno scrivere contratti in Rust, e queste opzioni potranno coesistere". Allo stesso tempo, prevede che "Solidity e Vyper rimarranno popolari a lungo per la loro eleganza nella logica degli smart contract". Usare linguaggi mainstream e le loro vaste librerie tramite la toolchain LLVM sarà rivoluzionario. Vitalik lo paragona a un'esperienza "in stile NodeJS", in cui gli sviluppatori possono scrivere codice on-chain e off-chain nello stesso linguaggio, unificando lo sviluppo.

Per gli utenti, questa trasformazione porterà infine a costi più bassi e prestazioni di rete più elevate. Si prevede che il costo delle prove scenderà di circa 100 volte, da alcuni dollari per transazione a pochi centesimi o meno. Questo si traduce direttamente in commissioni L1 e costi di settlement L2 più bassi. Questa sostenibilità economica sbloccherà la visione di "Gigagas L1", con l'obiettivo di circa 10.000 TPS, aprendo la strada a applicazioni on-chain più complesse e di valore.

Succinct Labs e SP1: costruire il futuro delle prove oggi

Ethereum è pronto al decollo. "Scalare L1, scalare i blocchi" è una missione strategica urgente all'interno del cluster di protocolli EF. Si prevede che nei prossimi 6-12 mesi si otterranno miglioramenti significativi delle prestazioni.

Team come Succinct Labs hanno già dimostrato nella pratica i vantaggi teorici di RISC-V, fornendo un caso concreto a sostegno di questa proposta.

SP1, sviluppato da Succinct Labs, è uno zkVM open source ad alte prestazioni basato su RISC-V, che dimostra la fattibilità del nuovo approccio architetturale. SP1 adotta una filosofia "precompile-centric", risolvendo perfettamente i colli di bottiglia crittografici dell'EVM. A differenza delle precompilate lente e hardcoded, SP1 scarica operazioni intensive come l'hash Keccak su circuiti ZK appositamente progettati e ottimizzati manualmente, richiamandoli tramite l'istruzione standard ECALL. Questo metodo combina le prestazioni dell'hardware personalizzato con la flessibilità del software, offrendo agli sviluppatori una soluzione più efficiente e scalabile.

L'impatto pratico di Succinct Labs è già evidente. Il loro prodotto OP Succinct utilizza SP1 per dotare gli Optimistic Rollup di capacità zero-knowledge proof (ZK-ify). Come spiega Uma Roy, cofondatrice di Succinct:

"Con i Rollup basati su OP Stack, non è più necessario attendere sette giorni per la conferma finale e il prelievo... ora la conferma richiede solo un'ora. Questo aumento di velocità è fantastico."

Questa svolta risolve un punto critico per l'intero ecosistema OP Stack. Inoltre, l'infrastruttura di Succinct—Succinct Prover Network—è progettata come un mercato decentralizzato per la generazione delle prove, mostrando un modello economico praticabile per il calcolo verificabile del futuro. Il loro lavoro non è solo una proof of concept, ma una roadmap concreta per il futuro, come descritto in questo articolo.

Come Ethereum riduce i rischi

Uno dei grandi vantaggi di RISC-V è che rende realizzabile il "Santo Graal" della verifica formale: dimostrare matematicamente la correttezza del sistema. La specifica dell'EVM, scritta in linguaggio naturale nel Yellow Paper, è difficile da formalizzare. RISC-V, invece, dispone di una specifica SAIL ufficiale e leggibile dalla macchina, che fornisce un "golden reference" chiaro per il suo comportamento.

Questo apre la strada a una maggiore sicurezza. Come sottolinea Alex Hicks della Ethereum Foundation, è già in corso il lavoro per "formalizzare in Lean i circuiti zkVM RISC-V confrontandoli con la specifica ufficiale RISC-V". Questo è un traguardo fondamentale, che sposta la fiducia dalle implementazioni umane soggette a errori alle prove matematiche verificabili, portando la sicurezza della blockchain a nuovi livelli.

I principali rischi della trasformazione

Sebbene un L1 basato su RISC-V offra molti vantaggi, introduce anche nuove sfide complesse.

Problema del calcolo del Gas

Creare un modello di Gas deterministico ed equo per un'architettura ISA generica è una sfida ancora irrisolta. Il semplice conteggio delle istruzioni è vulnerabile agli attacchi di denial-of-service. Ad esempio, un attaccante potrebbe progettare un programma che attiva ripetutamente cache miss, consumando molte risorse a basso costo di Gas. Questo problema rappresenta una seria minaccia per la stabilità della rete e il modello economico.

Sicurezza della toolchain e problema della "build riproducibile"

Questo è il rischio più importante e spesso sottovalutato nel processo di trasformazione. Il modello di sicurezza si sposta dalla VM on-chain al compilatore off-chain (come LLVM), che è estremamente complesso e noto per avere vulnerabilità. Un attaccante potrebbe sfruttare bug del compilatore per trasformare codice sorgente apparentemente innocuo in bytecode malevolo. Inoltre, garantire che il binario compilato on-chain corrisponda esattamente al codice sorgente pubblico—il problema della "build riproducibile"—è molto difficile. Piccole differenze nell'ambiente di build possono generare binari diversi, minando trasparenza e fiducia. Questi problemi rappresentano una seria sfida per la sicurezza di sviluppatori e utenti.

Strategie di mitigazione

La strada da seguire richiede strategie di difesa multilivello.

Implementazione graduale

Adottare un piano di transizione graduale e a più fasi è la strategia chiave per gestire i rischi. Introdurre prima RISC-V come sostituto delle precompilate, poi farlo coesistere in un ambiente a doppia VM, consente alla community di acquisire esperienza operativa e fiducia in un ambiente a basso rischio, evitando cambiamenti irreversibili. Questo approccio graduale fornisce una base stabile per la trasformazione tecnologica.

Audit completi: fuzz testing e verifica formale

Sebbene la verifica formale sia l'obiettivo finale, deve essere integrata con test continui e intensivi. Come dimostrato da Valentine di Diligence Security nella call Ethproofs, il loro strumento di fuzz testing Argus ha già scoperto 11 vulnerabilità critiche di solidità e integrità nei principali zkVM. Questo dimostra che anche i sistemi meglio progettati possono avere bug che solo test avversariali rigorosi possono scoprire. La combinazione di fuzz testing e verifica formale offre una maggiore sicurezza del sistema.

Standardizzazione

Per evitare la frammentazione dell'ecosistema, la community deve adottare una configurazione RISC-V unica e standardizzata. Questa potrebbe essere la combinazione RV64GC con ABI compatibile Linux, poiché è la più supportata dai linguaggi e strumenti mainstream, massimizzando i vantaggi del nuovo ecosistema. La standardizzazione non solo migliora l'efficienza degli sviluppatori, ma getta anche solide basi per lo sviluppo a lungo termine dell'ecosistema.

Il futuro verificabile di Ethereum

La proposta di sostituire la Ethereum Virtual Machine (EVM) con RISC-V non è solo un aggiornamento incrementale, ma una ricostruzione fondamentale del livello di esecuzione di Ethereum. Questa ambiziosa visione mira a risolvere i colli di bottiglia della scalabilità, semplificare la complessità del protocollo e allineare la piattaforma all'ecosistema più ampio del calcolo generico. Nonostante le grandi sfide tecniche e sociali, i benefici strategici a lungo termine giustificano questo sforzo audace.

Questa trasformazione si concentra su una serie di trade-off chiave:

· L'equilibrio tra il grande aumento delle prestazioni dell'architettura ZK-native e l'urgente necessità di retrocompatibilità;

· Il compromesso tra i vantaggi di sicurezza della semplificazione del protocollo e l'inerzia dell'enorme effetto network di EVM;

· La scelta tra la potenza di un ecosistema generico e i rischi derivanti dalla dipendenza da toolchain di terze parti complesse.

Alla fine, questa trasformazione architetturale sarà fondamentale per mantenere la promessa della "Lean Execution" e rappresenta una parte importante della visione "Lean Ethereum". Trasformerà L1 di Ethereum da una semplice piattaforma per smart contract a uno strato di settlement e disponibilità dati efficiente e sicuro, progettato per supportare l'universo del calcolo verificabile.

Come dice Vitalik Buterin, "Il punto d'arrivo è... fornire ZK-snark per tutto."

Progetti come Ethproofs forniscono dati oggettivi e piattaforme collaborative per questa trasformazione, mentre il team di Succinct Labs, con l'applicazione pratica del loro SP1 zkVM, offre una roadmap operativa per questo futuro. Abbracciando RISC-V, Ethereum non solo risolve i propri colli di bottiglia di scalabilità, ma si posiziona come lo strato di fiducia fondamentale per la prossima generazione di Internet—guidato dalla terza grande primitiva crittografica dopo hash e firme: SNARK.

Dimostrare il software del mondo, inaugurando una nuova era della crittografia.

Per saperne di più: