Gli sviluppatori core di Ethereum discutono sul processo e sulla timeline di Fusaka

L’ultimo incontro degli All Core Devs di Ethereum si è concentrato non solo sul codice, ma anche sul processo: se rispettare o meno la finestra di 30 giorni precedentemente annunciata tra le release dei client e il primo fork su testnet, mentre l’upgrade Fusaka avanza. Alcuni partecipanti hanno spinto per riaffermare questo impegno, così che i team di infrastruttura e delle applicazioni abbiano il tempo di adattarsi; altri hanno invece sostenuto la necessità di flessibilità per evitare ritardi più ampi sulla roadmap.

Il dibattito si è svolto sullo sfondo di risultati contrastanti sui devnet. Su Devnet-3, un esercizio pianificato di non-finalità si è protratto più del previsto, secondo Barnabas Busa del team Dev Ops. “Volevamo fare circa due giorni inizialmente, e ora siamo al quinto giorno,” ha detto, sottolineando come la partecipazione sia calata per poi risalire sopra il 50%. La finalità richiede che oltre due terzi dello stake effettivo totale siano d’accordo.

Al contrario, una testnet separata si è ripresa rapidamente dopo un riavvio coordinato: “La chain si è ripresa, credo, in due ore,” ha detto Busa. Questo esercizio mette alla prova come le variabili interagiscono in un incidente reale, il che può aiutare Ethereum a riprendersi in caso di crisi.

Per saperne di più: L’upgrade Fusaka di Ethereum potrebbe subire ritardi

Con le correzioni in arrivo nei prossimi giorni, il piano a breve termine è ripristinare Devnet-3 a piena salute, ripetere il test e poi avviare Devnet-5.

Ma il punto più critico è stata la disciplina nella programmazione delle reti pubbliche. Lightclient ha sottolineato la promessa in essere: “C’è scritto 30 giorni prima del primo testnet.” Ha avvertito di non cambiare gli obiettivi per comodità, basandosi sulla valutazione dei core devs riguardo al tempo necessario agli altri team non presenti alla call.

La preoccupazione pratica è come migliorare la cadenza degli hard fork. Ridurre gli intervalli tra i test può accelerare i fork, ma aumenta il rischio che i team a valle rilascino aggiornamenti affrettati. L’argomentazione opposta è che pipeline troppo lunghe ritardano tutto il resto in coda, cosa che potrebbe scontentare la più ampia community di Ethereum.

“Non credo che dovremmo scegliere le tempistiche solo in base a ciò che la community desidera,” ha detto Lightclient. “Le persone che rilasciano il software hanno detto che vogliono 30 giorni per consegnare un software di alta qualità che la community userà.”

Ciononostante, lo scambio, a tratti teso, si è orientato verso il rispetto del processo scritto, a meno che gli stakeholder non chiedano esplicitamente un cambiamento.

Si è anche manifestata frustrazione per il fatto di dover rivedere la stessa questione a ogni ciclo. “Penso sia davvero un brutto precedente continuare a cambiare decisioni,” ha detto Lightclient, osservando che gli sviluppatori di app e le L2 di solito non partecipano alle call dei core e fanno affidamento su finestre prevedibili per programmare i propri rilasci.

Per ora, il consenso è di procedere come se il buffer di 30 giorni restasse in vigore, mentre si raccolgono proattivamente nuovi feedback, ha detto il coordinatore Tim Beiko. “Dovremmo preparare il calendario in base a quanto previsto dal documento [di processo] e in parallelo verificare con gli stakeholder interessati.” Se una corsia preferenziale avrà davvero ampio supporto, il gruppo lo formalizzerà per iscritto.