Glamsterdam Upgrade, Jawaban L1 Scalability Ethereum

Asli | Odaily Planet Daily jk

Upgrade Glamsterdam yang akan datang di Ethereum adalah rekonstruksi protokol terbesar yang pernah ada menurut para pengembang inti setelah The Merge. Nama ini berasal dari dua bagian: bagian upgrade lapisan eksekusi menggunakan "Amsterdam", diambil dari lokasi Devconnect sebelumnya yang diadakan di Amsterdam; sedangkan bagian upgrade lapisan konsensus dinamakan "Gloas", terinspirasi dari sebuah bintang. Setelah upgrade Fusaka sebelumnya, Glamsterdam mendorong L1 scalability dengan merestrukturisasi cara jaringan memproses transaksi dan mengelola basis data yang terus berkembang, secara fundamental memperbarui cara Ethereum membuat dan memverifikasi blok.

Upgrade ini berfokus pada tiga tujuan inti:

• Mempercepat pemrosesan (paralelisasi): Merestrukturisasi cara jaringan mencatat ketergantungan data, sehingga dapat memproses banyak transaksi secara bersamaan dengan aman, bukan secara lambat satu per satu.
• Skalabilitas: Memecah pekerjaan berat dalam pembuatan dan verifikasi blok, memberi jaringan lebih banyak waktu untuk menyebarkan data dalam jumlah besar tanpa melambat.
• Keberlanjutan: Menyesuaikan biaya jaringan untuk mencerminkan dengan akurat biaya perangkat keras jangka panjang untuk menyimpan data baru, membersihkan hambatan untuk peningkatan batas Gas di masa depan, sambil menghindari penurunan kinerja perangkat keras.

Dua proposal utama dari upgrade ini terletak di lapisan konsensus dan lapisan eksekusi:

Ada dua proposal Headliner. Sumber: Ethereum

Proposal Headliner Satu: ePBS, Mengubah "Perantara Outsourcing" Menjadi "Aturan Bawaan"

Mari kita mulai dengan proposal headliner di lapisan konsensus, pemisahan antara pengusul dan pembangun dalam protokol, disingkat ePBS (EIP-7732).

Setiap kali Ethereum menghasilkan blok, sebenarnya ada dua langkah: satu orang bertanggung jawab untuk "memilih blok mana yang akan digunakan" (pengusul), dan orang lain bertanggung jawab untuk "mengumpulkan transaksi dalam blok tersebut" (pembangun). Saat ini, pembagian tugas ini tidak ditentukan oleh protokol Ethereum itu sendiri, melainkan bergantung pada sekelompok "perusahaan perantara" di luar rantai (disebut relay) untuk menyelesaikannya. Hubungan di luar rantai ini juga menciptakan jalur selama verifikasi blok, memaksa validator untuk terburu-buru menyelesaikan siaran dan eksekusi transaksi dalam jendela 2 detik yang ketat, membatasi jumlah data yang dapat diproses oleh jaringan. Misalnya, ini seperti restoran yang memiliki proses pemesanan dan memasak, di mana seorang penghubung eksternal diperlukan untuk mengkoordinasikan pengiriman makanan, jika penghubung ini gagal, dapur dan meja depan mungkin tidak cocok.

Apa yang dilakukan ePBS adalah menuliskan aturan pembagian "pesan-memasak" ini ke dalam buku pedoman operasional restoran, tanpa bergantung pada penghubung eksternal. Dengan cara ini, mekanisme pengiriman dan pembayaran blok yang dapat dipercaya di dalam rantai dibangun langsung ke dalam protokol itu sendiri, sehingga tidak lagi bergantung pada middleware pihak ketiga, meskipun jika kedua belah pihak ingin menggunakan beberapa fungsi kompleks yang belum diatur dalam protokol, mereka masih dapat memilih untuk terus menggunakan penghubung eksternal. Selain itu, agar proses "pengiriman makanan" tidak terburu-buru, ePBS juga mendirikan "tim pemeriksa makanan" untuk memeriksa "siapa yang memesan" dan "apakah makanan sudah siap tepat waktu". Jendela waktu pengiriman makanan yang awalnya 2 detik kini diperluas menjadi sekitar 9 detik, memungkinkan restoran untuk menangani lebih banyak pesanan sekaligus, yang berarti Ethereum dapat menampung lebih banyak data yang ditujukan untuk Layer2.

Proposal Headliner Dua: BALs, Buat "Daftar Belanja" Sebelum Berangkat

Selanjutnya adalah proposal headliner di lapisan eksekusi, daftar akses tingkat blok, disingkat BALs (EIP-7928).

Saat ini, cara Ethereum memproses transaksi mirip dengan seseorang yang pergi ke supermarket dengan mata tertutup: mereka harus meraba-raba untuk menemukan satu barang, memastikan apa itu, sebelum memutuskan langkah selanjutnya, sehingga hanya bisa melakukannya satu per satu. Karena tidak mengetahui sebelumnya data apa yang akan digunakan dalam sebuah transaksi, seperti akun mana yang terlibat, sistem harus memproses transaksi satu per satu secara ketat, jika tidak, dua transaksi mungkin secara tidak sengaja ingin mengubah data yang sama (misalnya saldo alamat yang sama), menyebabkan konflik.

