EIP-7623: la proposta che riprezzerà i prezzi dei dati di chiamata per le transazioni Ethereum

Le transazioni blockchain consumano CPU, memoria, storage e altre risorse quando vengono propagate, eseguite tra nodi e archiviate. Pertanto, una corretta determinazione del prezzo delle transazioni è essenziale per prevenire l'abuso della rete e ottenere un utilizzo efficiente delle risorse.

Tuttavia, determinare il prezzo appropriato per le transazioni è stata una sfida di lunga data nella progettazione del protocollo blockchain. Vitalik Buterin, fondatore di Ethereum, tocca questo problema in un vecchio documento di ricerca :

Uno dei problemi più difficili nella progettazione del protocollo blockchain è come limitare e stabilire il prezzo dell'invio delle transazioni che vengono incluse nella catena." — Vitalik Buterin

EIP-7623 è una Ethereum Improvement Proposal (EIP) che mira a modificare il prezzo di calldata per limitare la dimensione massima del blocco. A differenza delle proposte precedenti che hanno semplicemente aumentato il costo di calldata, EIP-7623 si concentra sulla minimizzazione del suo impatto sulle transazioni quotidiane degli utenti, ottenendo al contempo un utilizzo efficiente delle risorse.

In questo articolo, spieghiamo la logica del repricing dei calldata utilizzati dalle transazioni su Ethereum Layer 1 (L1) e l'impatto sulle dimensioni dei blocchi e sulle prestazioni della rete. Stabiliamo inoltre il contesto per le modifiche proposte al meccanismo delle commissioni di transazione di Ethereum, attingendo ad anni di ricerca sul problema dell'efficiente determinazione dei prezzi delle risorse blockchain.

Cominciamo!

Preparazione del terreno: perché è così difficile stabilire il prezzo corretto delle transazioni?

La determinazione del prezzo delle transazioni blockchain è difficile perché stimare la quantità esatta di ogni risorsa che ogni transazione consuma è intrinsecamente complesso. Attualmente, in Ethereum, tutte le risorse sono rappresentate come unità unificate chiamate "gas" e "blob gas" (introdotte con EIP-4844 ).

Esistono regole predefinite che convertono il consumo di risorse di transazione in gas, e queste regole vengono aggiornate periodicamente. Esempi di queste regole includono:

• Una transazione che comporta un overhead fisso di almeno 21.000 gas, principalmente per la verifica della firma

• Consumo di gas predefinito per ogni codice operativo EVM

  
  

Inoltre, il consumo di gas per calldata è parte integrante di queste regole, il che è meno noto ma molto significativo. Il prezzo di calldata è cruciale perché influenza direttamente la dimensione massima del blocco. Inoltre, ha un impatto su tutte le transazioni che utilizzano contratti intelligenti, in particolare sul costo delle transazioni di rollup che dipendono dallo spazio calldata, piuttosto che dai blob, per la disponibilità dei dati .

Perché la dimensione del blocco è importante?

Ethereum opera in slot da 12 secondi, durante i quali tutti i nodi di convalida devono propagare blocchi e blob, eseguire e convalidare le transazioni e attestare il nuovo blocco. In particolare, l'implementazione del client Ethereum richiede che i nodi onesti ricevano e convalidino i blocchi entro i primi 4 secondi dello slot. Attestano a 4 secondi nello slot, il che significa che i blocchi che arrivano dopo 4 secondi non dovrebbero ricevere attestazioni e sono suscettibili di essere riorganizzati dal seguente proposer .

Per ridurre al minimo le visualizzazioni divise tra i nodi Ethereum, il tempo di esecuzione dei blocchi e il tempo di propagazione devono essere limitati. Ethereum limita il tempo di esecuzione dei blocchi impostando un utilizzo massimo di gas, attualmente limitato a 30 milioni con un obiettivo di 15 milioni . Ciò significa che i blocchi Ethereum utilizzeranno circa 15 milioni di gas in media, con la capacità di espandersi e consumare 30 milioni di gas in periodi di elevata attività.

