Ringkasan mesyuarat terbaharu pembangun teras Ethereum: Peningkatan Pectra boleh dibahagikan kepada dua garpu keras

Ditulis oleh: Christine Kim

Disusun oleh: Luccy, BlockBeats

Nota Editor: Panggilan Konsensus Pembangun Teras Ethereum (ACDC) diadakan setiap dua minggu untuk membincangkan dan menyelaras pelaksanaan Lapisan Konsensus Ethereum (CL). ) Ubah. Ini ialah panggilan persidangan ACDC ke-134 Pada persidangan ini, pembangun membincangkan butiran pelaksanaan dan cabaran teknikal berbilang EIP utama, termasuk EIP 7549, EIP 7251, EIP 6110, EIP 7688, dsb.

Selain itu, pembangun turut membincangkan secara mendalam pelaksanaan PeerDAS, teknologi pensampelan ketersediaan data yang dijangka dapat meningkatkan keupayaan rangkaian Ethereum dengan ketara untuk menyokong rollup dan keperluan ketersediaan data mereka. Semasa mesyuarat itu, cadangan telah dibuat untuk membahagikan Pectra kepada dua garpu keras untuk naik taraf, dan isu masa pengaktifan dan saling kebergantungan EIP yang berbeza telah dibincangkan.

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

Pada 30 Mei 2024, pembangun Ethereum berkumpul di Zoom untuk mengambil bahagian dalam Konsensus Semua Pembangun Teras (ACDC) panggilan #134 mesyuarat. Panggilan ACDC ialah siri mesyuarat dua minggu sekali yang dihoskan oleh penyelidik Yayasan Ethereum Alex Stokes di mana pembangun membincangkan dan menyelaraskan perubahan kepada Lapisan Konsensus Ethereum (CL, juga dikenali sebagai Rantaian Beacon). Minggu ini, pembangun membincangkan pengalaman dan isu terbuka sejak pelancaran Pectra Devnet 0. Mereka juga membahaskan kemungkinan mengembangkan skop peningkatan Pectra untuk memasukkan perubahan kod kontena peerDAS dan SSZ.

Devnet 0 Review

Berdasarkan pelancaran Pectra pada Devnet 0, pasukan pelanggan telah bersetuju untuk mengekalkan tingkah laku pengesahan yang terjejas oleh EIP 7549 tidak berubah semasa pengaktifan hard fork. Pada mesyuarat ACDC sebelumnya, pembangun mempertimbangkan pelbagai pilihan untuk memastikan bahawa kesan EIP 7549 tidak akan mengakibatkan sejumlah besar pengesahan tidak sah semasa fork. Untuk mengelakkan peningkatan yang merumitkan lagi, pasukan pelanggan memutuskan untuk mengaktifkan EIP 7549 dalam zaman yang sama seperti EIP Pectra lain, tanpa mengubah tingkah laku pengesahan sebelum dan selepas garpu.

Mengenai EIP 7251, pembangun masih tidak pasti sama ada gabungan ETH yang dipertaruhkan harus dibenarkan untuk dicetuskan daripada lapisan pelaksanaan (EL). Ini akan menjadi ciri yang ideal untuk kumpulan taruhan seperti Lido supaya penggabungan kepentingan tidak perlu bergantung pada pengendali nod tetapi sebaliknya boleh dicapai melalui kontrak pintar. Stokes mengesyorkan menyemak kemajuan pelanggan yang melaksanakan cantuman staking validator dalam beberapa minggu sebelum memutuskan sama ada mereka harus menjadi operasi EL atau CL.

Pemaju kemudian membincangkan beberapa soalan yang belum dijawab mengenai pengesahan akhir deposit pengesah di bawah EIP 6110. Pembangun Teku Mikhail Kalinin meringkaskan arahan untuk menangani isu ini dalam ulasan GitHub sebelum persidangan. Pembangun rumah api "sean" menimbulkan soalan tentang versi permintaan "GetPayloadBodies" dalam API Enjin. Stokes mengesyorkan agar pembangun menyiarkan ulasan mereka dalam permintaan tarik yang dibuat untuk isu tersebut di GitHub.

