Crypto · 4 min read · 5 views
Glamsterdam Ethereum: ePBS, Block-Level Access Lists, dan Ujian Scaling L1
Glamsterdam menata ulang arsitektur Ethereum melalui ePBS, Block-Level Access Lists, dan repricing state. Analisis ini memetakan manfaat, risiko implementasi, serta indikator teknis yang perlu dipantau menjelang mainnet.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum sedang menyiapkan Glamsterdam, peningkatan protokol yang mengubah cara jaringan membangun, menyebarkan, dan memproses blok. Ini bukan sekadar upaya menaikkan angka kapasitas: desainnya menyentuh pemisahan tugas proposer–builder, pemetaan akses data pada tingkat blok, dan penyesuaian biaya penyimpanan *state*. Halaman roadmap resmi menempatkan Glamsterdam dalam tahap pengujian di devnet, dengan target mainnet kuartal IV 2026 yang tanggalnya belum dikonfirmasi ([ethereum.org](https://ethereum.org/roadmap/glamsterdam/)).
Bagi pengguna, hasil akhirnya diharapkan berupa fondasi layer-1 yang mampu menangani lebih banyak aktivitas tanpa mengorbankan kemampuan operator rumahan menjalankan node. Namun manfaat tersebut tidak hadir otomatis: perubahan arsitektur perlu lolos pengujian multi-client, operator harus memperbarui perangkat lunak, dan asumsi keamanan baru harus diperiksa. Artikel ini membedah tiga poros Glamsterdam—ePBS, Block-Level Access Lists, dan repricing *state*—tanpa mengubah roadmap teknis menjadi janji harga aset.
## Daftar Isi
- [01 — Glamsterdam dalam Peta Scaling Ethereum](#bagian-01)
- [02 — ePBS Memindahkan Pemisahan Peran ke Protokol](#bagian-02)
- [03 — BAL Membuka Jalan bagi Pemrosesan Paralel](#bagian-03)
- [04 — Biaya State dan Keberlanjutan Node](#bagian-04)
- [05 — Risiko Implementasi dan Sinyal yang Perlu Dipantau](#bagian-05)
- [Kesimpulan](#kesimpulan-artikel)
- [Sumber](#sumber-artikel)
<a id="bagian-01"></a>
## 01 — Glamsterdam dalam Peta Scaling Ethereum
Glamsterdam menggabungkan nama Gloas pada consensus layer dan Amsterdam pada execution layer. Menurut roadmap resmi, fokusnya meneruskan pekerjaan setelah Fusaka dengan tiga sasaran: menyiapkan pemrosesan paralel, memperluas kapasitas melalui pembagian kerja pembuatan serta verifikasi blok, dan menahan pembengkakan basis data jaringan. Ethereum Foundation melaporkan pada Mei 2026 bahwa devnet multi-client untuk ePBS telah berjalan dan pipeline builder eksternal telah diuji lintas hampir semua client—sebuah tonggak rekayasa, bukan bukti bahwa implementasi mainnet telah final ([Ethereum Foundation, 11 Mei 2026](https://blog.ethereum.org/en/2026/05/11/protocol-update-may-26)).
> **Highlight:** Nilai strategis Glamsterdam terletak pada perubahan struktur kerja jaringan; peningkatan throughput hanyalah hasil yang dituju, bukan jaminan sebelum pengujian dan aktivasi selesai.
<a id="bagian-02"></a>
## 02 — ePBS Memindahkan Pemisahan Peran ke Protokol
Saat ini, proposer yang memilih blok konsensus dan builder yang menyusun payload eksekusi berinteraksi melalui mekanisme yang sebagian berada di luar protokol, termasuk relay dan middleware. Enshrined Proposer-Builder Separation atau ePBS (EIP-7732) membawa pertukaran payload dan pembayaran builder ke aturan inti Ethereum. Roadmap menjelaskan adanya Payload Timeliness Committee dan dua tenggat terpisah agar validator dapat menilai blok konsensus serta ketepatan waktu payload eksekusi secara berbeda. Jendela propagasi payload ditargetkan melebar dari sekitar dua detik menjadi sekitar sembilan detik, sehingga blok lebih besar tidak harus dipaksakan melewati jalur validasi yang sangat sempit ([ethereum.org](https://ethereum.org/roadmap/glamsterdam/)).
| Dimensi | Sebelum ePBS | Arah setelah ePBS |
|---|---|---|
| Hubungan proposer–builder | Bergantung pada mekanisme dan kepercayaan di luar protokol | Pertukaran payload dan pembayaran diatur protokol |
| Waktu propagasi payload | Jalur ketat sekitar 2 detik | Target sekitar 9 detik |
| Relay pihak ketiga | Berperan penting dalam alur umum | Ketergantungan dasar berkurang, meski layanan tambahan tetap mungkin |
| Implikasi operator | Arsitektur yang telah dikenal | Pool staking dan client perlu penyesuaian serta pengujian |
<a id="bagian-03"></a>
## 03 — BAL Membuka Jalan bagi Pemrosesan Paralel
Block-Level Access Lists atau BAL (EIP-7928) memberi node peta tentang akun, lokasi penyimpanan, dan hasil perubahan yang disentuh oleh transaksi dalam sebuah blok. Tanpa peta itu, node baru mengetahui ketergantungan ketika transaksi dieksekusi sehingga pekerjaan cenderung serial. Dengan BAL, data yang tidak saling tumpang tindih dapat dibaca secara paralel; node yang melakukan sinkronisasi juga dapat memanfaatkan hasil pasca-eksekusi tanpa selalu mengulang seluruh komputasi. Ini belum berarti semua transaksi langsung dieksekusi paralel pada hari aktivasi. Lebih tepat memandang BAL sebagai prasyarat data yang membuat optimasi paralel aman dan dapat dikembangkan bertahap ([roadmap Glamsterdam](https://ethereum.org/roadmap/glamsterdam/)).
<a id="bagian-04"></a>
## 04 — Biaya State dan Keberlanjutan Node
Scaling memiliki tagihan tersembunyi: setiap data permanen baru menambah beban penyimpanan dan akses bagi node dalam jangka panjang. Karena itu, Glamsterdam juga memasukkan repricing agar gas lebih mencerminkan biaya pembuatan dan akses *state*. Catatan Protocol Cluster menyebut EIP-8037 telah difinalkan untuk devnet dengan model biaya tetap per byte *state*, sementara angka repricing diuji pada lingkungan BAL. Hubungannya penting: ePBS memperlebar ruang propagasi, BAL memperbaiki cara node mengetahui ketergantungan, dan repricing mencegah kapasitas tambahan mendorong pertumbuhan basis data tanpa harga yang sepadan ([Ethereum Foundation](https://blog.ethereum.org/en/2026/05/11/protocol-update-may-26)).
<a id="bagian-05"></a>
## 05 — Risiko Implementasi dan Sinyal yang Perlu Dipantau
Status “scheduled for inclusion” tidak sama dengan aktivasi yang pasti tanpa perubahan. Roadmap resmi menegaskan scope telah dibekukan tetapi meta-EIP masih berstatus draft dan dapat berubah sebelum mainnet. Karena itu, indikator yang lebih berguna daripada spekulasi pasar ialah hasil devnet dan testnet, kompatibilitas antar-client, stabilitas pipeline builder, audit spesifikasi, serta pengumuman resmi tanggal aktivasi. Operator node dan staking pool perlu mengikuti rilis execution client serta consensus client masing-masing; pengembang kontrak perlu menguji kembali asumsi gas bila aplikasinya bergantung pada stipend atau pola akses penyimpanan tertentu.
- [ ] Jadwal mainnet diumumkan melalui kanal resmi, bukan sekadar perkiraan kuartal.
- [ ] Devnet dan testnet selesai tanpa masalah konsensus lintas client yang belum tertangani.
- [ ] Spesifikasi EIP dan parameter gas telah stabil.
- [ ] Dokumentasi upgrade tersedia untuk operator node, validator, pool, dan pengembang aplikasi.
- [ ] Dampak terhadap desentralisasi diukur, termasuk kebutuhan perangkat keras serta konsentrasi builder.
<a id="kesimpulan-artikel"></a>
## Kesimpulan
Glamsterdam mencoba meningkatkan kapasitas Ethereum dengan membenahi arsitektur, bukan hanya menaikkan batas. ePBS membawa pembagian proposer–builder ke dalam protokol dan memperpanjang waktu propagasi; BAL menyediakan peta ketergantungan untuk pembacaan paralel dan sinkronisasi yang lebih efisien; repricing *state* menjaga agar ekspansi tidak dibayar dengan basis data yang sulit dipelihara. Per 30 September 2026, kerangka tersebut patut dibaca sebagai pekerjaan teknis yang sedang diuji. Keberhasilannya harus dinilai dari keamanan aktivasi, interoperabilitas client, dan aksesibilitas menjalankan node—bukan dari narasi investasi jangka pendek.
<a id="sumber-artikel"></a>
## Sumber
1. [ethereum.org — Glamsterdam](https://ethereum.org/roadmap/glamsterdam/) — status upgrade, sasaran desain, ePBS, BAL, repricing, dan estimasi jadwal.
2. [Ethereum Foundation Blog — Protocol Cluster Updates: May 2026](https://blog.ethereum.org/en/2026/05/11/protocol-update-may-26) — hasil interop, perkembangan devnet ePBS, EIP-8037, dan persiapan implementasi.
3. [EIP-7732 — Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732) — spesifikasi teknis pemisahan proposer dan builder.
4. [EIP-7928 — Block-Level Access Lists](https://eips.ethereum.org/EIPS/eip-7928) — spesifikasi struktur daftar akses pada tingkat blok.
Tags: #Ethereum#Glamsterdam#ePBS#EIP-7732#Block-Level Access Lists#EIP-7928#scaling#protocol upgrade
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
