Almeno una volta al mese qualcuno posta un grafico su r/ethereum che prevede che le dimensioni della blockchain di Ethereum eccederanno presto 1TB.

Coglieremo questa occasione per mettere in chiaro in questo articolo alcuni aspetti sulle storie che riguardano le dimensioni della blockchain di Ethereum e proveremo a spiegare perchè questo grafico è tecnicamente corretto ma non rappresenta il quadro generale.

Innanzitutto diamo un’occhiata a questo grafico. Ci mostra le dimensioni totali della directory dei dati di un nodo di Ethereum (rosso), Geth in questo caso, ed un nodo di Bitcoin (blu), probabilmente Biticoin-Core, tracciate nel corso del tempo.

Mentre il grafico di Bitcoin si va spostando leggermente verso su in quella che sembra un’inclinazione lineare, il grafico di Ethereum ci ricorda un’inclinazione che cresce in maniera esponenziale.

On Blocks, Block-History, States e State-History

Gli utenti che accusano Ethereum di blockchain-bloat non sono così lontani dalla verità con le loro ipotesi. Ma in realtà, non è la chain ad essere gonfiata ma lo state di Ethereum. Prima di procedere, esaminiamo la terminologia proveniente dal Whitepaper.

Block – Un insieme di transazioni che, in seguito ad una corretta esecuzione, aggiornano lo state. Ogni block che racchiude delle transazioni ha un numero, ha qualche difficoltà e contiene lo state più recente.

State – Lo state è composto da tutti gli account Ethereum inizializzati. Nel momento della scrittura ci sono circa 12 milioni di account e contratti che crescono ad un tasso di grossomodo centomila nuovi account ogni giorno.

Block-History –  Una chain di tutti i block precedenti, cominciando dal block genesis fino al più recente, anche conosciuta come la blockchain.

State-History – Lo state di ogni block della sequenza costituisce la state history. Vedremo i dettagli in seguito.

Verso la comprensione di modalità di pruning e modalità di sincronizzazione

All’inizio del 2016, la squadra Go-Ethereum ha introdotto una cosiddetta modalità di sincronizzazione fast.

Da allora diventò abbastanza famoso da gestire Geth fast, specialmente in seguito agli attacchi spam che sono avvenuti più tardi in quello stesso anno, rendendo dolorosa una modalità di sincronizzazione full.

Il team di Parity (ex Ethcore) ha reagito alle spam on-chain offrendo una modalità di sincronizzazione warp alla fine del 2016, in modo tale da facilitare la sincronizzazione della chain per i nuovi utenti.

Un pò come il fast di Geth, Parity warp diventò presto la modalità standard de facto per gli utenti che tentavano di sincronizzare la chain di Ethereum. Oggi entrambe queste opzioni sono state adattate come impostazioni predefinite in entrambi i client.

Ma cosa vuol dire sincronizzazione fast contro sincronizzazione full di un nodo Geth? Cosa vuol dire veramente sincronizzazione warp di un nodo Parity invece che sincronizzazione senza warp?

Un nodo Geth full processa l’intera blockchain e replica tutte le transazioni che ci sono state fino a quel momento. Un nodo Geth fast scarica tutte le ricevute delle transazioni in parallelo a tutti i block e il più recente database di state.

Una volta finito questo passa ad una sincronizzazione full.

Considerate che questo risulta non solo in una sincronizzazione fast, ma anche in un database di state tagliato perché gli state precedenti non sono disponibili per block più piccoli del migliore block meno 1024.

Questo non è un problema, ma prima di continuare a leggere, tenete a mente che le modalità di sincronizzazione di Geth sono anche modalità pruning.

Guardando le opzioni di configurazione di Parity, questo diventa più complesso. Oltre alle modalità di sincronizzazione precedentemente menzionate, Parity offre anche modalità di pruning (taglio) separate, ossia fast ed archive…

Esattamente, Geth fast è una modalità di sincronizzazione, che abbiamo imparato, fa anche pruning, tuttavia, Parity fast è una modalità pruning che non è strettamente abbinata alla modalità di sincronizzazione.

Il fast di Geth rende possibile una sincronizzazione più rapida e la pulizia/pruning del database. Il full di Geth disattiva entrambe. Il wrap di Parity, tuttavia, può essere disattivato senza disattivare lo state-trie pruning!

Questa è una frase significativa e possiamo dimostrare che è possibile far funzionare un nodo Ethereum completamente verificato con un piccolo database. Parity fornisce semplicemente la proof-of-concept per questo.

Ma perché? Perché fino a quando avrete tutti i block precedenti nel vostro disco, potrete calcolare qualunque state precedente da essi rianalizzando nuovamente l’intera chain. Ma nella maggior parte dei casi, non avrete affatto bisogno degli state precedenti! Quindi conviene semplicemente cancellare le voci obsolete dalla cronologia degli state e ridurre il vostro spazio necessario sul disco di 95%.

Dunque, quali sono le dimensioni minime di un Node completamente verificato?

Alcune decine di GB semplicemente utilizzando parity no-warp.

All’inizio di questo autunno erano meno di 20GB, ma lo state sta crescendo molto rapidamente. Al momento i blocchi di dati grezzi precedenti che contengono i block e le transazioni sono all’incirca 12-15GB di dimensione e l’ultimo state è di circa 1-2GB.

Ma può questo essere considerato un nodo Ethereum full?

Si:

–Gestisce una sincronizzazione completa partendo da genesis.

–Ripete tutte le transazioni ed esegue tutti i contratti.

–Ricalcola lo state per ogni block.

–Mantiene tutti i block precedenti sul disco.

–Mantiene gli state più recenti sul disco e taglia quelli vecchi.

Una cosa che un client Ethereum non fa mai è cancellare vecchi block. Questa è una differenza significativa fra Bitcoin ed Ethereum, perchè effettuare il pruning su un nodo Bitcoin non lascia altra scelta che rimuovere vecchi block.

In questo contesto è più facile comprendere perché gli utenti pensano spesso che un nodo Ethereum tagliato non sia un nodo completo. Ma adesso sapete che è proprio l’opposto.

E come se non bastasse, anche un nodo Parity sincronizzato warp sta scaricando l’intera cronologia dei block dopo che la sincronizzazione iniziale gli permette di essere di aiuto al network come un nodo full una volta completata la sincronizzazione dei vecchi blocchi.

Il quadro completo: 9 configurazioni Parity a confronto

Qui sotto possiamo vedere uno screenshot di una tabella che prova a distinguere fra la sicurezza dei nodi di diverse modalità operative di Parity.

Le configurazioni da 00 a 05 sono considerate tutte nodi full. La configurazione 06 è un nodo warp con configurazione predefinita che può essere considerata come un full una volta che il download del vecchio blocco è terminato. Tuttavia, non ripete tutte le transazioni; controlla solamente la Proof-of-Work dei blocchi precedenti.

La configurazione 07 è spesso richiesta dagli utenti ma dovrebbe essere altamente scoraggiata nella produzione. Questa impostazione può essere messa a confronto con un nodo bitcoin pruned dato che i block precedenti sono parzialmente disponibili. Questo non è più un nodo completo.

La configurazione 08 è un light client, ma ci vorrebbe un altro articolo per parlarne. Concludiamo dicendo che un nodo full di Ethereum non ha normalmente bisogno di più di 20-30 GB di spazio sul disco.

Di: Dev