Il prossimo aggiornamento di Ethereum conterrà uno degli aggiornamenti più attesi dalla community: la possibilità di ritirare gli ETH bloccati nella Beacon Chain.
Durante il loro incontro settimanale, gli sviluppatori della Ethereum Foundation hanno raggiunto un consenso 8 proposte per migliorare Ethereum (EIP), che verrà implementato nel prossimo importante aggiornamento, chiamato Shanghai.
Queste proposte dovrebbero essere incluse nel Il prossimo hard fork di Ethereum che dovrebbe avvenire nel 2023, possibilmente durante il secondo trimestre dell’anno.
Shanghai è da allora un aggiornamento molto atteso dalla comunità Ethereum implementerà la possibilità di ritirare gli ETH bloccati nella Beacon Chain. Ciò significa che gli utenti che hanno bloccato i propri token per partecipare alla convalida potranno recuperare i propri fondi e puntare i premi.
Fino al lancio del hard fork, gli sviluppatori potranno testare applicazioni e come funzionano gli EIP implementato in Shandong, il testnet di Ethereum, lanciato a ottobre.
Sai quali sono le proposte di miglioramento di Ethereum?
Scopri tutto su queste proposte degli sviluppatori per migliorare il funzionamento e le prestazioni di Ethereum e come vengono implementate sulla rete.
Le 8 proposte per il futuro di Ethereum
EIP-3540: formato oggetto EVM
EIP-3540 introduce un formato di contenitore estensibile e versionato per l'EVM con una convalida una tantum al momento della distribuzione.
Questa versione consente di separare codice e dati, rendendo più semplice l'implementazione delle modifiche e il miglioramento della macchina virtuale Ethereum in futuro.
EIP- 3651: Coinbase caldo
Questa proposta Ha lo scopo di "riscaldare" l'indirizzo Coinbase all'inizio di ogni esecuzione di transazione, in base al costo effettivo di lettura del conto.
In questo modo è inteso ridurre i prezzi di questo tipo di transazioni, poiché questi indirizzi sono inizialmente freddi nella lista di accesso inserita nell'EIP-2929, il che provoca un certo squilibrio nel costo del gas.
EIP-3670: contratti EOF con codice di convalida
EIP-3670 Inserisci il convalida del codice al momento della creazione del contratto per i contratti in formato EOF. Rifiuterà inoltre i contratti che contengono dati PUSH troncati o istruzioni non definite. Questa modifica non influirà sul bytecode legacy, ovvero sul codice grezzo EOF.
I contratti attuali non richiedono la convalida della correttezza, quindi le implementazioni EVM possono decidere come gestire il bytecode con istruzioni non definite. Questo EIP mira a portare al consenso la validità del codice, per rendere più semplice la gestione e il ragionamento sul bytecode. Allo stesso tempo, vengono ridotti i percorsi attraverso i quali EVM decide quale istruzione è valida in ciascuna esecuzione.
EIP-3855: Istruzioni PUSH0
Viene introdotta un'istruzione PUSH0 (0x5f) che inserisce il valore costante 0 nello stack.
Questo PEI viene introdotto per ridurre il costo del gas di tutte quelle istruzioni che cercano di impilare o spingere un valore zero. In questo momento, a causa del tipo di codifica, si genera un costo elevato del gas, poiché esegue due operazioni, il che comporta l'utilizzo di operazioni complesse, il cui valore può dipendere dal contesto e causare errori.
EIP-3860: codice limiti e contatori
EIP-3860 cerca di estendere EIP-170 introducendo un limite di dimensione massima per l'initcode.
Allo stesso tempo, a 2 cariche di gas per porzione di 32 byte di initcode per rappresentare il costo dell'analisi del salto. Infine, il limite di dimensione dà origine a una nuova proprietà: la dimensione dell'EVM, l'offset del codice e l'offset del salto sono impostati su un valore a 16 bit.
EIP-4895: La Beacon Chain consente i prelievi nell'EVM
Questa è una delle funzionalità più attese. Con esso, viene introdotta un'operazione a livello di sistema per supportare il prelievi dal validatore che “spingono” dalla Beacon Chain all’EVM.
Queste operazioni creano aumenti di saldo incondizionati per destinatari specifici. Fondamentalmente lo consente i prelievi dai validatori Beacon Chain entrano nell'EVM.
EIP-4758: Disabilita SELFDESTRUCT
Questo PEI rinomina il codice SELFDESTRUCT in SENDALL, sostituendone la funzionalità. In questo modo, SENDALL servirà a invia tutto l'Ether in un account all'utente chiamante.
SELFDESTRUCT richiede grandi modifiche allo stato dell'account poiché rimuove tutto il codice e lo spazio di archiviazione. Con l'implementazione del Alberi verkle questo non sarà possibile in quanto ogni account sarà memorizzato in molte chiavi diverse che non saranno collegate all'account root.
Altre proposte approvate per essere implementate a Shanghai
Oltre alle proposte sopra descritte, le successive hard fork implementerà anche il EIP-4844, focalizzato sullo sfruttamento di tutto il potenziale di sharding.
Per fare ciò, implementerà il primo sistema di proto-dankharding e si prevede che aumenterà le prestazioni della rete, riducendo al contempo i tassi di transazione e migliorando la scalabilità.
[hubspot type=cta portal=20298209 id=38fb28e1-1dc1-40e3-9098-5704ca7fcb07]