Inoltre, ogni codice operativo EVM ha un costo di gas predeterminato in base al consumo di risorse. Ad esempio, il codice operativo SSTORE è più costoso di operazioni più semplici (ad esempio, l'addizione aritmetica, ADD) perché implica l'accesso e la modifica del trie di stato. Questa differenziazione dei prezzi dei codici operativi EVM, insieme al limite totale di gas, mirava a limitare il tempo di esecuzione totale.

Mentre il limite di gas di un blocco può in qualche modo limitare il tempo di esecuzione del blocco, il tempo di propagazione del blocco rimane esplicitamente non vincolato. La dimensione del blocco è un fattore importante che influenza il tempo di propagazione nelle blockchain pubbliche. Ad esempio, dimensioni di blocco maggiori aumentano il carico di rete e i requisiti di larghezza di banda; se la dimensione del blocco supera di gran lunga la larghezza di banda della maggior parte dei nodi, ci vuole più tempo perché i nodi si propaghino completamente e ricevano il blocco, aumentando il rischio di blocchi persi o riorganizzati. (Questo è il motivo per cui il protocollo Bitcoin (pre -Segwit ) aveva un limite di dimensione del blocco di 1 MB per impedire tassi di fork aumentati e garantire la sicurezza e i bassi requisiti dei nodi della blockchain.)

Attualmente Ethereum non ha un limite di dimensione del blocco esplicitamente impostato. Tuttavia, la dimensione massima teorica del blocco può essere stimata considerando il limite del gas, il costo dei dati delle chiamate, il tasso di compressione, ecc. Sebbene la dimensione attuale del blocco di Ethereum sia di circa 2,78 MB (esclusi i blob), l'attuale prezzo dei dati delle chiamate consente payload EL fino a 7,15 MB, mentre la dimensione media è molto più piccola, circa 100 KB.

Se carichi utili così grandi venissero propagati in modo coerente nell'arco di 10 minuti, potrebbero ammontare a circa 42,9 MB, ovvero dimensioni di blocco notevolmente superiori a quelle tipiche di altre reti blockchain.

Ciò potrebbe sovraccaricare la rete Ethereum e far sì che i nodi abbiano visualizzazioni diverse per un breve periodo in uno scenario di attacco DoS in cui i payload da 7,15 MB continuano a essere attivi per un po'.

In pratica, la dimensione media del blocco in Ethereum oggi è di circa 125 KB, il che indica un divario significativo rispetto alla dimensione massima del blocco. Ciò solleva un'altra preoccupazione riguardante l'inefficienza nell'utilizzo delle risorse. Ad esempio, se la rete può gestire sufficientemente blocchi da 1 MB di seguito, una grande discrepanza tra la dimensione media del blocco e 1 MB suggerisce che Ethereum ha più capacità per la funzionalità di disponibilità dei dati (DA) ma non la sta utilizzando in modo efficace.

Limitando la dimensione massima del blocco e allineando la dimensione media del blocco più vicina a questo massimo, Ethereum potrebbe ridurre i rischi di consenso, ottenendo al contempo un utilizzo più efficiente delle risorse. Ecco perché EIP-7623 si concentra sulla possibile dimensione massima del blocco, che è fortemente influenzata dal prezzo dei calldata.

Cosa sono i Calldata in Ethereum?

Calldata è un campo in una transazione solitamente utilizzato per comunicare quali funzioni chiamare e quali parametri passare. Ad esempio, se vuoi coniare un NFT, includi il metodo 'mint' e tratti specifici dell'NFT nel campo calldata. L'esempio seguente mostra la prima transazione mint di un CryptoPunk nel 2017.

Il calldata (indicato come 'dati di input' nella figura) contiene il nome della funzione getPunk , rappresentato da 0xc81d1d5b, e l'indice NFT, rappresentato da 0x00001eb0 (7856 in esadecimale). Se trasferisci solo ETH e non interagisci con alcun contratto intelligente, il campo calldata è nullo ( 0x ).

Oltre al suo scopo principale di passare parametri agli smart contract, calldata viene anche utilizzato per registrare semplici promemoria o tramite rollup che memorizzano i dati delle transazioni. In altre parole, calldata non deve sempre interagire con gli smart contract o seguire regole rigide; può contenere valori arbitrari.

Sfruttando questa flessibilità, rollup ottimistici come Optimism e Arbitrum, alcuni rollup ZK (validità), dati di transazione rollup post-compressi e stati aggiornati nel campo calldata delle loro transazioni di sequenziamento. Sebbene EIP-4844 abbia abilitato la disponibilità dei dati tramite blob anziché calldata, calldata è ancora preferito da piccoli rollup che non necessitano dei 128 KB completi di un blob per un singolo batch.

Calldata è spesso utilizzato per la funzionalità DA perché è il modo che consuma meno gas per pubblicare grandi dati sull'EVM. Ecco perché la dimensione massima del blocco è vincolata dal prezzo di calldata. Lo scenario peggiore si verifica quando un blocco è riempito con transazioni DA-purpose che utilizzano piccole quantità di gas ma grandi dimensioni di dati.

Attualmente, il costo di calldata è di 4 gas per byte zero e 16 gas per byte diverso da zero. Calldata può essere compresso utilizzando la compressione snappy ( EIP-706 ) e la dimensione della transazione non può superare i 125 KB. Il calcolo accurato della dimensione massima del blocco è complesso a causa della natura variabile dei rapporti di compressione, ma è noto che il blocco può aumentare fino a ~2,78 MB.

Se i blocchi da 2,78 MB continuano consecutivamente per determinati motivi (ad esempio, attacchi di spamming), la rete potrebbe essere sovraccarica e i nodi potrebbero avere viste divise a causa delle basse velocità di propagazione. Più nodi potrebbero attestare blocchi diversi come la catena canonica, aumentando il rischio di non raggiungere un consenso. Per evitare ciò, una soluzione semplice potrebbe essere quella di aumentare il costo di calldata, ad esempio raddoppiando il costo di calldata a 8 gas per byte zero e 32 gas per byte diverso da zero si potrebbe ridurre approssimativamente della metà la dimensione massima del blocco.

Tuttavia, questo approccio potrebbe danneggiare le normali transazioni utente. Aumentare i costi calldata solo per prevenire lo scenario peggiore potrebbe comportare una perdita maggiore del guadagno, dato che la dimensione media del blocco è attualmente di soli 125 KB e non pone preoccupazioni significative.

Qual è la motivazione dell'EIP-7623?

EIP-7623 differisce leggermente da altre proposte che aumentano semplicemente il costo calldata. Invece di un adeguamento generalizzato del prezzo di calldata, EIP-7623 si concentra sull'aumento del costo del gas specificamente per le transazioni che sembrano servire a scopi di disponibilità dei dati (DA).

Cosa significa? Se il gas utilizzato in una transazione è insufficiente rispetto alla dimensione totale dei dati caricati, viene considerata una transazione con scopo DA e addebitata in modo significativo di più per calldata. Al contrario, se una transazione consuma abbastanza gas rispetto alla dimensione dei dati, viene considerata una transazione non DA e addebitata allo stesso modo di oggi.

Si può tracciare un'utile analogia tra calldata in Ethereum e buste di plastica nel mondo reale. Quando acquistiamo prodotti o generi alimentari, spesso riceviamo buste di plastica per trasportarli, solitamente a un costo molto basso o addirittura gratis. Tuttavia, se gli individui potessero acquistare un numero illimitato di buste di plastica, ciò sarebbe dannoso per l'ambiente.

Una possibile soluzione è quella di limitare i sacchetti di plastica ai clienti che acquistano abbastanza prodotti o applicano un prezzo più alto, come $ 1 per sacchetto. Ciò è analogo all'approccio EIP-7623, che funziona come una forma di imposta pigouviana. Impone costi più elevati sulle transazioni che utilizzano una grande quantità di calldata ma gas insufficiente, promuovendo così un uso più efficiente delle risorse. Applicando costi più aggressivi a coloro che utilizzano principalmente calldata per la disponibilità dei dati piuttosto che un mix equilibrato di dati ed esecuzione, il protocollo mira a garantire un utilizzo più efficiente e sostenibile delle risorse di rete.

Perché prendere di mira le transazioni DA su Ethereum?

Non c'è nulla di intrinsecamente sbagliato nelle transazioni che utilizzano Ethereum per la disponibilità dei dati. EIP-7623 non scoraggia Ethereum dal funzionare come un livello di disponibilità dei dati; piuttosto, scoraggia l'uso di calldata allo scopo di archiviare i dati delle transazioni e incoraggia indirettamente l'uso di blob per DA. Questa proposta mira a separare il livello di esecuzione dal livello di disponibilità dei dati, consentendo a ciascun livello di gestire in modo efficiente la domanda e prevedere meglio i casi estremi.

In questo modo, EIP-7623 cerca di migliorare l'efficienza e la prevedibilità della gestione delle risorse di Ethereum, limitando al contempo la superficie DoS. Questa separazione garantisce che ogni livello possa gestire le sue funzioni specifiche in modo più efficace, contribuendo in ultima analisi a una rete Ethereum più solida e scalabile.

Una panoramica delle specifiche EIP-7623

Il calcolo attuale del gas di una transazione è il seguente:

Il 21,000 nella specifica di cui sopra è il gas minimo addebitato per qualsiasi transazione. Inoltre, STANDARD_TOKEN_COST tokens_in_calldata rappresenta il gas utilizzato per calldata, che EIP-7623 cerca principalmente di risolvere. Qui, tokens_in_calldata è una semplice combinazione ponderata di byte zero e diversi da zero, che viene calcolata da tokens_in_calldata = zero_bytes_in_calldata + 4 * nonzero_bytes_in_calldata .

STANDARD_TOKEN_COST è attualmente impostato su 4, quindi il costo del gas di zero_bytes_in_calldata è 4 e nonzero_bytes_in_calldata è 16.

evm_gas_used è il gas utilizzato per l'esecuzione di una transazione, che copre principalmente le interazioni con gli smart contract. Le transazioni non DA hanno in genere un componente evm_gas_used di grandi dimensioni.

Quando una transazione crea un nuovo contratto, il termine isContractCreation diventa 1, ovvero comporta un costo aggiuntivo per la creazione e l'archiviazione del nuovo contratto. Poiché la creazione del contratto non è il focus qui, imposteremo questo termine su zero.

EIP-7623 propone la seguente modifica al calcolo del gas totale:

Nel nuovo calcolo, max(blue box, red box) confronta il gas calcolato dal metodo corrente(blue box), con TOTAL_COST_FLOOR_PER_TOKEN calldata (red box). Il blue box è esattamente lo stesso del metodo di calcolo del gas corrente. Il red box, che è nuovo in EIP-7623, rappresenta il valore che giudica se una transazione è per scopi DA. A partire dal 1° gennaio 2025, si propone che TOTAL_COST_FLOOR_PER_TOKEN sia 10, che è molto più alto di STANDARD_TOKEN_COST di 4.

In altre parole, se una transazione non spende abbastanza evm_gas_used , il box rosso avrà probabilmente un valore più alto del valore del box blu, contrassegnandolo come una transazione DA-purpose. Di conseguenza, la transazione verrà addebitata alla tariffa TOTAL_COST_FLOOR_PER_TOKEN , pagando effettivamente poco meno di 3 volte di più per calldata. Al contrario, la maggior parte delle transazioni di uso generale spende abbastanza evm_gas_used , quindi max(blue box, red box) sarà impostato di default sul valore del box blu, mantenendo il metodo di costo del gas corrente.

Quali tipi di transazioni sono interessate da EIP-7623?

Per determinare quali transazioni sono interessate da EIP-7623, dobbiamo identificare la condizione in cui la casella rossa (nuovo calcolo del gas) è più alta della casella blu (calcolo del gas corrente).

Ignorando il termine di creazione del contratto e sostituendo i valori nei parametri, ricaviamo la seguente condizione: le transazioni comporteranno un costo del gas più elevato se il gas consumato per l'esecuzione EVM è inferiore a 6 volte i token in calldata.

Per rendere il tutto più intuitivo, dividiamo entrambi i lati per 4 tokens_in_calldata . Ricordiamo che 6 tokens_in_calldata è il gas pagato per calldata in una transazione.

Questa equazione finale indica che se il gas utilizzato per l'esecuzione dell'EVM è inferiore al doppio del gas utilizzato per calldata, la transazione comporterà commissioni più elevate per calldata.

Quanto aumenteranno i costi delle chiamate dati dopo l'EIP-7623?

Supponiamo che il gas minimo per una transazione sia 21.000, il gas utilizzato per l'esecuzione EVM sia k e il gas utilizzato per calldata sia kx. Il costo totale della transazione può quindi essere espresso come:

Con il calcolo attuale (senza EIP-7623), il costo sarebbe di 21.000+k+kx. Pertanto, il tasso di incremento con EIP-7623 sarebbe:

Il tasso di incremento in funzione di k è rappresentato graficamente di seguito:

Per comprenderne l'impatto pratico, esaminiamo le statistiche sul consumo di gas per i metodi di funzionamento più comuni, concentrandoci su quelli noti alla maggior parte degli utenti.

Tra le varie funzioni di swap negli exchange decentralizzati, swap(string, address, uint256, bytes) è la più utilizzata.

In media, utilizza 5.152 per calldata e 175.742 per EVM , e questo rappresenta un valore 34 volte maggiore. La funzione transfer(address, uint256) , utilizzata per trasferire token ERC20, consuma circa 24.501 gas per l'esecuzione di EVM, circa 40 volte in più rispetto ai 620 gas utilizzati per calldata.

Similmente a queste funzioni, la maggior parte delle transazioni quotidiane degli utenti presenta una differenza significativa tra il gas utilizzato per calldata e l'esecuzione EVM, il che significa che è improbabile che siano influenzate da EIP-7623.

L'analisi fornita dal ricercatore di Ethereum Toni Wahrstätter mostra che se si applica EIP-7623, il 3,02% delle recenti transazioni Ethereum verrebbe influenzato. La sua analisi identifica anche quali metodi di funzione saranno influenzati e stima l'aumento dei costi per tali metodi. Un'ulteriore analisi fornita da Wahrstätter mostra che per le recenti transazioni su Ethereum, il 3,02% delle transazioni viene influenzato se si applica EIP-7623.

Il suo sito mostra anche quali metodi di funzione saranno effettivamente interessati e quanto aumenterebbe il prezzo di tali metodi.

Tra le funzioni interessate da EIP-7623, la più frequentemente utilizzata è addSequencerL2BatchFromOrigin() , comunemente impiegata per il sequenziamento delle transazioni rollup su Ethereum. Un altro metodo interessato è commitBatches() , frequentemente utilizzato nelle transazioni rollup. Si prevede che queste due funzioni vedranno gli aumenti di costo più significativi, con un aumento stimato del 150% nei costi totali del gas quando si utilizzano questi metodi.

Tuttavia, i rollup possono utilizzare i blob per la pubblicazione dei dati e molti rollup, come Arbitrum One e Base, lo stanno già facendo . Di conseguenza, è improbabile che i rollup che utilizzano i blob per la pubblicazione dei dati siano pesantemente influenzati dai costi aumentati imposti da EIP-7623.

Analisi dell'impatto di EIP-7623 sulle dimensioni dei blocchi

EIP-7623 aumenta il costo del gas per le transazioni che utilizzano grandi quantità di calldata. Ciò significa che gli attacchi di spamming, che si basano in gran parte su calldata, richiederebbero circa tre volte più costi del gas, riducendo di fatto la dimensione massima del blocco da 2,54 MB a circa 0,72 MB. Di conseguenza, la rete Ethereum sarebbe meglio equipaggiata per gestire gli scenari peggiori in cui grandi blocchi vengono propagati continuamente.

La riduzione della dimensione massima possibile del blocco crea un'opportunità per aumentare il numero di blob inclusi per blocco. Attualmente, il numero massimo di blob è 6, ciascuno di 128 KiB di dimensione. Se si adotta EIP-7623 e si mantiene la stessa dimensione massima del blocco, potrebbe essere possibile aumentare il numero massimo di blob a circa 18, il che significa un aumento di 3 volte nel massimo TPS (transazioni al secondo) dei rollup.

Questo calcolo comporta una certa semplificazione eccessiva, poiché i metodi di propagazione per blob e blocchi differiscono. Tuttavia, il vantaggio principale è la maggiore separazione tra i livelli di esecuzione e disponibilità dei dati. Poiché blob gas ed execution gas hanno mercati di commissioni separati, le perturbazioni in un mercato non avranno un impatto diretto sull'altro.

Questa separazione semplifica il raggiungimento dell'efficienza del capitale perché diventa più facile controllare le risorse target e massime che la rete Ethereum può gestire all'interno di un singolo blocco.

Quali sono le altre considerazioni relative all'implementazione di EIP-7623?

Sebbene EIP-7623 offra vantaggi significativi, potrebbe potenzialmente avere un impatto sui piccoli rollup rendendo necessario l'uso di blob anziché calldata. Per i rollup a bassa richiesta, le grandi dimensioni del blob di 128 KiB potrebbero richiedere loro di attendere più a lungo prima di poter riempire l'intero blob. Questa situazione aumenta la necessità di protocolli di condivisione dei blob , consentendo a più rollup di condividere l'ampio spazio del blob per una migliore efficienza dei costi.

Sebbene la tariffa base dei blob sia attualmente molto bassa (rendendo i blob uno spazio DA poco costoso), un improvviso aumento della domanda potrebbe gravare in modo significativo su questi rollup. Senza un aumento simultaneo del numero di blob per blocco, EIP-7623 potrebbe rendere i rollup che inviano transazioni DA più competitivi, poiché la capacità totale per DA sta diminuendo complessivamente. È necessario valutare se il numero di blob debba essere aumentato simultaneamente per accogliere questo cambiamento.

Un'altra considerazione è decidere i criteri per la soglia in cui le transazioni dovrebbero essere interessate da questo aggiornamento. Ci sono compromessi tra dimensione del blocco ed esperienza utente. Ad esempio, impostare la soglia in modo troppo aggressivo potrebbe ridurre notevolmente la dimensione massima del blocco, ma molte transazioni potrebbero dover pagare più gas per calldata.

Sebbene il cambiamento nella dimensione massima del blocco sia esplicito e vivido, è difficile stimare e quantificare quanto Ethereum sarebbe influenzato dalla richiesta di costi del gas più elevati per le transazioni DA-purpose. Questa soglia può essere impostata solo socialmente.

Inoltre, i criteri dipendono fortemente da altri parametri impostati dalle operazioni EVM o dal limite di gas. Ad esempio, se Ethereum dovesse aumentare il limite di gas del blocco a 300 milioni in futuro, anche la soglia di EIP-7623 dovrebbe essere modificata per mantenere la dimensione massima del blocco.

Conclusione

EIP-7623 è una proposta di miglioramento di Ethereum che mira a ridurre la dimensione massima del blocco regolando il costo calldata, mirando specificamente alle transazioni DA-purpose. Questa regolazione potrebbe potenzialmente aumentare il costo per le transazioni DA non-blob fino al 300%, mentre la maggior parte delle transazioni utente quotidiane rimangono inalterate.

In questo post abbiamo esplorato la motivazione alla base della proposta, le sue implicazioni, i tipi di transazioni interessate e le potenziali preoccupazioni che potrebbero sorgere. Spero che questo scritto ti aiuti a capire di più su questa recente proposta e fornisca approfondimenti dettagliati sui suoi contenuti. Se sei interessato e vuoi saperne di più, puoi dare seguito all'analisi e alla spiegazione di Toni Wahrstätter e partecipare alla discussione aperta sul forum Ethereum Magicians.