Gli sviluppatori Ethereum hanno finalizzato il programma per i prossimi aggiornamenti della rete. I cambiamenti più importanti sono previsti per il 24 febbraio, il 5 marzo e l'8 aprile. Le decisioni chiave sono state prese durante la recente All Core Developers Execution (ACDE) Call 205, tenutasi il 13 febbraio 2025.
della riunione Zoom bisettimanale discussioni sono state guidate da Ethereum Foundation (EF). Gli sviluppatori hanno confermato che l'aggiornamento Pectra verrà attivato sulla testnet Holesky il 24 febbraio. Successivamente, la testnet Sepolia verrà attivata il 5 marzo.
Se entrambi i lanci procederanno senza intoppi, la rete principale di Ethereumriceverà l'aggiornamento intorno all'8 aprile.
Beiko ha affermato che si sarebbe coordinato con i team per trovare un volontario per distribuiretracdel sistema Pectra su entrambe le reti di prova.
Dibattiti sui futuri fork Ethereum e sulla velocità di aggiornamento
Inoltre, il team di sviluppatori ha discusso del prossimo aggiornamento previsto dopo Pectra e Fusaka. Beiko ha proposto di congelare l'ambito di Fusaka fino al lancio di Pectra sulla rete principale.
La sequenza temporale consente agli sviluppatori di iniziare a lavorare su Fusaka e allo stesso tempo di pianificare il successivo hardfork Glamsterdam.
Il team di sviluppo di Geth non vuole lavorare con questa tempistica. Sostiene che sia prematuro consolidare la portata di Fusaka. L'inclusione dell'EOF ( Ethereum Improvement Proposal) (EIP) in Fusaka ha suscitato un acceso dibattito. Una fazione di sviluppatori ne sostiene l'esclusione dal prossimo aggiornamento.
EOF (Ethereum Object Format) è un aggiornamento volto a migliorare il modo in cui gli smart contracttracstrutturati ed eseguiti sulla Ethereum blockchain
Lightclient, sviluppatore di Geth, si è opposto all'accelerazione del blocco degli aggiornamenti di Fusaka. Lo sviluppatore sostiene che Ethereumpotrebbero cambiare nei prossimi due anni. Ha sottolineato che, sebbene gli sviluppatori puntino a cicli di aggiornamento di sei mesi, i ritardi reali potrebbero allungarli a otto mesi o più. Ciò significa che importanti miglioramenti potrebbero non essere implementati per anni.
Lightclient ha sollevato preoccupazioni riguardo all'integrazione di EOF, evidenziando i rapidi progressi della tecnologia di rollup a conoscenza zero (zkEVM) di Ethereum. Gli sviluppatori rimangono all'oscuro riguardo all'interazione di questi cambiamenti con la macchina virtuale.
Durante la discussione, lo sviluppatore di Geth, Marius van der Wijden, ha elencato il suo ambito preferito per Fusaka, che includeva PeerDAS, FOCIL, EOF e limiti superiori per modexp. Parithosh Jayanthi, ingegnere operativo per gli sviluppatori di EF, ha replicato, affermando che FOCIL non era pronto per l'implementazione come PeerDAS ed EOF.
Aggiornamenti della testnet del software Pectra e feedback della community
Gli sviluppatori hanno superato i loro disaccordi su Fusaka per esprimere fiducia nell'implementazione in corso di Pectra. Parithosh Jayanthi, ingegnere di sviluppo e operazioni di EF, ha riferito che Pectra Devnet 6 sta funzionando bene, con tassi di partecipazione dei validatori quasi perfetti.
Inoltre, la testnet Ephemery di Ethereumha attivato l'aggiornamento Pectra poche ore dopo la chiamata ACDE, consentendo agli sviluppatori di condurre ulteriori test.
Beiko ha chiesto agli autori di Pectra EIP di spostare le loro proposte alla fase di "ultima chiamata" su GitHub. Questo indica le fasi finali prima dell'implementazione sulla mainnet. Ha inoltre esaminato il feedback della Ethereum . A tal proposito, ha notato che la richiesta più comune era quella di accelerare i cicli di aggiornamento.
In risposta, ha suggerito che gli sviluppatori Ethereum dovrebbero cercare di finalizzare la portata di ogni aggiornamento non appena quello precedente viene lanciato sulla rete principale.
da Beiko proposta per la definizione dell'ambito di Fusaka, entro il 13 marzo gli sviluppatori dovranno proporre gli EIP (Early Improvement Programs) da includere nell'aggiornamento. Due settimane dopo, il 27 marzo, i team dei clienti condivideranno le proprie preferenze sugli EIP da considerare per Fusaka. Infine, entro il 10 aprile, l'ambito dell'aggiornamento sarà definito in via definitiva.
Tuttavia, il ricercatore di EF Ansgar Dietrichs ha aggiunto un'eccezione alla tempistica. Ha sottolineato che i miglioramenti al codice PeerDAS, componente fondamentale dell'aggiornamento di Pectra, dovrebbero essere caricati sulla mainnet Ethereum non appena completati. Nessuno ha sollevato obiezioni a questo requisito.
Preoccupazioni sugli standard di prova EELS ed EIP
Un altro punto di interesse emerso durante la call ACDE è stata una proposta dell'ingegnere di test EF Mario Vega, riguardante il framework di test del livello di esecuzione Ethereum . Vega ha suggerito di rendere obbligatori EELS (Ethereum Execution Layer Specifications) ed EEST (Ethereum Execution Specification Test cases) per qualsiasi EIP incluso in un hard fork.
Ha suggerito che ciò migliorerebbe il flusso di lavoro dei test e standardizzerebbe il modo in cui gli EIP vengono valutati prima dell'adozione.
Tuttavia, diversi sviluppatori si sono opposti alla proposta. Il motivo? Il requisito potrebbe rallentare il processo di aggiornamento. Van der Wijden ha sostenuto che i manutentori di EELS potrebbero diventare di fatto i guardiani dell'inclusione di EIP. Perché? Non tutti gli sviluppatori sono in grado di scrivere implementazioni basate su Python delle loro proposte.
Wijden ha suggerito un approccio alternativo. L'ETH dovrebbe avere implementazioni EELS che possano essere inviate come pull request non unite. Ciò impedisce al team EELS di avere il potere di approvazione finale sugli aggiornamenti.
Justin Florentine, del Ethereum Besu, ha consigliato alla community di valutare la creazione di un linguaggio di scripting aggiuntivo. Questo chiarirebbe se un EIP può essere incluso senza casi di test EELS o EEST.
