EVM 2.0: dentro la corsa per sostituire il cuore di Ethereum

Il cuore di Ethereum è un computer virtuale.

Archiviata su decine di migliaia di nodi che compongono la piattaforma, la macchina virtuale Ethereum , o EVM, è responsabile dell'esecuzione degli innumerevoli token, dapp, DAO e gattini digitali di cui è composta la blockchain.

Si tratta di un motore su cui opera l'intero Ethereum e che parla in un linguaggio chiamato "EVM bytecode": stringhe di informazioni grezze da 256 BIT in grado di fornire qualsiasi equazione concepibile (purché rientri nel limite autoimposto dalla piattaforma, GAS).

Sembra potente e importante, eh? Qualcosa con cui non si deve scherzare troppo?

Tuttavia, quella parte integrante dell'infrastruttura di Ethereum si sta preparando per una riscrittura completa.

"Direi che T c'è stata un'enorme quantità di design thinking all'inizio", ha detto Lane Rettig, uno sviluppatore Ethereum , a CoinDesk riguardo all'EVM. "Era una specie di strumento, un coltellino svizzero è il modo in cui lo descriverei, fa un sacco di cose ma non incredibilmente bene".

Pertanto, l'attuale EVM verrà sostituito da una nuova macchina virtuale denominata eWASM.

EWASM è semplicemente la versione Ethereum del codice WASM (acronimo di WebAssembly), creato dal World Wide Web Consortium (W3C), il team di sviluppatori responsabile della manutenzione e della standardizzazione del Web.

"Ci sono molti ingegneri altamente pagati e molto esperti, e molte migliaia di ore di lavoro di ingegneri professionisti che sono state investite nella concezione del set di costruzione [WASM], rispetto a EVM", ha affermato Rettig, che contribuisce allo sviluppo di eWASM.

In effetti, eWASM consentirà agli sviluppatori di codificare in più linguaggi di programmazione, non solo nel linguaggio specifico di Ethereum, Solidity, e si dice che porterà anche una serie di miglioramenti delle prestazioni.

A ulteriore conferma di questa decisione, Ethereum si unirà a diversi concorrenti, tra cui EOS, TRON e Cardano, che hanno ciascuno implementato (o pianificano di implementare) macchine virtuali specifiche per progetto per gestire l'elaborazione decentralizzata utilizzando il codice WASM.

Per Ethereum, lo switch è impostato per essere eseguito insieme a un paio di altri aggiornamenti ora soprannominati "Shasper", che includono lo sharding della soluzione di scaling e la riscrittura del mining Casper, nei prossimi anni. E mentre una tempistica esatta per lo switch T è stata ancora fissata, lo sviluppo di eWASM sta facendo rapidi progressi e si sta preparando al lancio della sua testnet al Devcon 4, la conferenza per sviluppatori Ethereum , a Praga in ottobre.

Parlando della decisione di sostituire la macchina esistente, Rettig ha riassunto:

"Ethereum è arrivato al punto in cui sta passando dall'essere un goffo progetto personalizzato fatto in casa che abbiamo guidato in giro per la nostra FARM a una vera e propria auto da corsa che possiamo portare in autostrada e scatenare."

Un modo "verrucoso"

Alla base di questo cambiamento c'è la consapevolezza che, sebbene l'EVM sia una Tecnologie innovativa (che per la prima volta fornisce una soluzione al calcolo decentralizzato resistente agli attacchi), non è pulita come potrebbe essere.

Un esempio concreto è la maggior parte degli sviluppatori di dapps che programmano in Solidity di Ethereum, un linguaggio di programmazione di alto livello che compila automaticamente in un formato compatibile con il bytecode EVM.

Poiché l'EVM si basa su "istruzioni molto grandi e ampie", ha affermato Rettig, anche i tipi di calcoli più piccoli, come l'aritmetica di base, dovrebbero essere convertiti in stringhe da 256 BIT (un processo complesso per la matematica semplice) affinché l'EVM possa elaborarli.

Questa è solo ONE delle numerose operazioni integrate nel codice di sistema che Rettig sostiene T dovrebbero esserci. Un'altra include la popolare funzione hash SHA-3.

Per questo motivo, Rettig descrive l'EVM come "verrucoso".

