Rumah  >  Artikel  >  Ringkasan mesyuarat terkini pembangun teras Ethereum: kemajuan akhir peningkatan Dencun dan perbincangan skop peningkatan Pectra

Ringkasan mesyuarat terkini pembangun teras Ethereum: kemajuan akhir peningkatan Dencun dan perbincangan skop peningkatan Pectra

WBOY
WBOYke hadapan
2024-03-09 13:13:111246semak imbas

以太坊核心开发者最新会议摘要:Dencun升级最终进展及Pectra 升级范围讨论

Disusun oleh: Luccy, BlockBeats

Panggilan Konsensus Pembangun Teras Ethereum (ACDC) diadakan secara kerap untuk membincangkan dan menyelaraskan pelarasan pada Lapisan Konsensus Ethereum (CL). Panggilan ACDC terbaharu ialah yang ke-129, di mana pembangun berkongsi kemajuan terkini mengenai persediaan untuk peningkatan Dencun dan membincangkan skop dan EIP Pectra, peningkatan Ethereum seterusnya.

Christine Kim, Naib Presiden Penyelidikan di Galaxy Digital, merekodkan perkara penting mesyuarat ini secara terperinci, dan BlockBeasts menyusun teks asal seperti berikut:

Pada 7 Mac 2024, pemaju Ethereum berkumpul di Zoom untuk mengambil bahagian dalam Semua Pertemuan Konsensus Pembangun Teras (ACDC) panggilan #129. Panggilan ACDC ialah siri mesyuarat dua minggu sekali yang dihoskan oleh penyelidik Yayasan Ethereum Danny Ryan, di mana pembangun membincangkan dan menyelaraskan perubahan kepada Lapisan Konsensus Ethereum (CL). Minggu ini, pembangun berkongsi kemas kini terakhir mengenai persediaan untuk naik taraf Dencun, yang dijadualkan akan diaktifkan pada mainnet pada hari Rabu, 13 Mac. Mereka juga membincangkan skop peningkatan Ethereum seterusnya, Pectra, serta beberapa topik penyelidikan, salah satunya ialah penyeragaman nilai blok di kalangan pelanggan CL.

Deneb

Ryan mengingatkan semua orang pada permulaan panggilan persidangan bahawa peningkatan Dencun akan disiarkan secara langsung di Ethereum dalam masa kurang daripada seminggu daripada DST. Memandangkan semua panggilan persidangan dan peningkatan ACD dijadualkan berdasarkan Waktu Sejagat Selaras (UTC) tanpa memerhatikan DST, pembangun dan peserta panggilan di luar A.S. perlu melaraskan jadual mereka dengan sewajarnya.

Dalam panggilan persidangan, sesetengah pelanggan The pasukan mendedahkan bahawa mereka merancang untuk mengeluarkan versi perisian yang dikemas kini dalam beberapa hari akan datang bertepatan dengan peningkatan Dencun. Pasukan Prysm, Lighthouse dan Teku dijangka mengeluarkan versi baharu menjelang akhir minggu ini. Walaupun versi yang dikemas kini ini bukan peningkatan wajib, Tim Beiko dari Ethereum Foundation menyatakan semasa mesyuarat Zoom bahawa mereka tidak akan mengemas kini catatan blog yang meringkaskan semua versi yang serasi dengan Dencun.

Chris Hager daripada pasukan Flashbots berkongsi kemas kini pantas tentang kesediaan perisian MEV-Boost. Hager mengesahkan bahawa MEV-Boost versi 1.7, dikeluarkan minggu lepas, adalah stabil dan boleh digunakan oleh pengendali nod pengesah. Perisian pembina Flashbots untuk Deneb masih dalam pembangunan dan dijangka siap dan digabungkan pada minggu ini, katanya. Mengenai kesediaan pengesah untuk naik taraf, Hager menyatakan kebimbangan bahawa pengesah tidak mencukupi nampaknya telah mengemas kini perisian MEV-Boost mereka untuk menampung peningkatan Dencun. Selepas menyemak semula datanya, Hager berkata bahawa kira-kira 50% pengesah yang disambungkan ke geganti Flashbots menggunakan versi MEV-Boost terbaharu, v1.7.

Beiko seterusnya menyatakan bahawa sumbernya, Metrika dan Ethernets, menunjukkan bahawa kira-kira separuh daripada nod Ethereum sedia untuk dinaik taraf kepada Dencun. Beliau juga menyatakan harapan untuk alat data yang boleh menjejaki kesediaan nod pengesah untuk naik taraf, bukan hanya semua nod Ethereum.

Electra

Pembangun Ethereum membincangkan empat perubahan kod yang berkaitan dengan peningkatan Pectra.

EIP 7459

Yang pertama ialah Cadangan Penambahbaikan Ethereum (EIP) 7549, yang membolehkan pelanggan CL mengagregat undian untuk blok dengan lebih cekap (juga dikenali sebagai pengesahan). Pembangun bersetuju dengan cadangan terdahulu untuk memasukkan EIP 7549 ke dalam Pectra. Pembangun Teku Mikhail Kalinin berkongsi analisis lanjut tentang cara EIP 7549 akan dilaksanakan pada Ethereum dan mencadangkan beberapa pertukaran atau "kesan negatif" yang mungkin diperkenalkan akibat daripada perubahan kod. Ryan mencadangkan agar Kalinin meringkaskan cadangan perubahannya kepada spesifikasi CL secara langsung di GitHub untuk maklum balas dan semakan lanjut.

Pemaju Prysm Terence Tsao berkata bahawa dia bersetuju dengan cadangan pelaksanaan EIP 7549 Kalinin, tetapi mengesyorkan bahawa dokumentasi dan spesifikasi lanjut untuk perubahan API Beacon diperlukan dengan EIP ini. "Hari ini, jika anda mempunyai 10 agregator dalam slot yang sama, anda perlu menandatangani 10 pengesahan, maka dengan perubahan ini, anda hanya perlu menghantar satu mesej, jadi anda mungkin perlu membuat beberapa perubahan API Beacon," kata Tsao sambil menambah Dao , "Saya fikir bahagian ini mungkin memerlukan lebih banyak pemikiran tentang cara menukar penyepaduan pengesah API Beacon untuk menyelesaikan masalah ini sebagai latar belakang, API Beacon ialah spesifikasi CL yang membolehkan nod bertanya kepada rangkaian dan mendapatkan maklumat tentang keadaan." rangkaian.

Terbitan Lebih Rendah

Kemudian, penyelidik EF Ansgar Dietrichs berkongsi kemas kini pantas mengenai cadangannya untuk mengurangkan ganjaran taruhan dengan menurunkan pengeluaran rangkaian. Beliau berkata terdapat "maklum balas bercampur-campur daripada masyarakat" sejak cadangan itu dibentangkan semasa panggilan ACDC yang lalu. Beliau mengulangi bahawa cadangan itu akan menjadi perubahan kod kecil yang boleh dimasukkan dalam peningkatan Electra saat akhir menjelang Jun atau Julai, dengan mengandaikan mainnet mengalami masalah pada Oktober. Walau bagaimanapun, Dietrichs juga berkata bahawa perbualan adalah "berterusan," bermakna idea itu perlu dibincangkan lebih lanjut sebelum keputusan dibuat.

EIP 7547

Ketiga, penyelidik EF Mike Neuder mencadangkan EIP 7547, yang mengandungi senarai untuk perbincangan lanjut. Beliau berkata sesi pecah kedua untuk membincangkan "ciri-ciri tepat" reka bentuk EIP akan berguna dan beliau sedang mempertimbangkan untuk menganjurkan satu pada Jumaat depan, 15 Mac. Beliau juga menyebut bahawa EIP mempunyai saluran Discord khusus yang dipanggil "Senarai Kemasukan" yang harus digunakan oleh orang yang berminat untuk mengetahui lebih lanjut tentang cadangan atau bertanya soalan. Tsao juga berkata bahawa spesifikasi untuk cadangan itu sebahagian besarnya telah disempurnakan sejak mesyuarat pecahan senarai inklusi pertama pada 16 Februari. "Saya rasa spesifikasi itu mungkin kira-kira 75% siap," kata Tsao, sambil menambah bahawa terdapat beberapa komponen spesifikasi lain yang memerlukan penambahbaikan, seperti perubahan pada API pelaksanaan dan spesifikasi sekitar pengesah yang jujur.

