Mentre tutta l’attenzione della community di Ethereum è attratta da Ethereum 2.0 (Serenity), Ethereum 1x è passato un po’ in sordina.

Ethereum 1x è un progetto di miglioramento della scalabilità di Ethereum, che si basa sulla combinazione di diverse implementazioni.

Con Ethereum 1x si vuole rendere la rete più efficiente, quindi scalabile, anche prima dell’approdo di Serenity. Ovviamente, sono migliorie che potranno essere sfruttate anche sulla blockchain di Ethereum 2.0.

Serenity a piccoli passi

Serenity è il macro aggiornamento che renderà Ethereum un’infrastruttura multi-layer.

Ethereum 2.0 farà perno sulla combinazione dell’algoritmo di consenso PoS e della soluzione di scalabilità Sharding.

La mainnet di Ethereum 2.0 sarà suddivisa in shards (o micro-chains). A questa si uniranno soluzioni di secondo livello (layer 2), come Plasma, e la combinazione di progetti chiave per ottenere un meccanismo di consenso PoS.

Con Ethereum 2.0 si aspira a processare migliaia e migliaia di transazioni al secondo, rendendo finalmente Ethereum una piattaforma utilizzabile su larga scala.

Il problema, però, è che Serenity non sarà ultimato in un paio di giorni. Probabilmente non sarà completato, nella sua interezza, neppure entro la fine del 2019.

Il rilascio della Beacon Chain non equivarrà alla conclusione di Ethereum 2.0. Dovranno essere implementate anche le Shard chains e il layer VM (per l’esecuzione dei contratti e delle transazioni).

Tra gli sviluppatori è stata avvertita l’esigenza di rinvenire delle soluzioni che consentano di migliorare le performance della rete sin da subito, durante la fase transitoria che condurrà al completamento di Serenity.

L’idea è di migliorare l’efficienza dell’attuale rete, per ampliare in maniera netta il limite di transazioni processabili al secondo.

Attualmente, il limite di TPS è di circa 16. Si aspira a elevare dalle tre alle cinque volte il limite corrente di transazioni al secondo.

Un ritocco più veloce: Ethereum 1x

Al momento ci sono quattro gruppi di lavoro impegnati a far progredire Ethereum 1x.

Uno di questi team, guidato da Alexey Akhunov, si sta focalizzando sul concetto di “storage rent”, idea già presentata la scorsa primavera.

Lo storage rent consiste in una fee che gli utenti dovrebbero pagare per utilizzare la rete, in base a quanto tempo desiderano che i loro dati rimangano accessibili sulla blockchain.

Lo scopo dello storage rent è quello di frenare l’eccessiva crescita dello “stato” di Ethereum, altrimenti inteso come tutte le applicazioni e gli account attivi che operano sulla rete blockchain.

La quantità di dati archiviati sulla blockchain cresce esponenzialmente.

L’allungamento dei tempi per sincronizzare un nodo che mantiene l’intera copia della blockchain, costituisce un ostacolo per tutti i nuovi utenti che vogliono eseguire un full node e diventare parte attiva della rete.

L’imposizione di una fee agli utenti che archiviano i dati degli smart contract sulla blockchain, ha lo scopo di rallentare la crescita della blockchain e rendere la rete accessibile a tutti gli utenti.

Per conseguire lo stesso fine, c’è anche un’altra proposta denominata “stateless contracts”.

Si suggerisce di trasferire off chain alcune porzioni dei dati degli smart contract, ciò che ricondurrebbe in in capo agli sviluppatori delle dApps la responsabilità per la memorizzazione dei dati.

Un altro gruppo di sviluppatori sta esplorando delle proposte per mettere un cap alla crescita del data storage di Ethereum. Parte delle proposte prevedono la cancellazione di vecchie informazioni memorizzate sulla blockchain (pruning della blockchain).

Con Ethereum 1x, oltre a fronteggiare il problema dell’eccessiva crescita della blockchain, si vuole migliorare anche il throughput delle transazioni sulla rete di Ethereum.

Un altro gruppo di lavoro, chiamato “the simulation group”, si occupa di analizzare le conseguenze derivanti dall’incremento della dimensione del blocco o dall’aumento della latenza.

Sulla blockchain di Ethereum, la “dimensione” del blocco è data dal limite di gas consumabile per blocco. Quindi il limite delle transazioni dipende dalla complessità delle transazioni stesse in termini di istruzioni.

Uno dei punti di attenzione di Ethereum 1x, è quello di testare dei limiti di gas più elevati rispetto agli attuali.

Le ottimizzazioni che consentono di aumentare la velocità di propagazione dei blocchi, permettono ai miner di includere un maggior numero di transazioni per blocco, con maggiori guadagni in termini di fee.

Un quarto gruppo di lavoro, invece, si sta focalizzando sulla riduzione del costo di deployment degli smart contract.

eWASM sarà la nuova virtual machine per l’esecuzione del codice degli smart contract.

Suggerendone una prima implementazione, gli sviluppatori ambiscono a creare i cosiddetti “precompiles” in modo più facile. Sono alcune operazioni di smart contract, comunemente deployate, che vengono ottimizzate per essere eseguite nativamente su Ethereum a un costo fisso.

Quando arriverà Ethereum 1x?

Non c’è una data precisa per l’implementazione delle proposte di Ethereum 1x, che dovranno essere attuate attraverso un hard fork.

Ancora non sono state stabilite le precise modifiche al codice. Siamo ancora nella fase delle discussioni aperte.

La volontà da parte degli sviluppatori è quella di raggiungere un consenso diffuso in seno alla community, prima di applicare qualsivoglia modifica. Si vuole evitare qualunque pericolo di aggiornamento contenzioso.

I piani per Ethereum 1x sono stati dapprima discussi in un incontro faccia a faccia tra gli sviluppatori, in occasione del Devcon4.

Alcuni membri della community hanno manifestato il disappunto per la mancanza di coinvolgimento pubblico. Per garantire una discussione pubblica e un consenso diffuso, sono stati creati dei forum pubblici per discutere apertamente di Ethereum 1x.

Se una proposta finale verrà formulata, discussa e approvata da parte degli utenti, alcune delle proposte analizzate potrebbero essere attivate già entro giugno 2019, quindi con largo anticipo rispetto al completamento di Ethereum 2.0 (Serenity).