L'ultimo round di sviluppo del testnet di Ethereum Shapella rivela alcuni bug

I test sulla testnet Zhejiang di Ethereum prima dell'aggiornamento Shanghai-Capella hanno rivelato alcuni bug, ma nulla che influirà sulla tempistica per l'introduzione dello staking nella rete. 

Lo sviluppatore Marius VanDerWijden documentata un bug di sincronizzazione riscontrato da altri client che gli sviluppatori sono fiduciosi possa essere corretto, secondo un thread di Tim Beiko della Ethereum Foundation. Il bug non influirà sulle tempistiche stabilite per il set di aggiornamento proposto per il testnet Sepolia previsto per il 28 febbraio, ha osservato.

L'ultimo aggiornamento del ritiro del devnet ha dettagliato uno stress test composto da 600,000 validatori, 360,000 dei quali hanno eseguito gli aggiornamenti delle credenziali di ritiro al momento del fork. Si sono verificati picchi di client nella RAM e nella CPU e gli sviluppatori misureranno il numero di messaggi di aggiornamento delle credenziali persi rispetto a quelli registrati nei prossimi giorni, ha affermato Beiko.

Lo stress test ha anche rivelato un bug tra un client proof-of-stake, Prysm, e il client Besu, progettato per casi d'uso autorizzati. Per sincronizzarsi correttamente, il client Prysm si aspetta un certo numero di risposte; tuttavia, Besu impone limiti di risposta che lo portano al di sotto della soglia di sincronizzazione necessaria, ha affermato Beiko. Il team Besu sta indagando sulla questione.

Divieto senza blob

Dopo una discussione su come ottimizzare al meglio l'orientamento iniziale del cliente, gli sviluppatori alla fine deciso vietare completamente le transazioni 4844 senza blob, il che cambierebbe le ipotesi del cliente sulle transazioni e potrebbe complicare l'installazione.

Gli sviluppatori hanno anche discusso su come procedere con la deprecazione della parola chiave SELFDESTRUCT, che risolve un contratto, rimuove il bytecode del contratto dalla blockchain e reindirizza i fondi sul contatto a un indirizzo specificato.

Mentre il percorso da seguire rimane poco chiaro, ci sono tre proposte attuali sull'argomento in discussione mentre gli sviluppatori cercano di trovare "opzioni di disattivazione che non rompano le cose", ha detto Beiko.

"La sfida qui è che apre un brutto vettore di attacco: distribuisci un contratto, riempi lo spazio di archiviazione in un certo modo e quando ridistribuisci il contratto, il vecchio spazio di archiviazione è ancora lì e potrebbe essere accessibile in modi dannosi", ha detto Beiko.