Panggilan Lapisan Konsensus Ethereum #99 Writeup

https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

Pada tanggal 1 Desember 2022, pengembang Ethereum berkumpul untuk acara merekaLapisan Konsensus ke-99 (CL) panggilan. Diketuai oleh Danny Ryan dari Ethereum Foundation, panggilan CL adalah salah satu dari dua seri pertemuan dua mingguan di mana pengembang Ethereum mendiskusikan dan mengoordinasikan perubahan pada protokol Ethereum. Minggu ini, pengembang menegaskan kembali keputusan yang dibuat pada panggilan All Core Developers (ACD) minggu lalu. Yaitu, pengembang setuju untuk bekerja mengaktifkan penarikan ETH yang dipertaruhkan untuk peningkatan Ethereum berikutnya, Shanghai, secara terpisah dari pekerjaan mereka pada proto-danksharding (EIP 4844), yang kemungkinan akan diaktifkan dalam peningkatan terpisah setelah Shanghai. Pengembang juga membahas banyak topik dan inisiatif penelitian yang sedang berlangsung terkait dengan spesifikasi Lapisan Konsensus Ethereum. Akhirnya, menjelang akhir panggilan, pengembang merayakan ulang tahun ke-2 Ethereum Beacon Chain, yang diluncurkan pada 1 Desember 2020.

Penarikan ETH yang dipertaruhkan dan EIP 4844

Untuk memulai panggilan, Danny Ryan mengulangi diskusi dari ACD Call #150 di mana tim klien CL mencapai konsensus tentang fokus secara eksklusif pada penarikan ETH yang dipertaruhkan untuk Shanghai. “Saya pikir hal terpenting yang diperjelas oleh tim Consensus Layer adalah bahwa mereka percaya bahwa EIP 4844 hampir tidak dalam kesiapan yang sama dengan penarikan [stakeed ETH] dan menggabungkannya akan menunda penarikan secara signifikan. Kami tidak akan memasangkan mereka. Kami akan bekerja keras untuk Capella dalam bentuknya saat ini, ”kata Ryan melalui telepon. Capella adalah nama jaringan pengujian khusus tempat pengembang inti menguji perubahan kode untuk penarikan ETH yang dipertaruhkan.

Barnabas Busa, seorang insinyur devops di Ethereum Foundation, memberikan pembaruan tentang kemajuan untuk mengaktifkan penarikan ETH yang dipertaruhkan. Busa menyebutkan bahwa ada dua jaringan pengembang multi-klien yang menguji penarikan, satu yang meniru lingkungan pra-Penggabungan dan satu lagi yang meniru lingkungan pasca-Penggabungan. Tak satu pun dari devnet ini yang saat ini mendukung semua klien EL dan CL. Yang lebih baru menguji penarikan di lingkungan pasca-Penggabungan mendukung klien Prysm, Lighthouse, dan Teku CL, serta klien Geth dan Nethermind EL. Setelah implementasi dari klien lain seperti Nethermind (EL) dan Besu (EL) siap, pengembang akan menjalankan testnet multi-klien yang berumur lebih panjang untuk penarikan.

Kemudian, Alex Stokes, seorang peneliti di Ethereum Foundation, memberikan pembaruan singkat tentang permintaan penarikannya yang menerapkan sapuan terbatas. Singkatnya, ini adalah mekanisme untuk mencegah skenario kasus ekstrem di mana protokol diperlukan untuk memindai seluruh set validator untuk penarikan sebagian dan penuh. Proposal Stokes membatasi pemindaianmaksimal 1.024 validator . Tidak ada keberatan terhadap proposal Stokes dan pengembang setuju untuk bergerak maju dengan lebih banyak kasus uji penarikan di sekitar sapuan terbatas pada akhir minggu depan.

Meskipun pengembangan untuk EIP 4844 akan terjadi secara terpisah dari pekerjaan pengembangan yang masuk ke Shanghai dan mempertaruhkan penarikan ETH, pengembang masih membahas beberapa item diskusi terbuka terkait penerapan proto-danksharding. Sean Anderson, seorang insinyur perangkat lunak Sigma Prime yang membangun klien Lighthouse (CL), menyebutkan bahwa ada pertanyaan terbuka tentang bagaimana jaringan akan menangani gumpalan sinkronisasi. Blob adalah jenis transaksi baru yang akan diperkenalkan di EIP 4844 yang secara eksklusif melakukan data transaksi dari rollup Layer-2 ke lapisan dasar Ethereum. Ryan merekomendasikan diskusi lebih lanjut seputar kasus edge untuk sinkronisasi blobmasalah GitHub terbuka.

Trent Van Epps, orang ekosistem untuk Ethereum Foundation, memberikan pembaruan tentang kemajuan upacara penyiapan tepercaya yang diperlukan untuk implementasi EIP 4844. Upacara, yang dirancang untuk menghasilkan potongan kode yang aman yang akan digunakan di EIP 4844, hampir siap untuk periode kontribusi publik. Van Epps berharap upacara tersebut akan menjadi salah satu yang terbesar yang pernah dilakukan di ruang crypto, mengumpulkan antara 8.000 dan 10.000 kontribusi. Periode kontribusi publik untuk upacara akan berlangsung kira-kira 2 bulan dan dimulai sekitar bulan Desember. Untuk informasi lebih lanjut, bacasitus ini dan bergabungsesi Twitter Spaces ini pada 2 Desember 2022.

Diskusi Penelitian

Pengembang menjalankan beberapa item diskusi terkait dengan potensi pengoptimalan dan perubahan pada spesifikasi Ethereum CL. Pertama, Adrian Manning, salah satu pendiri Sigma Prime, menyoroti dua proposal, keduanya kompatibel dengan versi sebelumnya, yang berarti mereka tidak memerlukan pemutakhiran hard fork di seluruh sistem untuk diterapkan. Detail pertamadi sini bertujuan untuk meningkatkan penemuan rekan di antara node yang mengintai di Ethereum. Yang kedua memungkinkan dukungan untuk node CL yang menjalankan protokol komunikasi internet terbaru yang dikenal sebagai IPv6. Item diskusi terakhir ini diangkat oleh tim Sigma Prime pada bulan Mei. Catatan panggilan dari panggilan CL sebelumnya dapat ditemukandi sini .

Sinkronisasi pos pemeriksaan mengacu pada operasi yang memungkinkan node baru yang terhubung ke Rantai Beacon menyinkronkan dengan cepat ke kepala rantai dengan mengambil status blok terbaru dari node tepercaya. Checkpointz adalah alat yang dibuat oleh tim Ethereum Foundation DevOps untuk memudahkan node tepercaya mengekspos titik akhir sinkronisasi checkpoint. Dalam panggilan tersebut, Mikhail Kalinin, Peneliti Utama di ConsenSys, menjelaskan ada beberapa kekhawatiran seputar Checkpointz yang menjadi titik pusat kegagalan node dan menunjuk kebeberapa usulan untuk membantu mendiversifikasi ketergantungan dari Checkpointz ke alat lain.

Kemudian, Oisin Kyne, salah satu pendiri Obol Technologies yang merupakan perusahaan membangun solusi teknologi validator terdistribusi (DVT), menyoroti masalah penugasan validator tugas agregasi. Kyne menjelaskan bahwa tugas tidak dirancang untuk dijalankan oleh set validator terdistribusi. Karena itu, dia mengusulkan dua titik akhir baru untuk klien CL agar lebih mendukung pengoperasian validator terdistribusi. Informasi lebih lanjut tentang proposal Kynesdi sini dan latar belakang tingkat tinggi pada DVTdi sini .

Terakhir, Kalinin mengajukan dua pertanyaan seputar spesifikasi Ethereum Engine API. Yang pertama adalah item tata graha untuk membantu menyederhanakan spesifikasi Engine API dengan menghapus metode lama untuk mengambil kemampuan yang didukung oleh klien EL yang disebut "engine_getCapabilities .” Pengembang setuju untuk memberikan umpan balik atas saran ini secara asinkron di GitHub. Pertanyaan kedua oleh Kalinin adalah tentang struktur mana yang akan digunakan untuk dokumen spesifikasi Engine API. Salah satu pendekatan mendokumentasikan perubahan ke Engine API by fork, artinya dengan peningkatan hard fork tingkat sistem. Dokumen struktur lainnya berubah berdasarkan fungsi Engine API. Pro dan kontra untuk setiap pendekatan dijelaskan secara lebih rincidi sini . Tidak ada pengembang yang menelepon yang memiliki bias yang kuat terhadap keduanya, tetapi Ryan memang menyebutkan bahwa dia lebih nyaman dengan pendekatan garpu, dan Kalinin menyebutkan bahwa menurutnya kelebihan menggunakan pendekatan fungsi itu kuat.

Item Lain-Lain

Pengembang setuju untuk meninjau diskusi di sekitar GitHubengine_getCapabilities dan pikirkan lebih lanjut tentang struktur untuk mendokumentasikan perubahan Engine API menjelang Shanghai. Sebelum mengakhiri panggilan, pengembang Ethereum independen Micah Zoltu mengajukan pertanyaan singkat seputar data di balik situs webclientdiversity.org . Zoltu menjelaskan bahwa situs web mendapatkan data mereka dari dua sumber yang berbeda, dan ini menghasilkan hasil yang sangat berbeda. Ryan menjawab dengan mengatakan bahwa salah satu metode ini menghitung distribusi klien dengan mempertaruhkan ETH. Yang lain merekam data tentang distribusi klien dengan menggunakan perayap yang mengidentifikasi node dan rekannya. Sepengetahuan Ryan, data yang dikumpulkan oleh perayap node tidak akurat dan metode yang mengandalkan cetak blok dan distribusi ETH yang dipertaruhkan, meskipun tidak sempurna, secara signifikan lebih dapat diandalkan.

Jacek Sieka, juga dikenal sebagai “Arnetheduck,” Kepala Pengembangan Riset di Status yang membangun klien Nimbus (CL), menyebutkan bahwa timnya telah meluncurkan rilis klien baru. Rilis ini secara resmi meluluskan klien Nimbus dari beta ke status siap produksi. Rincian lebih lanjut tentang perbaikan dalam rilis ini dapat ditemukandi sini . Sebelum mengakhiri panggilan, Ryan mencatat bahwa panggilan CL berikutnya pada 15 Desember 2022 akan menjadi panggilan terakhir tahun ini. Pengembang akan melanjutkan panggilan sekitar bulan Januari di tahun baru.