Pengembang inti Ethereum berselisih tentang proses, jadwal Fusaka

All Core Devs terbaru Ethereum membahas proses, bukan hanya kode: apakah akan menghormati jendela 30 hari yang telah dinyatakan sebelumnya antara rilis klien dan fork testnet pertama seiring kemajuan upgrade Fusaka. Beberapa peserta mendorong untuk menegaskan kembali komitmen tersebut agar tim infrastruktur dan aplikasi memiliki waktu untuk beradaptasi; yang lain berpendapat perlunya fleksibilitas untuk menghindari keterlambatan roadmap yang lebih luas.

Perdebatan ini terjadi di tengah hasil devnet yang beragam. Di Devnet-3, latihan non-finality yang direncanakan berlangsung lebih lama, menurut Barnabas Busa dari tim Dev Ops. “Kami awalnya ingin melakukan sekitar dua hari, dan sekarang kami sudah memasuki hari kelima,” katanya, mencatat bagaimana partisipasi sempat turun lalu kembali naik di atas 50%. Finality membutuhkan lebih dari dua pertiga total stake efektif yang setuju.

Sebaliknya, testnet terpisah pulih dengan cepat setelah restart terkoordinasi: “Chain telah pulih dalam, saya kira dua jam,” kata Busa. Latihan ini menguji tekanan bagaimana variabel berinteraksi dalam insiden nyata, yang dapat membantu Ethereum pulih dalam situasi krisis.

Baca selengkapnya: Upgrade Fusaka Ethereum mungkin menghadapi penundaan

Dengan perbaikan yang akan datang dalam beberapa hari ke depan, rencana jangka pendeknya adalah memulihkan Devnet-3 ke kondisi penuh, mengulangi tes, lalu meluncurkan Devnet-5.

Namun, isu utama adalah disiplin penjadwalan untuk jaringan publik. Lightclient menekankan janji yang telah dibuat: “Tertulis 30 hari sebelum testnet pertama.” Ia memperingatkan agar tidak mengubah target hanya demi kenyamanan, berdasarkan penilaian core devs atas waktu yang dibutuhkan tim lain yang tidak hadir dalam panggilan tersebut.

Kekhawatiran praktisnya adalah bagaimana meningkatkan ritme hard fork. Memperpendek jeda antar pengujian dapat mempercepat fork, namun meningkatkan risiko tim lain merilis pembaruan secara terburu-buru. Argumen sebaliknya adalah bahwa pipeline yang terlalu lama akan menunda semua hal lain dalam antrean, yang mungkin tidak disukai komunitas Ethereum secara luas.

“Saya rasa kita tidak seharusnya memilih timeline berdasarkan apa yang diinginkan komunitas,” kata Lightclient. “Orang-orang yang mengirimkan software mengatakan mereka ingin 30 hari untuk memberikan software berkualitas tinggi yang akan digunakan komunitas.”

Meski begitu, diskusi yang agak tegang ini mengarah pada penegakan proses tertulis kecuali para pemangku kepentingan secara eksplisit meminta perubahan.

Ada juga rasa frustrasi karena harus membahas pertanyaan yang sama di setiap siklus. “Saya pikir ini preseden yang buruk jika terus membiarkan keputusan berubah,” kata Lightclient, mencatat bahwa pengembang aplikasi dan L2 biasanya tidak hadir dalam panggilan inti dan mengandalkan jendela yang dapat diprediksi untuk menjadwalkan rilis mereka sendiri.

Untuk saat ini, konsensusnya adalah melanjutkan seolah-olah buffer 30 hari tetap berlaku, sambil secara proaktif meminta masukan baru, kata koordinator Tim Beiko. “Kita harus menyiapkan jadwal sesuai dokumen [proses] dan secara paralel memeriksa dengan pemangku kepentingan yang terdampak.” Jika jalur cepat benar-benar mendapat dukungan luas, kelompok akan meresmikannya secara tertulis.