Judul asli: "Pembaruan Rapat Pengembang Inti Ethereum 014"
Sumber asli: Pembaruan AllCoreDevs
Penulis asli: Tim Beiko
Kompilasi asli: Ethereum.cn
Selamat datang di pembaruan AllCoreDevs (Ethereum Core Developer Conference) edisi baru – yang terakhir pada tahun 2022.
ringkasan
Konten peningkatan Shanghai/Capella telah diselesaikan: penarikan, EOF dan beberapa modifikasi kecil... asalkan tidak menunda penarikan.
Ruang blob akan hadir: EIP-4844 akan menjadi pusat peningkatan Ethereum berikutnya, dan upacara pemanggilannya akan segera dimulai.
Di sisi teknis, upaya sedang dilakukan untuk mengoordinasikan proses peningkatan lapisan eksekusi dan lapisan konsensus. Kami juga melihat diskusi aktif tentang cara memasukkan masukan masyarakat ke dalam proses dengan lebih baik.
Protocol Guild telah merilis laporan percontohan jangka menengah dan rencana kasar untuk memperluas ukuran pengelola tingkat pertama dan memberikan dukungan yang lebih baik kepada mereka pada tahun 2023.
Peningkatan Shanghai/Capella
Pada AllCoreDevs baru-baru ini, tim klien mencapai konsensus mengenai cakupan akhir peningkatan Shanghai/Capella. Meskipun nama peningkatan tersebut mungkin masih diperdebatkan, tim tersebut sudah jelas mengenai cakupannya. Fitur utama dari peningkatan ini adalah memperkenalkan penarikan beacon chain untuk para pemangku kepentingan. Meluncurkan fitur ini secepat mungkin adalah sesuatu yang tidak ingin dikompromikan oleh tim klien, sehingga fitur lain dalam peningkatan harus siap pada saat yang sama atau berisiko ditinggalkan.
Spesifikasi Lapisan Eksekutif Shanghai mencantumkan semua EIP yang disertakan:
EIP-3540: Format Objek EVM (EOF) v1
EIP-3651: Mengurangi biaya bahan bakar untuk mengakses alamat COINBASE
EIP-3670: EOF - Verifikasi Kode
EIP-3855: Menambahkan opcode PUSH 0
EIP-3860: Batasi ukuran kode init dan perkenalkan pengukuran gas
EIP-4200: EOF - lompatan relatif statis
EIP-4750: EOF - Mengimpor fungsi
EIP-4895: Penarikan dorong rantai suar sebagai operasi sistem
EIP-5450: EOF - Verifikasi Tumpukan
Meskipun daftarnya panjang, daftar ini dapat dibagi menjadi tiga bagian berbeda: perbaikan kecil, format objek EVM, dan penarikan. Selanjutnya kami akan memperkenalkannya satu per satu:
Perbaikan kecil
EIP-3651: COINBASE Hangat (mengurangi biaya bahan bakar untuk mengakses alamat COINBASE)
EIP ini memperbaiki pengawasan di EIP-2929 di mana biaya bahan bakar untuk mengakses bidang data tertentu diubah berdasarkan apakah data sudah ada di memori klien (WARM) atau perlu diambil dari disk (COLD).
EIP-2929 menyetel dua bagian data dalam memori klien ke WARM di awal setiap transaksi: alamat pengirim dan alamat penerima. EIP-3651 menambahkan alamat ketiga ke daftar ini, alamat COINBASE (yaitu feeRecipient), karena ini juga merupakan alamat yang dimiliki klien di memori saat memproses transaksi blok.
EIP-3855: Instruksi PUSH 0 (opcode baru `PUSH 0)
Seperti namanya, EIP-3855 memperkenalkan opcode yang memasukkan nilai 0 ke dalam tumpukan. Menekan 0 sering digunakan untuk mengisi nilai di EVM, opcode ini akan memberikan cara yang lebih efisien dan murah untuk melakukan hal ini.
EIP-3860: Batasi dan kode init meteran (batasi ukuran kode init dan perkenalkan pengukuran gas)
EIP ini menambahkan batasan pada ukuran kode init dan memperkenalkan pengukuran gas berdasarkan panjangnya. Batas ukuran atasnya menambahkan invarian pada EVM, sehingga lebih mudah untuk memahami dan mengusulkan modifikasi.
Memperkenalkan overhead sebesar 2 gas per 32 byte untuk kode init, yang digunakan untuk membayar analisis jumpdest yang harus dilakukan klien sebelum eksekusi, yang tidak tercantum dalam meteran gas.
format objek
Sebagian besar EIP yang disertakan dalam pemutakhiran Shanghai sebenarnya merupakan bagian dari satu fitur: EVM Object Format (EOF). Pekerjaan ini dipecah menjadi 5 EIP berbeda untuk membantu pengembang klien memahami setiap modifikasi individu, tetapi untuk memberikan gambaran umum tingkat yang lebih tinggi, pengembang merilis spesifikasi terpadu. EIP dari lima EOF ini adalah:
EIP-3540: Format objek EVM versi 1
EIP-3670: EOF - Verifikasi Kode
EIP-4200: EOF - lompatan relatif statis
EIP-4750: EOF - Mengimpor fungsi
EIP-5450: EOF - Verifikasi Tumpukan
Perlu dicatat bahwa langkah pertama EOF adalah pemutakhiran London EIP-3541, yang mencadangkan awalan 0xEF 00 untuk kontrak EOF. Cakupan EOF dari peningkatan Shanghai juga telah berubah selama beberapa bulan terakhir.
Pada bulan Februari, tim klien setuju untuk mempertimbangkan peningkatan di Shanghai untuk menyertakan dua EIP EOF terkecil: EIPs 3540 & 3670. Semuanya akan berfungsi sebagai elemen penyusun, namun tidak akan menyediakan fungsionalitas penuh tanpa diperkenalkannya EIP 4200, 4750, dan 5450. Meskipun dimungkinkan untuk memperluas EOF, ketidakcocokan ke belakang mungkin memerlukan versi baru. Karena kontrak pra-EOF atau EOF dengan versi tertentu harus selalu dapat dieksekusi, setiap versi EOF baru berarti pengembang klien harus mempertahankan seperangkat aturan eksekusi EVM baru secara paralel dengan aturan lama.
Sebelum EOF, klien hanya memelihara satu set aturan EVM dalam satu waktu. Basis kode juga mendukung aturan EVM sebelumnya, yang dimodifikasi dengan setiap peningkatan jaringan, tetapi begitu aturan tersebut mencapai puncak blockchain, hanya aturan terbaru yang harus diterapkan. Setelah menerapkan EOF, klien akan mempertahankan dua set aturan EVM paralel, sehingga mereka dapat mengeksekusi kode dalam kontrak EOF dan non-EOF. Dengan kata lain, peningkatan versi EOF akan meningkatkan jumlah rangkaian aturan EVM paralel yang harus dipertahankan, bukan berturut-turut.
Untuk mencapai tujuan ini, selama beberapa bulan terakhir, tim klien mulai memilih pendekatan "EOF besar". Dengan cara ini, meskipun mereka harus menerapkan set modifikasi yang lebih besar, versi EOF akan bertahan lebih lama dan mengurangi jumlah "EVM paralel" yang perlu dipertahankan. Oleh karena itu, pengembang mempertimbangkan "EOF besar" dan akhirnya memasukkannya ke dalam peningkatan Shanghai.
Meskipun demikian, fitur yang lebih besar jelas lebih sulit untuk diimplementasikan dan diuji, dan tim tidak ingin melihat EOF menunda penarikan beacon chain secara signifikan. Oleh karena itu, jika penerapan EOF belum selesai pada bulan Januari dan mereka tidak dapat saling beroperasi dengan cepat, tim klien setuju untuk memindahkan EOF keluar dari Shanghai untuk peningkatan.
Dengan mengingat konteks ini, sekarang mari kita perkenalkan secara singkat masing-masing EOF EIP:
EIP-3540: Format Objek EVM (EOF) v1 (Format Objek EVM versi 1)
EIP ini memperkenalkan "wadah" pada kontrak EOF. Ia menambahkan tag untuk membedakan kode dan bagian data kontrak dan mencegah penerapan kontrak EOF yang tidak sesuai dengan format. Hal ini menjamin bahwa setiap kontrak EOF dalam rantai akan mengikuti format yang valid, yang menyederhanakan interaksi dengan kontrak-kontrak ini, serta analisis statis terhadap kontrak-kontrak tersebut.
EIP-3670: EOF - Validasi Kode (EOF - Validasi Kode)
Berdasarkan kontainer yang diperkenalkan pada 3540, EIP-3670 memastikan bahwa kode dalam kontrak EOF valid atau mencegah penerapannya.
Artinya, opcode yang tidak ditentukan tidak dapat diterapkan dalam kontrak EOF, sehingga memiliki manfaat tambahan yaitu mengurangi jumlah versi EOF yang perlu ditambahkan. Jika opcode baru ditambahkan, aturan validasi dapat dengan mudah diubah untuk mengaktifkannya dan memastikan bahwa tidak ada kontrak EOF yang diterapkan yang mereferensikannya di bagian kodenya.
EIP-4200: EOF - Lompatan relatif statis (EOF - Lompatan relatif statis)
EIP-4200 memperkenalkan opcode khusus EOF pertama: RJUMP, RJUMPI, dan RJUMPV, yang mengkodekan tujuan sebagai nilai langsung yang ditandatangani. Opcode JUMP baru ini dapat digunakan oleh kompiler untuk mengoptimalkan overhead gas karena menghilangkan kebutuhan akan analisis runtime jumpdest, yang diperlukan oleh opcode JUMP & JUMPI yang ada.
EIP-4750: EOF - Fungsi (fungsi yang diperkenalkan EOF)
EIP-4750 melangkah lebih jauh dari 4200: ia melarang penggunaan opcode JUMP & JUMPI dan menambahkan alternatif untuk fungsi yang tidak dapat disalin. Ini diimplementasikan dengan memperkenalkan bagian fungsi tertentu dalam bytecode EOF. Fungsi-fungsi ini masing-masing dapat melompat dari opcode JUMPF, CALLF dan RETF yang baru, dan menggunakannya untuk memanggil dan kembali.
EIP-5450: EOF - Validasi Tumpukan (Validasi Tumpukan EOF)
Terakhir, EIP-5450 menambahkan pemeriksaan validasi lain untuk kontrak EOF, kali ini di tumpukan. EIP ini mencegah kontrak EOF menyebarkan kode yang dapat menyebabkan tumpukan underflow, dan overflow dalam beberapa kasus. Dengan EIP ini, klien dapat mengurangi jumlah pemeriksaan validasi saat menjalankan kontrak EOF karena mereka memiliki jaminan yang lebih baik seputar pengecualian terkait tumpukan.
Sebagai pakar non-EVM yang sangat fokus pada EIP itu sendiri, tidak banyak yang bisa saya katakan tentangnya! Jika pembaca ingin mempelajari lebih lanjut tentang EOF, saya merekomendasikan tweet relevan yang diposting oleh lightclients dari tim Geth dan Leo dari tim Solidity.
Penarikan Rantai Suar
Yang terakhir, bagian utama dari "Shapella" (Catatan Penerjemah: nama kolektif Shanghai/Capella) adalah penarikan rantai suar. Bagian perubahan ini dijelaskan dalam spesifikasi lapisan konsensus dan EIP-4895. Sekarang ada meta-spesifikasi yang agak ketinggalan jaman yang menghubungkan perubahan-perubahan ini.
Pada tingkat tinggi, mekanisme penarikan adalah sebagai berikut:
Saat mengusulkan blok, validator memindai indeks validator secara linear untuk menemukan 16 validator pertama dengan kredensial 0x01, yang harus memenuhi salah satu kondisi berikut:
Memiliki saldo di atas 32 ETH (yaitu telah memperoleh hadiah validator)
Dapat ditarik (yaitu telah sepenuhnya keluar dari set validator)
Saldo lebih besar dari 32 ETH (yaitu, hadiah validator telah diperoleh)
Itu dapat ditarik (dapat ditarik, yaitu telah sepenuhnya keluar dari set validator)
Dari sini, validator akan membuat daftar penarikan untuk disertakan dalam ExecutionPayload mereka. Setiap item dalam daftar itu berisi yang berikut:
Validator akan membuat daftar penarikan dari validator ini dan mengemasnya ke dalam ExecutionPayload mereka. Setiap item dalam daftar berisi yang berikut:
WithdrawalIndex: Indeks semua transaksi penarikan yang telah dilakukan - ini membantu membedakan penarikan dalam jumlah yang sama dari alamat yang sama, validator yang sama
ValidatorIndex: indeks validator tempat saldo dinaikkan
ExecutionAddress: Alamat ETH dari lapisan eksekusi, tempat penarikan harus dikirim
Jumlah: Jumlah yang dikirim ke ExecutionAddress, jumlah ini diukur dalam gwei (bukan wei)
Klien lapisan eksekusi akan melakukan penarikan ini setelah transaksi dieksekusi ketika membangun atau memproses blok. Dengan kata lain, penarikan diproses dengan cara yang mirip dengan pencatatan hadiah bukti kerja, dan tidak bersaing dengan transaksi pengguna untuk mendapatkan ruang blok.
Ada beberapa detail lain yang perlu diperhatikan:
Saat memproses penarikan, tidak ada perbedaan prioritas/urutan antara "dana penuh" dan "dana sebagian". Penarikan penuh terjadi ketika validator meninggalkan tim keluar, sedangkan penarikan sebagian terjadi secara berkala, yaitu ketika pemindaian linier dari set validator dilakukan dan nomor indeks validator tertentu dipindai.
Agar penarikan dapat diproses, validator harus menggunakan kredensial 0x01, yang diwakili oleh alamat ETH. Hanya kredensial pasangan kunci BLS 0x00 yang diizinkan saat rantai suar online. Untuk memulai penarikan, validator dengan kredensial 0x00 perlu menandatangani pesan BLSToExecutionChange. Ini akan diaktifkan di peningkatan Capella. Akan ada berbagai alat yang digunakan untuk menandatangani pesan ini, dan validator dapat mengharapkan dukungan dan tutorial untuk alat ini.
Pemindaian validator dilakukan per blok. Jika tidak ada 16 penarikan yang harus diproses setelah memindai subset kumpulan validator, validator akan berhenti memindai dan validator berikutnya akan memulai dari indeks validator yang terakhir dipindai.
Seperti biasa, akan ada beberapa testnet pengembang dan testnet (bahkan mungkin beberapa testnet baru!) bagi validator untuk menjalankan seluruh proses dan mengatasi segala kendala sebelum mainnet diluncurkan.
Shanghai/Capella bukan satu-satunya peningkatan yang mengalami kemajuan! Tim pengembang juga menantikan peningkatan berikutnya.
Peningkatan Cancun
Karena konten upgrade Shanghai sudah penuh, banyak EIP (CFI) yang dipertimbangkan untuk upgrade belum bisa mengikuti upgrade Shanghai. Tim klien mulai mendiskusikan EIP mana yang harus dipertimbangkan untuk pemutakhiran berikutnya: pemutakhiran Cancun (nama lapisan konsensus akan ditentukan)
Dalam hal lapisan konsensus, EIP-4844 telah menjadi EIP pertama yang ditulis ke dalam spesifikasi setelah peningkatan Capella. Belum ada spesifikasi untuk lapisan eksekutif yang dapat mengimplementasikan tata letak ini, namun tim lapisan eksekutif sepakat untuk mengikuti jalur serupa dan memusatkan EIP-4844 pada peningkatan berikutnya.
Mengikuti konvensi peningkatan menggunakan nama kota tempat Devcon diadakan, cancun.md telah dibuat, dengan EIP-4844 secara resmi disertakan dalam peningkatan.
Keputusan ini terjadi pada menit-menit terakhir rapat AllCoreDevs terakhir tahun 2022, sehingga tidak ada waktu untuk mengerjakan proposal lainnya. EIP yang masuk dalam peningkatan CFI di Shanghai tetapi tidak disertakan pada akhirnya dipindahkan ke daftar CFI untuk peningkatan CFI di Cancun. Sebuah postingan juga dibuka di forum Ethereum Magicians untuk membahas kandidat EIP di Cancun. Diskusi mengenai ruang lingkup peningkatan di Cancun harus dimulai dengan sungguh-sungguh awal tahun depan.
Upacara KZG
Hal lain yang dinantikan terkait upgrade Cancun adalah Upacara KZG yang merupakan persyaratan EIP-4844.
Ritual ini akan menghasilkan keacakan yang diperlukan untuk memverifikasi validitas data blob. Agar dianggap aman, hanya satu peserta yang harus jujur. Dengan kata lain, jika semua kecuali satu peserta berkolusi, seluruh proses aman secara kriptografis.
Upacara dimulai pada bulan Januari dan akan terbuka untuk semua orang selama beberapa bulan. Dengan target 10.000 peserta, upacara ini direncanakan menjadi upacara terbesar hingga saat ini! Jika Anda ingin memastikan Anda tidak ketinggalan, ikuti Trent Van Epps di Twitter!
Proses peningkatan pasca merger
Seperti disebutkan dalam pembaruan sebelumnya, setelah merger, mengoordinasikan proses peningkatan Ethereum pada lapisan eksekusi dan lapisan konsensus adalah hal penting yang harus dilakukan. Dari perspektif tingkat tinggi, lapisan eksekusi menggunakan Yellow Paper & EIP untuk menjelaskan modifikasi, sedangkan lapisan konsensus menggunakan spesifikasi Python yang dapat dieksekusi.
Manfaat dari proses lapisan eksekutif adalah bahwa EIP dikenal oleh masyarakat dan diformat sedemikian rupa sehingga secara jelas menunjukkan alasan di balik usulan tersebut. Buku kuning dengan banyak konten matematika yang dipasangkan dengan EIP, dan kebutuhan untuk mengembalikan spesifikasi ke dalam konteks setiap EIP, membuat spesifikasi lapisan eksekusi sulit untuk dipahami dan diperluas.
Masalah dengan lapisan konsensus adalah sebaliknya: ia memiliki spesifikasi yang jelas dan dapat dimengerti dalam satu repositori, namun perubahannya tidak nyata dan proposalnya terkubur dalam PR publik lainnya di dalam repositori.
Dengan diperkenalkannya spesifikasi lapisan eksekusi Ethereum, kami berharap dapat memperpendek kesenjangan ini dari sisi lapisan eksekusi. Dan, dengan beberapa perselisihan proses, kita mungkin bisa memasukkan EIP ke dalam proses lapisan konsensus!
Oleh karena itu, ketika cakupan peningkatan Shanghai didiskusikan dan diselesaikan, menjadi jelas bahwa ada bagian lain dari proses yang mungkin hilang: memungkinkan masyarakat untuk mengekspresikan preferensi relatif mereka terhadap perubahan dan terlibat dalam diskusi tentang keseluruhan cakupan peningkatan (daripada masing-masing EIP) Diskusikan hal ini dan jadikan ini bagian dari keputusan pertemuan lapisan AllCoreDev dan konsensus.
Belum jelas seperti apa tampilannya – saya ingin sarannya! — namun seiring bertambahnya jumlah pemangku kepentingan yang secara aktif terlibat dalam perubahan protokol, begitu pula dengan jumlah wilayah yang terkena dampak perubahan lapisan pertama, jelas bahwa kita memerlukan sesuatu.
Untungnya, kita tidak perlu memulai dari awal. Ethereum Magicians telah ada selama bertahun-tahun, dan pertemuan offline, pertemuan kelompok khusus, atau pertemuan komunitas mungkin merupakan titik awal yang baik untuk ekspansi.
Harapkan lebih banyak kemajuan dalam hal ini pada awal tahun 2023!
Pembaruan Persekutuan Perjanjian
Dengan percontohan Protocol Guild (PG) yang kini sudah setengah jalan, mereka telah merilis laporan untuk melihat perkembangannya dan mempertimbangkan langkah selanjutnya untuk proyek tersebut.
Sebagai pengingat, PG adalah mekanisme pendanaan tanpa izin untuk pengembang klien Ethereum Layer 1, peneliti protokol, dan kontributor pendukung (seperti Anda).
Mekanisme ini berpusat pada individu, bukan organisasi. Singkatnya, setiap anggota berhak mendapatkan bagian dari token guild, yang ditimbang berdasarkan berapa lama mereka berkontribusi pada Ethereum. Penambahan dan penghapusan anggota dilakukan dengan cara Ethereum yang sebenarnya - berdasarkan serangkaian standar dan konsensus kasar dalam PG. Daftar ini kemudian akan dimasukkan ke dalam rantai menggunakan kontrak pemisahan 0xSplit. Donor kemudian dapat mengirimkan dana langsung ke alamat penerima, atau ke kontrak vesting yang melepaskan dana ke alamat penerima.
Laporan sementara percontohan dirangkum dalam tweet ini. Berikut ini beberapa hal penting
Uji coba ini mengumpulkan $9,7 juta dari organisasi seperti Lido, Uniswap, ENS, NounsDAO, dan MolochDAO, serta donatur tetap dari individu (terima kasih Tetranode!) - terima kasih kepada semua orang yang memungkinkan hal ini!
PG memiliki 90 anggota pada saat peluncuran dan sekarang memiliki 128 anggota, dengan $5 juta didistribusikan di antara mereka
Rata-rata, setiap anggota menerima $39,000, dengan yang terendah $13,000 dan tertinggi mencapai $79,000
Arsitektur PG berubah dan akan mendukung L2 dan menghilangkan kebutuhan multi-sig untuk memperbarui bobot
Hasil awal ini menunjukkan bahwa PG bekerja sesuai rencana: sebuah mekanisme untuk mendistribusikan sekeranjang token ke kelompok kontributor protokol yang melakukan inkubasi mandiri dan berkembang. Proyek ini tidak akan bisa berjalan seperti sekarang ini tanpa dukungan dari para donor percontohan.
Melihat ke masa depan, sekarang adalah waktu untuk memperluas jangkauan PG dan mewujudkan potensi penuhnya: memberikan kompensasi yang kompetitif dan disesuaikan dengan risiko kepada pengelola Ethereum. Hal termudah untuk dilakukan di sini adalah proyek tersebut didonasikan ke PG sejak awal, seperti yang dikatakan Danny Ryan dalam tweet peluncuran PG.
Sebagian besar donasi dalam uji coba ini berasal dari proyek-proyek besar dengan pendanaan dalam jumlah besar. Jika Protocol Guild dapat meyakinkan proyek-proyek ini untuk menyumbang ke PG sejak hari pertama, ketika token mereka masih benar-benar “tidak berharga”, maka pengelola Ethereum dapat memperoleh manfaat dari keseluruhan perkembangan proyek-proyek yang sukses ini.
Ketika cukup banyak proyek yang dilibatkan, insentif dapat mempertahankan talenta terbaik dalam perjanjian pemeliharaan alih-alih menarik mereka keluar.
Untuk mendukung hal ini, dan banyak jenis donasi lainnya, PG memerlukan perombakan teknologi. Versi berikutnya akan mendukung L1 dan L2 dan semakin mengurangi jejak tata kelola on-chainnya.
Jika Anda adalah proyek yang ingin menyumbang ke Protocol Guild, silakan hubungi saya - DM saya terbuka!
Menindaklanjuti
Itu mengakhiri tahun 2022... Sungguh tahun yang luar biasa! Tiga bulan lalu, kami bahkan belum bergabung! Sekarang Ethereum memiliki bukti kepemilikan yang diam-diam berjalan di latar belakang, fokusnya telah beralih ke transaksi di masa depan.
Saat semua orang kembali pada bulan Januari, Anda dapat mengharapkan:
Shanghai/Capella meningkatkan testnet pengembang dan shadow fork
Upacara KZG berlangsung secara online
Diskusi seputar Cancun dan bagaimana proses peningkatan jaringan harus berkembang agar dapat lebih menangkap preferensi masyarakat
Percontohan serikat protokol akan berakhir dan kami akan mengumumkan struktur pasca-percontohan.