Dencun Ethereum: deep dive focus

Il demone dello sharding completo

Ethereum vuole diventare il più sicuro e scalabile settlement layer per le applicazioni sviluppate sul proprio network. Ricordiamo brevemente, per chi si fosse distratto negli ultimi 6 mesi che il concetto di modularità prevede la delega dei vari compiti affidati ad una blockchain ad attori qualificati.

Il consenso riguarda l’algoritmo tramite il quale si stabiliscono e mantengono le regole che portano avanti la rete; il settlement è quel layer in cui le transazioni sono inscritte in maniera permanente ed irreversibile; la data availability tratta della disponibilità dei dati per un periodo di tempo limitato e sufficiente a dimostrarne l’accessibilità; l’esecuzione riguarda invece tutte le operazioni tra utenti, smart contract, applicazioni e via dicendo.

Ethereum punta a mantenere il suo ruolo di leader nel consenso, nel settlement e nella data availability, grazie al suo trust network largamente utilizzato e alla lunga roadmap che porterà i costi di transazione, di inserimento dati e di on board di nuovi utenti a livelli sempre più bassi.

L’introduzione dei layer 2 è stato un passo significativo in avanti verso una maggiore scalabilità su Ethereum. La migrazione verso un modello “modulare” è iniziata separando l’esecuzione delle transazioni dal settlement, consentendo l’attività “off chain” e accennando un tentativo di implementazione dello sharding esecutivo.

Si parla di tentativo poiché nel corso degli anni, il demone dello sharding completo ha tenuto svegli sviluppatori e ricercatori, finchè non si è compreso che si stava cercando di fare il passo più lungo della gamba e che solo affrontando un problema alla volta con ordine, si sarebbe potuto ottenere il risultato finale.

Proto-DankSharding

La rete di Ethereum ha un ulteriore obiettivo, ossia quello di aumentare la sua scalabilità senza compromettere le sue caratteristiche di sicurezza. Per scalabilità si intende la capacità di mantenere le performance costanti al variare del numero di utenti e transazioni.

Per farlo si è prediletto un sistema basato su L2 che assorbono parte del traffico del L1 e tramite una serie di meccanismi riportano le informazioni sulla rete principale in maniera compressa.

Questi L2, che vengono definiti rollup pubblicano una grande quantità di dati su Ethereum e, ad oggi, ciò ha un costo proibitivo non permettendo una reale scalabilità del sistema.

Per questo Ethereum creerà un nuovo spazio, dedicato ai dati dei L2, il quale può essere definito a tutti gli effetti uno shard, dando così il via al famoso processo di sharding che oggi cercheremo di spiegare in termini semplici ed accessibili.

La pubblicazione di questi dati garantisce la c.d. data availability nei confronti degli utenti dei L2, anche se questi dati non verranno detenuti ad oltranza. Infatti vedremo che Ethereum è una macchina che provvede a garantire la verificabilità dei dati e la presenza degli stessi per un periodo di tempo sufficiente a far si che chiunque sia interessato possa scaricarli e verificarne la correttezza.

Se però ogni nodo dovesse verificare e mantenere questi dati sempre disponibili verrebbe meno la decentralizzazione, dato che le richieste hardware per la sincronizzazione di tutti i dati della rete aumenterebbero sempre di più e quindi non tutti potrebbero partecipare al network.

Il design che è stato studiato per risolvere queste problematiche è definito DankSharding, dato che è una forma di Sharding rivisitata e proposta dal ricercatore Dankrad Feist. Questa versione passerà tramite diversi step e il primo che affronteremo l’EIP4844, anche conosciuto come ProtoDankSharding (poiché proposto da un dev della community chiamato ProtoLambda).

Trilemma

Prima di snocciolare i tecnicismi di questo EIP e dell’aggiornamento Dencun in generale, affrontiamo il concetto di Trilemma da un punto di vista innovativo, partendo da queste due assunzioni:

• Vogliamo che tutti siano in grado di verificare autonomamente la blockchain, eseguendo il proprio nodo su hardware personale.
• Un nodo deve scaricare ogni singolo blocco ed eseguire ogni singola transazione per verificare che sia valido e coerente con il resto della rete.

