La chiamata ACDE di Ethereum 205: principali aggiornamenti di Ethereum in arrivo il 24 febbraio, 5 marzo e 8 aprile
- L'aggiornamento Pectra di Ethereum è previsto per il 24 febbraio sulla testnet Holesky, con un rollout sulla mainnet previsto per l'8 aprile 2025.
- Sono state discusse le divergenze sulla tempistica dell'aggiornamento Fusaka e sull'inclusione di EIP EOF, con gli sviluppatori di Geth che chiedono maggiore flessibilità.
- Sono state sollevate preoccupazioni riguardo ai test obbligatori EELS ed EEST per le EIP, con alcuni sviluppatori che temono ritardi nel processo di aggiornamento.
Gli sviluppatori di Ethereum hanno finalizzato il calendario per i prossimi aggiornamenti della rete. Grandi cambiamenti sono previsti per il 24 febbraio, 5 marzo e 8 aprile. Le decisioni chiave sono state finalizzate durante la recente chiamata All Core Developers Execution (ACDE) 205, tenuta il 13 febbraio 2025.
L'incontro settimanale su Zoom discussioni è stato guidato dal Protocol Support Lead di Ethereum Foundation (EF) Tim Beiko. Gli sviluppatori hanno confermato che l'aggiornamento Pectra sarebbe stato attivato sulla testnet Holesky il 24 febbraio. Successivamente, la testnet Sepolia verrebbe attivata il 5 marzo.
Se entrambi i rollout procedono senza intoppi, la mainnet di Ethereum riceverà l'aggiornamento intorno all'8 aprile.
Beiko ha detto che avrebbe coordinato con i team per trovare un volontario per il deployment dei contratti di sistema Pectra su entrambe le testnet.
Dibattiti sui futuri fork di Ethereum e sulla velocità degli aggiornamenti
Inoltre, il team di sviluppatori ha discusso del prossimo aggiornamento pianificato dopo Pectra e Fusaka. Beiko proposto congelando l'ambito di Fusaka per il momento del lancio di Pectra sulla mainnet.
La tempistica permette agli sviluppatori di iniziare il lavoro su Fusaka mentre pianificano anche il successivo hardfork Glamsterdam.
Il team di sviluppo Geth non vuole lavorare con questa tempistica. Sostengono che sia stato prematuro cementare l'ambito di Fusaka. L'inclusione dell'Ethereum Improvement Proposal (EIP) EOF in Fusaka ha scatenato un notevole dibattito. Una fazione di sviluppatori sostiene la sua esclusione dall'aggiornamento in arrivo.
EOF (Ethereum Object Format) è un revisione al rialzo progetto volto a migliorare il modo in cui gli smart contract sono strutturati ed eseguiti sulla blockchain di Ethereum.
Lo sviluppatore Geth Lightclient si è opposto all'accelerazione del congelamento dell'ambito di Fusaka. Lo sviluppatore sostiene che le priorità di Ethereum potrebbero cambiare nei prossimi due anni. Ha sottolineato che, mentre gli sviluppatori mirano a cicli di aggiornamento di sei mesi, i ritardi nel mondo reale potrebbero estenderli a otto mesi o più. Questo significa che importanti miglioramenti potrebbero non essere implementati per anni.
Lightclient ha sollevato preoccupazioni riguardo all'incorporazione di EOF, evidenziando il rapido progresso della tecnologia di rollup zero-knowledge di Ethereum (zkEVMs). Gli sviluppatori rimangono all'oscuro riguardo all'interazione di questi cambiamenti con la macchina virtuale.
Durante la discussione, lo sviluppatore Geth Marius van der Wijden ha elencato il suo ambito preferito per Fusaka, che includeva PeerDAS, FOCIL, EOF e limiti superiori per modexp. L'Ingegnere Operativo EF Parithosh Jayanthi ha obiettato, affermando che FOCIL non era pronto per l'implementazione quanto PeerDAS e EOF.
Aggiornamenti della testnet software Pectra e feedback della comunità
Gli sviluppatori hanno superato i loro disaccordi su Fusaka per esprimere fiducia nel deployment di Pectra. L'Ingegnere Sviluppo e Operazioni EF Parithosh Jayanthi ha riferito che Pectra Devnet 6 stava funzionando bene, con tassi di partecipazione dei validatori quasi perfetti.
Inoltre, la testnet Ephemery di Ethereum ha attivato l'aggiornamento Pectra poche ore dopo la chiamata ACDE, permettendo agli sviluppatori di condurre ulteriori test.
Beiko ha chiesto agli autori delle EIP di Pectra di spostare le loro proposte nella fase di "ultima chiamata" su GitHub. Questo segnala gli ultimi passi prima dell'implementazione sulla mainnet. Ha anche esaminato il feedback dalla comunità Ethereum. A tal fine, ha notato che la richiesta più comune era accelerare i cicli di aggiornamento.
In risposta, ha suggerito che gli sviluppatori di Ethereum dovrebbero mirare a finalizzare l'ambito di ogni aggiornamento non appena il precedente va in live sulla mainnet.
La proposta di Beiko per la tempistica di finalizzazione dell'ambito di Fusaka stabilisce che, entro il 13 marzo, gli sviluppatori devono proporre EIP da includere nell'aggiornamento. Due settimane dopo, il 27 marzo, i team client condivideranno le loro preferenze su quali EIP dovrebbero essere considerate per Fusaka. Infine, entro il 10 aprile, l'ambito dell'aggiornamento sarà finalizzato.
Tuttavia, il Ricercatore EF Ansgar Dietrichs ha aggiunto un'eccezione alla tempistica. Ha notato che i miglioramenti del codice PeerDAS, un componente critico dell'aggiornamento Pectra, dovrebbero essere caricati sulla mainnet di Ethereum non appena completati. Nessuno ha obiettato a questo requisito.
Preoccupazioni per gli standard di test EELS e EIP
Un altro punto di preoccupazione durante la chiamata ACDE è stata una proposta dall'Ingegnere di Test EF Mario Vega. Questo riguardava il framework di testing del layer di esecuzione di Ethereum. Vega ha suggerito di rendere EELS (Ethereum Execution Layer Specifications) ed EEST (Ethereum Execution Specification Test cases) obbligatori per qualsiasi EIP inclusa in un hard fork.
Ha suggerito che questo migliorerebbe il flusso di lavoro di testing e standardizzerebbe il modo in cui le EIP vengono valutate prima dell'adozione.
Tuttavia, diversi sviluppatori erano contrari alla proposta. Il motivo? Il requisito potrebbe rallentare il processo di aggiornamento. Van der Wijden ha sostenuto che i manutentori di EELS potrebbero diventare i de facto gatekeeper dell'inclusione delle EIP. Perché? Non tutti gli sviluppatori sono capaci di scrivere implementazioni basate su Python delle loro proposte.
Wijden ha suggerito un approccio alternativo. ETH dovrebbe avere implementazioni EELS che potrebbero essere presentate come pull request non mergeate. Questo impedisce al team EELS di avere il potere di approvazione finale sugli aggiornamenti.
Justin Florentine con blockchain il client Besu ha consigliato alla comunità di considerare la creazione di un linguaggio di scripting aggiuntivo. Questo chiarirebbe se un'EIP può essere inclusa senza casi di test EELS o EEST.
I cervelli più intelligenti del crypto leggono già la nostra newsletter. Vuoi unirti a loro? Unisciti a loro.
Dichiarazione di responsabilità. Le informazioni fornite non costituiscono consigli di trading. Cryptopolitan.com non si assume alcuna responsabilità per eventuali investimenti effettuati sulla base delle informazioni fornite in questa pagina. Si consiglia vivamente di effettuare ricerche indipendenti e/o consultare un professionista qualificato prima di prendere qualsiasi decisione di investimento.
Florence Muchai
Florence si occupa di notizie relative a criptovalute, gaming, tecnologia e AI da oltre 6 anni. I suoi studi in Informatica presso l'Università Meru di Scienze e Tecnologia e in Gestione delle Emergenze e Diplomazia Internazionale presso il MMUST le hanno fornito eccellenti competenze linguistiche, osservative e tecniche. Florence ha lavorato al VAP Group e come editor per diverse testate specializzate in criptovalute.
