Ringkasan pertemuan terbaru pengembang inti ETH Place: Devnet 12 diluncurkan, dan proses perencanaan peningkatan sedang ditingkatkan

Judul asli: Ethereum Semua Pengembang Inti Panggilan Konsensus # 123 Writeup

Artikel asli oleh Christine Kim

Kompilasi asli: Luccy, BlockBeats

Catatan editor:

Lokakarya ETH Semua Panggilan Konsensus Pengembang Inti (ACDC) diadakan dua minggu sekali untuk membahas dan mengoordinasikan perubahan pada Lapisan Konsensus (CL) Lokakarya ETH. Ini adalah panggilan konferensi ke-123 ACDC, yang berfokus pada evaluasi pembaruan pengujian Cancun/Deneb dan Devnet #12, serta penyelesaian masalah keluar validator yang muncul di Devnet #11. Selain itu, para pengembang melakukan diskusi mendalam tentang klarifikasi spesifikasi jaringan, proses perencanaan peningkatan, dan status EIP.

Selama diskusi Cancun / Deneb, para pengembang menekankan stabilitas dan mendiskusikan apakah akan memulai garpu bayangan Goerli atau tidak. Namun, karena klien Prysm belum siap untuk pengujian, diputuskan untuk menunggu sampai siap. Diskusi tentang alat pengujian dan restrukturisasi rantai menyoroti perlunya cakupan pengujian yang lebih komprehensif dan membuat rekomendasi untuk penggunaan suite uji Apache Hive dan Kurtosis. Mengenai masalah status EIP dan label CFI, Beiko mengemukakan kekhawatiran tentang apakah tag ini harus dipertahankan, dan pengembang belum mencapai konsensus yang jelas tentang masalah ini.

Christine Kim, VP of Research di Galaxy Digital, memberikan catatan rinci tentang sorotan pertemuan, yang disusun BlockBeasts sebagai berikut:

Pada 30 November 2023, ETH pengembang berkumpul di Zoom untuk sesi panggilan All Core Developers Consensus (ACDC) #122. Panggilan konferensi ACDC adalah serangkaian pertemuan dua mingguan yang dipimpin oleh Danny Ryan, seorang peneliti di ETH Workshop Foundation, di mana pengembang mendiskusikan dan mengoordinasikan perubahan pada ETH Workshop Consensus Layer (CL). Minggu ini, para pengembang fokus pada perkembangan terbaru dalam pengujian Cancun / Deneb, termasuk:

· Peluncuran Devnet #12: Pengujian perangkat lunak klien Teku, Lodestar, dan Lighthouse, serta semua perangkat lunak klien lapisan eksekusi (EL), pada Devnet #12 sedang berlangsung. Tim Prysm mengharapkan perangkat lunak mereka siap untuk pengujian dalam waktu dua hingga tiga minggu di Devnet terbaru.

· Masalah Keluar Validator di Devnet #11: Di Devnet #11, pengembang telah mengidentifikasi masalah yang terkait dengan keluarnya validator, yang saat ini sedang diselesaikan oleh tim klien Nimbus. Devnet #11 akan terus berfungsi secara normal sampai masalah teratasi.

· Klarifikasi Spesifikasi Jaringan: Pengembang membahas klarifikasi spesifikasi untuk permintaan “BlockByRoot” dan “BlobSidecarsByRoot”, mengklarifikasi apakah node lapisan konsensus (CL) harus menanggapi permintaan ini dalam urutan tertentu.

Selain pembaruan Cancun / Deneb, para pengembang membahas beberapa masalah proses yang diangkat oleh Tim Beiko, Kepala Dukungan Protokol untuk Yayasan ETH, untuk meningkatkan koordinasi peningkatan Lokakarya ETH.

Pembangunan #12

Pada Rabu, 30 November 2023, upgrade Cancun/Deneb resmi diluncurkan di Devnet #12. Mario Vega dari tim pengujian ETH Foundation mengatakan bahwa “tidak ada masalah besar yang diidentifikasi hingga saat ini” pada tiga klien CL yang saat ini berjalan di testnet. Barnabas Busa, seorang DevOps engineer di Foundation, menyebutkan bahwa ada total 225 validator yang tersebar di tiga node antara Lighthouse, Teku, dan Lodestar. Karena stabilitas Devnet # 12, Parithosh Jayanthi, seorang insinyur DevOps di Foundation, bertanya kepada pengembang apakah mereka harus mulai merencanakan garpu bayangan Goerli untuk menguji lebih lanjut Cancun / Deneb. Namun, mengingat bahwa Prysm, klien CL paling populer saat ini, belum bergabung dengan Devnet # 12, para pengembang telah memutuskan untuk menunda rencana untuk garpu bayangan Goerli sampai perangkat lunak klien Prysm siap untuk pengujian. Beiko menyarankan untuk pindah ke garpu bayangan Goerli beberapa saat sebelum akhir tahun. Karena stabilitas Devnet # 12, rencana ditunda sampai perangkat lunak klien Prysm siap untuk pengujian.

Pembangunan #11