EIP 7549 perubahan

Pemaju Nimbus Etan Kissling mencadangkan perubahan kecil kepada pelaksanaan EIP 7549. "Ini mengenai kestabilan indeks umum. Apabila kami menambah medan baharu di tengah-tengah bekas, medan seterusnya akan diberikan indeks baharu, yang akan memecahkan bukti berdasarkan EIP 4788 pada peringkat pelaksanaan (EL), dan beberapa Mengelirukan … Oleh itu, saya mengesyorkan memindahkan medan baharu ke penghujung untuk mengelakkan kedua-dua masalah," jelas Kissling. Tiada bantahan terhadap perubahan ini. Stokes mengesyorkan pembangun menyemak permintaan tarik Kissling pada GitHub.

Satu lagi perubahan kepada EIP 7549 yang dicadangkan pada mesyuarat itu adalah untuk mereka bentuk permintaan dan permintaan lain yang dicetuskan oleh EL sebagai tambahan kepada blok EL. Mengenai perubahan ini, Kalinin berkata: "Pada pendapat saya, ini adalah penyelesaian reka bentuk yang sangat baik, ia memudahkan EL... dan pada asasnya ia adalah alternatif kepada permintaan umum dalam blok lapisan pelaksanaan Adalah disyorkan bahawa topik ini." dibincangkan semula pada mesyuarat CL seterusnya supaya pembangun mempunyai lebih banyak masa untuk menyemak cadangan di GitHub.

Perbincangan Skop Pectra

Terdapat beberapa EIP fokus lapisan konsensus (CL) yang belum disertakan secara rasmi atau dikecualikan daripada peningkatan Pectra. Pada mesyuarat minggu ini, pembangun membincangkan sama ada untuk menambah EIP 7688 dan PeerDAS pada Pectra. EIP 7688 mengguna pakai sebahagian daripada struktur data SSZ "StableContainer" untuk memastikan keserasian hadapan perubahan pengesahan EIP 7549. Sebagai pengenalan latar belakang, SSZ ialah struktur data yang digunakan dalam CL, dan pembangun mahu menggunakannya dalam lapisan pelaksanaan (EL) juga. Untuk maklumat lanjut tentang peralihan SSZ, lihat minit mesyuarat sebelumnya. PeerDAS ialah pelaksanaan pensampelan ketersediaan data pada Ethereum yang dijangka akan meningkatkan keupayaan rangkaian untuk menyokong rollup dan keperluan ketersediaan datanya. Dalam amalan, PeerDAS dijangka meningkatkan bilangan transaksi gumpalan yang boleh dilampirkan oleh pengesah pada blok daripada 3 kepada 64 atau lebih setiap blok.

Barnabas Busa, jurutera operasi pembangun di Ethereum Foundation, berkata bahawa pembangun telah melancarkan lelaran awal PeerDAS pada rangkaian pembangunan. "Saya fikir ramai pelanggan telah menemui banyak masalah, dan apabila kami membuat kemajuan yang ketara, kami sentiasa boleh memulakan semula rangkaian pembangunan baharu," kata Busa. Stokes bertanya kepada pembangun sama ada mereka bersedia untuk menambah PeerDAS pada Pectra tanpa menyebabkan kelewatan naik taraf.

Seorang pembangun yang digelar "Nishant" telah menghidupkan semula cadangan untuk memisahkan pengaktifan PeerDAS daripada pengaktifan EIP lain dalam Pectra. Walaupun ini boleh dilaksanakan, pemaju lain yang digelar "atd" menekankan bahawa jika pembangun merancang untuk mengaktifkan peningkatan ini satu demi satu dalam tempoh yang singkat, pengguna masih perlu meningkatkan perisian mereka pada masa yang sama. atd berkata: "Saya rasa agak gila untuk melakukan fork dua bulan selepas naik taraf lain. Jika kami akan menyelaraskan semua orang untuk menaik taraf pelanggan, kami tidak mahu semua orang menaik taraf pelanggan dua bulan kemudian. Itu akan , walaupun satu kitaran keluaran tidak mencukupi."