Queste due affermazioni insieme spiegano la scarsità di spazio nel blocco presente oggi: le commissioni di transazione sono più basse se c’è più spazio nel blocco, ma più spazio nel blocco significa che i nodi devono fare più lavoro (larghezza di banda, calcolo, archiviazione), il che potrebbe andare contro l’obiettivo dichiarato nella Dichiarazione n. 1.

Viceversa, abbiamo un’offerta relativamente limitata di spazio nel blocco – circa 15 milioni di gas – che si scontra con una domanda piuttosto elevata, causando le famigerate gas fee elevate di Ethereum.

L’obiettivo è rendere in qualche modo non contraddittorie le due affermazioni: vogliamo più spazio nel blocco, ma senza aumentare l’onere sui nodi che costituiscono la rete.

"Più spazio nel blocco, ma senza aumentare l'onere sui nodi che costituiscono la rete"

Rollup centric scalability solution

Vitalik dice:

“Mi sembra molto plausibile che quando [il full execution sharding] sarà finalmente implementato, praticamente nessuno se ne preoccuperà. Tutti si saranno già adattati a un mondo incentrato sui rollup, che ci piaccia o no, e a quel punto sarà più facile continuare su quella strada piuttosto che cercare di riportare tutti sulla mainnet di Ethereum, senza un beneficio chiaro e una riduzione della scalabilità di 20-100 volte.”

Un altro aspetto sottovalutato di questa roadmap incentrata sui rollup è che i rollup sono molto più liberi di innovare indipendentemente l’uno dall’altro: con i piani originali di shard, ogni shard avrebbe avuto la stessa EVM, le stesse proprietà di finalità, le stesse caratteristiche con gli stessi esatti compromessi. Scommettere sui rollup significa ottenere molta più innovazione a un ritmo decisamente più veloce.

Il metodo più immediato ed economico per riportare i dati sul layer principale per i rollup è la funzione call data, che costa 16 Unit of Gas per ogni Byte riportato on chain; ovviamente, nel momento in cui il gas aumenta esponenzialmente per attività anomale sul layer 1, questo diventa molto costoso.

Il problema che osserviamo da questa dinamica non è tanto il costo in sé, ma il fatto che esso possa essere influenzato da categorie di operatori di per sé non concorrenti: on chain e rollup. Nonostante stiano utilizzando due servizi differenti, questi competono per lo stesso spazio o servizio, il blockspace; infatti, i trader utilizzano il BlockSpace per l’esecuzione, mentre i rollup richiedono di poter inserire dei dati dell’esecuzione già eseguita off chain.

Blob e BlobSpace

Ecco che entrano in gioco i Blob. In parole povere i blob sono parti di dati che i rollup possono mettere on chain e vengono inserite all’interno del blocco, occupando però un apposito spazio, che non compete con quello dedicato ai dati delle transazioni e ai cambi di stato.

Il BlobSpace non è altro che una nuova parte del blockspace dedicata ai dati che i rollup hanno bisogno di inserire nel layer 1. I partecipanti della chain principale non avranno bisogno di sapere il contenuto del Blobspace salvo per verificare che i rollup abbiano compiuto correttamente il loro lavoro

Infatti, se i dati delle transazioni occupano block space, quelli dei rollup occupano blob space ed entrambi sono contenuti all’interno dei blocchi. Questo è un esempio semplice per spiegare il concetto, ma c’è però da precisare che i Blob non sono esattamente contenuti all’interno del blocco, per far si che quest’ultimo possa rimanere agile e leggero, quindi esiste un riferimento all’interno del blocco che rimanda al blob che vi è associato detto blob-carrying-transaction.

La parte che impediva di scalare il layer 1 viene così esternalizzata. Infatti, se prima i nodi dovevano occuparsi di validare ogni transazione inserita all’interno del blocco del layer 1, ora succede che devono solo pensare a verificare la conformità della referenza al blob, all’interno del quale saranno contenuti i dati delle transazioni eseguite esternamente.

Inoltre le dimensioni dei dati che occupano blockspace, per coloro che eseguono una transazione, sono esponenziali rispetto al numero di operazioni contenute nel singolo evento di esecuzione: una transazione pesa x, mintare un NFT pesa y, mintare 50 NFT insieme pesa z; viceversa abbiamo un nuovo elemento, il blobspace appunto, che è separato dal blockspace e che è dedicato all’inserimento dei dati dei rollup e alla disponibilità di scaricarli qualora richiesto.

Dencun