BALs memungkinkan orang ini untuk mendapatkan daftar belanja yang jelas tentang "rak mana yang harus dikunjungi dan barang apa yang harus diambil" sebelum berangkat. Dengan daftar ini, sistem dapat melihat sebelumnya transaksi mana yang tidak akan saling "bertabrakan", sehingga dapat membagi transaksi yang tidak terkait menjadi beberapa kelompok, dan memprosesnya secara paralel tanpa harus mengantri satu per satu. Daftar ini juga memiliki keuntungan tambahan: ketika node baru bergabung dengan jaringan, mereka dapat langsung menyalin hasil akhir yang tercatat dalam daftar ini, tanpa harus menghitung ulang semua transaksi sejarah yang rumit, sehingga proses sinkronisasi node baru akan jauh lebih cepat. Untuk memastikan daftar ini benar-benar dapat beredar di jaringan, Glamsterdam juga mengemas peningkatan protokol transmisi yang memungkinkan node untuk berbagi daftar akses ini, dan protokol transmisi ini kini menjadi persyaratan wajib bagi semua klien lapisan eksekusi.

Proposal Pendukung: Menghitung Ulang Biaya untuk Operasi yang "Mengambil Tempat"

Selain dua proposal headliner ini, Glamsterdam juga mengemas dua proposal pendukung untuk penetapan ulang harga, yang dapat dipahami sebagai penyesuaian daftar harga untuk "biaya penyimpanan" dan "biaya kueri" jaringan.

• Proposal pertama adalah untuk operasi seperti membuat akun dan menerapkan kontrak yang "secara permanen mengambil tempat" di jaringan, biaya sebelumnya tidak sebanding dengan ruang yang sebenarnya mereka gunakan, sekarang akan dihitung ulang berdasarkan "setiap ruang yang digunakan akan dikenakan biaya yang sesuai", dengan tujuan mengendalikan laju pertumbuhan data jaringan pada tingkat yang aman dan dapat diprediksi sebesar 120 GiB per tahun, memastikan jaringan ini dapat terus berjalan dengan perangkat keras biasa. Selain itu, biaya penyimpanan ini akan dihitung dalam akun terpisah, tidak lagi dicampur dengan biaya komputasi untuk memproses transaksi itu sendiri, selama pengembang bersedia membayar sedikit lebih banyak untuk biaya penyimpanan, mereka masih dapat menerapkan aplikasi yang lebih besar dan lebih kompleks tanpa terhambat oleh batas Gas total.
• Proposal kedua adalah untuk operasi seperti kueri dan membaca data yang sudah ada di jaringan, harga sebelumnya terlalu rendah, tidak sesuai dengan biaya kueri yang sebenarnya setelah volume data meningkat, kali ini standar biaya untuk operasi ini akan ditingkatkan, membuat harga lebih mendekati beban nyata perangkat keras modern, dan juga mencegah orang memanfaatkan biaya yang terlalu murah dengan sengaja mengirimkan banyak permintaan kueri untuk memblokir jaringan.

Waktu Peluncuran Mainnet: Belum Ditentukan

Dalam hal jadwal, Glamsterdam saat ini berada dalam fase yang cukup rumit. Di tingkat resmi, rapat eksekusi lapisan pengembang inti yang terakhir dapat diverifikasi (ACDE) adalah yang ke-241, pada 16 Juli, dengan agenda utama termasuk laporan kemajuan terbaru dari fase Devnet Glamsterdam, serta pemilihan proposal headliner untuk upgrade berikutnya Hegota. Sebelumnya, sebuah jadwal yang banyak dikutip di industri menunjukkan bahwa fase Devnet telah melakukan delapan iterasi dari 0 hingga 7, dengan rentang waktu dari 28 Maret 2026 hingga 8 Juli, diikuti dengan fork jaringan pengujian Sepolia yang dijadwalkan pada 3 Agustus 2026, dan fork jaringan pengujian Hoodi yang dijadwalkan pada 17 Agustus 2026, dengan tanggal target aktivasi mainnet pada 16 September 2026.

Awalnya jadwalnya adalah paruh pertama tahun 2026, sumber: Ethereum

Namun, dari perkembangan terbaru, jadwal ini kemungkinan besar telah ditunda. Tim EthPandaOps baru-baru ini meluncurkan jaringan pengujian publik jangka pendek bernama Plataberget, yang dirancang khusus untuk Glamsterdam, dan peluncuran resmi Sepolia dan Hoodi diperkirakan akan ditunda hingga September, sehingga target peluncuran mainnet juga dipindahkan ke kuartal keempat tahun 2026. Ini juga merupakan penundaan kedua Glamsterdam setelah sebelumnya ditunda dari paruh pertama tahun 2026. Para pengembang inti telah menekankan beberapa kali bahwa akurasi upgrade lebih penting daripada mengejar tanggal tertentu, sehingga sebelum rapat ACD resmi mengunci tinggi blok tertentu, kita mungkin harus menunggu hingga kuartal keempat atau bahkan akhir tahun untuk melihat upgrade ini.

Konten ini disediakan hanya untuk tujuan informasi umum dan bukan merupakan nasihat keuangan, investasi, hukum, atau pajak. Setiap acara, reward, promosi online, atau informasi terkait yang disebutkan di sini tidak boleh dianggap sebagai rekomendasi, ajakan, atau undangan untuk membeli, menjual, memperdagangkan, atau melakukan transaksi aset kripto apa pun. Aset kripto sangat fluktuatif dan dapat mengakibatkan kerugian. Ketersediaan layanan, produk, dan acara terkait WEEX dapat berbeda-beda di setiap wilayah. Anda bertanggung jawab untuk memastikan bahwa partisipasi Anda sesuai dengan hukum dan peraturan setempat yang berlaku.