Mentre ci avviciniamo al Merge di Ethereum, occhio a questa soluzione per ridurre le commissioni

EIP-4844: guida rapida ad una proposta provvisoria che punta ad aggiungere spazio ai blocchi per ridurre le commissioni su Ethereum.

Il team di Ethereum ha proposto EIP-4844 come soluzione provvisoria per affrontare il problema delle commissioni costose. Ma cos’è e come funziona? Una guida poco tecnica per spiegare un termine tecnico!

Il problema dell’elevata tariffa del gas su Ethereum ha portato a EIP-4844, noto anche come proto-danksharding. Si tratta di un tentativo di introdurre una soluzione provvisoria per aumentare lo spazio di blocco all’interno della rete. Questo è reso possibile implementando un nuovo formato per le transazioni, che altrimenti dovrebbero essere implementate in sharding, una strategia per il ridimensionamento di Ethereum.

Poiché la distribuzione degli shard può richiedere del tempo, per ridurre l’importo elevato delle commissioni che gli utenti stanno attualmente pagando, questo nuovo formato di transazione è in fase di implementazione. Si tratta di una soluzione provvisoria che, nella distribuzione completa delle shard chain, aggiungerebbe circa 16 MB di spazio sui blocchi.

Per capire di più su questa proposta di miglioramento di Ethereum e su come aiuta la catena, immergiamoci un po’ più a fondo!

In che modo EIP-4844 aiuterà gli utenti?

La proposta EIP-4844 sta tentando di creare una soluzione “stop-gap” in modo che la rete possa liberarsi dalle transazioni sempre crescenti aggiungendo circa 2 MB di spazio ai blocchi. Come si può ben immaginare, questo dà un po’ di sollievo sia alla rete che agli utenti, che ora possono contare sulle tariffe gas più basse.

I rollup implementati si baseranno sui dati sharded, o frammentati (noti anche come BLOB) per garantire che gli utenti non debbano sostenere costi delle commissioni estremamente elevati. Un’altra cosa da notare qui è che in precedenza si è parlato di diverse versioni di questo EIP. Questa versione punta ad introdurre il formato per i dati frammentati, senza effettivamente frammentarli.

Una delle sfide principali è l’implementazione stessa. Se in questo round viene implementata solo una parte del processo di sharding, come verrebbe implementato il resto? Sebbene il processo possa sembrare semplice, dipende da come la community decide di portarlo avanti. Finora sono già state implementate diverse modifiche al ground-level, mentre alcune di esse sono ancora in lavorazione.

Il principale compromesso nella progettazione di questo EIP è quello di implementare di più ora rispetto a doverne implementare di più in seguito: implementiamo il 25% del lavoro aspettando lo sharding completo, o il 50% o il 75%?

Prima di questo, la maggior parte di questi aggiornamenti dipendeva dalla roadmap incentrata sul rollup per Ethereum. Questo Proto-danksharding invece fornisce solo i formati delle transazioni e le regole di verifica per l’esecuzione del processo, senza implementarlo completamente. Come parte di questo processo, si crea un nuovo tipo di transazione nota come “transazione di trasporto del blob“. L’obiettivo è includere i BLOB – quindi i dati frammentati – all’interno dei blocchi. Questi sono poi utilizzati dalle soluzioni layer 2 per aiutare a scalare Ethereum, senza fare affidamento sulla macchina virtuale di Ethereum (EVM) per accedervi.

Ecco perché questa soluzione è necessaria

Attualmente la rete è stata progettata per elaborare transazioni che hanno circa 90 Kb di spazio per ogni blocco. Anche se si riusciranno ad ottimizzare le commissioni di transazione – dovesse quindi essere ottimizzato in modo da adattarsi a blocchi di dimensioni maggiori – la dimensione massima potrebbe aumentare fino a 18 MB.

Ma questo sarebbe di per sé sarebbe troppo costoso sia per i validatori partecipanti che per gli utenti. Se utilizziamo invece il mercato dinamico delle commissioni – che è già stato implementato nell’ambito dell’EIP 1559 – tutto questo ci aiuta ad elaborare più transazioni senza gravare troppo sulla rete.

Questa soluzione quindi rende le cose leggermente meno complicate.

Il processo prevede la creazione di una transazione che contiene i dati frammentati di dimensioni fisse, introducendo anche un limite massimo al numero di BLOB che possono essere inclusi nel blocco. La beacon chain archivia questi dati, richiedendo solo una conferma da parte della macchina virtuale di Ethereum (EVM).

C’è solo una differenza significativa tra EIP-4488 e proto-danksharding, che è in termini di implementazione. Mentre il primo introduce modifiche minime oggi in modo da creare una soluzione provvisoria, il secondo richiede un’implementazione più completa in modo da ridurre al minimo la quantità di sforzi necessari da dedicare in seguito. La complessità dell’implementazione dello sharding è limitata solo alla beacon chain e non al livello di esecuzione.

L’aumento della dimensione del blocco può anche avere ripercussioni sulla dimensione del blocco e sulla capacità dei validatori di archiviare i dati sulle proprie risorse hardware. Secondo le stime, ci può essere un aumento di oltre 2,5 TB di dati all’anno. Uno dei modi per ridurlo è eliminare i dati BLOB che diventano “obsoleti” dopo un certo periodo di tempo, ad esempio 30 giorni o più.

In che modo gli utenti accederanno ai vecchi dati dopo l’implementazione di EIP-4844?

Lo scopo di EIP-4844 non è quello di garantire l’archiviazione permanente dei dati storici della blockchain in quanto può accumulare molte commissioni tra i partecipanti alla rete. Piuttosto sarebbe possibile di archiviare i dati altrove in modo che siano facilmente accessibili come diverse applicazioni/protocolli che forniscono quel servizio. In questo modo, i dati storici possono essere consultati da coloro che ne hanno bisogno.

Considerazioni finali

Man mano che ci avviciniamo al famoso Merge, ci sono diversi cambiamenti che l’EVM deve affrontare. Alcune di queste modifiche aiuteranno a ridimensionare Ethereum in modo che possa essere abilitato a supportare più transazioni e offrire maggiore scalabilità. Il proto-danksharding è uno di questi.