Parliamo nel dettaglio di Dencun (Cancun-Deneb) e di quali aspetti ed EIP sono da tenere sott’occhio. Ricordiamo anche il perché dell’arrivo di questo aggiornamento.

I layer 2 elaborano le transazioni, le “raggruppano” insieme e quindi inviano una versione compressa alla rete principale, Ethereum, per l’irreversibilità o c.d. settlement.

Grazie a questo processo di batching, i layer 2 possono offrire agli utenti un throughput di elaborazione significativamente maggiore e costi più bassi rispetto alle transazioni eseguite su mainnet, affidandosi alla solidità di Ethereum e alla sicurezza complessiva del network.

Ma i layer 2 sono stati solo un punto di partenza. Sebbene abbiano contribuito a ridurre le commissioni di transazione per gli utenti più di 10 volte rispetto alle transazioni sulla mainnet, i layer-2 sono ancora significativamente più costosi rispetto ai competitor come Solana o Near.

Ciò è dovuto principalmente alle commissioni sulla scrittura dei dati, infatti, circa l’80% dei costi delle transazioni imposte dai Layer 2 deriva dal costo che i rollup andranno a pagare per inserire i batch on chain.

Allo stesso tempo, soluzioni di data availability come Celestia offrono il potenziale per ridurre i costi dei Layer 2 di numerosi ordini di grandezza e minacciando di togliere utilità e valore ad Ethereum.

Grazie a Dencun, all’EIP4844 e alla creazione del concetto di BlobSpace l’abbattimento dei costi dei call data diventerà sempre di più realtà. Non sarà lo step finale il quale probabilmente impiegherà ancora qualche anno, ma se i piani rimanessero quelli previsti oggi, il grande aumento di scalabilità arriverà con il Dank Sharding Completo; questi aggiornamenti fanno parte dello step della roadmap definito The Surge.

Da mercoledì abbiamo avuto Dencun e un iniziale adeguamento dei costi che i rollup devono sostenere per operare. Molti di questi si sono già guardati intorno e si stanno appoggiando a soluzioni con Celestia o EigenDA, ma d’ora in avanti potranno tornare a tenere in considerazione anche Ethereum come layer di data availability e settlement.

Storia e nomenclatura degli aggiornamenti

La rete di Ethereum opera gli aggiornamenti su due livelli, che prima del Merge operavano indipendentemente mentre ora si sviluppano parallelamente. Per questo, anche gli aggiornamenti spesso sono la fusione di due realtà anche se affrontano ambiti diametralmente opposti.

Il Layer di Esecuzione come visto anche in precedenza gestisce l’esecuzione degli smart contract, delle transazioni e la trasmissione dei dati al resto della rete; è inoltre responsabile del mantenimento dello stato della rete, il passaggio di asset e l’aggiornamento degli Account Balance eseguendo la Ethereum Virtual Machine. Gli Hard Fork che si occupano di modificare o migliorare questi ambiti prendono il nome delle città in cui avvengono i Devcon: Berlino -> Londra -> Shanghai -> Cancun -> Praga -> Osaka -> Bogotà.

Mentre il Layer di Consenso è responsabile del coordinamento sullo stato della rete e delle regole tra i nodi, garantisce che tutte le transazioni e gli smart contract vengano gestiti in conformità con le regole del protocollo e secondo l’algoritmo Proof of Stake. Ogni aggiornamento del Layer di Consenso invece prende il nome di una stella procedendo in ordine alfabetico: Altair -> Bellatrix -> Capella -> Deneb -> Electra.

Inoltre per ognuno di questi update deve avvenire un rigido passaggio per tutte le testnet che precedono la mainnet e che servono per verificare il funzionamento e la presenza di errori e bug. Nell’infografica sottostante potete osservare i vari passaggi forzati.

Indice degli EIP

Vediamo ora nel dettaglio quali sono gli EIP introdotti da Dencun e su cosa si concentrano:

• EIP-4844: Aumenta la scalabilità e riduce i costi di transazione per i Rollup
• EIP-1153: Riduce i costi di storage on-chain
• EIP-4788: Aumenta sicurezza e funzionalità trustless
• EIP-5656: Migliora le performance dell’EVM
• EIP-6780: Aumenta la sicurezza complessiva della rete
• EIP-7044: Permette un design di staking più semplice
• EIP-7045: Aggiornamento critico per la sicurezza delle prove e delle regole di consenso
• EIP-7514: Ritarda il raggiungimento di soglie critiche per lo staking