E Nick Johnson, uno sviluppatore Ethereum CORE , è d'accordo, dicendo a CoinDesk che quando si è unito a Ethereum, gli è stato subito chiaro che l'EVM era stato creato da sviluppatori con una profonda conoscenza dell'informatica, ma senza molta esperienza nella creazione di prodotti ampiamente utilizzabili.

Come ha sottolineato Johnson, l'EVM è stato "ottimizzato per la purezza teorica, piuttosto che per l'uso pratico".

"Ha questi registri enormi, ma sono tutti uguali, ed è molto coerente internamente e così via", ha affermato, "ma non è stato progettato pensando all'implementazione nel mondo reale".

"Più vicino al metallo"

Il codice WASM, d'altro canto, è stato sviluppato pensando alla produzione.

ONE, ha affermato Rettig, è costruito "più vicino al metallo", il che significa che il codice che esegue è simile alle istruzioni hardware effettive, quindi richiede meno sforzi per tradurre diverse logiche di codifica.

"Le istruzioni imitano molto da vicino le istruzioni hardware reali", ha continuato Rettig. "Queste istruzioni possono mappare direttamente uno a uno le istruzioni eseguite dai dispositivi effettivi, quindi puoi, in teoria, ottenere miglioramenti delle prestazioni piuttosto entusiasmanti".

Ad esempio, gli sviluppatori che lavorano su Ethereum potranno programmare utilizzando più linguaggi, quelli con cui si sentono più a loro agio, compresi quelli che offrono ulteriori vantaggi in termini di sicurezza.

Un altro vantaggio fondamentale, che secondo Rettig alcuni sviluppatori indicano come "la motivazione principale alla base di eWASM", è che potenzialmente elimina quella che viene chiamata "precompilazione".

Poiché l'EVM è composto da codice poco maneggevole, alcune operazioni devono essere costruite all'interno del sistema, altrimenti supererebbero i costi GAS ad esse associati. Chiamate precompilazioni, per rendere tali operazioni disponibili su una rete, è richiesto un aggiornamento a livello di sistema, o hard fork; e tali aggiornamenti si sono dimostrati rischiosi e complicati da orchestrare.

Con eWASM, invece, gli sviluppatori sostengono che le operazioni possono essere semplicemente scritte come contratti intelligenti e distribuite, saltando lo scenario dell'hard fork.

"Con eWASM, l'elaborazione è sufficientemente efficiente da consentire di eliminare la maggior parte di quelle precompilazioni e sostituirle semplicemente con contratti eWASM", ha affermato Johnson.

Cuore spezzato

Tuttavia, come ogni cambiamento sostanziale in un ecosistema decentralizzato, la spinta ad abbandonare l'EVM non è esente da critiche.

ONE , Greg Colvin, sviluppatore CORE Ethereum , che si è dedicato alla manutenzione dell'EVM per anni, è riluttante ad abbandonare il vecchio codice.

Colvin stava progettando una nuova versione migliorata del codice EVM, denominata EVM 1.5, che in origine avrebbe dovuto essere il futuro della macchina virtuale Ethereum . Tuttavia, senza preavviso, i suoi finanziamenti sono stati tagliati dalla fondazione non-profit Ethereum Foundation.

"Ero incazzato", ha detto Colvin, che ha contribuito a formare ilConsiglio dei maghi Ethereum, un gruppo di discussione dedicato a promuovere la competenza tecnica di Ethereum, dopo l'esperienza, ha detto a CoinDesk. "Ho pensato aspetta un attimo, T mi pagherai 8,40 $ l'ora quando hai già ridotto le mie ore da 35 a 20, quindi perché lo sto facendo. E poi per il resto dell'anno non ho più potuto permettermi di fare volontariato."

Tuttavia, il motivo per cui Colvin si oppone all'aWASM T è solo l'orgoglio.

Secondo lui, ci sono anche problemi tecnici con eWASM. Ad esempio, poiché eWASM consente il supporto di più linguaggi, il codice si basa pesantemente su ciò che è noto come "compilatori", qualcosa che Colvin sostiene potrebbe essere un singolo punto di errore per gli aggressori.

Non è inoltre convinto che gli smart contract eWASM possano sostituire la necessità di precompilare.

Inoltre, Colvin ha ulteriori critiche orientate al design con cui anche Rettig è d'accordo. Secondo entrambi gli sviluppatori, per qualche motivo la tecnologia più inefficiente di solito vince. Prendiamo ad esempio Javascript, che è ONE dei linguaggi di programmazione più utilizzati, ma è noto per essere particolarmente brutto.

