Pertemuan @ethereum #AllCoreDevs lainnya berakhir pada tanggal 15 September: pembaruan pada jaringan pengembangan, penambahan Dencun, dan tinjauan komprehensif tentang Reth telah dibahas!
Agenda: Tautan langsung:
Di bawah ini adalah ringkasan pertemuan oleh @TimBeiko.
1. Pembaruan status Devnet-8
Pertama, pembaruan status pada devnet-8: jaringan sedang menjalani pengembangan akhir dan banyak klien telah mendorong pembaruan baru ke dalamnya. Sementara itu, kami telah mulai menguji proses pembuatan MEV/blok menggunakan @KurtosisTech. @NethermindEth menyatakan bahwa kumpulan transaksi blob mereka sekarang siap dan setelah beberapa hari pengujian pada satu node, mereka telah menyebarkannya ke semua node pengujian Dencun.
Kumpulan transaksi blob Geth juga hampir selesai. Besu melakukan perbaikan ekstensif pada kumpulan transaksinya (membatasi ukuran total transaksi blob dan non-blob) yang diharapkan akan dirilis pada rilis berikutnya. Erigon terus meningkatkan kumpulan transaksinya dan berharap siap untuk devnet-9. Prysm juga mencatat bahwa ada beberapa latensi dalam menerima sidecar blob, yang menurut mereka biasanya tiba dengan penundaan sekitar 500 milidetik setelah blok (sementara blok memerlukan waktu sekitar 15 milidetik untuk diproses).
Mereka sedang menyelidiki masalah ini untuk menentukan apakah masalah ini mungkin disebabkan oleh kondisi perlombaan antara impor blob dan chunk. Mengenai pertanyaan apakah akan mengizinkan dukungan untuk transaksi blob di kumpulan memori sebelum hard fork, tim dengan suara bulat setuju untuk tidak melakukannya.
2、EIP-7514
Selanjutnya, kami melanjutkan diskusi dari panggilan ACDC minggu lalu tentang apakah akan menambahkan batas konstan ke antrean aktivasi validator. Proposal ini telah resmi dibentuk sebagai EIP-7514. Singkatnya, hal ini akan memperlambat persentase pertumbuhan taruhan ETH dalam skenario terburuk. Dankrad menyatakan dukungannya terhadap proposal tersebut selama panggilan telepon, dengan mengatakan bahwa hal ini akan memberi kami waktu untuk melakukan perubahan yang berpotensi lebih kompleks terhadap imbalan validator.
Semua tim CL mendukung perubahan ini, dengan peringatan bahwa ini hanya berlaku untuk antrian deposit dan bukan antrian penarikan. Setelah berdiskusi lebih lanjut, kami memutuskan untuk menetapkan batas menjadi 8. Oleh karena itu, EIP-7514 akan menjadi bagian dari peningkatan Dencun! Diharapkan dalam beberapa hari ke depan, EIP dan PR spesifikasi CL terkait akan diperbarui untuk mencerminkan perubahan ini.
3. EVM dan Blob
Selanjutnya, kita membahas proposal sementara lainnya: menambahkan opcode ke Mesin Virtual Ethereum (EVM) untuk mengekspos biaya dasar blob. Proposal ini diajukan oleh @PlasmaPower0 dari Arbitrum, yang mengatakan pada R&D Discord awal pekan ini bahwa ini akan berguna bagi mereka (dan solusi Lapisan 2 lainnya). Kami telah memiliki opcode serupa yang mengekspos BASEFEE di EIP-1559, yang diperkenalkan bersamaan dengan aktivasi EIP. Hal ini memudahkan solusi Lapisan 2 untuk menentukan harga bahan bakar yang tepat untuk membebankan biaya kepada pengguna berdasarkan biaya data L1.
@protolambda dari Optimism juga menghadiri pertemuan tersebut dan menyarankan bahwa ini bukan satu-satunya cara untuk mendapatkan biaya dasar blob untuk L2, karena mereka dapat melihat header blok (yang berisi nilai yang digunakan untuk menghitung biaya dasar blob) dan memberikan Merkle terhadap nilai-nilai tersebut membuktikan. Namun, dia setuju bahwa ini adalah fitur yang bagus. Arbitrum saat ini tidak melakukan penguraian header blok, dan mengandalkan hal ini dapat menimbulkan masalah untuk solusi Lapisan 2 yang tidak dapat diubah, karena hal ini dapat menimbulkan masalah jika format header blok akhirnya berubah.
Salah satu penulis EIP-4844 @adietrichs menyebutkan bahwa opcode ini tidak disertakan dalam spesifikasi asli karena ada keinginan untuk mengembangkan cara yang lebih umum untuk mengakses informasi header blok (daripada menambahkan opcode satu kali). Namun, mengadopsi perubahan yang lebih ambisius ini akan menjadi tugas yang lebih ambisius dibandingkan memperkenalkan opcode ini.
Informasi yang diekspos oleh opcode ini sudah sesuai dengan kebutuhan komputasi klien EL, dan secara semantik hampir identik dengan opcode BASEFEE. Tim klien dengan suara bulat setuju bahwa kami harus menambahkan opcode ini, agar konsisten dengan BASEFEE. Jika di masa depan kita datang dengan mekanisme yang "lebih licin", setiap fungsi yang berlebihan dalam opcode baru ini juga akan menjadi masalah bagi opcode lain yang menggunakan informasi header blok. Selain itu, perlu ditekankan bahwa ini adalah perubahan kecil: @vdWijden menerapkannya di Geth sebelum EIP ada, dan hanya membutuhkan waktu sekitar 20 menit, dan tim Reth melakukan perubahan selama PR panggilan ACD.
4、EIP-4788
Selanjutnya, kita membahas beberapa pembaruan pada EIP-4788, sebuah proposal untuk menyimpan akar suar dalam kontrak di rantai utama Ethereum. Selama beberapa minggu terakhir, kami telah melakukan beberapa audit dan pengujian fuzz terhadap kontrak, yang menghasilkan beberapa perubahan kecil yang dijelaskan dalam PR ini. Meskipun belum semua audit selesai dan laporan belum keluar, @lightclients memberikan gambaran umum tentang perubahan yang dipertimbangkan sejauh ini. Perubahan pertama adalah secara eksplisit menangani stempel waktu 0 sehingga menyebabkan rollback (seperti stempel waktu tidak valid lainnya) alih-alih mengembalikan 0. Perubahan kedua menyangkut ukuran buffer. Dengan asumsi waktu slot berubah, kontrak asli akan mengakibatkan penyimpanan terbuang karena cara kerja aritmatika modular.
5. Optimalisasi gas
Terakhir, terdapat optimalisasi gas yang mengurangi jumlah kali CALLDATA dimuat. Auditor akan meninjau perubahan ini dan kami berharap laporan akhir mereka dapat diperoleh sebelum pertemuan ACDE berikutnya. Agar pengujian fuzz dan pekerjaan implementasi tetap berjalan, kami telah sepakat untuk menggabungkan perubahan yang diusulkan sekarang.
@shemnon juga menyebutkan bahwa perubahan ini harus didokumentasikan dalam EIP sebenarnya - kami sedang mengerjakannya! Selanjutnya, kita membahas bagaimana klien harus menangani hal ini jika alamat kontrak sistem adalah bagian dari negara tetapi kosong pada akhir eksekusi. Meskipun hal ini sebenarnya tidak mungkin terjadi di mainnet (dari apa yang saya pahami!), ini adalah kasus edge yang terjadi dalam pengujian dengan menyetel alamat di blok genesis.
Mengingat bahwa ini adalah kasus khusus dan tidak ada perilaku kanonik yang jelas, kami sepakat untuk meluangkan lebih banyak waktu memikirkan masalah ini dan melanjutkan diskusi pada pertemuan pengujian minggu depan. Itu saja tentang perubahan spesifikasi! Semua hal di atas direncanakan untuk dimasukkan dalam devnet-9. Tim klien setuju bahwa semuanya harus diterapkan dan diuji sebelum ACDC minggu depan. Melalui panggilan itu, kami akan menyetujui tanggal peluncuran devnet-9.
ACDE berikutnya dijadwalkan akan diadakan pada 28 September, 14:00 waktu UTC. Sampai saat itu tiba, ikuti @terencechain untuk ringkasan pertemuan pengujian, @benjaminion_xyz untuk informasi pertemuan ACDC, dan @christine_dkim untuk liputan lebih rinci tentang keseluruhan acara.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
EIP-7514 akan menjadi bagian dari peningkatan Ethereum Dencun
Penulis: @TimBeiko Terjemahan: Huohuo/Blockchain Vernakular
Pertemuan @ethereum #AllCoreDevs lainnya berakhir pada tanggal 15 September: pembaruan pada jaringan pengembangan, penambahan Dencun, dan tinjauan komprehensif tentang Reth telah dibahas!
Agenda: Tautan langsung:
Di bawah ini adalah ringkasan pertemuan oleh @TimBeiko.
1. Pembaruan status Devnet-8
Pertama, pembaruan status pada devnet-8: jaringan sedang menjalani pengembangan akhir dan banyak klien telah mendorong pembaruan baru ke dalamnya. Sementara itu, kami telah mulai menguji proses pembuatan MEV/blok menggunakan @KurtosisTech. @NethermindEth menyatakan bahwa kumpulan transaksi blob mereka sekarang siap dan setelah beberapa hari pengujian pada satu node, mereka telah menyebarkannya ke semua node pengujian Dencun.
Kumpulan transaksi blob Geth juga hampir selesai. Besu melakukan perbaikan ekstensif pada kumpulan transaksinya (membatasi ukuran total transaksi blob dan non-blob) yang diharapkan akan dirilis pada rilis berikutnya. Erigon terus meningkatkan kumpulan transaksinya dan berharap siap untuk devnet-9. Prysm juga mencatat bahwa ada beberapa latensi dalam menerima sidecar blob, yang menurut mereka biasanya tiba dengan penundaan sekitar 500 milidetik setelah blok (sementara blok memerlukan waktu sekitar 15 milidetik untuk diproses).
Mereka sedang menyelidiki masalah ini untuk menentukan apakah masalah ini mungkin disebabkan oleh kondisi perlombaan antara impor blob dan chunk. Mengenai pertanyaan apakah akan mengizinkan dukungan untuk transaksi blob di kumpulan memori sebelum hard fork, tim dengan suara bulat setuju untuk tidak melakukannya.
2、EIP-7514
Selanjutnya, kami melanjutkan diskusi dari panggilan ACDC minggu lalu tentang apakah akan menambahkan batas konstan ke antrean aktivasi validator. Proposal ini telah resmi dibentuk sebagai EIP-7514. Singkatnya, hal ini akan memperlambat persentase pertumbuhan taruhan ETH dalam skenario terburuk. Dankrad menyatakan dukungannya terhadap proposal tersebut selama panggilan telepon, dengan mengatakan bahwa hal ini akan memberi kami waktu untuk melakukan perubahan yang berpotensi lebih kompleks terhadap imbalan validator.
Semua tim CL mendukung perubahan ini, dengan peringatan bahwa ini hanya berlaku untuk antrian deposit dan bukan antrian penarikan. Setelah berdiskusi lebih lanjut, kami memutuskan untuk menetapkan batas menjadi 8. Oleh karena itu, EIP-7514 akan menjadi bagian dari peningkatan Dencun! Diharapkan dalam beberapa hari ke depan, EIP dan PR spesifikasi CL terkait akan diperbarui untuk mencerminkan perubahan ini.
3. EVM dan Blob
Selanjutnya, kita membahas proposal sementara lainnya: menambahkan opcode ke Mesin Virtual Ethereum (EVM) untuk mengekspos biaya dasar blob. Proposal ini diajukan oleh @PlasmaPower0 dari Arbitrum, yang mengatakan pada R&D Discord awal pekan ini bahwa ini akan berguna bagi mereka (dan solusi Lapisan 2 lainnya). Kami telah memiliki opcode serupa yang mengekspos BASEFEE di EIP-1559, yang diperkenalkan bersamaan dengan aktivasi EIP. Hal ini memudahkan solusi Lapisan 2 untuk menentukan harga bahan bakar yang tepat untuk membebankan biaya kepada pengguna berdasarkan biaya data L1.
@protolambda dari Optimism juga menghadiri pertemuan tersebut dan menyarankan bahwa ini bukan satu-satunya cara untuk mendapatkan biaya dasar blob untuk L2, karena mereka dapat melihat header blok (yang berisi nilai yang digunakan untuk menghitung biaya dasar blob) dan memberikan Merkle terhadap nilai-nilai tersebut membuktikan. Namun, dia setuju bahwa ini adalah fitur yang bagus. Arbitrum saat ini tidak melakukan penguraian header blok, dan mengandalkan hal ini dapat menimbulkan masalah untuk solusi Lapisan 2 yang tidak dapat diubah, karena hal ini dapat menimbulkan masalah jika format header blok akhirnya berubah.
Salah satu penulis EIP-4844 @adietrichs menyebutkan bahwa opcode ini tidak disertakan dalam spesifikasi asli karena ada keinginan untuk mengembangkan cara yang lebih umum untuk mengakses informasi header blok (daripada menambahkan opcode satu kali). Namun, mengadopsi perubahan yang lebih ambisius ini akan menjadi tugas yang lebih ambisius dibandingkan memperkenalkan opcode ini.
Informasi yang diekspos oleh opcode ini sudah sesuai dengan kebutuhan komputasi klien EL, dan secara semantik hampir identik dengan opcode BASEFEE. Tim klien dengan suara bulat setuju bahwa kami harus menambahkan opcode ini, agar konsisten dengan BASEFEE. Jika di masa depan kita datang dengan mekanisme yang "lebih licin", setiap fungsi yang berlebihan dalam opcode baru ini juga akan menjadi masalah bagi opcode lain yang menggunakan informasi header blok. Selain itu, perlu ditekankan bahwa ini adalah perubahan kecil: @vdWijden menerapkannya di Geth sebelum EIP ada, dan hanya membutuhkan waktu sekitar 20 menit, dan tim Reth melakukan perubahan selama PR panggilan ACD.
4、EIP-4788
Selanjutnya, kita membahas beberapa pembaruan pada EIP-4788, sebuah proposal untuk menyimpan akar suar dalam kontrak di rantai utama Ethereum. Selama beberapa minggu terakhir, kami telah melakukan beberapa audit dan pengujian fuzz terhadap kontrak, yang menghasilkan beberapa perubahan kecil yang dijelaskan dalam PR ini. Meskipun belum semua audit selesai dan laporan belum keluar, @lightclients memberikan gambaran umum tentang perubahan yang dipertimbangkan sejauh ini. Perubahan pertama adalah secara eksplisit menangani stempel waktu 0 sehingga menyebabkan rollback (seperti stempel waktu tidak valid lainnya) alih-alih mengembalikan 0. Perubahan kedua menyangkut ukuran buffer. Dengan asumsi waktu slot berubah, kontrak asli akan mengakibatkan penyimpanan terbuang karena cara kerja aritmatika modular.
5. Optimalisasi gas
Terakhir, terdapat optimalisasi gas yang mengurangi jumlah kali CALLDATA dimuat. Auditor akan meninjau perubahan ini dan kami berharap laporan akhir mereka dapat diperoleh sebelum pertemuan ACDE berikutnya. Agar pengujian fuzz dan pekerjaan implementasi tetap berjalan, kami telah sepakat untuk menggabungkan perubahan yang diusulkan sekarang.
@shemnon juga menyebutkan bahwa perubahan ini harus didokumentasikan dalam EIP sebenarnya - kami sedang mengerjakannya! Selanjutnya, kita membahas bagaimana klien harus menangani hal ini jika alamat kontrak sistem adalah bagian dari negara tetapi kosong pada akhir eksekusi. Meskipun hal ini sebenarnya tidak mungkin terjadi di mainnet (dari apa yang saya pahami!), ini adalah kasus edge yang terjadi dalam pengujian dengan menyetel alamat di blok genesis.
Mengingat bahwa ini adalah kasus khusus dan tidak ada perilaku kanonik yang jelas, kami sepakat untuk meluangkan lebih banyak waktu memikirkan masalah ini dan melanjutkan diskusi pada pertemuan pengujian minggu depan. Itu saja tentang perubahan spesifikasi! Semua hal di atas direncanakan untuk dimasukkan dalam devnet-9. Tim klien setuju bahwa semuanya harus diterapkan dan diuji sebelum ACDC minggu depan. Melalui panggilan itu, kami akan menyetujui tanggal peluncuran devnet-9.
ACDE berikutnya dijadwalkan akan diadakan pada 28 September, 14:00 waktu UTC. Sampai saat itu tiba, ikuti @terencechain untuk ringkasan pertemuan pengujian, @benjaminion_xyz untuk informasi pertemuan ACDC, dan @christine_dkim untuk liputan lebih rinci tentang keseluruhan acara.