Da Istanbul a Berlino: pietre miliari di Ethereum sulla strada per la serenità

All’inizio di questo mese, il capo del team della Fondazione Ethereum Péter Szilágyi ha confermato la data del prossimo aggiornamento della rete, Istanbul. L’ottavo hard fork di Ethereum in assoluto e il secondo quest’anno avrebbe dovuto svolgersi il 4 dicembre. Tuttavia, il 20 novembre, secondo il funzionario annuncio, la data stimata è stata spostata intorno al 7 dicembre.

Istanbul introdurrà una serie di miglioramenti come l’interoperabilità con Zcash, soluzioni più economiche di scalabilità del livello zero-knowledge due e aggiustamento del prezzo del gas per determinate operazioni, segnando un’altra pietra miliare lungo la strada per Ethereum 2.0, una versione “definitiva” della rete molto attesa. . Come si inserisce esattamente Istanbul nel grande schema delle cose?

Forks, release e fasi

Nessun sistema open source complesso è mai allo stato finale: il software è sempre in movimento, viene costantemente migliorato e aggiornato. Ciò è particolarmente vero per Ethereum, il cui percorso per diventare un “computer mondiale” distribuito e la piattaforma per applicazioni decentralizzate è stato delineato fin dall’inizio come una serie di pietre miliari consecutive.

L’obiettivo attuale che la comunità di sviluppatori di Ethereum sta perseguendo è una versione avanzata della rete chiamata Ethereum 2.0, Eth2 o Serenity. Si prevede che l’aggiornamento vedrà una serie di sviluppi drastici, come la transizione dalla prova di lavoro a una più efficiente dal punto di vista energetico proof-of-stake algoritmo di consenso, realizzazione di un nuovo paradigma di scalabilità chiamato sharding, e l’introduzione di un più efficiente Macchina virtuale Ethereum in grado di eseguire contratti intelligenti ad alte prestazioni. Il ricercatore Danny Ryan ha formulato cinque obiettivi di progettazione generali per Ethereum 2.0: decentralizzazione, resilienza, sicurezza, semplicità e longevità.

Le differenze nel linguaggio utilizzato per descrivere le fasi degli aggiornamenti di rete possono creare confusione: ci sono hard fork che prendono il nome dalle grandi città del mondo, fasi numerate, versioni denotate da codici di versione ed etichette poetiche come “serenità”. Tuttavia, alla fine si riduce a una struttura piuttosto semplice.

Il più grande incremento del processo di sviluppo è chiamato rilascio. Una singola versione può essere emanata per mezzo di uno o più hard fork – rifacimenti del protocollo blockchain che segnano un completo allontanamento dalla sua vecchia versione.

Ad oggi sono stati tre rilasci – l’attuale Metropolis – che è stato srotolato in due fasi: Bisanzio e Costantinopoli hard fork, con Istanbul ancora da fare. Successive forcelle dure, Berlino (indicativamente previsto per giugno 2023) e Londra, segnerà l’avvento della quarta release, Ethereum 2.0, o Serenity.

Gli hard fork apportano modifiche alla mainnet Ethereum attualmente operativa. Il roadmap a Ethereum 2.0, invece, prevede la creazione di nuove catene separate – come l’eventuale esistenza di due catene di Ethereum attive con differenti meccanismi di consenso. Il lancio della catena Ethereum 2.0 avverrà in una sequenza di fasi specificate nella roadmap.

Istanbul: miglioramenti accettati

Il principale veicolo di governance su cui la comunità di Ethereum fa affidamento per far avanzare la rete è Proposte di miglioramento di Ethereum. Specificano i suggerimenti relativi alle modifiche al protocollo principale, alle API client (interfacce di programmazione dell’applicazione) e agli standard dei contratti intelligenti.

Gli autori normalmente cercano di temporizzare le proposte per il programma di fork e mirare a specifici hard fork annunciati in anticipo. Attualmente c’è una spinta nella comunità per passare a un “EIP-centric” approccio nell’aggiornamento del sistema, in cui forcelle più frequenti e più piccole potrebbero consentire alle proposte di svilupparsi al proprio ritmo. Berlino, l’hard fork previsto per seguire Istanbul, lo è previsto essere il primo in questo paradigma.

Istanbul ancora segue l’approccio “fork-centric”, in cui molte proposte in varie fasi del loro ciclo di vita sono state presentate e riviste durante le chiamate All Core Devs. Gli sviluppatori hanno classificato gli EIP come desiderati e pronti per essere inseriti nel fork (accettati), desiderati ma non ancora pronti (accettati provvisoriamente, si presume che vadano in diretta con l’hard fork successivo) o non desiderati (rifiutati in modo permanente). Su 38 PEI presentati, solo sei sono stati accettati per l’inclusione, con altri otto approvati per il bivio di Berlino. Ecco uno schema delle proposte accettate:

EIP-152 offre la possibilità di verificare l’algoritmo di prova di lavoro di Equihash all’interno di un contratto Ethereum, consentendo l’interoperabilità tra le blockchain Zcash ed Ethereum.

EIP-1108 riduce i costi del gas precompilati, rendendo più economica una generazione di zero-knowledge proof non interattivi o zk-SNARK. Questa è una buona notizia per due motivi. Uno è che il cambiamento migliorerà lo sviluppo di applicazioni incentrate sulla privacy che utilizzano questo tipo di crittografia.

