Penulis|jk
Upgrade Ethereum yang akan datang, Glamsterdam, adalah rekonstruksi tingkat protokol dengan perubahan terbesar dalam pandangan para pengembang inti sejak The Merge. Nama ini berasal dari kombinasi dua bagian: bagian upgrade lapisan eksekusi tetap menggunakan "Amsterdam", diambil dari lokasi penyelenggaraan Devconnect sebelumnya, Amsterdam; bagian upgrade lapisan konsensus dinamai "Gloas", sesuai nama sebuah bintang. Mengikuti upgrade Fusaka sebelumnya, Glamsterdam memajukan skalabilitas L1 dengan merekonstruksi cara jaringan memproses transaksi dan mengelola basis datanya yang terus tumbuh, secara fundamental memperbarui cara Ethereum membuat dan memvalidasi blok.
Upgrade ini berfokus pada tiga tujuan inti:
- Mempercepat Pemrosesan (Paralelisasi): Merekonstruksi cara jaringan mencatat dependensi data, memungkinkannya memproses sejumlah besar transaksi secara bersamaan dengan aman, bukan secara lambat satu per satu secara berurutan.
- Skalabilitas: Memisahkan pekerjaan berat pembuatan dan validasi blok, memberi jaringan lebih banyak waktu untuk menyebarkan data dalam volume lebih besar tanpa melambat.
- Keberlanjutan: Menyesuaikan biaya jaringan untuk mencerminkan biaya perangkat keras jangka panjang secara akurat dalam menyimpan data baru, membuka jalan untuk peningkatan batas Gas di masa depan, sekaligus mencegah degradasi kinerja perangkat keras.
Dua proposal utama upgrade berada di lapisan konsensus dan lapisan eksekusi:

Ada dua proposal Headliner (utama). Sumber: Ethereum
Proposal Utama Satu: ePBS, Mengubah "Perantara Outsourcing" Menjadi "Aturan Bawaan"
Pertama, proposal utama lapisan konsensus, Proposer-Builder Separation di dalam protokol, disingkat ePBS (EIP-7732).
Setiap kali Ethereum memproduksi blok, sebenarnya ada dua langkah: satu orang bertanggung jawab "memilih blok mana" (proposer), orang lain bertanggung jawab "merakit transaksi dalam blok dengan sebenarnya" (builder). Saat ini pembagian kerja ini tidak diatur oleh protokol Ethereum itu sendiri, melainkan bergantung pada sekelompok "perusahaan perantara" di luar rantai (jargon: relay) untuk mempertemukannya. Hubungan di luar rantai ini juga menciptakan jalur kritis selama validasi blok, memaksa validator untuk buru-buru menyelesaikan penyiaran dan eksekusi transaksi dalam jendela ketat 2 detik, membatasi jumlah data yang dapat ditangani jaringan. Analoginya, ini seperti bagian pemesanan dan memasak di restoran yang awalnya bergantung pada koordinator eksternal independen untuk menyampaikan pesanan, sekali koordinator ini gagal, dapur dan bagian depan mungkin tidak sinkron.
Yang dilakukan ePBS adalah menuliskan aturan pembagian kerja "pemesanan-memasak" ini ke dalam manual operasi restoran itu sendiri, tidak lagi bergantung pada koordinator eksternal. Dengan demikian, mekanisme pengiriman blok dan pembayaran yang andal di dalam rantai dibangun langsung ke dalam protokol itu sendiri, sehingga tidak lagi memerlukan perangkat lunak perantara pihak ketiga, meskipun jika kedua belah pihak ingin menggunakan fungsi kompleks yang belum diatur dalam protokol, mereka masih dapat memilih untuk kembali menggunakan koordinator eksternal. Secara bersamaan, agar bagian "penyampaian pesanan" tidak lagi kalang kabut, ePBS secara khusus membentuk "tim pemeriksa", masing-masing memeriksa dua hal: "siapa yang memesan" dan "apakah pesanan telah siap dan disajikan tepat waktu", jendela waktu penyampaian yang semula 2 detik juga diperluas menjadi sekitar 9 detik, memungkinkan restoran menangani lebih banyak pesanan sekaligus, artinya memungkinkan Ethereum membawa lebih banyak data untuk Layer2.
Proposal Utama Dua: BALs, Buat "Daftar Belanja" Sebelum Berangkat
Kemudian proposal utama lapisan eksekusi, Block-level Access Lists, disingkat BALs (EIP-7928).
Cara Ethereum memproses transaksi saat ini agak mirip dengan seseorang yang pergi berbelanja dengan mata tertutup: harus meraih satu barang terlebih dahulu, memastikan apa itu, baru bisa memutuskan langkah selanjutnya, sehingga harus mengantri satu per satu. Karena tidak mengetahui terlebih dahulu data apa yang akan digunakan oleh suatu transaksi, misalnya akun mana yang akan terlibat, sistem harus memproses transaksi secara berurutan dan ketat satu per satu, jika tidak, dua transaksi mungkin secara tidak sengaja ingin memodifikasi data yang sama (misalnya saldo alamat yang sama) secara bersamaan, menyebabkan konflik dan kesalahan.
BALs setara dengan memberi orang ini sebuah "daftar belanja" yang jelas menuliskan "rak mana yang akan dituju, barang apa yang akan diambil" sebelum berangkat. Dengan daftar ini, sistem dapat melihat terlebih dahulu transaksi mana yang sama sekali tidak akan "bentrokan" satu sama lain, sehingga dapat mengelompokkan transaksi yang tidak terkait menjadi beberapa kelompok, dan memprosesnya secara paralel bersamaan, tanpa harus mengantri satu per satu. Daftar ini juga memiliki keuntungan tambahan: ketika node baru bergabung ke jaringan, mereka dapat langsung menyalin hasil akhir yang tercatat dalam daftar ini, tanpa harus menghitung ulang semua transaksi sejarah yang kompleks, sehingga sinkronisasi node baru akan jauh lebih cepat. Untuk mendukung daftar ini benar-benar beredar di jaringan, Glamsterdam juga membawa upgrade protokol transmisi pendamping, memungkinkan node saling berbagi daftar akses ini, protokol transmisi ini kini telah menjadi persyaratan wajib bagi semua klien lapisan eksekusi.
Proposal Pendamping: Menghitung Ulang Biaya Operasi "Makan Tempat"
Selain dua proposal utama ini, Glamsterdam juga membawa dua proposal pendamping repricing, yang dapat dipahami sebagai penyesuaian daftar harga untuk "biaya penyimpanan" dan "biaya kueri" jaringan.
- Pertama, operasi seperti membuat akun baru, menerapkan kontrak yang akan "selamanya makan tempat" di jaringan, biaya sebelumnya tidak proporsional dengan ruang yang sebenarnya ditempati, sekarang akan dibebankan ulang sesuai prinsip "bayar sesuai ruang yang ditempati", dengan tujuan mengontrol pertumbuhan data seluruh jaringan pada tingkat yang aman dan dapat diprediksi, yaitu 120 GiB per tahun, memastikan jaringan dapat terus berjalan dengan perangkat keras biasa. Secara bersamaan, biaya penyimpanan ini akan dihitung dalam akun terpisah, tidak lagi dicampur dengan biaya komputasi pemrosesan transaksi itu sendiri, selama pengembang bersedia membayar sedikit lebih banyak untuk biaya penyimpanan, mereka masih dapat menerapkan aplikasi yang lebih besar dan kompleks, tidak akan langsung terhambat oleh batas Gas total.
- Kedua, operasi seperti mengueri, membaca data yang sudah ada di jaringan, sebelumnya harganya terlalu rendah, tidak mengikuti biaya kueri aktual setelah volume data bertambah, kali ini standar biaya untuk opcode semacam ini akan dinaikkan, mendekatkan harga ke beban aktual perangkat keras modern, sekaligus mencegah orang memanfaatkan celah biaya yang terlalu murah untuk sengaja memblokir jaringan dengan banyak permintaan kueri.
Waktu Peluncuran Mainnet: Saat Ini Belum Ditentukan
Dalam hal jadwal, Glamsterdam saat ini berada pada tahap yang cukup rumit. Secara resmi, pertemuan terakhir yang dapat diverifikasi dari semua pengembang inti lapisan eksekusi (ACDE) adalah yang ke-241, pada 16 Juli, agenda utamanya termasuk laporan perkembangan terbaru tahap Devnet Glamsterdam, serta pemilihan proposal utama untuk upgrade berikutnya, Hegota. Sebelumnya, sebuah jadwal yang banyak dikutip industri menunjukkan bahwa tahap Devnet telah melalui delapan iterasi dari 0 hingga 7, rentang waktunya dari 28 Maret 2026 hingga 8 Juli 2026, kemudian fork testnet Sepolia semula dijadwalkan pada 3 Agustus 2026, fork testnet Hoodi semula dijadwalkan pada 17 Agustus 2026, target tanggal aktivasi mainnet adalah 16 September 2026.

Jadwal semula adalah paruh pertama 2026, Sumber: Ethereum
Tetapi dari perkembangan terbaru, kemungkinan besar jadwal ini telah ditunda. Tim EthPandaOps baru-baru ini meluncurkan testnet baru bernama Plataberget, ini adalah testnet publik jangka pendek pertama yang dirancang khusus untuk Glamsterdam, penyebaran resmi Sepolia dan Hoodi diperkirakan akan ditunda hingga September baru diikuti, target peluncuran mainnet juga sesuai bergeser ke kuartal keempat 2026. Ini adalah kali kedua Glamsterdam mengalami pergeseran tanggal setelah sebelumnya ditunda dari paruh pertama 2026. Para pengembang inti telah berulang kali menekankan bahwa kebenaran upgrade lebih diutamakan daripada mengejar tanggal tertentu, sehingga sebelum pertemuan ACD resmi mengunci tinggi blok spesifik, kita mungkin baru akan melihat upgrade ini pada kuartal keempat atau bahkan akhir tahun.







