EIP-2537: Perjalanan panjang dari 2020 hingga 2025
EIP-2537 adalah instruksi prakompilasi EVM yang ditambahkan dalam pembaruan fork Pectra terbaru Ethereum. Instruksi ini menambah berbagai fungsi perhitungan dari kurva BLS12-381 ke EVM, seperti perhitungan pasangan di atas domain kurva.
EIP-2537 pertama kali diusulkan pada tahun 2020, dan baru dikonfirmasi untuk dimasukkan dalam peningkatan Ethereum pada tahun 2025. Artikel ini akan memperkenalkan proses pemerintahan EIP-2537 dan membahas mengapa proposal ini baru diadopsi setelah 5 tahun.
Latar Belakang Proposal
Pada Januari 2017, Vitalik Buterin pertama kali memperkenalkan algoritma pasangan dan kurva alt_bn128 dalam sebuah artikel. Kemudian pada bulan Februari, Vitalik dan Christian Reitwiessner mengusulkan EIP-196 dan EIP-197, yang menyarankan untuk menambahkan dukungan perhitungan kurva alt_bn128 ke EVM.
Pembaruan Byzantium pada bulan Oktober 2017 secara resmi memasukkan kurva alt_bn128, mewujudkan perhitungan pasangan domain kurva di dalam EVM, sehingga verifikasi bukti ZK-Snarks dapat dilakukan di dalam EVM.
Namun, seiring dengan perkembangan kriptografi, pada November 2017 tim zcash mengusulkan kurva BLS12-381, yang memiliki keamanan yang lebih tinggi dan kinerja yang lebih baik dibandingkan alt_bn128. Banyak protokol blockchain kemudian mengadopsi kurva BLS12-381 sebagai pengganti alt_bn128.
Pada Mei 2018, Justin Drake menulis bahwa pembaruan PoS dan sharding masa depan Ethereum dapat menggunakan algoritma BLS multi-tanda tangan berbasis BLS12-381. Ini meletakkan dasar untuk pembaruan ETH2 yang akan datang.
Seiring dengan pengembangan ETH2, desakan untuk memperkenalkan BLS12-381 ke dalam lapisan eksekusi semakin meningkat. Pada Februari 2020, para peneliti mengusulkan EIP-2537, berharap untuk mengujinya bersama dengan jaringan uji ETH2. Penulis EIP-2537, Alex Stokes, menyerukan agar ini dimasukkan ke dalam hard fork Berlin.
Perlu dicatat bahwa penulis EIP-2537 juga merupakan salah satu pendiri Matter Labs, yang produk paling terkenal adalah ZKSync.
Berlin yang Bergetar
Sebelum memperkenalkan konten selanjutnya, perlu untuk memahami EIP-1962. Ini adalah proposal pra-kompilasi pasangan domain kurva elips pertama yang diajukan oleh Matter Labs pada April 2019, mendukung tiga kurva: BLS12, BN, dan MNT4/6.
Rencana EIP-1962 untuk menambah 10 instruksi pra-kompilasi sekaligus untuk menangani berbagai kurva. Namun, banyak pengembang menganggapnya terlalu rumit untuk diimplementasikan dan tidak ramah bagi insinyur kontrak pintar. Namun, Matter Labs telah menyelesaikan pengembangan algoritma dan menyediakan implementasi referensi multi-bahasa.
Untuk menyelesaikan masalah EIP-1962, Matter Labs mengusulkan beberapa skema pemisahan EIP pada bulan Februari 2020:
EIP-2537 menyediakan dukungan BLS12-381
EIP-2539 menyediakan dukungan BLS12-377
PR#2541 menyediakan dukungan kurva BLS12-377(Zexe ), tetapi belum mendapatkan nomor EIP.
Di antara semuanya, EIP-2537 adalah yang paling penting, karena lapisan konsensus juga menggunakan kurva BLS12-381. Tujuan inti dari EIP-1962 dan EIP-2537 adalah untuk mewujudkan verifikasi tanda tangan BLS di lapisan konsensus di jaringan utama.
Saat itu ETH2 sedang mengembangkan kontrak deposit. Karena lapisan eksekusi tidak memiliki verifikasi BLS, kontrak deposit dalam desain asli tidak memverifikasi tanda tangan, melainkan diverifikasi oleh lapisan konsensus, jika tidak benar maka deposit akan gagal dan menyebabkan kerugian dana.
Oleh karena itu, pengembang inti ingin memperkenalkan BLS12-381 precompiled, untuk memverifikasi tanda tangan dalam kontrak deposito guna menghindari risiko dana. Ini juga merupakan alasan mengapa pengembang saat itu memperhatikan EIP-1962 dan EIP-2537.
Setelah EIP-2537 diajukan, Vitalik segera menunjukkan serangkaian masalah, yang terutama berfokus pada konten dokumen. Penulis kemudian memberikan tanggapan dan diskusi.
Pertemuan pengembang inti pada 6 Maret 2020 membahas EIP-2537. Vitalik percaya bahwa ini sangat efektif untuk pembuktian SNARK rekursif dan tidak akan merugikan Ethereum dalam jangka panjang. Pertemuan tersebut mengkonfirmasi posisi prioritas EIP-2537, semua klien sepakat untuk segera mengimplementasikannya dan menyelesaikan pengembangan sebelum peningkatan Berlin.
Kemudian EIP-2537 menjadi tugas prioritas tinggi. Pertemuan pada 20 Maret 83 kembali mengutamakan pembahasan proposal tersebut, memastikan bahwa itu menggantikan EIP-1962 sebagai proposal BLS inti, dan dimasukkan dalam daftar pra-pemilihan upgrade Berlin.
Rapat bulan April 84 secara resmi memasukkan EIP-2537 ke dalam hard fork Berlin, menetapkan garis waktu pelaksanaan pada bulan April dan pengujian pada bulan Mei-Juni. EIP-2537 dicatat sebagai hal yang paling prioritas.
Setelah itu, EIP-2537 memasuki fase pengembangan dan pengujian yang besar, di hampir setiap pertemuan pengembang inti berikutnya yang berlangsung hampir 20 kali, selalu ada diskusi terkait.
Diskusi dalam pertemuan 85 membahas masalah pengkodean ABI. Karena Matter Labs telah menyelesaikan implementasi Rust, klien Besu menyatakan bahwa mereka telah secara dasar mengimplementasikan fungsi EIP-2537, tetapi Geth menyatakan bahwa mereka belum memulai pekerjaan.
Rapat 86 semua node kembali menyinkronkan keadaan implementasi, Geth menyatakan telah menyelesaikan sebagian pekerjaan tetapi masih ada banyak tugas yang harus diselesaikan.
Inti dari pertemuan 87 adalah masalah implementasi EIP-2537. Pengembang Geth menyatakan bahwa ada PR sepanjang 16000 baris untuk implementasi EIP-2537, tetapi tidak dapat memastikan apakah itu aman dan efektif, hanya bisa dinilai melalui pengujian fuzz sederhana. Geth percaya bahwa kemungkinan besar tidak akan dapat menyelesaikan pengembangan terkait sebelum waktu yang dijadwalkan di Berlin.
Hudson Jameson mengusulkan untuk mencari insinyur kriptografi untuk membantu tinjauan PR Geth, dan menyarankan untuk menguji keamanan melalui jaringan uji. Tim ETH2 juga dapat berpartisipasi dalam pengujian.
Perlu ditambahkan bahwa PR implementasi EIP-2537 Geth menggunakan banyak kode assembly untuk menjamin efisiensi, sehingga sulit dibaca dan dipahami. Alex Vlasov menyarankan untuk menghapus optimasi assembly yang kompleks untuk mengurangi kesulitan dalam peninjauan.
Meskipun salah satu tujuan utama EIP-2537 adalah untuk mendukung kontrak deposit ETH2, pengembang kontrak deposit dalam pertemuan ini menyatakan bahwa versi yang tidak menggunakan EIP-2537 telah diaudit, beberapa pengembang menyarankan agar tidak meluncurkan versi baru yang menggunakan EIP-2537.
Akhirnya, rapat memutuskan untuk menambahkan pengujian khusus YOLO testnet untuk EIP-2537. Pada saat ini, terlihat bahwa dengan selesainya kontrak penyimpanan, pentingnya EIP-2537 telah menurun secara signifikan, dan pengembang Geth percaya bahwa mungkin tidak dapat direalisasikan sebelum peningkatan Berlin. Tampaknya EIP-2537 tidak akan dimasukkan dalam Berlin.
Pada pertemuan 88, pengembang Geth menemukan bahwa terdapat serangkaian masalah dalam implementasi PR EIP-2537 yang perlu diperbaiki dan diuji lebih lanjut. Pada saat itu, Geth memiliki dua versi implementasi, satu yang mengandung optimasi assembly, dan yang lainnya sepenuhnya ditulis dalam Go. Beberapa orang menyarankan untuk langsung menggunakan versi Go untuk mengurangi kesulitan dalam peninjauan kode.
Pertemuan 89 muncul masalah yang lebih serius, jaringan uji YOLO mengalami anomali, dicurigai disebabkan oleh tanda tangan BLS, tetapi pengembang EIP-2537 membantahnya. Kabar baiknya adalah kontrak setoran yang berdasarkan EIP-2537 hampir selesai dikembangkan, sedang menunggu audit.
Pertemuan 90 telah menetapkan batas waktu peluncuran upgrade Berlin pada bulan Juli. Pertemuan juga membahas masalah keberagaman klien, di mana ada yang mengusulkan untuk membekukan implementasi EIP saat ini untuk mengurangi biaya pengembangan klien lainnya. Pertemuan 91 bahkan mengusulkan penggunaan solusi modular untuk meningkatkan keberagaman klien.
Konferensi 92 sekali lagi mengonfirmasi EIP-2537 sebagai EIP yang diperlukan untuk upgrade Berlin.
Pertemuan 96 membahas apakah EIP-2539 juga akan dimasukkan dalam pengujian Berlin, karena Celo telah memasukkan EIP-2537 dan EIP-2539 ke dalam pembaruan jaringannya. Namun, pengembang Geth menolak, berpendapat bahwa EIP-2537 sendiri masih belum sepenuhnya teruji. Keputusan akhir adalah tidak menambahkan EIP-2696 dalam Berlin.
Konferensi 99 memutuskan untuk mengeluarkan EIP-2537 dari jaringan pengujian YOLO v3 dan peningkatan Berlin, alasan utamanya adalah ia menghabiskan terlalu banyak waktu pengembang yang mempengaruhi pengembangan EIP lainnya. Faktor sekunder adalah Ethereum Foundation mengusulkan EVM384 sebagai alternatif. Namun, para pengembang menyatakan kekhawatiran tentang keamanannya.
Inilah perjalanan awal EIP-2537. Ini adalah salah satu EIP terpenting dari upgrade Berlin, tetapi akhirnya dibatalkan karena masalah implementasi. Pada April 2021, Ethereum menyelesaikan upgrade Berlin, dan implementasi EIP inti seperti EIP-2565 relatif sederhana, terlihat agak tipis, karena EIP-2537 yang paling rumit telah dihapus.
Perkembangan Selanjutnya
Seperti yang kita ketahui, setiap kali Ethereum melakukan upgrade, ada proposal inti, seperti London setelah Berlin yang memperkenalkan EIP-1559. Untuk EIP-2537 yang pernah menjadi proposal inti, akan sulit untuk memasukkannya kembali dalam upgrade selanjutnya.
Saat peningkatan London, pengembang mempertimbangkan untuk menambahkan EIP-2537. Rapat 109 menyinkronkan status pengembangannya, karena penggunaan perpustakaan baru memicu diskusi gas. Seseorang mengusulkan untuk mengganti dengan EVM384. Namun, rapat 111 mengeluarkannya dari peningkatan London karena kompleksitas, terutama karena perubahan perpustakaan yang menyebabkan perubahan harga gas, perlu dievaluasi ulang.
Pada bulan Juni 2021, secara resmi diusulkan untuk memasukkan EIP-2537 ke dalam peningkatan Shanghai. Namun setelah London, The Merge menyita banyak waktu pengembang. Setelah The Merge selesai pada bulan September 2022, pengembang lapisan eksekusi baru memiliki kesempatan untuk melanjutkan diskusi tentang tujuan Shanghai.
Pertemuan singkat 150 pada bulan November 2022 membahas apakah akan memasukkan Shanghai, tetapi pengembang berpikir sebaiknya ditunda, inti dari Shanghai adalah mendukung penarikan PoS. Akhirnya EIP-2537 tidak dimasukkan ke dalam peningkatan Shanghai yang berfokus pada penarikan.
Lebih buruk lagi, peningkatan Cancun belum membahas EIP-2537, karena inti dari itu adalah mendukung EIP-4844, untuk menyediakan ketersediaan data Blob untuk lapisan kedua.
Akhirnya, pada pertemuan 181 Februari 2024, diskusi tentang peningkatan Pectra yang menyertakan EIP-2537, para pengembang percaya bahwa implementasi bukan lagi masalah, hanya ada masalah penetapan harga gas.
Pada pertemuan tanggal 19 Desember 2024, para pengembang Nethermind akhirnya menyetujui model penetapan harga EIP-2537. Pengusul awal, Matter Labs, hampir keluar dari diskusi pada saat itu. Pertemuan 203 pada bulan Januari 2025 membahas penetapan ulang harga, pengembang Geth menyarankan untuk meningkatkan biaya gas sebesar 20%, dan mendapatkan dukungan dari tim Besu.
Ringkasan
EIP-2537 telah melalui perjalanan panjang selama 5 tahun dari diusulkan hingga diadopsi. Itu pernah menjadi inti dari peningkatan Berlin, tetapi ditinggalkan karena kesulitan dalam implementasinya. Kemudian Ethereum memasuki proses sejarah PoS, EIP lapisan eksekusi murni yang kompleks tidak mendapat perhatian, dan banyak EIP terkait PoS menjadi tujuan utama, yang menyebabkan EIP-2537 tidak diterima dalam waktu lama. Sampai tahun 2025, dengan solusi untuk masalah teknis utama, EIP-2537 akhirnya memiliki harapan untuk diimplementasikan dalam peningkatan Pectra.
Proses ini menunjukkan bahwa apakah EIP dapat dimasukkan ke dalam pembaruan Ethereum, tidak hanya bergantung pada nilai teknisnya sendiri, tetapi juga perlu mempertimbangkan tahap perkembangan dan prioritas keseluruhan Ethereum. Setiap pembaruan memiliki tema tersendiri, hanya EIP yang memenuhi kebutuhan saat ini dan matang secara teknis yang dapat akhirnya diadopsi.
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.
11 Suka
Hadiah
11
8
Bagikan
Komentar
0/400
LuckyPig
· 9jam yang lalu
冲就完了💪masukkan posisi！🚗坐稳扶好，马上To da moon 🛫坐稳扶好，马上To da moon 🛫坐稳扶好，马上To da moon 🛫坐稳扶好，马上To da moon 🛫坐稳扶好，马上To da moon 🛫坐稳扶好，马上To da moon 🛫
Lihat AsliBalas0
DataBartender
· 9jam yang lalu
Tunggu selama 5 tahun ini terlalu sulit.
Lihat AsliBalas0
MetaverseHobo
· 9jam yang lalu
5 tahun menunggu adalah siksaan bagi orang?
Lihat AsliBalas0
AirdropHunterXM
· 9jam yang lalu
Sudah lima tahun? Tindakan V God terlalu lambat, ya?
Lihat AsliBalas0
defi_detective
· 10jam yang lalu
5 tahun terlalu lama, membuat orang mati terburu-buru.
Lihat AsliBalas0
MevWhisperer
· 10jam yang lalu
Lima tahun baru lulus, bikin orang pengen ngebanting komputer.
Lihat AsliBalas0
NoodlesOrTokens
· 10jam yang lalu
5 tahun terlalu lambat, ya? Vitalik Buterin sedang apa?
Lihat AsliBalas0
rekt_but_not_broke
· 10jam yang lalu
Lima tahun baru berlalu! Efisiensi ini bahkan lebih buruk daripada Newton menemukan gravitasi.
Perjalanan panjang EIP-2537: dari prioritas tinggi Berlin hingga akhirnya diadopsi dalam pembaruan Pectra
EIP-2537: Perjalanan panjang dari 2020 hingga 2025
EIP-2537 adalah instruksi prakompilasi EVM yang ditambahkan dalam pembaruan fork Pectra terbaru Ethereum. Instruksi ini menambah berbagai fungsi perhitungan dari kurva BLS12-381 ke EVM, seperti perhitungan pasangan di atas domain kurva.
EIP-2537 pertama kali diusulkan pada tahun 2020, dan baru dikonfirmasi untuk dimasukkan dalam peningkatan Ethereum pada tahun 2025. Artikel ini akan memperkenalkan proses pemerintahan EIP-2537 dan membahas mengapa proposal ini baru diadopsi setelah 5 tahun.
Latar Belakang Proposal
Pada Januari 2017, Vitalik Buterin pertama kali memperkenalkan algoritma pasangan dan kurva alt_bn128 dalam sebuah artikel. Kemudian pada bulan Februari, Vitalik dan Christian Reitwiessner mengusulkan EIP-196 dan EIP-197, yang menyarankan untuk menambahkan dukungan perhitungan kurva alt_bn128 ke EVM.
Pembaruan Byzantium pada bulan Oktober 2017 secara resmi memasukkan kurva alt_bn128, mewujudkan perhitungan pasangan domain kurva di dalam EVM, sehingga verifikasi bukti ZK-Snarks dapat dilakukan di dalam EVM.
Namun, seiring dengan perkembangan kriptografi, pada November 2017 tim zcash mengusulkan kurva BLS12-381, yang memiliki keamanan yang lebih tinggi dan kinerja yang lebih baik dibandingkan alt_bn128. Banyak protokol blockchain kemudian mengadopsi kurva BLS12-381 sebagai pengganti alt_bn128.
Pada Mei 2018, Justin Drake menulis bahwa pembaruan PoS dan sharding masa depan Ethereum dapat menggunakan algoritma BLS multi-tanda tangan berbasis BLS12-381. Ini meletakkan dasar untuk pembaruan ETH2 yang akan datang.
Seiring dengan pengembangan ETH2, desakan untuk memperkenalkan BLS12-381 ke dalam lapisan eksekusi semakin meningkat. Pada Februari 2020, para peneliti mengusulkan EIP-2537, berharap untuk mengujinya bersama dengan jaringan uji ETH2. Penulis EIP-2537, Alex Stokes, menyerukan agar ini dimasukkan ke dalam hard fork Berlin.
Perlu dicatat bahwa penulis EIP-2537 juga merupakan salah satu pendiri Matter Labs, yang produk paling terkenal adalah ZKSync.
Berlin yang Bergetar
Sebelum memperkenalkan konten selanjutnya, perlu untuk memahami EIP-1962. Ini adalah proposal pra-kompilasi pasangan domain kurva elips pertama yang diajukan oleh Matter Labs pada April 2019, mendukung tiga kurva: BLS12, BN, dan MNT4/6.
Rencana EIP-1962 untuk menambah 10 instruksi pra-kompilasi sekaligus untuk menangani berbagai kurva. Namun, banyak pengembang menganggapnya terlalu rumit untuk diimplementasikan dan tidak ramah bagi insinyur kontrak pintar. Namun, Matter Labs telah menyelesaikan pengembangan algoritma dan menyediakan implementasi referensi multi-bahasa.
Untuk menyelesaikan masalah EIP-1962, Matter Labs mengusulkan beberapa skema pemisahan EIP pada bulan Februari 2020:
Di antara semuanya, EIP-2537 adalah yang paling penting, karena lapisan konsensus juga menggunakan kurva BLS12-381. Tujuan inti dari EIP-1962 dan EIP-2537 adalah untuk mewujudkan verifikasi tanda tangan BLS di lapisan konsensus di jaringan utama.
Saat itu ETH2 sedang mengembangkan kontrak deposit. Karena lapisan eksekusi tidak memiliki verifikasi BLS, kontrak deposit dalam desain asli tidak memverifikasi tanda tangan, melainkan diverifikasi oleh lapisan konsensus, jika tidak benar maka deposit akan gagal dan menyebabkan kerugian dana.
Oleh karena itu, pengembang inti ingin memperkenalkan BLS12-381 precompiled, untuk memverifikasi tanda tangan dalam kontrak deposito guna menghindari risiko dana. Ini juga merupakan alasan mengapa pengembang saat itu memperhatikan EIP-1962 dan EIP-2537.
Setelah EIP-2537 diajukan, Vitalik segera menunjukkan serangkaian masalah, yang terutama berfokus pada konten dokumen. Penulis kemudian memberikan tanggapan dan diskusi.
Pertemuan pengembang inti pada 6 Maret 2020 membahas EIP-2537. Vitalik percaya bahwa ini sangat efektif untuk pembuktian SNARK rekursif dan tidak akan merugikan Ethereum dalam jangka panjang. Pertemuan tersebut mengkonfirmasi posisi prioritas EIP-2537, semua klien sepakat untuk segera mengimplementasikannya dan menyelesaikan pengembangan sebelum peningkatan Berlin.
Kemudian EIP-2537 menjadi tugas prioritas tinggi. Pertemuan pada 20 Maret 83 kembali mengutamakan pembahasan proposal tersebut, memastikan bahwa itu menggantikan EIP-1962 sebagai proposal BLS inti, dan dimasukkan dalam daftar pra-pemilihan upgrade Berlin.
Rapat bulan April 84 secara resmi memasukkan EIP-2537 ke dalam hard fork Berlin, menetapkan garis waktu pelaksanaan pada bulan April dan pengujian pada bulan Mei-Juni. EIP-2537 dicatat sebagai hal yang paling prioritas.
Setelah itu, EIP-2537 memasuki fase pengembangan dan pengujian yang besar, di hampir setiap pertemuan pengembang inti berikutnya yang berlangsung hampir 20 kali, selalu ada diskusi terkait.
Diskusi dalam pertemuan 85 membahas masalah pengkodean ABI. Karena Matter Labs telah menyelesaikan implementasi Rust, klien Besu menyatakan bahwa mereka telah secara dasar mengimplementasikan fungsi EIP-2537, tetapi Geth menyatakan bahwa mereka belum memulai pekerjaan.
Rapat 86 semua node kembali menyinkronkan keadaan implementasi, Geth menyatakan telah menyelesaikan sebagian pekerjaan tetapi masih ada banyak tugas yang harus diselesaikan.
Inti dari pertemuan 87 adalah masalah implementasi EIP-2537. Pengembang Geth menyatakan bahwa ada PR sepanjang 16000 baris untuk implementasi EIP-2537, tetapi tidak dapat memastikan apakah itu aman dan efektif, hanya bisa dinilai melalui pengujian fuzz sederhana. Geth percaya bahwa kemungkinan besar tidak akan dapat menyelesaikan pengembangan terkait sebelum waktu yang dijadwalkan di Berlin.
Hudson Jameson mengusulkan untuk mencari insinyur kriptografi untuk membantu tinjauan PR Geth, dan menyarankan untuk menguji keamanan melalui jaringan uji. Tim ETH2 juga dapat berpartisipasi dalam pengujian.
Perlu ditambahkan bahwa PR implementasi EIP-2537 Geth menggunakan banyak kode assembly untuk menjamin efisiensi, sehingga sulit dibaca dan dipahami. Alex Vlasov menyarankan untuk menghapus optimasi assembly yang kompleks untuk mengurangi kesulitan dalam peninjauan.
Meskipun salah satu tujuan utama EIP-2537 adalah untuk mendukung kontrak deposit ETH2, pengembang kontrak deposit dalam pertemuan ini menyatakan bahwa versi yang tidak menggunakan EIP-2537 telah diaudit, beberapa pengembang menyarankan agar tidak meluncurkan versi baru yang menggunakan EIP-2537.
Akhirnya, rapat memutuskan untuk menambahkan pengujian khusus YOLO testnet untuk EIP-2537. Pada saat ini, terlihat bahwa dengan selesainya kontrak penyimpanan, pentingnya EIP-2537 telah menurun secara signifikan, dan pengembang Geth percaya bahwa mungkin tidak dapat direalisasikan sebelum peningkatan Berlin. Tampaknya EIP-2537 tidak akan dimasukkan dalam Berlin.
Pada pertemuan 88, pengembang Geth menemukan bahwa terdapat serangkaian masalah dalam implementasi PR EIP-2537 yang perlu diperbaiki dan diuji lebih lanjut. Pada saat itu, Geth memiliki dua versi implementasi, satu yang mengandung optimasi assembly, dan yang lainnya sepenuhnya ditulis dalam Go. Beberapa orang menyarankan untuk langsung menggunakan versi Go untuk mengurangi kesulitan dalam peninjauan kode.
Pertemuan 89 muncul masalah yang lebih serius, jaringan uji YOLO mengalami anomali, dicurigai disebabkan oleh tanda tangan BLS, tetapi pengembang EIP-2537 membantahnya. Kabar baiknya adalah kontrak setoran yang berdasarkan EIP-2537 hampir selesai dikembangkan, sedang menunggu audit.
Pertemuan 90 telah menetapkan batas waktu peluncuran upgrade Berlin pada bulan Juli. Pertemuan juga membahas masalah keberagaman klien, di mana ada yang mengusulkan untuk membekukan implementasi EIP saat ini untuk mengurangi biaya pengembangan klien lainnya. Pertemuan 91 bahkan mengusulkan penggunaan solusi modular untuk meningkatkan keberagaman klien.
Konferensi 92 sekali lagi mengonfirmasi EIP-2537 sebagai EIP yang diperlukan untuk upgrade Berlin.
Pertemuan 96 membahas apakah EIP-2539 juga akan dimasukkan dalam pengujian Berlin, karena Celo telah memasukkan EIP-2537 dan EIP-2539 ke dalam pembaruan jaringannya. Namun, pengembang Geth menolak, berpendapat bahwa EIP-2537 sendiri masih belum sepenuhnya teruji. Keputusan akhir adalah tidak menambahkan EIP-2696 dalam Berlin.
Konferensi 99 memutuskan untuk mengeluarkan EIP-2537 dari jaringan pengujian YOLO v3 dan peningkatan Berlin, alasan utamanya adalah ia menghabiskan terlalu banyak waktu pengembang yang mempengaruhi pengembangan EIP lainnya. Faktor sekunder adalah Ethereum Foundation mengusulkan EVM384 sebagai alternatif. Namun, para pengembang menyatakan kekhawatiran tentang keamanannya.
Inilah perjalanan awal EIP-2537. Ini adalah salah satu EIP terpenting dari upgrade Berlin, tetapi akhirnya dibatalkan karena masalah implementasi. Pada April 2021, Ethereum menyelesaikan upgrade Berlin, dan implementasi EIP inti seperti EIP-2565 relatif sederhana, terlihat agak tipis, karena EIP-2537 yang paling rumit telah dihapus.
Perkembangan Selanjutnya
Seperti yang kita ketahui, setiap kali Ethereum melakukan upgrade, ada proposal inti, seperti London setelah Berlin yang memperkenalkan EIP-1559. Untuk EIP-2537 yang pernah menjadi proposal inti, akan sulit untuk memasukkannya kembali dalam upgrade selanjutnya.
Saat peningkatan London, pengembang mempertimbangkan untuk menambahkan EIP-2537. Rapat 109 menyinkronkan status pengembangannya, karena penggunaan perpustakaan baru memicu diskusi gas. Seseorang mengusulkan untuk mengganti dengan EVM384. Namun, rapat 111 mengeluarkannya dari peningkatan London karena kompleksitas, terutama karena perubahan perpustakaan yang menyebabkan perubahan harga gas, perlu dievaluasi ulang.
Pada bulan Juni 2021, secara resmi diusulkan untuk memasukkan EIP-2537 ke dalam peningkatan Shanghai. Namun setelah London, The Merge menyita banyak waktu pengembang. Setelah The Merge selesai pada bulan September 2022, pengembang lapisan eksekusi baru memiliki kesempatan untuk melanjutkan diskusi tentang tujuan Shanghai.
Pertemuan singkat 150 pada bulan November 2022 membahas apakah akan memasukkan Shanghai, tetapi pengembang berpikir sebaiknya ditunda, inti dari Shanghai adalah mendukung penarikan PoS. Akhirnya EIP-2537 tidak dimasukkan ke dalam peningkatan Shanghai yang berfokus pada penarikan.
Lebih buruk lagi, peningkatan Cancun belum membahas EIP-2537, karena inti dari itu adalah mendukung EIP-4844, untuk menyediakan ketersediaan data Blob untuk lapisan kedua.
Akhirnya, pada pertemuan 181 Februari 2024, diskusi tentang peningkatan Pectra yang menyertakan EIP-2537, para pengembang percaya bahwa implementasi bukan lagi masalah, hanya ada masalah penetapan harga gas.
Pada pertemuan tanggal 19 Desember 2024, para pengembang Nethermind akhirnya menyetujui model penetapan harga EIP-2537. Pengusul awal, Matter Labs, hampir keluar dari diskusi pada saat itu. Pertemuan 203 pada bulan Januari 2025 membahas penetapan ulang harga, pengembang Geth menyarankan untuk meningkatkan biaya gas sebesar 20%, dan mendapatkan dukungan dari tim Besu.
Ringkasan
EIP-2537 telah melalui perjalanan panjang selama 5 tahun dari diusulkan hingga diadopsi. Itu pernah menjadi inti dari peningkatan Berlin, tetapi ditinggalkan karena kesulitan dalam implementasinya. Kemudian Ethereum memasuki proses sejarah PoS, EIP lapisan eksekusi murni yang kompleks tidak mendapat perhatian, dan banyak EIP terkait PoS menjadi tujuan utama, yang menyebabkan EIP-2537 tidak diterima dalam waktu lama. Sampai tahun 2025, dengan solusi untuk masalah teknis utama, EIP-2537 akhirnya memiliki harapan untuk diimplementasikan dalam peningkatan Pectra.
Proses ini menunjukkan bahwa apakah EIP dapat dimasukkan ke dalam pembaruan Ethereum, tidak hanya bergantung pada nilai teknisnya sendiri, tetapi juga perlu mempertimbangkan tahap perkembangan dan prioritas keseluruhan Ethereum. Setiap pembaruan memiliki tema tersendiri, hanya EIP yang memenuhi kebutuhan saat ini dan matang secara teknis yang dapat akhirnya diadopsi.