EIP 7251

Akhir sekali, pemaju Lighthouse Mark Mackey menyatakan sokongan untuk EIP 7251, yang meningkatkan baki berkesan maksimum (maxEB). "Kami telah hampir membuat prototaipnya dalam Rumah Api. Masih terdapat beberapa kerja yang perlu dilakukan pada spesifikasi, tetapi ia tidak kelihatan seperti banyak kerja, dan memandangkan saiz set pengesah adalah sedikit bom masa yang berdetik. , kami mencadangkan untuk mengeluarkan cadangan Tweaking, perubahan keluaran sentiasa kontroversi, jadi tidak ada jaminan bahawa komuniti akan menerimanya, dan jika mereka tidak menyukainya, maka satu-satunya perkara yang boleh kami lakukan ialah maxEB," kata Mackey. Ryan berkata rintangan utama untuk memasukkan maxEB ke dalam Electra adalah disebabkan oleh kerumitan perubahan kod, seperti yang dinyatakan dalam panggilan sebelumnya dengan pasukan Prysm. "Potuz," pembangun tanpa nama dalam pasukan Prysm, berkata dalam sembang mesyuarat Zoom bahawa pasukannya akan menyemak semula EIP dan menilai semula kerumitan cadangan itu. Ryan meminta pasukan akaun bersedia untuk panggilan ACDC seterusnya dalam masa dua minggu untuk membuat "keputusan tegas" pada EIP 7547 dan 7251.

Key Manager API Standardization

EF Developer Operations (DevOps) Engineer Barnabas Busa menjelaskan bahawa semua pelanggan CL nampaknya mempunyai kaedah yang sedikit berbeza untuk menjana kunci pengesah, yang digunakan untuk mengendalikan dan membatalkan pengesah Kunci penyulitan yang diperlukan. Terdapat API yang dipanggil "API Pengurus Utama" yang membantu pengendali nod pengesah dengan pengurusan kunci dan menyertai serta keluar dari pengesah. Busa menjelaskan bahawa perbezaan halus antara pelanggan apabila ia berkaitan dengan mengembalikan nilai untuk API ini memang menyukarkan ujian titik akhir API. Beliau juga menyebut bahawa pasukannya telah memulakan ujian asas pengesah hibrid, bermakna pengendali nod pengesah menggunakan klien yang berbeza untuk nod suar mereka daripada klien pengesah. Nod suar ialah pelanggan yang mengekalkan keadaan CL tetapi tidak mengurus pasangan utama yang diperlukan oleh pengesah untuk mengambil bahagian dalam konsensus. Pelanggan pengesah ialah pelanggan yang menggunakan pasangan kunci untuk menjana blok dan menandatangani bukti pada rantaian. Ryan mencadangkan Busa memulakan dokumentasi atau permintaan tarik dengan cadangan untuk menyeragamkan API pengurus utama. Pembangun dalam panggilan juga menyokong ujian lanjut untuk memastikan pengesah hibrid berfungsi pada semua kombinasi klien CL.

Block Value Beacon API Standardization

