Ringkasan pertemuan terbaru Pengembang Inti Lokakarya ETH: Aktifkan peningkatan Cancun di testnet pada awal Januari 2024

Judul asli: Ethereum All Core Developers ution Call #176 Writeup

Artikel asli oleh Christine Kim

Kompilasi asli: Luccy, BlockBeats

Catatan editor:

The ETH Workshop All Core Developer Consensus Calls (ACDEs) diadakan setiap dua minggu untuk membahas dan mengoordinasikan perubahan pada ETH Workshop Execution Layer (EL). Ini adalah panggilan konferensi ke-176 ACDE, dan ini akan mencakup diskusi dengan peningkatan Cancun / Deneb, kemajuan pengujian Devnet # 12, dan rencana peningkatan Praha / Electra.

Para pengembang membahas bagaimana peningkatan Cancun / Deneb diuji pada Devnet # 12, termasuk kemajuan dan beberapa masalah yang ditemukan oleh tim klien yang berbeda, serta tantangan teknis dalam propagasi gumpalan, MEV (Nilai Maksimum yang Dapat Diekstraksi), dan banyak lagi. Untuk upgrade Praha / Electra yang akan datang, para pengembang telah mengusulkan serangkaian kemungkinan perubahan teknis.

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

Pada 7 Desember 2023, ETH pengembang berkumpul di Zoom for All Core Developers ution (ACDE) call #176. ACDC Conference Call adalah serangkaian pertemuan dua mingguan yang dipimpin oleh Tim Beiko, Kepala Dukungan Protokol di ETH Foundation, di mana pengembang mendiskusikan dan mengoordinasikan perubahan pada Lapisan Eksekutif (EL) ETH Place. Minggu ini, para pengembang membahas pengujian upgrade Cancun / Deneb di Devnet # 12. Mereka sepakat untuk mengoordinasikan tanggal aktivasi upgrade pada jaringan uji Goerli pada ETH awal Januari setelah liburan berakhir. Selain itu, mereka berencana untuk memulai diskusi pada awal Januari tentang perubahan kode apa yang harus dimasukkan dalam peningkatan lokakarya ETH berikutnya, Praha / Electra.

Devnet #12 memperbarui

Pengujian upgrade Cancun / Deneb pada Devnet # 12 berjalan dengan baik. Parithosh Jayanthi, seorang insinyur DevOps di Foundation, mengungkapkan bahwa beberapa bug telah ditemukan di dua klien, Reth dan Lighthouse, dan bahwa dua tim klien sedang mengerjakan perbaikan darurat. Untuk menguji alur kerja MEV secara lebih menyeluruh, tim DevOps lebih fokus untuk mengaktifkan perangkat lunak MEV-Boost pada lebih banyak validator di Devnet #12. Menurut Jayanthi, timnya telah menemukan setidaknya satu bug dalam implementasi relay MEV Flashbots. Danny Ryan, seorang peneliti di ETH Foundation, menekankan bahwa untuk memastikan bahwa validator dapat beralih ke build blok lokal jika terjadi kegagalan relai, pengujian tambahan diperlukan untuk memeriksa mekanisme alternatif.

Untuk peningkatan tim khusus klien, Terence Tsao, pengembang klien Prysm, mengatakan timnya sedang mengerjakan desain yang diperbarui untuk propagasi gumpalan #122中讨论的 ACDC. Tsao mengkonfirmasi bahwa klien Prysm akan siap untuk bergabung dengan Devnet # 12 untuk pengujian minggu depan, mungkin minggu depan. Justin Florentine, pengembang klien Besu, mengatakan bahwa Besu siap untuk pindah dari Devnet #12. Perwakilan dari tim klien Nethermind, Erigon, Lodestar, dan Teku juga mengatakan mereka siap untuk melanjutkan pengujian upgrade di testnet ETH publik.

Berdasarkan kesiapan klien, Beiko merekomendasikan untuk mengoordinasikan tanggal hard fork segera setelah pengembang keluar dari liburan. Dengan asumsi tidak ada bug besar yang ditemukan di Devnet # 12 dalam beberapa minggu ke depan setelah klien Prysm bergabung, Beiko menyatakan bahwa aktivasi Cancun / Deneb pada Goerli kemungkinan akan terjadi sekitar pertengahan Januari. Ben Edgington dari tim Teku bertanya kepada pengembang apakah mereka yakin dalam mengubah jumlah gumpalan per blok dari dua menjadi tiga. Ryan menyarankan pengujian tambahan dari target gumpalan yang meningkat selama garpu bayangan besar dan aktivasi Cancun / Deneb pada Goerli. Beiko menegaskan bahwa aktivasi peningkatan pada Goerli akan menjadi “tes signifikan terakhir” dari tiga target gumpalan per blok. Dengan asumsi tidak ada masalah yang ditemukan, pengembang akan terus menggunakan peningkatan jumlah blob untuk aktivasi mainnet.

Secara keseluruhan, Beiko mengatakan bahwa pengembang akan terus menguji upgrade pada Devnet # 12 antara sekarang dan akhir liburan. Tim DevOps berencana untuk meluncurkan setidaknya satu garpu bayangan Goerli pada akhir Desember sebagai persiapan untuk garpu keras Goerli sejati pada bulan Januari. Jika pengembang berkumpul untuk Tahun Baru, mereka akan membahas tanggal aktivasi garpu keras Goerli.

Builder mengganti bendera

Selanjutnya, Tsao bertanya kepada tim klien tentang kemajuan mereka dalam menerapkan bendera penggantian Builder. Bendera penggantian Builder adalah bidang Boolean baru dalam pemutakhiran Cancun yang dapat digunakan klien lapisan eksekusi untuk menunjukkan kepada klien lapisan konsensus bahwa ketika Builder mendeteksi aktivitas sensor, validator harus kembali ke pembuatan blok lokal alih-alih menggunakan Builder pihak ketiga. Seperti yang ditekankan Tsao, detail implementasi tentang cara mendeteksi aktivitas peninjauan Builder bersifat subjektif dan sengaja diserahkan kepada tim klien untuk dirancang. Untuk informasi selengkapnya tentang bendera penggantian Builder, lihat risalah ACDC#112 dan ACDE#165.

Pengembang tim klien Geth, yang menggunakan nama layar “Lightclient”, mengatakan bahwa timnya telah menerapkan bendera, tetapi tidak akan menggabungkannya dalam rilis resmi “dalam waktu dekat”. Perwakilan dari tim Besu dan Nethermind menyatakan bahwa bendera opsional ini belum diterapkan di klien mereka. Tsao menekankan bahwa bendera dapat menjadi alat yang berguna, dan yang terbaik adalah menerapkannya sedini mungkin untuk mencegah dan mencegah kumpulan staking atau operator node validator besar untuk berpartisipasi dalam “permainan waktu” tertentu. Tsao menjelaskan bahwa validator dapat memperoleh lebih banyak MEV (Nilai Maksimum yang Dapat Diekstraksi) dengan menunda propagasi blok, dan bahwa setelah pengenalan blob setelah peningkatan Cancun, akan ada penundaan dalam propagasi blok. Selama penundaan ini, validator dapat memilih untuk menyertakan transaksi MEV yang lebih menguntungkan di blok, yang kurang optimal untuk propagasi blob tepat waktu.

Mengkonfirmasi bahwa transaksi blob harus bersaing dengan transaksi reguler, pengembang pseudonim di tim Prysm, yang menggunakan nama layar Potuz, menambahkan: "Blob perlu bersaing tidak hanya dengan biaya, tetapi juga dengan latensi itu sendiri dan semua MEV yang diperoleh dengan menunda blok. Saat merancang mekanisme biaya untuk gumpalan, saya pikir itu adalah pasar yang belum diblokir atau diperhitungkan. Tsao mengatakan dia akan mengangkat masalah ini lagi di Ethereum Research Discord untuk diskusi lebih lanjut. Selain itu, Ryan menyoroti peneliti Ethereum Foundation Caspar Schwarz-Schilling dan posting terbaru Mike Neuder tentang “permainan waktu” di situs web Ethresearch.

Kemajuan Proyek

Selanjutnya, Beiko membagikan tiga pembaruan terkait proses perencanaan peningkatan ETH Workshop. Pertama, seperti dalam #123上讨论的那样 ACDC, Beiko telah membuat dokumen Meta EIP untuk upgrade Cancun / Deneb, yang mencantumkan semua ETH Proposal Peningkatan (EIP) yang telah disertakan dalam Cancun / Deneb. Ini telah dibuat di GitHub dengan nomor EIP 7569. Selain itu, Beiko membuat EIP 7568 sebagai dokumen Meta EIP untuk semua peningkatan sebelumnya, dan pengembang tidak membuat dokumen khusus untuk melacak daftar EIP yang termasuk dalam peningkatan. EIP 7568 terkait dengan spesifikasi kode upgrade.

Kedua, Beiko mengumumkan bahwa ia telah membuat utas diskusi baru di situs web Ethereum Magicians untuk mengidentifikasi peningkatan jaringan berikutnya, Praha / Electra. Dia meminta pengembang untuk berpikir kritis tentang apakah akan menggabungkan upgrade Execution Layer (EL) dan Consensus Layer (CL) bersama-sama seperti dua hard fork terakhir telah dilakukan. Aktivasi perubahan kode tertentu, seperti EIP 7002, akan memerlukan perubahan pada EL dan CL, sehingga peningkatan Praha dan Electra perlu dikoordinasikan. Namun, untuk perubahan kode lainnya, seperti pohon Verkle, ada cara untuk mendesain ulang implementasi dan hanya perlu meningkatkan CL.

Ryan mencatat bahwa pengembang lapisan konsensus (CL) yang bekerja secara paralel dengan pohon Verkle juga membuat perubahan kode untuk mendukung pengambilan sampel ketersediaan data. Beiko menyarankan pengembang untuk tidak menjelaskan secara rinci tentang semua EIP yang ingin mereka lihat dalam peningkatan Praha / Electra, melainkan untuk meninjau semua perubahan kode kandidat selama liburan dan siap untuk membahasnya secara serius pada bulan Januari. Potuz setuju, menambahkan bahwa EIP yang dirancang untuk mengatasi masalah yang berkembang dari ukuran set validator ETH akan menjadi perubahan kode penting di Praha / Electra. Berdasarkan kompleksitas perubahan kode, Beiko merekomendasikan bahwa untuk EIP tertentu, seperti Verkle atau pengambilan sampel ketersediaan data, pengembang mengatur pertemuan khusus setelah liburan untuk membahas perubahan protokol yang lebih besar ini secara rinci.