atd menambah bahawa pada pendapatnya, PeerDAS ialah perubahan kod yang paling "menarik" dalam EIP yang disertakan dan dibincangkan dalam Pectra. Stokes berkata beliau berharap untuk memasukkan PeerDAS dalam Pectra walaupun ia menyebabkan kelewatan naik taraf. Pembangun pelanggan Grandine Saulius Grigaitis mencadangkan mengalih keluar EIP 7549 dan EIP 7688 daripada Pectra yang memihak kepada PeerDAS. Ini mendorong perbincangan mengenai butiran pelaksanaan EIP 7688. Pembangun tidak dapat bersetuju dengan perubahan kod dan cadangan itu akan disemak semula pada mesyuarat ACDC akan datang.

Mengenai topik PeerDAS, pembangun terus mempertimbangkan idea untuk membelah Pectra kepada dua garpu keras. Jurutera pilihan pemaju Yayasan Ethereum Parithosh Jayanthi memberi amaran bahawa jika pemaju membahagikan Pectra kepada dua peningkatan, mereka mesti berhati-hati untuk tidak menambah lebih banyak EIP pada Pectra Bahagian 2 akan datang. Jayanthi berkata: "Satu perkara yang saya ingin nyatakan ialah jika kita mempertimbangkan untuk berpecah kepada dua garpu, kita perlu berhati-hati untuk tidak menambah lebih banyak EIP baharu dalam garpu seterusnya saya tidak tahu sama ada kita akan dapat melakukannya Setakat ini. Jika kita boleh komited pada sesuatu setahun atau setahun setengah yang lalu, kerana kita sentiasa datang dengan idea baharu dan keutamaan berubah dan sebagainya."

Teruskan membincangkan dua idea naik taraf, pembangunan Rumah Api . Pengarang "sean" berkata bahawa dia tidak meramalkan banyak saling bergantung antara PeerDAS dan senarai EIP Pectra semasa. Oleh itu, kedua-duanya boleh dilakukan secara berasingan dan kemudiannya mudah digabungkan apabila pembangun menjadi lebih yakin dalam pelaksanaannya. Atd bersetuju, dengan alasan bahawa tidak akan ada banyak risiko dalam menggabungkan Pectra EIP, PeerDAS dan EIP 7688 selepas membangunkan dan menguji ini secara berasingan.

Busa mengesyorkan untuk terus menguji Pectra EIP dan PeerDAS, tetapi mereka bentuk kod berubah supaya PeerDAS diaktifkan satu zaman kemudian daripada Pectra EIP pada rangkaian pembangunan dan ujian. Beliau menyatakan bahawa ini sudah menjadi cara ujian Pectra EIP dan PeerDAS dilakukan pada Devnet 0. "Tiada apa-apa yang perlu diubah, " kata Busa, sambil menambah bahawa jika PeerDAS tidak bersedia apabila Pectra EIP yang lain, pembangun boleh mengalih keluar perubahan kod itu daripada peningkatan. Ini menimbulkan beberapa persoalan tentang cara zaman pengaktifan berbeza PeerDAS mempengaruhi kerja pasukan pelanggan. Akhirnya, pembangun bersetuju untuk terus membangunkan PeerDAS dan Pectra EIP, tetapi premisnya ialah PeerDAS akan diaktifkan dalam zaman yang berbeza pada rangkaian pembangunan dan rangkaian ujian.

Seperti yang dinyatakan di atas, pemaju bersetuju untuk meninggalkan perbincangan sama ada EIP 7688 akan dimasukkan ke dalam Pectra sehingga panggilan ACDC seterusnya.

Atas ialah kandungan terperinci Ringkasan mesyuarat terbaharu pembangun teras Ethereum: Peningkatan Pectra boleh dibahagikan kepada dua garpu keras. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!