Seorang pembangun Nimbus dengan nama skrin "Dustin" turut menyatakan kebimbangan mengenai penyeragaman CL bagi titik akhir API Beacon "productBlockV3" dan "getBlockRewards". Dustin menjelaskan bahawa sesetengah kawasan API Beacon tidak ditakrifkan dengan jelas dan "tidak dilaksanakan secara universal" dalam kalangan pelanggan. Khususnya, apabila ia berkaitan dengan titik akhir yang sepatutnya mengembalikan nilai blok, pengiraan sekurang-kurangnya harus memasukkan perubahan dalam baki pengesah sebelum dan selepas blok yang dicadangkan. Walau bagaimanapun, spesifikasi tidak memperincikan sama ada pelanggan harus memasukkan ganjaran dan penalti untuk perubahan dalam baki pengesah disebabkan tindakan pengesah lain. Ini termasuk, sebagai contoh, anugerah atau penalti tugas jawatankuasa serentak, pengurangan diri pencadang atau pensijil, dan anugerah pemberi maklumat. Ryan bersetuju bahawa arahan harus ditambahkan pada API Beacon. Walau bagaimanapun, pembangun lain dalam panggilan itu, termasuk Radosław Kapka dan Potuz dari pasukan Prysm, kurang yakin. Potuz menyatakan kebimbangan bahawa bilangan orang yang menggunakan titik akhir ini adalah kecil dan dapat menggunakan alat mereka sendiri untuk menormalkan nilai blok daripada pelanggan CL yang berbeza. "Saya tidak faham mengapa kami bersetuju untuk menyokong ini jika pengguna dihadkan. Saya akan cuba melihat pasaran ini dan melihat sama ada kami benar-benar boleh menghantar kerja ini kepada orang ramai menggunakan titik akhir ini dan bukannya diri kami sendiri," kata Potuz.

Pemaju Nimbus Jacek Sieka menyangkal pandangan ini, dengan mengatakan bahawa disebabkan kewujudan titik akhir "productBlockV3", pembangun perlu menyelesaikan ketidakkonsistenan antara pelanggan atau menafikan titik akhir memihak kepada "V4". Tambahan pula, Sieka menambah: "Saya fikir titik akhir ini hanyalah fungsi yang sangat asas. Jika kita membayangkan masa depan di mana kita mempunyai pelbagai sumber blok dan anda perlu membandingkannya, maka ini masuk akal. Semudah itu Ryan menasihati Dustin Buat cadangan." untuk menyeragamkan V3 dan titik akhir "getBlockRewards" Setelah cadangan dibuat, pasukan akaun akan menyemak semula sama ada akan terus menyokongnya.

Selebihnya

Potuz menandakan dua projek untuk maklum balas dan perbincangan pembangun selanjutnya. Yang pertama ialah mengenai kelakuan klien lapisan pelaksanaan (EL) bagi blok lewat yang tidak dinyatakan pada masa ini dalam API enjin yang menentukan komunikasi antara EL dan CL. "Jika ini boleh dinyatakan dalam API enjin, ia akan memudahkan kami apabila menyusun semula blok kemudian," kata Potuz. Item kedua yang dibenderakan Potuz adalah mengenai analisisnya tentang peningkatan muatan Pemisahan Pembina Pencadang (ePBS), peningkatan yang akan menghapuskan keperluan untuk geganti yang dipercayai pada Ethereum. Potuz meminta maklum balas tambahan mengenai analisis dan batasan reka bentuk ePBS yang lain.

Akhirnya, Pooja Ranjan daripada kumpulan Ethereum Cat Herder mengumumkan pembentukan kumpulan kerja baharu yang dipanggil Women in the Ethereum Protocol (WiEP). WiEP ialah organisasi baharu daripada Yayasan Ethereum yang berdedikasi untuk menggalakkan dan membangunkan lebih ramai pembangun protokol Ethereum wanita. Ranjan berkata kumpulan itu akan menganjurkan webinar selama sejam pada 8 Mac untuk berbincang dengan beberapa penyumbang protokol Ethereum wanita.

Ryan kemudian menyatakan bahawa dia akan berehat selama tiga bulan bermula pada 1 April. Jika beliau tidak hadir, Fellow EF Alex Stokes akan menyederhanakan panggilan ACDC.

Atas ialah kandungan terperinci Ringkasan mesyuarat terkini pembangun teras Ethereum: kemajuan akhir peningkatan Dencun dan perbincangan skop peningkatan Pectra. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:panewslab.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam