Quali EIP sono stati confermati per l’aggiornamento Pectra? L’aggiornamento potrebbe aumentare l’inflazione di ETH?

Gli EIP già confermati miglioreranno la programmabilità degli account, l'efficienza della validazione di Ethereum e l'ottimizzazione dello staking, mentre gli EIP non ancora confermati si concentrano su come migliorare la scalabilità di L2.

Autore: 0XNATALIE

Il prossimo aggiornamento di Ethereum, Pectra, prende il nome dalla combinazione di Prague ed Electra.

Prague rappresenta l'aggiornamento del livello di esecuzione, prendendo il nome dalla città che ha ospitato la conferenza degli sviluppatori di Ethereum (Devcon 4), Praga, mentre Electra simboleggia l'aggiornamento del livello di consenso, seguendo l'ordine alfabetico delle stelle. Il nome della stella scelta questa volta, Electra, corrisponde alla lettera "E".

L'aggiornamento Pectra potrebbe essere l'hard fork nella storia di Ethereum che coinvolge il maggior numero di Ethereum Improvement Proposals (EIP), includendo una serie di proposte per migliorare le operazioni dei validatori e le prestazioni della mainnet, oltre a introdurre proposte per ottimizzare L2. La testnet Pectra Devnet 4 è appena stata lanciata e attualmente sono già stati confermati 8 EIP che saranno inclusi nell'aggiornamento Pectra.

EIP confermati e i loro impatti

Questi 8 EIP avranno i seguenti impatti sugli utenti: aggiungendo la capacità di eseguire codice agli EOA, aumentano la flessibilità degli account, consentendo loro di eseguire operazioni più complesse; l'aumento del limite di staking potrebbe incrementare la domanda di ETH; inoltre, l'ottimizzazione dei processi dei validatori migliora la sicurezza e l'efficienza, aumentando la velocità e la capacità di throughput di Ethereum.

1. EIP-2537 (supporto per firme BLS): Introducendo una serie di contratti precompilati (precompiles), aggiunge il supporto per le operazioni sulla curva BLS12-381 in Ethereum, consentendo la verifica delle firme BLS e permettendo l'aggregazione di più firme in una sola, riducendo così la complessità della verifica. Le firme BLS sono un algoritmo crittografico che può generare firme più piccole e supportare l'aggregazione delle firme. Questo sarà utile per L2 che necessitano di numerose operazioni di verifica delle firme e dei dati.
2. EIP-2935 (salvataggio degli hash dei blocchi storici nello stato): Memorizza gli hash degli ultimi 8192 blocchi in un contratto di sistema, supportando il modello Stateless Clients e fornendo una funzione di query più flessibile per gli hash dei blocchi storici. Questi hash possono essere interrogati direttamente tramite contratto e forniti come prove (witness) ai client senza stato. I client non hanno bisogno di mantenere l'intera storia della blockchain o di archiviare grandi quantità di dati, ma possono verificare la validità di blocchi e transazioni affidandosi agli hash dei blocchi e alle relative prove memorizzate nello stato.
3. EIP-6110 (depositi dei validatori on-chain): Sposta la gestione dei depositi dei validatori dal livello di consenso al livello di esecuzione, gestendo e verificando i depositi on-chain, senza più dipendere da meccanismi di voto aggiuntivi nel livello di consenso per confermare la validità delle informazioni sui depositi. Migliora la sicurezza del processo di deposito, riduce i ritardi di elaborazione e semplifica il design del livello di consenso e dei client.
4. EIP-7002 (uscita attivabile dal livello di esecuzione): Consente ai titolari dei certificati di prelievo di avviare autonomamente l'uscita, senza dover dipendere dalla chiave attiva del validatore (chiave BLS), aumentando l'autonomia degli utenti. Attualmente, solo la chiave attiva del validatore può attivare l'uscita, il che significa che se la chiave attiva viene persa o il validatore delega le attività di validazione a terzi (come i fornitori di servizi di staking), il titolare del certificato di prelievo (cioè il reale proprietario dei fondi) non può controllare autonomamente l'ETH in staking. Questa proposta consente di attivare l'uscita e il prelievo di ETH tramite il livello di esecuzione, permettendo ai titolari dei certificati di prelievo di avviare l'uscita senza dipendere dalla chiave attiva.
5. EIP-7251 (aumento del limite di staking): Aumenta il saldo massimo effettivo per i validatori, consentendo a ciascun validatore di detenere più di 32 ETH in staking, mentre la soglia minima di staking rimane a 32 ETH. Mira a consentire agli operatori di grandi nodi di ridurre il numero di validatori nella rete aggregando più validatori, riducendo così il carico di messaggi P2P, l'aggregazione delle firme e l'onere di archiviazione.
6. EIP-7549 (spostamento dell'indice del comitato fuori dalla prova): Spostando il campo dell'indice del comitato fuori dal messaggio di Attestation (prova), consente un'aggregazione più efficiente dei voti di consenso. Attualmente, nel meccanismo di consenso di Ethereum, ogni validatore vota includendo: voto LMD GHOST (che include la radice del blocco votato e lo slot), voto Casper-FFG (che include informazioni sulla fonte e sulla destinazione), indice del comitato (numero del comitato a cui appartiene il validatore). Poiché l'indice del comitato è incluso nel messaggio firmato, quando più validatori votano per lo stesso blocco, anche se il contenuto del voto è identico, la radice della firma generata è diversa, rendendo difficile l'aggregazione dei voti. Spostando il campo dell'indice del comitato fuori dal messaggio firmato, si ottiene un'aggregazione dei voti più efficiente, riducendo i costi di verifica e il carico di rete.
7. EIP-7685 (richieste generiche del livello di esecuzione): Definisce un framework generico per il livello di esecuzione (EL) per archiviare e gestire le richieste attivate dagli smart contract. Questo framework supporta più comportamenti attivati dal livello di esecuzione e consente di gestire in modo uniforme diversi tipi di richieste, semplificando il processo di aggiunta di nuovi tipi di richieste senza modificare la struttura dei blocchi di esecuzione.
8. EIP-7702 (aggiunta della capacità di esecuzione del codice agli EOA): Aggiunge la capacità di eseguire codice agli account esterni (EOA), aumentando così la flessibilità e la programmabilità degli account. Gli EOA possono, tramite firma autorizzata, specificare uno smart contract per delegare l'esecuzione di determinate operazioni, come transazioni in batch o controllo dei permessi. Questo consente di avere alcune funzionalità degli smart contract senza dover convertire l'account in uno smart contract.

EIP in fase di valutazione prioritaria

Di seguito alcuni EIP attivamente considerati, che principalmente ottimizzano i blob, migliorano la stabilità delle commissioni di pubblicazione dei dati su L2, aumentano la capacità di elaborazione delle transazioni di L2 e riducono efficacemente i costi di L2. Inoltre, l'aumento del costo del calldata potrebbe influenzare la quantità di ETH bruciato, aumentando la pressione inflazionistica su ETH.

• EIP-7742 (rimozione della dipendenza dal conteggio dei blob tra livello di consenso e livello di esecuzione): Disaccoppia il numero di blob tra il livello di consenso e il livello di esecuzione, semplificando il processo di verifica dei blob, riducendo la complessità non necessaria e migliorando la scalabilità e la flessibilità del protocollo. Nell'attuale protocollo, sia il livello di esecuzione che quello di consenso hanno codificato il valore massimo dei blob, portando a verifiche ridondanti. Questa proposta elimina la verifica del valore massimo dei blob dal livello di esecuzione, facendo sì che il livello di consenso fornisca dinamicamente il valore target dei blob al livello di esecuzione. In questo modo, è possibile regolare in modo più flessibile i parametri target dei blob per soddisfare le esigenze di scalabilità future. L'EIP-7742 è la proposta meno controversa tra quelle in fase di valutazione per l'inclusione nell'aggiornamento; secondo l'ultima riunione del livello di consenso, gli sviluppatori hanno concordato di iniziare l'implementazione di EIP-7742 in pectra-devnet 5, ma la sua inclusione ufficiale dipenderà dal feedback del livello di esecuzione durante la riunione ACDE (All Core Developers Execution Layer Meeting).
• EIP 7762 (commissione minima di base per blob): Aumenta il MIN_BASE_FEE_PER_BLOB_GAS, con l'obiettivo di ridurre il tempo necessario affinché il prezzo dei blob si adegui a un livello ragionevole. Attualmente, la commissione minima di base per i blob è impostata a 1 wei; quando la domanda di blob supera l'offerta, il processo di scoperta del prezzo (cioè la determinazione di un prezzo ragionevole per il blob gas) è troppo lento e richiede molto tempo per raggiungere un livello di commissione adeguato. Aumentando la commissione minima di base per i blob, si può ridurre il tempo di adeguamento dei prezzi, raggiungendo più rapidamente l'equilibrio di mercato e garantendo la stabilità della rete anche nei periodi di alta domanda.
• EIP-7623 (aumento del costo del calldata): Aumenta il costo del calldata nelle transazioni per ridurre la dimensione massima dei blocchi e la sua variabilità, garantendo che la rete possa gestire le transazioni in modo più stabile. Attualmente, la dimensione massima dei blocchi è di circa 1,79 MB, ma a causa della pubblicazione di grandi quantità di dati da parte di applicazioni come i rollup, la dimensione media dei blocchi continua ad aumentare. Aumentando il costo del calldata, utilizzato principalmente per le transazioni di Data Availability (DA), la dimensione massima dei blocchi si riduce a circa 0,72 MB, lasciando spazio per futuri aumenti del gas limit dei blocchi o per più blob. Il costo delle transazioni per gli utenti comuni rimane invariato; questa modifica riguarda principalmente le tipologie di transazioni che fanno affidamento su Ethereum per l'archiviazione di grandi quantità di dati. Tuttavia, l'aumento del costo del calldata potrebbe ridurre la competitività di Ethereum nell'ambito dello storage dei dati. Inoltre, con l'aumento del costo del calldata, il numero di transazioni potrebbe diminuire, portando a una riduzione dell'ETH bruciato tramite il meccanismo EIP-1559, aumentando così la pressione inflazionistica su ETH.
• EIP 7782 (riduzione del tempo di slot): Riduce il tempo di slot di Ethereum da 12 secondi a 8 secondi, generando blocchi più frequentemente per gestire un maggior numero di transazioni, come alternativa all'aumento del numero di blob per incrementare il throughput delle transazioni. Tuttavia, potrebbe compromettere alcuni smart contract che hanno codificato il tempo di slot a 12 secondi e accelerare il problema della crescita dello stato di Ethereum, aumentando il carico di archiviazione e calcolo.
• EIP-7783 (aumento graduale del gas limit dei blocchi): Come alternativa più moderata all'EIP-7782, regola dinamicamente il gas limit dei blocchi, aumentando gradualmente il numero di transazioni che ogni blocco può contenere, migliorando così la capacità di elaborazione della rete. Rispetto alla semplice riduzione del tempo di slot, l'aumento graduale del gas limit consente un'espansione della rete più stabile. Questa proposta non richiede un hard fork, ma potrebbe avere un impatto sui dati di stato.

Poiché l'aggiornamento Pectra include un gran numero di EIP, per ridurre la complessità di ogni singolo aggiornamento e accelerare il rilascio di alcuni EIP, a maggio il team di ingegneri della Ethereum Foundation, EthPandaOps, ha suggerito di suddividere Pectra in due parti, ma all'epoca si temeva che ciò avrebbe ritardato l'aggiornamento e la proposta non è stata presa seriamente in considerazione. A settembre, il ricercatore di Ethereum Alex Stokes ha riproposto la suddivisione, ottenendo questa volta il consenso degli sviluppatori; questa suddivisione aiuta a completare la prima parte dell'aggiornamento entro sei mesi:

• Prima parte: include gli EIP già in esecuzione sulla testnet Pectra Devnet (cioè gli 8 EIP già confermati), che sono relativamente più facili da implementare e hanno già superato numerosi test.
• Seconda parte: include gli EIP più complessi (come PeerDAS, proposte relative a EOF) e altre proposte che richiedono più tempo per lo sviluppo, l'audit e i test, in particolare quelle che coinvolgono il coordinamento tra livello di consenso e livello di esecuzione.