Il 13 maggio 2024, Vitalik Buterin ha introdotto EIP-7706. Questo Ethereum Improvement Proposal integra il modello del gas fees esistente proponendo calcoli del gas separati per i calldata. Introduce inoltre un meccanismo di tariffazione base personalizzato simile al blob gas, con l’obiettivo di ridurre ulteriormente i costi operativi delle soluzioni Layer 2.
In questo articolo approfondiremo il meccanismo della nuova proposta di miglioramento di Ethereum.
Per una comprensione completa dell'ultimo meccanismo del gas Ethereum, si consiglia di rivedere l'EIP-4844 precedentemente proposto da febbraio 2022.
La rete Ethereum utilizza attualmente due modelli di gas primari: EIP-1559 e EIP-4844.
Partiamo dal principio:
Nella progettazione iniziale di Ethereum, le commissioni di transazione erano determinate attraverso un semplice meccanismo di tipo asta. Gli utenti hanno partecipato attivamente facendo offerte per le proprie transazioni, fissando il prezzo del gas. Poiché le commissioni di transazione venivano assegnate ai miner, questi dettavano l’ordine in cui le transazioni venivano impacchettate, dando priorità a quelle con le offerte più alte.
È importante notare che questa definizione delle priorità ignora il valore MEV per questa spiegazione.
Gli sviluppatori principali dell'epoca identificarono quattro problemi chiave con questo meccanismo:
Discrepanza tra volatilità delle commissioni e costi di transazione: la volatilità dei livelli delle fees di transazione non riflette accuratamente il costo effettivo del consenso per l’elaborazione delle transazioni. Durante i periodi di domanda elevata, i blocchi si riempivano rapidamente, facendo aumentare significativamente le fees. Ad esempio, se il prezzo medio del gas fosse di 10 Gwei, il costo marginale della rete per includere una transazione aggiuntiva sarebbe superiore solo del 10% rispetto a una media di 1 Gwei. Questa incoerenza presentava una chiara inefficienza.
Latenza utente non necessaria: il limite rigido sul gas per blocco, combinato con le fluttuazioni naturali del volume delle transazioni, spesso comportava ritardi inutili per gli utenti. Le transazioni potrebbero attendere diversi blocchi prima di essere incluse, anche quando la capacità della rete consentiva un'elaborazione più rapida. Ciò ha evidenziato la mancanza di un meccanismo per regolare dinamicamente le dimensioni dei blocchi in base alla domanda in tempo reale.
Scoperta inefficiente dei prezzi: il semplice meccanismo dell’asta si è rivelato inefficiente nello stabilire prezzi di mercato equi per le commissioni di transazione. Gli utenti hanno faticato a determinare i prezzi del gas adeguati, spesso portando a pagare più del dovuto per l’inclusione della transazione.
Instabilità nelle blockchain senza ricompense dal blocco: l’eliminazione delle ricompense dal blocco e l’adozione di un modello puramente basato sulle commissioni potrebbe introdurre instabilità della rete. I minatori potrebbero essere incentivati a rubare le commissioni di transazione o a lanciare attacchi minerari egoistici per massimizzare i propri profitti.
Prima dell'EIP-1559, la rete Ethereum si basava su un modello preliminare del gas.
Proposto da Vitalik Buterin e altri sviluppatori principali nell'aprile 2019, EIP-1559 è stato implementato come parte dell'aggiornamento di London il 5 agosto 2021. Questo miglioramento ha introdotto un concetto chiave: la tariffa base. La tariffa base si adatta dinamicamente in base alla congestione della rete. Se il gas utilizzato nel blocco precedente supera un obiettivo di gas predeterminato, la tariffa base aumenta automaticamente. Al contrario, se scende al di sotto dell’obiettivo, la tariffa base diminuisce. Questo meccanismo aiuta a raggiungere un migliore equilibrio tra domanda e offerta di transazioni.
Inoltre, l’EIP-1559 migliora la prevedibilità dei prezzi ragionevoli del gas. Gli utenti non devono più fare affidamento esclusivamente su stime, poiché la tariffa base viene calcolata dal sistema stesso, eliminando la possibilità di commissioni esorbitanti dovute a errori dell'utente. Il codice specifico per il calcolo della tariffa base è reperibile nella documentazione EIP-1559.
Si può vedere che quando parent_gas_used è maggiore di parent_gas_target, la tariffa base del blocco corrente verrà confrontata con la tariffa base del blocco precedente più un valore di offset e il valore di offset è il valore massimo di parent_base_fee moltiplicato per offset dell'utilizzo totale di gas del blocco precedente rispetto al gas target, e il resto del gas target e una costante e 1.
La logica inversa è simile. Inoltre, la commissione di base non verrà più distribuita ai miner come ricompensa, ma verrà bruciata direttamente, in modo che il modello economico di ETH si trovi in uno stato teorico di deflazione, il che favorisce la stabilità del valore. D'altra parte, la commissione per priorità equivale alla ricompensa dall'utente per il miner, che può essere impostata liberamente, il che può consentire il riutilizzo dell'algoritmo di ordinamento del miner in una certa misura:
Entro il 2021, la tecnologia Rollup era maturata in modo significativo. Sia Optimistic Rollups (OP) che Zero-Knowledge Rollups (ZK) si basano su calldata per caricare i dati L2 compressi nella chain principale. Questi dati di chiamata sono essenziali per garantire la disponibilità dei dati o la verifica diretta sulla chain. Sfortunatamente, queste soluzioni comportavano costi elevati del gas per mantenere la definitività L2, con un impatto negativo sulle tariffe per gli utenti.
Anche Ethereum deve affrontare una sfida di concorrenza nello spazio dei blocchi. Ogni blocco ha un limite di gas, che limita il consumo totale di gas di tutte le transazioni al suo interno. Con il limite attuale di 300.000.000 di gas, la capacità massima teorica dei dati si traduce in circa 1,79 MB (assumendo 16 unità di gas per byte di calldata elaborati dall'EVM). Tuttavia, i dati relativi al rollup generati dai sequencer L2 spesso superano questa dimensione, competendo con altri utenti per la conferma della transazione. Questa concorrenza porta a volumi di transazioni inferiori per blocco, ostacolando il throughput complessivo della chainprincipale.
Per risolvere queste limitazioni, gli sviluppatori principali hanno introdotto EIP-4844 nel febbraio 2022. Implementato all'inizio del secondo trimestre del 2024 con l'aggiornamento Dencun, EIP-4844 introduce un nuovo tipo di transazione: la transazione BLOB. Questo tipo di transazione utilizza un nuovo formato dati chiamato BLOB data, distinto dai tradizionali calldata. A differenza dei calldata, i BLOB non sono accessibili all'EVM; è accessibile solo il suo hash crittografico, noto come VersionedHash.
EIP-4844 incorpora due design chiave aggiuntivi:
Periodo di Garbage Collection più breve: le transazioni BLOB hanno un periodo di Garbage Collection (GC) più breve rispetto alle transazioni standard. Questo design garantisce che i dati del blocco non diventino eccessivamente gonfiati.
Meccanismo del gas nativo per i dati BLOB: i dati BLOB hanno il proprio meccanismo del gas nativo, simile in linea di principio a EIP-1559. Tuttavia, utilizza una funzione esponenziale naturale nel suo modello matematico. Questa funzione offre una migliore stabilità in risposta alle fluttuazioni delle dimensioni delle transazioni. Essendo la pendenza della funzione esponenziale naturale un'altra funzione esponenziale naturale, significa che la tariffa base del gas Blob risponde in modo più significativo ai rapidi picchi delle dimensioni delle transazioni, frenando efficacemente l'eccessiva attività di transazione. Inoltre, la funzione garantisce un valore di tariffa base pari a 1 quando non c'è gas blob in eccesso.
Ecco la formula per calcolare la tariffa base del gas Blob:
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
MIN_BASE_FEE_PER_BLOB_GAS e BLOB_BASE_FEE_UPDATE_FRACTION sono costanti.
excess_blob_gas rappresenta la differenza tra il consumo totale di gas del blob nel blocco precedente e un valore costante, TARGET_BLOB_GAS_PER_BLOCK.
Quando il consumo totale di gas blob supera il valore target (differenza positiva), il termine esponenziale diventa maggiore di 1, risultando in una base_fee_per_blob_gas più elevata. Al contrario, la tariffa base diminuisce in condizioni opposte.
Questo design consente scenari che richiedono solo il potere di consenso di Ethereum per l'archiviazione di dati su larga scala e per ottenere la disponibilità dei dati a basso costo. Inoltre, impedisce che questi scenari esauriscano la capacità di impacchettamento delle transazioni del blocco. Ad esempio, i sequencer di rollup possono sfruttare le transazioni BLOB per incapsulare informazioni L2 cruciali all'interno dei dati BLOB. L'EVM, attraverso una progettazione intelligente utilizzando VersionedHash, può quindi implementare la logica per la verifica on-chain.
Va aggiunto che le attuali impostazioni TARGET_BLOB_GAS_PER_BLOCK e MAX_BLOB_GAS_PER_BLOCK introducono un limite sulla mainnet, che è target di 3 blob (0,375 MB) e un massimo di 6 blob (0,75 MB) per blocco. Questi limiti iniziali sono progettati per ridurre al minimo la tensione sulla rete causata da questo nuovo EIP e si prevede che aumenteranno nei futuri aggiornamenti man mano che la rete dimostrerà affidabilità in blocchi più grandi.
Dopo aver chiarito l'attuale modello di gas di Ethereum, analizziamo gli obiettivi e i dettagli di implementazione della proposta EIP-7706, presentata da Vitalik Buterin il 13 maggio 2024. Similmente ai Blob in EIP-4844, questa proposta isola il modello di gas associato a un altro tipo di dato speciale: calldata. Inoltre, ottimizza la logica di implementazione del codice corrispondente.
Il concetto centrale alla base di EIP-7706 consiste nel rispecchiare la logica di calcolo della tariffa base per calldata a quella stabilita per i dati Blob in EIP-4844. Entrambi i meccanismi utilizzano una funzione esponenziale per determinare il fattore di scala applicato alla tariffa base corrente. Questo fattore viene calcolato in base alla deviazione tra il consumo effettivo di gas nel blocco precedente e un valore target predefinito.
EIP-7706 introduce un nuovo design dei parametri chiamato LIMIT_TARGET_RATIOS. Questo vettore contiene tre valori che definiscono i rapporti target per diverse classi di gas:
LIMIT_TARGET_RATIOS[0]Questo valore rappresenta il rapporto target per il gas utilizzato dalle operazioni EVM.
Blob DataLIMIT_TARGET_RATIOS[1]Questo valore rappresenta il rapporto target per il gas consumato dai Blata ob d(introdotti in EIP-4844).
OtherLIMIT_TARGET_RATIOS[2] Il valore rappresenta il rapporto target per tutti gli altri tipi di gas non classificati come dati Operazione o Blob.
Il vettore LIMIT_TARGET_RATIOS viene utilizzato per calcolare il target del gas per ciascuna categoria all'interno di un blocco. Il limite di gas per il blocco viene diviso per ciascun elemento nel vettore, risultando in tre target di gas indipendenti. Ad esempio, dato un limite di gas di 300.000.000 e un vettore LIMIT_TARGET_RATIOS di [2, 2, 4], gli obiettivi di gas sarebbero:
Questo design garantisce che ciascuna classe di gas abbia una porzione designata del limite di gas del blocco, impedendo che ogni singola classe domini il consumo di gas. Promuove un meccanismo di allocazione del gas più equo tra vari tipi di transazioni.
La logica di gas_limits è la seguente: gas_limits[0] deve seguire la formula di regolazione esistente gas_limits[1] deve essere uguale a MAX_BLOB_GAS_PER_BLOCK
gas_limits[2] deve essere uguale a gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO
Sappiamo che l'attuale gas_limits [0] è 30000000 e CALLDATA_GAS_LIMIT_RATIO è preimpostato su 4, il che significa che l'attuale target gas calldata è circa 300000000 // 4 // 4 = 1875000 e perché secondo l'attuale logica di calcolo del gas calldata , ogni byte diverso da zero consuma 16 Gas e zero byte consuma 4 Gas.
Se la distribuzione di byte zero e non-zero in un determinato segmento di calldata rappresenta ciascuno il 50%, l'elaborazione media di 1 byte di calldata consuma 10 gas.
Pertanto, l’attuale obiettivo di gas dei calldata dovrebbe far fronte a 187.500 byte di dati di calldata, ovvero circa il doppio dell’attuale utilizzo medio. Il vantaggio di ciò è che riduce notevolmente la probabilità che gli stessi raggiungano il limite del gas, mantiene l'utilizzo in uno stato più coerente attraverso il modello economico ed elimina anche l'abuso dei calldata. Il motivo di questo progetto è aprire la strada allo sviluppo di L2 e, con i BLOB data, il costo del sequencer è ulteriormente ridotto.
Il panorama in evoluzione di Ethereum: abbracciare i Layer2 per scalabilità e sostenibilità
Poiché la popolarità e l'utilizzo di Ethereum continuano a crescere, la necessità di scalabilità e transazioni economicamente vantaggiose rimane fondamentale. Le soluzioni Layer 2 sono emerse come un approccio promettente per affrontare queste sfide, offrendo miglioramenti significativi nel throughput delle transazioni e commissioni ridotte rispetto alla chain principale di Ethereum.
L'EIP-1559, un aggiornamento significativo introdotto nel 2021, ha introdotto un meccanismo di burn delle commissioni volto a trasformare Ethereum verso un modello deflazionistico. Tuttavia, la maggiore adozione dei L2 ha rappresentato una sfida unica. Poiché una parte sostanziale delle transazioni avviene ora su L2, il meccanismo di burn del gas non è pienamente realizzato sulla chain principale, ostacolando potenzialmente i suoi obiettivi deflazionistici.
EIP-4844, introdotto nel 2024, vuole risolvere questo problema introducendo transazioni Blob e un nuovo meccanismo di gas appositamente progettato per i dati L2. Questa proposta mira a ottimizzare l’utilizzo del gas per i dati relativi a L2, garantendo al tempo stesso che la chain principale rimanga sicura ed efficiente.
L’introduzione dell’EIP-7706 perfeziona ulteriormente il modello di consumo di gas, stabilendo obiettivi di gas indipendenti per diverse classi di gas. Questo progetto mira a impedire che una singola classe di gas domini, promuovendo un’allocazione del gas più equa e garantendo un modello di utilizzo più prevedibile.
Questi progressi evidenziano l’impegno di Ethereum nell’abbracciare L2 come componente cruciale del suo ecosistema. Dotando L2 di meccanismi di gas efficienti e ottimizzando il ruolo della chain principale, Ethereum sta aprendo la strada a una rete più scalabile, sostenibile e di facile utilizzo.
Il futuro di Ethereum: una relazione simbiotica con L2
Man mano che Ethereum avanza, è probabile che gli L2 giocheranno un ruolo sempre più importante. La chain principale potrebbe trasformarsi in un hub di coordinamento per le L2, concentrandosi su sicurezza, consenso e gestione patrimoniale. Gli L2, d’altro canto, possono gestire la maggior parte dell’elaborazione delle transazioni, fornendo la scalabilità e il rapporto costo-efficacia richiesti dagli utenti.
Questa relazione simbiotica tra la chain principale e L2 rappresenta un percorso promettente per il successo a lungo termine di Ethereum. Abbracciando L2 e innovando continuamente, Ethereum può mantenere la sua posizione di piattaforma blockchain leader affrontando al tempo stesso le sfide della scalabilità e della sostenibilità.