Pengembang Nimbus, yang menggunakan nama layar “Dustin”, berbagi rincian masalah Devnet # 11 yang sedang dikerjakan timnya. Masalah ini pertama kali ditemukan ketika pengembang keluar dari sepertiga validator Devnet #11 untuk digunakan pada Devnet #12. Ryan bertanya kepada Dustin apakah dia dapat menemukan masalah ini dengan pengujian tambahan. Dustin menjawab bahwa, menurutnya, sifat kesalahan ini disebabkan oleh detail implementasi di luar ruang lingkup spesifikasi konsensus. Namun, ia juga mengakui bahwa ada “ketegangan yang jelas” antara menulis perangkat lunak klien secara ketat ke spesifikasi CL untuk menguji manfaat cakupan dan mengarungi area abu-abu spesifikasi untuk mencapai kinerja node yang lebih baik.

"Saya mengatakan lebih banyak pengujian selalu baik, tetapi mencari tahu lebih sistematis bagaimana menggabungkan lebih banyak fungsionalitas sisi klien ke dalam menjalankan tes, mungkin lebih banyak otomatisasi, apakah itu menggunakan Apache Hive atau Kurtosis atau apa pun. Jika masalah ini dapat diselesaikan atau hal-hal dapat dipecah dengan cukup baik untuk dapat menggabungkan lebih banyak tugas-tugas ini, saya pikir itu pasti akan berguna, "tambah Dustin, menambahkan bahwa tantangan lain yang harus dipertimbangkan oleh pengembang CL adalah mencari tahu tingkat detail di mana spesifikasi CL harus menentukan dan menstandarisasi perilaku node. “Tantangan lain di sini adalah tingkat standardisasi, yang sebenarnya bukan hanya masalah rekayasa perangkat lunak, seberapa standar perilakunya?” tanya Dustin. Semua klien CL diuji untuk memeriksa perilaku dasar, tetapi perilaku di luar ruang lingkup tes ini ambigu. “Apakah ini hal-hal yang sengaja tidak jelas? Apa yang harus benar-benar didefinisikan dengan jelas oleh spesifikasi, dan apa yang harus sengaja dikaburkan?” Dustin bertanya.

Paling tidak, para pengembang setuju untuk menambahkan lebih banyak tes ke Devnet dan testnet di masa depan untuk sejumlah besar validator keluar di Cancun / Deneb. Ryan juga mengakui bahwa ada ruang untuk cakupan pengujian yang lebih ketat dan komprehensif ketika datang ke klien CL dan implementasi spesifikasi CL. Vega menyarankan agar Dustin membuat posting HackMD yang merinci kekhawatirannya dan mendiskusikan topik tersebut pada panggilan tes Cancun / Deneb berikutnya. Jayanthi menambahkan bahwa berdasarkan beberapa masalah yang baru-baru ini diidentifikasi pada Cancun / Deneb Devnets, ada kebutuhan yang jelas bagi pengembang untuk memiliki alat yang secara sistematis dapat melakukan sejumlah perilaku terkait integrasi on-chain, seperti mempertaruhkan ETH penarikan, penarikan validator, dll. Untuk melakukan ini, Jayanthi merekomendasikan untuk menggunakan campuran suite uji Hive dan Kurtosis untuk membangun alat semacam itu.

Berbicara tentang alat pengujian baru untuk upgrade Cancun / Deneb, Jayanthi mencatat bahwa pengembang sedang mengerjakan alat untuk mengaktifkan reuni rantai dengan andal di Devnet dan testnet. Untuk memastikan alat ini berfungsi, Jayanthi meminta pengembang untuk membagikan rincian bug yang diketahui yang memicu reorganisasi rantai di ETH. Jayanthi menjelaskan bahwa ia akan menggunakan bug ini untuk menguji alat dan memastikan bahwa alat tersebut dapat mengidentifikasi dengan andal kapan reorganisasi terjadi dan kapan diselesaikan.

Klarifikasi spesifikasi jaringan

Para pengembang secara singkat membahas permintaan tarik terbuka yang diusulkan oleh Justin Traglia, seorang peneliti di ETH Foundation, mengenai urutan tanggapan yang harus dikembalikan klien CL ketika menerima permintaan “BlockbyRoot” atau “BlobSidecarsByRoot”. Ryan bertanya bagaimana tim klien CL yang berbeda sudah menerapkan fitur ini. Tak satu pun dari pengembang yang menelepon menjawab pertanyaan ini. Ryan menyarankan untuk menghidupkan kembali diskusi di saluran ETH Research &; Development Discord untuk melibatkan pengembang klien yang lebih luas. Ryan mengakui bahwa ada ambiguitas dalam spesifikasi dua permintaan, yang “mungkin menjadi penyebab masalah dan kasus tepi yang aneh” dan “layak untuk diklarifikasi dan diselesaikan,” Ryan menegaskan.