Miglioramento della sicurezza della rete

EIP-6780: Migliora la sicurezza degli smart contract eliminando self destruct.

Self Destruct è un vecchio opcode nell’EVM. È stato progettato per essere utilizzato dai creatori di Smart Contract per pulire e rimuovere codice non necessario o deprecato dallo stato di Ethereum. Tuttavia, la maggior parte degli sviluppatori di Ethereum considera che Self Destruct abbia fallito in questo obiettivo. I numerosi pericoli e le conseguenze non volute della chiamata a questo opcode hanno portato gli sviluppatori a evitarlo, nei casi migliori, o ad usarlo in modo errato, negli scenari peggiori.

EIP-5656: Permette di avere una copia più efficiente della memoria nell’EVM aumentando le performance

In termini generali, la copia di memoria si riferisce al processo di spostamento di blocchi di dati da una posizione in memoria a un’altra. È un’operazione fondamentale nell’informatica, utilizzata per compiti come la costruzione di strutture dati e la copia di oggetti.

Ottimizzazione dell’algoritmo e miglioramento dell’interfaccia utente di staking

• EIP-7044: Migliora l’esperienza di staking dell’utente.
• EIP-7045: Aiuta ad ottenere una conferma più rapida dei blocchi e migliorare l’algoritmo di consenso.

Potenziamento delle comunicazioni tra il layer di esecuzione e il layer di consenso

EIP-4788: Elimina la necessità di sistemi di oracoli fidati rendendo verificabile lo stato di consenso di Ethereum sulla mainnet. Questo aggiornamento influisce sui pool di liquid staking migliorando l’efficienza del capitale e rimuovendo i rischi di centralizzazione. Migliora inoltre la sicurezza e l’affidabilità delle applicazioni di restaking come Eigen Layer.

Affrontare l’ingrandimento dello stato della rete e introduzione dello storage transitorio

EIP-7514: Stabilisce un limite al turnover dei validatori per prevenire una crescita eccessiva.

Stabilirà un churn limit per epoca a 8, modificando così il tasso massimo di crescita dei validatori di Ethereum da esponenziale a lineare. Il limite di churn di Ethereum definisce il numero massimo di validatori che possono entrare (o uscire) dall’insieme attivo di validatori di Ethereum ad ogni epoca (~6,4 minuti). Il churn limit è attualmente una variabile che ha un valore minimo di quattro e aumenta di uno ogni volta che un numero specifico di validatori entra nell’insieme attivo.

EIP-1153: Introduce opcode di storage transitorio per una maggiore efficienza in termini di gas. Lo storage transitorio si cancella dopo ogni transazione, differenziandosi dallo storage permanente e dalla memoria in Ethereum un po’ come si pulisce la RAM di un PC quando non è più necessario che conservi certi dati.

Blob carrying transactions

EIP-4844: Introduce le blob-carrying-transaction per scalare Ethereum efficientemente.

I blob contengono dati delle transazioni off chain e vengono inseriti nei blocchi della mainnet, vengono utilizzati principalmente dai sequencers di rollup. Le blob-carrying transaction contengono riferimenti ai blob stessi, riducendo i requisiti di elaborazione di questi ultimi, verificando solo la correttezza del riferimento. Con questo aggiornamento il protocollo garantirà l’inclusione limitata di blob per ogni blocco per gestire gradualmente il carico computazionale.

Conclusioni

Abbiamo affrontato i vari aggiornamenti tecnici e le aspettative di miglioramento che questi ultimi porteranno sulla rete, di cui il più visibile e documentabile è sicuramente l’EIP4844 con la riduzione dei costi di transazione sui layer 1.

Per osservare quali Rollup adotteranno il Blobspace Calldata possiamo utilizzare L2BEat che ha di recente inserito una nuova dashboard di monitoraggio proprio per la Data Availability.

Mentre per monitorare il costo delle fees per ogni Layer 2 post EIP si può utilizzare questa dashboard di Dune Analytics.

Inoltre per i più curiosi rispetto all’adozione dei Blob e delle loro caratteristiche consigliamo anche quest’altra dashboard su Dune

Ringraziamo per l’attenzione e buon ATH a tutti!