Di conseguenza, l’utilizzo di zk-SNARK è una soluzione di secondo livello che può essere strumentale per alleviare alcuni dei problemi di scalabilità di Ethereum spostando una quantità significativa di lavoro computazionale fuori catena.

EIP-1344 aggiunge un codice operativo che restituisce l’identificatore univoco della catena corrente, introducendo un modo per i contratti di tracciare la catena Ethereum in cui si trovano. Ciò migliorerà la resilienza del sistema a riprodurre gli attacchi sulle transazioni firmate.

EIP-1884 è forse la più dibattuta delle proposte accettate, provocando polemiche almeno dall’agosto di quest’anno. Introdotta da Martin Holst Swende, responsabile della sicurezza presso la Fondazione Ethereum, questa proposta è rivolta a repricing alcuni codici operativi (istruzioni fornite alla macchina virtuale Ethereum che esegue contratti intelligenti) al fine di “ottenere un buon equilibrio tra la spesa di gas e il consumo di risorse”.

Il problema che EIP-1884 dovrebbe risolvere deriva da alcune operazioni che diventano più dispendiose in termini di risorse con l’espansione della blockchain di Ethereum. Al momento, i blocchi con consumi di gas simili richiedono tempi molto diversi per essere completati, il che non è solo un problema in sé, ma può anche essere un vettore di un attacco di negazione del servizio.

L’attrito è emerso durante il 69 Core Dev call il 23 agosto, dove si è espresso Wei Tang di Parity Technologies preoccupazioni sulla possibilità che la modifica dei costi del codice operativo rompa alcuni contratti già implementati. Ha sostenuto che la compatibilità con le versioni precedenti dovrebbe essere preservata, consentendo ai vecchi contratti di funzionare secondo i prezzi originali.

Hudson Jameson, collegamento con la comunità della Fondazione Ethereum, ha risposto che esiste un “set di precedenti che i prezzi di OPCODE possono cambiare e cambieranno, quindi i tuoi contratti non dovrebbero fare affidamento sul presupposto che non cambieranno”, aggiungendo che la transizione lascerebbe le persone più preparate per i cambiamenti più drastici che sono imminenti.

EIP-1884 interesserà un numero limitato di contratti su una varietà di progetti. Hubert Ritzdorf della società di sicurezza blockchain ChainSecurity ha messo insieme forse di più elenco completo di tali contratti che rischiano di essere interessati.

EIP-2028 riduce il costo di chiamata dei dati nelle transazioni, portando potenzialmente a blocchi più grandi e quindi una migliore scalabilità della rete. Ciò renderà anche le soluzioni di scalabilità di livello due (come zk-SNARK) più accessibili.

EIP-2200 implementa la misura del gas netto, modificando il modo in cui viene calcolato il costo di stoccaggio nell’EVM. Ciò consentirà nuove funzioni di archiviazione dei contratti e ridurrà alcuni costi eccessivi.

Ancora in lavorazione

Un’altra proposta di alto profilo che la comunità di Ethereum ha preso in considerazione nell’accumulo dell’hard fork di Istanbul è EIP-1057, che cerca di sostituire l’attuale algoritmo di mining Ethash con una nuova funzione proof-of-work chiamata ProgPoW, abbreviazione di Programmatic Proof-of-Work. Gli sviluppatori core hanno provvisoriamente accettato l’iniziativa, in attesa audit risultati, per l’inclusione nell’hard fork di Berlino.

L’idea alla base di questo aggiornamento dell’algoritmo è di ottimizzarlo per hardware di base che utilizza unità di elaborazione grafica, rendendo il mining più difficile per le configurazioni dotate di chip a circuito integrato specifici per l’applicazione.

Questa misura è progettata per ripristinare un certo grado di decentralizzazione nella distribuzione dell’energia mineraria, livellando il campo rendendo il mining di Ethereum più attraente per i singoli utenti e le piccole imprese non investite in hardware specializzato. Gli ASIC sono stati uno dei principali motori dell’industrializzazione del settore minerario negli ultimi anni, portando a massicci cluster minerari centralizzati.

All’inizio di quest’anno, Martin Holst Swende, responsabile della sicurezza della Fondazione Ethereum, ha affermato che l’introduzione di ProgPoW mitigherebbe il grado di predominio degli ASIC e di altri acceleratori hardware sulla rete. Ha aggiunto che un altro motivo del cambiamento sono le falle di sicurezza inerenti a Ethash.

Sebbene sembri esserci un accordo tra gli sviluppatori principali riguardo alla desiderabilità di ProgPoW, non tutti nella comunità sono contenti della prospettiva che l’algoritmo di mining cambi prima del passaggio alla proof-of-stake in Ethereum 2.0.

Il dissenziente più esplicito finora è stato Aragon, un progetto per la gestione di organizzazioni autonome decentralizzate, la cui comunità ha votato il 2 novembre per opporsi a qualsiasi modifica a Ethash prima del passaggio a Ethereum 2.0.

Nonostante qualche tensione, non vi è alcuna indicazione che una massa critica di utenti di Ethereum sia aspramente contraria alla modifica proposta, rendendo improbabile che lo sviluppo porti a una grave spaccatura.

Se l’audit indipendente dovesse attestare la robustezza del nuovo algoritmo, sarà probabilmente applicato con l’hard fork di Berlino, ora provvisoriamente programmato per giugno 2023, mentre Ethereum continua la sua marcia verso l’ambita versione 2.0 della rete..

L’articolo è stato aggiornato per riflettere la nuova scadenza per l’hard fork di Istanbul.