Ryan juga menyebutkan bahwa ia akan merilis versi baru dari spesifikasi CL dalam beberapa hari ke depan. Versi terbaru secara signifikan menambahkan spesifikasi kapan klien CL dapat menyediakan blok dan blok melalui permintaan RPC “byRoot”. Untuk latar belakang lebih lanjut tentang diskusi tentang mengambil potongan dan potongan yang hilang melalui permintaan RPC “byRoot”, silakan merujuk ke log panggilan sebelumnya. Ryan menekankan bahwa penambahan baru pada spesifikasi CL yang disertakan dalam versi terbaru tidak akan memiliki perubahan yang melanggar pada kode yang akan mempengaruhi kode untuk validator yang sudah berjalan di Devnet # 11 atau # 12.

Proses perencanaan peningkatan

Selanjutnya, para pengembang membahas berbagai item proses yang diusulkan oleh Beiko. Menurut Beiko, sebuah posting blog yang memperingatkan pengguna testnet Goerli tentang penghentian yang akan datang dalam waktu 3 bulan setelah upgrade Cancun / Deneb diaktifkan di Goerli, atau dalam waktu 1 bulan setelah mengaktifkan upgrade di mainnet ETH, mana saja yang lebih lambat, akan dipublikasikan di blog ETH Foundation pada 30 November. Sejak kesimpulan panggilan, posting blog di atas telah diterbitkan dan dapat dibaca di sini.

Beiko merekomendasikan untuk membuat folder khusus peningkatan di bawah repositori “pm” ETH untuk mengatur berbagai file yang terkait dengan peningkatan tertentu ke dalam satu folder untuk digunakan nanti. Para pengembang di telepon setuju dengan saran Beiko.

Item proses kedua yang diusulkan oleh Beiko adalah membuat dokumen “Meta EIP” untuk melacak cakupan penuh peningkatan jaringan yang telah diselesaikan pada ETH. “Tidak ada tempat yang baik untuk melacak cakupan penuh peningkatan jaringan sebelum menyebarkan dan mengumumkannya dalam posting blog,” tulis Beiko dalam sebuah posting tentang proposal Meta EIP-nya. "Untuk Dencun, kami memiliki EIP EL dalam file penurunan harga 7 yang sulit ditemukan, dan CL EIP adalah bagian dari Spesifikasi Rantai Suar 3. Ini tidak bagus, karena keduanya agak sulit ditemukan, masing-masing menggunakan ‘format’ yang berbeda, dan mereka mengarah pada duplikasi. Karena ERC dan EIP sekarang terpisah, saya akan merekomendasikan (kembali) untuk menggunakan EIP Meta untuk melacak EIP yang termasuk dalam peningkatan jaringan. Para pengembang mendukung pembuatan dokumen-dokumen ini. Beiko mengatakan dia akan menyusun dokumen untuk meninjau upgrade Cancun / Deneb minggu ini.

Akhirnya, Beiko mengajukan pertanyaan tentang kegunaan menandai perubahan kode yang diusulkan, ETH Proposal Peningkatan (EIP) sebagai “dianggap termasuk” (CFI). Menurut Beiko, CFI adalah keadaan yang secara historis digunakan pengembang sebagai “sinyal lunak”, menunjukkan bahwa penulis EIP harus terus bekerja keras pada proposal yang mungkin dimasukkan dalam hard fork di masa depan. Ini hanya digunakan untuk perubahan dan peningkatan kode yang berfokus pada EL. 「[CFI] lebih tinggi dari ide-ide acak dari orang-orang acak, tetapi sebelum mereka diterima di garpu," kata Beiko.

Di masa lalu, label CFI memiliki sedikit efek dalam menunjukkan EIP mana pada EL yang akan diterapkan dalam peningkatan atau kapan. Ini telah diterapkan pada berbagai EIP dengan berbagai tingkat kesiapan kode dan dukungan dari tim klien. Dalam kasus proposal EVM Object Format (EOF), pengembang menggunakan tag ini untuk menunjukkan komitmen mereka untuk menerapkan EOF dalam peningkatan mendatang berikutnya, Cancun/Deneb. Namun, EOF, serta beberapa proposal lain yang juga ditandai sebagai CFI, ditolak dari Cancun / Deneb, dan tidak jelas status EIP ini ditandai sebagai CFI dalam peningkatan berikutnya Praha / Electra.

Beiko mengatakan bahwa jika keadaan ini tidak membantu, pengembang harus menghapusnya, tetapi jika mereka berniat untuk menyimpannya, pengembang CL juga harus menggunakan label yang sama pada perubahan kode yang mereka pertimbangkan untuk diterapkan dalam peningkatan CL. Tidak jelas sejauh mana proses peninjauan CL EIP mencerminkan proses peninjauan EL EIP dan apakah mereka harus berkembang dengan cara yang sama di masa depan. Biasanya, perubahan kode yang diusulkan pada spesifikasi CL dibahas pada panggilan konferensi ACDC, sementara EIP yang diusulkan ke spesifikasi EL dibahas pada panggilan konferensi ACDE.

Danno Ferrin dari Swirlds Labs juga datang dengan ide untuk membuat bidang placeholder untuk semua EIP, baik CL atau EL terkait, yang mengidentifikasi status mereka selama proses peninjauan, termasuk status CFI. Tidak ada keputusan yang jelas tentang topik status EIP dan label CFI pada panggilan ini.