"Sembra esserci uno schema nella Tecnologie e nell'informatica per cui le cose meglio progettate non solo non WIN necessariamente, ma sembrano anche non funzionare molto bene", ha sostenuto Rettig.

Per non parlare del fatto che, secondo Colvin, nonostante tutto il lavoro di sviluppo dietro WASM, il codice è ancora relativamente poco testato sul campo.

Colvin ha detto a CoinDesk:

"T capivo perché volessimo essere i primi ad adottare un esperimento, quando eravamo già i primi ad adottare il nostro esperimento."

Imprevedibilità

A parte i conflitti, eWASM sta guadagnando terreno tra molti sviluppatori Ethereum .

In effetti, il piano è di implementarlo come testnet prima della conferenza per gli sviluppatori Ethereum , Devcon4, a novembre.

Ciò T significa, tuttavia, che la nuova macchina virtuale verrà implementata a breve.

Poiché eWASM verrà prima portato su uno shard, o sidechain, prima di sostituire l'EVM stesso, il lancio di eWASM è strettamente legato all'aggiornamento Shasper. E in termini di tempistica, ciò significa che gli sviluppatori dovranno occuparsi della ricerca che sostiene tali cambiamenti, prima di passare a eWASM.

Purtroppo, i progressi di questo tipo di ricerca possono essere imprevedibili.

In effetti, l'ambiguità implicita negli aggiornamenti del codice di questo tipo è stata fonte di confusione per un ampio gruppo di sviluppatori Ethereum che hanno lavorato sulla piattaforma.

"Se sei nel processo di creazione di un nuovo client, c'è molta confusione: dovrei creare eWASM? Dovrei creare EVM? Dovrei creare entrambi? Dovrei creare qualcos'altro", ha detto Rettig a CoinDesk.

La mancanza di chiarezza è stata ONE delle principali frustrazioni per Colvin, perché per quanto riguarda l'attuale EVM, ci sono alcuni problemi di prestazioni che sarebbe facile migliorare, ma che sono stati messi da parte a causa del brusco cambiamento nella roadmap.

"È stata una mia frustrazione per un po', eWASM era chiaramente oltre l'orizzonte, ma senza troppe risorse EVM 1.5 era NEAR . E ora, è ancora fattibile, ma è stato posticipato, un anno intero è stato sprecato", ha detto Colvin a CoinDesk.

Più siamo, meglio è?

Tuttavia, sia Rettig che Colvin ammettono che questa incertezza è solo una parte del contributo a un progetto open source senza una leadership centrale.

"L'aspetto comunitario è così importante. Se questa fosse un'azienda, me ne sarei andato da un pezzo", ha detto Colvin a CoinDesk.

Inoltre, Rettig si è QUICK a sostenere che quando si tratta di miglioramenti Ethereum , non c'è lavoro sprecato.

In effetti, ha continuato, grazie alla natura dell'aggiornamento tramite sharding, che suddivide Ethereum in blocchi più piccoli e gestibili, alla fine Ethereum potrebbe supportare più macchine virtuali.

Parlando di un Ethereum aggiornato, Rettig ha affermato: "Non esiste un singolo Ethereum, non esiste un'unica roadmap, non esiste un'unica autorità, è una comunità, è una famiglia di tecnologie e non credo che il futuro sia solo ONE catena che le governa tutte".

In linea con ciò, eWASM sbloccherà anche nuovi livelli di interoperabilità. Per ONE, è costruito in un linguaggio che è stato standardizzato per il World Wide Web, quindi aggiungere il supporto nel browser per un client Ethereum light sarebbe banale.

E potrebbe anche aprire la strada a un'interoperabilità inedita tra diverse blockchain.

"Forse hai lo sharding quadratico qui, e Plasma qui, e forse si sovrappongono in alcuni punti, e forse abbiamo una catena Dfinity che comunica con una catena Ethereum che comunica con Bitcoin tramite Cosmos e Polkadot", ha detto Rettig, suggerendo:

"T lo sappiamo, quindi T fatevi prendere troppo dalla roadmap canonica ufficiale, qualunque essa sia."

Cuore di cartaimmagine tramite Shutterstock