EIP-2537: Jalan Panjang dari Kontroversi ke Adopsi
EIP-2537 adalah instruksi prekompilasi EVM yang ditambahkan dalam pembaruan fork Pectra terbaru Ethereum. Instruksi ini menambah berbagai fungsi perhitungan untuk kurva BLS12-381 di EVM, seperti perhitungan pasangan di domain kurva.
EIP-2537 awalnya diajukan pada tahun 2020, dan baru dikonfirmasi untuk dimasukkan dalam upgrade Ethereum pada tahun 2025. Artikel ini akan memperkenalkan perjalanan tata kelola EIP-2537, serta membahas mengapa proposal ini memakan waktu 5 tahun sebelum akhirnya diadopsi.
Latar Belakang Proposal
Pada Januari 2017, Vitalik Buterin pertama kali memperkenalkan algoritma pasangan dan kurva alt_bn128 dalam sebuah artikel. Kemudian, Vitalik dan Christian Reitwiessner mengusulkan EIP-196 dan EIP-197, yang merekomendasikan penambahan dukungan perhitungan kurva alt_bn128 ke EVM.
Pembaruan Byzantium pada bulan Oktober 2017 secara resmi memperkenalkan kurva alt_bn128, yang memungkinkan perhitungan pasangan bidang kurva di dalam EVM, sehingga verifikasi bukti ZK-Snarks dapat dilakukan di dalam EVM.
Namun, seiring dengan perkembangan kriptografi, pada November 2017 tim pengembang zcash mengusulkan kurva BLS12-381. Dibandingkan dengan alt_bn128, BLS12-381 memiliki keamanan yang lebih tinggi dan kinerja yang lebih baik. Banyak protokol blockchain kemudian mengadopsi kurva BLS12-381, meninggalkan alt_bn128.
Pada bulan Mei 2018, Justin Drake menerbitkan artikel yang menunjukkan bahwa pembaruan PoS dan sharding masa depan Ethereum dapat menggunakan algoritma tanda tangan multipel BLS berbasis kurva BLS12-381. Solusi ini mengatasi masalah keterbatasan jumlah validator dalam skema PoS awal. Terbukti bahwa pembaruan ETH2 yang kemudian memang menggunakan kurva BLS12-381.
Dengan kemajuan pengembangan ETH2, seruan untuk memperkenalkan BLS12-381 ke dalam lapisan eksekusi ETH semakin meningkat. Pada bulan Februari 2020, para peneliti mengajukan EIP-2537, dan berharap proposal tersebut dapat diuji bersamaan dengan jaringan uji ETH2. Penulis EIP-2537, Alex Stokes, menyerukan agar proposal tersebut dimasukkan dalam hard fork Berlin.
Perlu dicatat bahwa penulis EIP-2537 juga merupakan salah satu pendiri perusahaan pengembang ZKSync, Matter Labs.
Kendala dalam Upgrade Berlin
Sebelum memperkenalkan kemajuan selanjutnya, kita perlu memahami EIP-1962 terlebih dahulu. Ini adalah proposal pertama tentang penyusunan precompiled untuk pasangan domain kurva elips yang diajukan oleh Matter Labs pada April 2019, mendukung tiga kurva: BLS12, BN, dan MNT4/6.
EIP-1962 berencana untuk menambahkan 10 instruksi pra-kompilasi sekaligus untuk menangani kurva yang berbeda. Namun, proposal ini mendapatkan banyak pertanyaan dari para pengembang, yang menganggapnya terlalu kompleks dan sulit untuk diimplementasikan. Selain itu, karena tingkat generalisasi yang tinggi, pemanggilan juga sangat merepotkan bagi insinyur kontrak pintar. Namun, sebagai pihak yang mengusulkan, Matter Labs telah menyelesaikan pengembangan algoritma kurva elips dan menyediakan berbagai implementasi referensi dalam berbagai bahasa.
Untuk menyelesaikan masalah EIP-1962, Matter Labs mengajukan beberapa EIP pada Februari 2020 untuk membagi EIP-1962, dan EIP ini sebagian mewarisi antarmuka EIP-1962:
EIP-2537 memberikan dukungan BLS12-381
EIP-2539 menyediakan dukungan BLS12-377
PR#2541 menyediakan dukungan untuk kurva BLS12-377(Zexe ), tetapi proposal ini akhirnya tidak mendapatkan nomor EIP.
Yang paling penting adalah EIP-2537, karena lapisan konsensus juga menggunakan kurva BLS12-381. Tujuan utama dari EIP-1962 dan EIP-2537 adalah untuk menerapkan verifikasi tanda tangan BLS di lapisan konsensus di mainnet. Pada saat itu, ETH2 sedang mengembangkan kontrak setoran untuk lapisan konsensus. Dalam desain awal, karena lapisan eksekusi tidak mencakup algoritma verifikasi BLS, kontrak setoran tidak akan memverifikasi tanda tangan, tanda tangan BLS yang spesifik akan diverifikasi oleh lapisan konsensus setelah pengguna melakukan setoran, jika ditemukan tidak benar, setoran akan gagal, dan ETH yang disetorkan pengguna mungkin hilang.
Dalam konteks ini, pengembang inti ingin memperkenalkan pra-kompilasi BLS12-381 untuk mewujudkan verifikasi tanda tangan dalam kontrak setoran, untuk menghindari kemungkinan kerugian dana pengguna. Ini juga merupakan alasan mengapa banyak pengembang saat itu tertarik pada EIP-1962 dan EIP-2537.
Ketika EIP-2537 baru saja diajukan, Vitalik segera menunjukkan serangkaian masalah yang ada dalam proposal tersebut. Keraguan ini terutama berfokus pada konten dokumen EIP, dan kemudian penulis EIP memberikan tanggapan dan diskusi terkait.
Pertemuan pengembang inti Ethereum yang ke-82 pada 6 Maret 2020 membahas EIP-2537. Vitalik percaya bahwa EIP ini sangat efektif untuk bukti SNARK rekursif dan tidak akan berdampak negatif pada Ethereum dalam jangka panjang. Pertemuan tersebut mengonfirmasi status prioritas EIP-2537, semua klien setuju untuk segera mengimplementasikan EIP ini dan merencanakan untuk menyelesaikan semua pengembangan sebelum peningkatan Berlin.
Selanjutnya, EIP-2537 menjadi tugas dengan prioritas yang lebih tinggi. Pada pertemuan pengembang inti yang ke-83 pada tanggal 20 Maret, proposal ini kembali dijadikan sebagai pembahasan utama. Pertemuan tersebut mengonfirmasi bahwa EIP-2537 menggantikan EIP-1962 sebagai proposal BLS inti, dan dimasukkan ke dalam daftar pra-pemilihan upgrade Berlin.
Rapat ke-84 bulan April secara resmi memasukkan EIP-2537 ke dalam peningkatan hard fork Berlin, dan menetapkan garis waktu untuk implementasi pada bulan April dan pengujian pada bulan Mei-Juni. Perlu dicatat bahwa EIP-2537 dalam diskusi ini dicatat sebagai hal yang memiliki prioritas tertinggi.
Setelah itu, EIP-2537 masuk ke tahap pengembangan dan pengujian yang intensif, hampir setiap kali ada diskusi terkait dalam hampir 20 pertemuan pengembang inti yang berlangsung.
Pada pertemuan ke-85, para pengembang membahas masalah pengkodean ABI EIP-2537. Karena Matter Labs sebelumnya telah menyelesaikan implementasi versi Rust, klien Besu menyatakan bahwa mereka telah secara dasar mengimplementasikan fungsi EIP-2537, tetapi pihak Geth mengklaim bahwa saat ini tidak ada yang sedang melakukan pekerjaan terkait.
Pada pertemuan ke-86, berbagai node berhasil menyinkronkan kembali kemajuan EIP-2537, Geth menyatakan bahwa sebagian pekerjaan telah selesai, tetapi masih ada banyak tugas yang harus diselesaikan.
Pertemuan ke-87 menekankan pada masalah implementasi EIP-2537. Pengembang Geth menyatakan ada PR sepanjang 16000 baris yang mengimplementasikan EIP-2537, tetapi tidak dapat memastikan apakah PR tersebut mengimplementasikan EIP-2537 dengan aman dan efektif, hanya dapat menilai kondisi kode melalui pengujian fuzz yang paling sederhana.
Pengembang Geth mengatakan: "Menurut insting saya, Geth tidak mungkin siap untuk operasi kurva BLS sebelum peluncuran mainnet pada bulan Juli."
Hudson Jameson mengusulkan untuk mencari insinyur kriptografi untuk membantu dalam peninjauan PR Geth, dan menyarankan untuk menggunakan jaringan pengujian untuk menguji keamanan implementasi EIP-2537. Karena tim pengembang ETH2 juga sedang mengimplementasikan verifikasi tanda tangan BLS, mereka dapat berpartisipasi dalam pengujian.
Perlu ditambahkan bahwa implementasi PR EIP-2537 dari Geth menggunakan banyak kode assembly untuk memastikan efisiensi, bagian kode ini sangat sulit dibaca dan dipahami. Alex Vlasov menyarankan untuk menghapus optimasi assembly yang kompleks dalam PR untuk mengurangi kesulitan dalam tinjauan.
Salah satu tujuan inti dari EIP-2537 adalah untuk membantu kontrak setoran ETH2, namun dalam pertemuan kali ini, pengembang kontrak setoran menyatakan bahwa kontrak yang tidak menggunakan EIP-2537 telah diaudit, dan beberapa pengembang berpendapat sebaiknya tidak meluncurkan kontrak versi baru yang menggunakan EIP-2537.
Akhirnya, konferensi memutuskan untuk menambahkan jaringan uji YOLO, yang khusus untuk menguji EIP-2537. Sebenarnya, dari konferensi ini dapat dilihat bahwa, dengan selesainya kontrak deposit, pentingnya EIP-2537 telah berkurang secara signifikan, sementara pengembang Geth percaya bahwa EIP ini sangat mungkin tidak dapat diimplementasikan sebelum peningkatan Berlin. Tampaknya sudah menjadi kepastian bahwa EIP-2537 tidak akan diadopsi dalam peningkatan Berlin.
Pada pertemuan ke-88, pengembang Geth menemukan bahwa implementasi PR EIP-2537 memiliki serangkaian masalah, dan menyatakan bahwa perlu dilakukan pengujian dan perbaikan lebih lanjut. Saat ini, terdapat dua implementasi EIP-2537 dalam sistem Geth, satu mengandung optimasi assembly, dan yang lainnya sepenuhnya ditulis dalam bahasa Go. Beberapa pengembang menyarankan untuk langsung menggunakan versi bahasa Go untuk mengurangi kesulitan dalam tinjauan kode.
Pada pertemuan ke-89, muncul masalah yang lebih serius, jaringan pengujian YOLO menunjukkan beberapa anomali, para pengembang curiga bahwa itu disebabkan oleh tanda tangan BLS, namun pengembang EIP-2537 membantah hal ini. Kabar baiknya adalah kontrak setoran berbasis EIP-2537 hampir selesai dikembangkan dan sedang menunggu audit.
Rapat ke-90 menetapkan batas waktu terakhir untuk peluncuran upgrade Berlin pada bulan Juli. Rapat juga membahas masalah keberagaman klien, terutama terkait dominasi Geth, di mana beberapa pengembang menyarankan untuk membekukan implementasi EIP saat ini untuk mengurangi biaya pengembangan klien lainnya. Dalam rapat ke-91, beberapa pengembang mengusulkan penggunaan solusi modular untuk mengurangi biaya pengembangan guna meningkatkan keberagaman klien.
Pertemuan ke-92 masih mengonfirmasi EIP-2537 sebagai EIP yang diperlukan untuk upgrade Berlin.
Pada pertemuan ke-96, karena Celo telah memasukkan EIP-2537 dan EIP-2539 secara bersamaan ke dalam hard fork jaringan mereka, Matter Labs berharap untuk memasukkan EIP-2539 ke dalam pengujian YOLO v2 dan masuk ke dalam upgrade Berlin. Namun, pengembang Geth menentang, berpendapat bahwa EIP-2537 saat ini masih belum diuji secara lengkap di Geth. Akhirnya, pertemuan memutuskan untuk tidak menambahkan EIP-2696 dalam upgrade Berlin, dan akan ditunda untuk diskusi di masa depan.
Rapat ke-99 memutuskan untuk mengeluarkan EIP-2537 dari jaringan uji YOLO v3 dan pembaruan Berlin, alasan utamanya adalah EIP-2537 menghabiskan terlalu banyak waktu pengembang inti, yang menyebabkan pengembangan EIP lainnya untuk pembaruan Berlin terhambat. Faktor sekunder adalah Yayasan Ethereum mengajukan EVM384 sebagai pengganti EIP-2537, yang menawarkan solusi perhitungan kurva elips yang lebih umum. Namun, pengembang inti menyatakan kekhawatiran tentang masalah keamanan.
Ini adalah perjalanan awal EIP-2537. Kita bisa melihat bahwa EIP-2537 awalnya adalah salah satu EIP terpenting dalam peningkatan Berlin, tetapi karena masalah implementasi akhirnya dibatalkan. Pada April 2021, Ethereum menyelesaikan peningkatan Berlin, EIP inti seperti EIP-2565 sebenarnya tidak terlalu rumit untuk diimplementasikan, peningkatan tersebut tampak sedikit tipis, hal ini disebabkan karena EIP-2537 yang paling kompleks dan inti telah dihapus.
Perkembangan Selanjutnya
Seperti yang kita ketahui, setiap pembaruan Ethereum selalu disertai dengan proposal inti. Pembaruan London setelah Berlin memperkenalkan proposal biaya transaksi terpenting dalam sejarah Ethereum, EIP-1559. Untuk proposal inti sebelumnya, EIP-2537, sulit untuk memasukkannya dalam pembaruan selanjutnya.
London setelah Berlin sedang dalam proses upgrade, para pengembang mempertimbangkan untuk menambahkan EIP-2537 di issues#369. Pertemuan pengembang inti yang ke-109 menyinkronkan status pengembangan EIP-2537, dan diskusi tentang penggunaan gas muncul karena penggunaan pustaka lain. Seorang pengembang mengusulkan untuk mengganti EIP-2537 dengan EVM384. Namun, pada pertemuan ke-111 pada bulan April 2021, EIP-2537 dikeluarkan dari upgrade London karena kompleksitasnya. Alasan utamanya adalah bahwa implementasi standar EIP-2537 telah mengganti pustaka yang bergantung, sehingga dapat mengubah penetapan harga gas, dan implementasi klien yang berbeda memerlukan banyak waktu untuk menilai kembali konsumsi gas.
Pada bulan Juni 2021, issues#343 secara resmi mengusulkan untuk memasukkan EIP-2537 ke dalam pembaruan Shanghai. Namun setelah pembaruan London, The Merge menyita banyak waktu pengembang, pengembang lapisan eksekusi perlu menulis banyak kode untuk melaksanakan pembaruan PoS. Setelah The Merge selesai pada bulan September 2022, pengembang lapisan eksekusi baru memiliki kesempatan untuk melanjutkan diskusi mengenai tujuan pembaruan Shanghai.
Pada November 2022, dalam pertemuan pengembang inti ke-150, dibahas secara singkat apakah EIP-2537 harus dimasukkan ke dalam Shanghai, tetapi para pengembang merasa bahwa hal itu harus ditunda, karena inti dari Shanghai adalah mendukung penarikan PoS. Akhirnya, EIP-2537 tidak dimasukkan dalam pembaruan Shanghai yang berfokus pada penarikan.
Lebih buruk lagi, pembaruan Cancun tidak pernah membahas EIP-2537, karena fokus Cancun adalah mendukung EIP-4844, yang menyediakan Blob untuk lapisan kedua Ethereum agar lapisan kedua dapat menggunakan Ethereum sebagai lapisan ketersediaan data.
Hingga pertemuan pengembang inti yang ke-181 pada Februari 2024, para pengembang baru membahas untuk memasukkan EIP-2537 dalam peningkatan Pectra. Pada saat itu, para pengembang percaya bahwa pelaksanaan EIP-2537 bukanlah masalah lagi, hanya beberapa masalah penetapan harga konsumsi gas yang perlu diselesaikan.
Pada pertemuan ke-202 pada tanggal 19 Desember 2024, pengembang Nethermind akhirnya menetapkan model penetapan harga untuk EIP-2537. Perlu dicatat bahwa Matter Labs, sebagai pengusul awal EIP-2537, pada saat ini telah hampir keluar dari diskusi. Pertemuan ke-203 pada bulan Januari 2025 membahas penetapan ulang harga untuk BLS precompile, di mana pengembang Geth, Jared Wasinger, menyarankan untuk meningkatkan biaya gas sebesar 20%, dan mendapatkan dukungan dari pengujian benchmark tim Besu.
Ringkasan
EIP-2537 mengalami proses yang panjang dan berliku dari pengajuannya hingga diterima secara resmi:
Februari 2020: EIP-2537 secara resmi diusulkan sebagai pemisahan dari EIP-1962
April-Oktober 2020: Beberapa kali mendiskusikan masalah implementasi, akhirnya ditinggalkan karena tidak dapat diimplementasikan dalam peningkatan Berlin.
Maret-April 2021: membahas masalah biaya gas, karena kompleksitasnya ditinggalkan dalam pembaruan London
November 2022: Diskusi tentang apakah akan memasukkan upgrade Shanghai, tetapi tidak berhasil.
Februari 2024: percaya bahwa pencapaian bukan lagi masalah, masih ada beberapa masalah biaya gas yang dapat dimasukkan dalam upgrade Pectra
Desember 2024-Januari 2025: Diskusikan model perhitungan biaya spesifik, secara resmi menyelesaikan biaya gas
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.
12 Suka
Hadiah
12
6
Bagikan
Komentar
0/400
StableGenius
· 08-03 06:12
secara empiris, mereka membutuhkan waktu 5 tahun untuk melakukan apa yang seharusnya dilakukan dalam 6 bulan. teater pemerintahan eth yang klasik
Lihat AsliBalas0
RugResistant
· 08-01 07:29
menganalisis eip. potensi bendera merah dalam implementasi bls perlu audit yang lebih mendalam sejujurnya
Lihat AsliBalas0
NFTDreamer
· 08-01 07:29
Wah, Vitalik Buterin sudah lama ingin melakukan ini.
Lihat AsliBalas0
TokenSleuth
· 08-01 07:29
Ah, ternyata harus menunggu lima tahun.. cukup merepotkan.
Lihat AsliBalas0
0xSunnyDay
· 08-01 07:14
5 tahun menunggu eip terlalu sulit
Lihat AsliBalas0
LiquidityHunter
· 08-01 07:11
Duh, gerakan Ethereum ini lambatnya membuatku mengantuk.
EIP-2537: Setelah 5 tahun melalui kontroversi hingga diadopsi, peningkatan penting Ethereum
EIP-2537: Jalan Panjang dari Kontroversi ke Adopsi
EIP-2537 adalah instruksi prekompilasi EVM yang ditambahkan dalam pembaruan fork Pectra terbaru Ethereum. Instruksi ini menambah berbagai fungsi perhitungan untuk kurva BLS12-381 di EVM, seperti perhitungan pasangan di domain kurva.
EIP-2537 awalnya diajukan pada tahun 2020, dan baru dikonfirmasi untuk dimasukkan dalam upgrade Ethereum pada tahun 2025. Artikel ini akan memperkenalkan perjalanan tata kelola EIP-2537, serta membahas mengapa proposal ini memakan waktu 5 tahun sebelum akhirnya diadopsi.
Latar Belakang Proposal
Pada Januari 2017, Vitalik Buterin pertama kali memperkenalkan algoritma pasangan dan kurva alt_bn128 dalam sebuah artikel. Kemudian, Vitalik dan Christian Reitwiessner mengusulkan EIP-196 dan EIP-197, yang merekomendasikan penambahan dukungan perhitungan kurva alt_bn128 ke EVM.
Pembaruan Byzantium pada bulan Oktober 2017 secara resmi memperkenalkan kurva alt_bn128, yang memungkinkan perhitungan pasangan bidang kurva di dalam EVM, sehingga verifikasi bukti ZK-Snarks dapat dilakukan di dalam EVM.
Namun, seiring dengan perkembangan kriptografi, pada November 2017 tim pengembang zcash mengusulkan kurva BLS12-381. Dibandingkan dengan alt_bn128, BLS12-381 memiliki keamanan yang lebih tinggi dan kinerja yang lebih baik. Banyak protokol blockchain kemudian mengadopsi kurva BLS12-381, meninggalkan alt_bn128.
Pada bulan Mei 2018, Justin Drake menerbitkan artikel yang menunjukkan bahwa pembaruan PoS dan sharding masa depan Ethereum dapat menggunakan algoritma tanda tangan multipel BLS berbasis kurva BLS12-381. Solusi ini mengatasi masalah keterbatasan jumlah validator dalam skema PoS awal. Terbukti bahwa pembaruan ETH2 yang kemudian memang menggunakan kurva BLS12-381.
Dengan kemajuan pengembangan ETH2, seruan untuk memperkenalkan BLS12-381 ke dalam lapisan eksekusi ETH semakin meningkat. Pada bulan Februari 2020, para peneliti mengajukan EIP-2537, dan berharap proposal tersebut dapat diuji bersamaan dengan jaringan uji ETH2. Penulis EIP-2537, Alex Stokes, menyerukan agar proposal tersebut dimasukkan dalam hard fork Berlin.
Perlu dicatat bahwa penulis EIP-2537 juga merupakan salah satu pendiri perusahaan pengembang ZKSync, Matter Labs.
Kendala dalam Upgrade Berlin
Sebelum memperkenalkan kemajuan selanjutnya, kita perlu memahami EIP-1962 terlebih dahulu. Ini adalah proposal pertama tentang penyusunan precompiled untuk pasangan domain kurva elips yang diajukan oleh Matter Labs pada April 2019, mendukung tiga kurva: BLS12, BN, dan MNT4/6.
EIP-1962 berencana untuk menambahkan 10 instruksi pra-kompilasi sekaligus untuk menangani kurva yang berbeda. Namun, proposal ini mendapatkan banyak pertanyaan dari para pengembang, yang menganggapnya terlalu kompleks dan sulit untuk diimplementasikan. Selain itu, karena tingkat generalisasi yang tinggi, pemanggilan juga sangat merepotkan bagi insinyur kontrak pintar. Namun, sebagai pihak yang mengusulkan, Matter Labs telah menyelesaikan pengembangan algoritma kurva elips dan menyediakan berbagai implementasi referensi dalam berbagai bahasa.
Untuk menyelesaikan masalah EIP-1962, Matter Labs mengajukan beberapa EIP pada Februari 2020 untuk membagi EIP-1962, dan EIP ini sebagian mewarisi antarmuka EIP-1962:
Yang paling penting adalah EIP-2537, karena lapisan konsensus juga menggunakan kurva BLS12-381. Tujuan utama dari EIP-1962 dan EIP-2537 adalah untuk menerapkan verifikasi tanda tangan BLS di lapisan konsensus di mainnet. Pada saat itu, ETH2 sedang mengembangkan kontrak setoran untuk lapisan konsensus. Dalam desain awal, karena lapisan eksekusi tidak mencakup algoritma verifikasi BLS, kontrak setoran tidak akan memverifikasi tanda tangan, tanda tangan BLS yang spesifik akan diverifikasi oleh lapisan konsensus setelah pengguna melakukan setoran, jika ditemukan tidak benar, setoran akan gagal, dan ETH yang disetorkan pengguna mungkin hilang.
Dalam konteks ini, pengembang inti ingin memperkenalkan pra-kompilasi BLS12-381 untuk mewujudkan verifikasi tanda tangan dalam kontrak setoran, untuk menghindari kemungkinan kerugian dana pengguna. Ini juga merupakan alasan mengapa banyak pengembang saat itu tertarik pada EIP-1962 dan EIP-2537.
Ketika EIP-2537 baru saja diajukan, Vitalik segera menunjukkan serangkaian masalah yang ada dalam proposal tersebut. Keraguan ini terutama berfokus pada konten dokumen EIP, dan kemudian penulis EIP memberikan tanggapan dan diskusi terkait.
Pertemuan pengembang inti Ethereum yang ke-82 pada 6 Maret 2020 membahas EIP-2537. Vitalik percaya bahwa EIP ini sangat efektif untuk bukti SNARK rekursif dan tidak akan berdampak negatif pada Ethereum dalam jangka panjang. Pertemuan tersebut mengonfirmasi status prioritas EIP-2537, semua klien setuju untuk segera mengimplementasikan EIP ini dan merencanakan untuk menyelesaikan semua pengembangan sebelum peningkatan Berlin.
Selanjutnya, EIP-2537 menjadi tugas dengan prioritas yang lebih tinggi. Pada pertemuan pengembang inti yang ke-83 pada tanggal 20 Maret, proposal ini kembali dijadikan sebagai pembahasan utama. Pertemuan tersebut mengonfirmasi bahwa EIP-2537 menggantikan EIP-1962 sebagai proposal BLS inti, dan dimasukkan ke dalam daftar pra-pemilihan upgrade Berlin.
Rapat ke-84 bulan April secara resmi memasukkan EIP-2537 ke dalam peningkatan hard fork Berlin, dan menetapkan garis waktu untuk implementasi pada bulan April dan pengujian pada bulan Mei-Juni. Perlu dicatat bahwa EIP-2537 dalam diskusi ini dicatat sebagai hal yang memiliki prioritas tertinggi.
Setelah itu, EIP-2537 masuk ke tahap pengembangan dan pengujian yang intensif, hampir setiap kali ada diskusi terkait dalam hampir 20 pertemuan pengembang inti yang berlangsung.
Pada pertemuan ke-85, para pengembang membahas masalah pengkodean ABI EIP-2537. Karena Matter Labs sebelumnya telah menyelesaikan implementasi versi Rust, klien Besu menyatakan bahwa mereka telah secara dasar mengimplementasikan fungsi EIP-2537, tetapi pihak Geth mengklaim bahwa saat ini tidak ada yang sedang melakukan pekerjaan terkait.
Pada pertemuan ke-86, berbagai node berhasil menyinkronkan kembali kemajuan EIP-2537, Geth menyatakan bahwa sebagian pekerjaan telah selesai, tetapi masih ada banyak tugas yang harus diselesaikan.
Pertemuan ke-87 menekankan pada masalah implementasi EIP-2537. Pengembang Geth menyatakan ada PR sepanjang 16000 baris yang mengimplementasikan EIP-2537, tetapi tidak dapat memastikan apakah PR tersebut mengimplementasikan EIP-2537 dengan aman dan efektif, hanya dapat menilai kondisi kode melalui pengujian fuzz yang paling sederhana.
Pengembang Geth mengatakan: "Menurut insting saya, Geth tidak mungkin siap untuk operasi kurva BLS sebelum peluncuran mainnet pada bulan Juli."
Hudson Jameson mengusulkan untuk mencari insinyur kriptografi untuk membantu dalam peninjauan PR Geth, dan menyarankan untuk menggunakan jaringan pengujian untuk menguji keamanan implementasi EIP-2537. Karena tim pengembang ETH2 juga sedang mengimplementasikan verifikasi tanda tangan BLS, mereka dapat berpartisipasi dalam pengujian.
Perlu ditambahkan bahwa implementasi PR EIP-2537 dari Geth menggunakan banyak kode assembly untuk memastikan efisiensi, bagian kode ini sangat sulit dibaca dan dipahami. Alex Vlasov menyarankan untuk menghapus optimasi assembly yang kompleks dalam PR untuk mengurangi kesulitan dalam tinjauan.
Salah satu tujuan inti dari EIP-2537 adalah untuk membantu kontrak setoran ETH2, namun dalam pertemuan kali ini, pengembang kontrak setoran menyatakan bahwa kontrak yang tidak menggunakan EIP-2537 telah diaudit, dan beberapa pengembang berpendapat sebaiknya tidak meluncurkan kontrak versi baru yang menggunakan EIP-2537.
Akhirnya, konferensi memutuskan untuk menambahkan jaringan uji YOLO, yang khusus untuk menguji EIP-2537. Sebenarnya, dari konferensi ini dapat dilihat bahwa, dengan selesainya kontrak deposit, pentingnya EIP-2537 telah berkurang secara signifikan, sementara pengembang Geth percaya bahwa EIP ini sangat mungkin tidak dapat diimplementasikan sebelum peningkatan Berlin. Tampaknya sudah menjadi kepastian bahwa EIP-2537 tidak akan diadopsi dalam peningkatan Berlin.
Pada pertemuan ke-88, pengembang Geth menemukan bahwa implementasi PR EIP-2537 memiliki serangkaian masalah, dan menyatakan bahwa perlu dilakukan pengujian dan perbaikan lebih lanjut. Saat ini, terdapat dua implementasi EIP-2537 dalam sistem Geth, satu mengandung optimasi assembly, dan yang lainnya sepenuhnya ditulis dalam bahasa Go. Beberapa pengembang menyarankan untuk langsung menggunakan versi bahasa Go untuk mengurangi kesulitan dalam tinjauan kode.
Pada pertemuan ke-89, muncul masalah yang lebih serius, jaringan pengujian YOLO menunjukkan beberapa anomali, para pengembang curiga bahwa itu disebabkan oleh tanda tangan BLS, namun pengembang EIP-2537 membantah hal ini. Kabar baiknya adalah kontrak setoran berbasis EIP-2537 hampir selesai dikembangkan dan sedang menunggu audit.
Rapat ke-90 menetapkan batas waktu terakhir untuk peluncuran upgrade Berlin pada bulan Juli. Rapat juga membahas masalah keberagaman klien, terutama terkait dominasi Geth, di mana beberapa pengembang menyarankan untuk membekukan implementasi EIP saat ini untuk mengurangi biaya pengembangan klien lainnya. Dalam rapat ke-91, beberapa pengembang mengusulkan penggunaan solusi modular untuk mengurangi biaya pengembangan guna meningkatkan keberagaman klien.
Pertemuan ke-92 masih mengonfirmasi EIP-2537 sebagai EIP yang diperlukan untuk upgrade Berlin.
Pada pertemuan ke-96, karena Celo telah memasukkan EIP-2537 dan EIP-2539 secara bersamaan ke dalam hard fork jaringan mereka, Matter Labs berharap untuk memasukkan EIP-2539 ke dalam pengujian YOLO v2 dan masuk ke dalam upgrade Berlin. Namun, pengembang Geth menentang, berpendapat bahwa EIP-2537 saat ini masih belum diuji secara lengkap di Geth. Akhirnya, pertemuan memutuskan untuk tidak menambahkan EIP-2696 dalam upgrade Berlin, dan akan ditunda untuk diskusi di masa depan.
Rapat ke-99 memutuskan untuk mengeluarkan EIP-2537 dari jaringan uji YOLO v3 dan pembaruan Berlin, alasan utamanya adalah EIP-2537 menghabiskan terlalu banyak waktu pengembang inti, yang menyebabkan pengembangan EIP lainnya untuk pembaruan Berlin terhambat. Faktor sekunder adalah Yayasan Ethereum mengajukan EVM384 sebagai pengganti EIP-2537, yang menawarkan solusi perhitungan kurva elips yang lebih umum. Namun, pengembang inti menyatakan kekhawatiran tentang masalah keamanan.
Ini adalah perjalanan awal EIP-2537. Kita bisa melihat bahwa EIP-2537 awalnya adalah salah satu EIP terpenting dalam peningkatan Berlin, tetapi karena masalah implementasi akhirnya dibatalkan. Pada April 2021, Ethereum menyelesaikan peningkatan Berlin, EIP inti seperti EIP-2565 sebenarnya tidak terlalu rumit untuk diimplementasikan, peningkatan tersebut tampak sedikit tipis, hal ini disebabkan karena EIP-2537 yang paling kompleks dan inti telah dihapus.
Perkembangan Selanjutnya
Seperti yang kita ketahui, setiap pembaruan Ethereum selalu disertai dengan proposal inti. Pembaruan London setelah Berlin memperkenalkan proposal biaya transaksi terpenting dalam sejarah Ethereum, EIP-1559. Untuk proposal inti sebelumnya, EIP-2537, sulit untuk memasukkannya dalam pembaruan selanjutnya.
London setelah Berlin sedang dalam proses upgrade, para pengembang mempertimbangkan untuk menambahkan EIP-2537 di issues#369. Pertemuan pengembang inti yang ke-109 menyinkronkan status pengembangan EIP-2537, dan diskusi tentang penggunaan gas muncul karena penggunaan pustaka lain. Seorang pengembang mengusulkan untuk mengganti EIP-2537 dengan EVM384. Namun, pada pertemuan ke-111 pada bulan April 2021, EIP-2537 dikeluarkan dari upgrade London karena kompleksitasnya. Alasan utamanya adalah bahwa implementasi standar EIP-2537 telah mengganti pustaka yang bergantung, sehingga dapat mengubah penetapan harga gas, dan implementasi klien yang berbeda memerlukan banyak waktu untuk menilai kembali konsumsi gas.
Pada bulan Juni 2021, issues#343 secara resmi mengusulkan untuk memasukkan EIP-2537 ke dalam pembaruan Shanghai. Namun setelah pembaruan London, The Merge menyita banyak waktu pengembang, pengembang lapisan eksekusi perlu menulis banyak kode untuk melaksanakan pembaruan PoS. Setelah The Merge selesai pada bulan September 2022, pengembang lapisan eksekusi baru memiliki kesempatan untuk melanjutkan diskusi mengenai tujuan pembaruan Shanghai.
Pada November 2022, dalam pertemuan pengembang inti ke-150, dibahas secara singkat apakah EIP-2537 harus dimasukkan ke dalam Shanghai, tetapi para pengembang merasa bahwa hal itu harus ditunda, karena inti dari Shanghai adalah mendukung penarikan PoS. Akhirnya, EIP-2537 tidak dimasukkan dalam pembaruan Shanghai yang berfokus pada penarikan.
Lebih buruk lagi, pembaruan Cancun tidak pernah membahas EIP-2537, karena fokus Cancun adalah mendukung EIP-4844, yang menyediakan Blob untuk lapisan kedua Ethereum agar lapisan kedua dapat menggunakan Ethereum sebagai lapisan ketersediaan data.
Hingga pertemuan pengembang inti yang ke-181 pada Februari 2024, para pengembang baru membahas untuk memasukkan EIP-2537 dalam peningkatan Pectra. Pada saat itu, para pengembang percaya bahwa pelaksanaan EIP-2537 bukanlah masalah lagi, hanya beberapa masalah penetapan harga konsumsi gas yang perlu diselesaikan.
Pada pertemuan ke-202 pada tanggal 19 Desember 2024, pengembang Nethermind akhirnya menetapkan model penetapan harga untuk EIP-2537. Perlu dicatat bahwa Matter Labs, sebagai pengusul awal EIP-2537, pada saat ini telah hampir keluar dari diskusi. Pertemuan ke-203 pada bulan Januari 2025 membahas penetapan ulang harga untuk BLS precompile, di mana pengembang Geth, Jared Wasinger, menyarankan untuk meningkatkan biaya gas sebesar 20%, dan mendapatkan dukungan dari pengujian benchmark tim Besu.
Ringkasan
EIP-2537 mengalami proses yang panjang dan berliku dari pengajuannya hingga diterima secara resmi: