Blockchain Bloat: come Ethereum sta affrontando i problemi di archiviazione

24.270 token. 27.358 transazioni in sospeso. 463.713gattini digitali.

Di recente Ethereum ha registrato una notevole attività e, sebbene molti appassionati Cripto lo considerino un segnale positivo, man mano che l'utilizzo della rete aumenta, la sua storia si allunga e la sua blockchain diventa più indisciplinata.

Sebbene la congestione della rete, che porta ad arretrati nelle transazioni e ad aumento delle commissioni, abbia attirato l'attenzione, c'è un altro problema causato da questa portata: un database in crescita che comporta costi di archiviazione significativi per gli utenti che desiderano gestire un nodo completo.

Quel database, chiamato stato Ethereum , contiene tutti i calcoli che devono essere memorizzati dai computer che supportano la piattaforma e la blockchain Ethereum stessa. E con i costi (sia in termini di tempo che di denaro) per l'archiviazione dello stato in aumento, sempre meno persone scelgono di eseguire nodi completi, il che molti temono centralizzerà la rete nelle mani di pochi arbitri.

E gli sviluppatori riconoscono il problema.

ONE , gli sviluppatori Ethereum sono già a buon punto nell'ingegnerizzare modifiche a livello di protocollo, come lo sharding, volte a ridurre al minimo il database.

Ma poiché queste tecnologie sono ancora in fase di sviluppo, altri stakeholder, in particolare coloro che gestiscono i client Ethereum (il software necessario agli utenti per comunicare con la blockchain), sono stati sottoposti a nuove pressioni per far fronte alla crescita del database statale.

"Il fatto che migliorare questa roba sia fondamentale è noto dalla fine del 2016, le idee circolano da sei mesi a più di un anno. Dove sono le implementazioni?" ha detto di recente il creatore Ethereum Vitalik Buterin su un canale per sviluppatori.

La frustrazione è palpabile sia per Buterin che per Afri Schoedon, che gestisce le comunicazioni tecniche presso il fornitore di software client Ethereum Parity. Schoedon ha detto a CoinDesk:

"Al tasso di crescita attuale, è prevedibile che quest'anno lo Stato crescerà molto rapidamente, al punto che sarà difficilmente gestibile su dispositivi di piccole dimensioni."

Nel tentativo di limitare gli effetti di questa situazione difficile, i due client Ethereum più popolari, Geth e Parity, hanno recentemente rilasciato degli aggiornamenti che tentano di migliorare la situazione.

Turbocompresso

IL primo aggiornamento, rilasciato la scorsa settimana da Parity, ha ridotto i requisiti di archiviazione eliminando i file temporanei non necessari prodotti dal software durante la memorizzazione della cronologia di Ethereum.

Riducendo notevolmente i requisiti di archiviazione, gli utenti che si collegano per eseguire nodi completi sperimentano tempi di sincronizzazione più rapidi. E con ciò, l'azienda ha affermato che il suo software Ethereum potrebbe ora essere eseguito su un disco rigido anziché su un unità a stato solido (SSD), un'impresa particolarmente degna di nota poiché i lunghi tempi di sincronizzazione hanno impedito a Ethereum di funzionare su un disco rigido dalla scorsa estate.

L'aggiornamento ha persino ricevuto una risposta entusiasta da Buterin, che ha detto su un canale per sviluppatori, "Wow. Come ci siete riusciti?"

A seguito dell'aggiornamento, gli utentihanno segnalatoun'esperienza notevolmente migliorata.

Allo stesso tempo, lo sviluppatore indipendente Alexey Akhunov ha lavorato su una riscrittura del client geth, chiamato "turbo geth". Descritto da Akhunov come un"ossessione,"Il progetto mira a rimuovere molte ripetizioni inutili nel modo in cui i client di Ethereum elaborano lo stato generale.

Sebbene non sia NEAR pronto, ha aperto alcune interessanti strade di "ottimizzazione speculativa", ha affermato Akhunov in una recente chiacchierata con gli sviluppatori.

Ad esempio, Akhunov suggerisce di "codificare" alcune informazioni sullo stato Ethereum nei client stessi. In definitiva, l'obiettivo è adattare il software in modo che funzioni semplicemente tramite memoria ad accesso casuale, o RAM, che potrebbe rendere i client molto più veloci, consentendo loro di sincronizzarsi potenzialmente con la rete all'istante.

Anche gli sviluppatori di Geth stanno lavorando alle ottimizzazioni, per ONE cercando di correggere una stranezza nel modo in cui le informazioni vengono archiviate quando un client si sincronizza con la rete in quella che viene chiamata modalità "veloce". Descritto dallo sviluppatore CORE di Geth Péter Szilágyi come "davvero orribile", è probabile che il codice esistente venga sostituito insieme a un sacco di aggiornamenti che rendono la sincronizzazione molto più veloce e meno intensiva in termini di archiviazione.

I limiti

Sono in corso anche ricerche su un tipo di client denominato "stateless client", che memorizza solo una compressione dello stato generale.

Anche Buterin è interessato all'idea, di recenteintraprendere uno studioche descrive uno scenario in cui "i miner e i nodi completi in generale non hanno più bisogno di memorizzare alcuno stato". Inoltre, Buterin ha affermato più avanti in un canale per sviluppatori, i client senza stato allevierebbero anche la necessità di ripulire lo stato tramite altre misure, come l'eliminazione di dati vecchi e irrilevanti, ad esempio account vuoti o inattivi da molto tempo.

"Ora sono favorevole all'approccio del client senza stato", ha scritto Buterin.

E c'è persino chi ipotizza che i client stateless potrebbero essere possibili senza apportare modifiche a livello di protocollo.

Presentando tali client come una possibile soluzione agli ostacoli di scalabilità affrontati da Ethereum in seguito al successo di CryptoKitties, Akhunov ha scritto in un recente post del blog: "Credo che (i client stateless) possano essere implementati già ora, senza alcun hard fork, 'semplicemente' modificando i client Ethereum ... Ciò significa che i nodi non hanno bisogno di accedere allo storage dai file e i tempi di convalida dei blocchi dovrebbero ridursi in modo significativo."

Tuttavia, le ottimizzazioni del client T possono essere l'unico elemento su cui la rete fa affidamento per ridurre i problemi di stato.

Secondo Szilágyi

, alla fine, le ottimizzazioni dei client raggiungeranno il loro limite. E poi gli sviluppatori dovranno rivolgere la loro attenzione alle tecnologie in corso, come lo sharding, che suddivide il database Ethereum in parti più piccole archiviate in nodi diversi, nel tentativo di alleviare la pressione di archiviare l'intero database su singoli client.

Forse in risposta alle recenti tensioni sulla rete, lo sviluppo dello sharding è avanzato negli ultimi mesi, con una specifica in fase iniziale delineata suGuida.

"Possiamo ottimizzare il database e renderlo dieci volte più veloce e ottimale, il che ci dà la possibilità di crescere fino a dieci volte le nostre dimensioni attuali", ha affermato Szilágyi, aggiungendo:

"Ma alla fine arriveremo al punto in cui T saremo più in grado di ottimizzare il database e a quel punto dovremo essere in grado di suddividere i nostri dati".

Disco rigidoimmagine tramite Shutterstock