Crypto · 7 min read · 7 views
Platåberget & Glamsterdam: Checklist Uji Gas Repricing Ethereum Sebelum Mainnet
Platåberget membuka arena uji publik untuk perubahan besar Glamsterdam. Panduan ini menjelaskan ePBS, block-level access lists, state gas, serta checklist praktis agar wallet, dApp, indexer, dan infrastruktur tidak kaget saat upgrade tiba.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum telah membuka **Platåberget**, testnet publik jangka pendek untuk mencoba perubahan Glamsterdam sebelum upgrade bergerak ke testnet berumur panjang dan akhirnya mainnet. Ini bukan sekadar jaringan latihan baru: Ethereum Foundation memperingatkan bahwa wallet, indexer, gas estimator, serta tool yang mengunci asumsi batas gas maksimum dapat rusak dan perlu diperbarui. Karena itu, nilai utama Platåberget bukan mengejar test ETH, melainkan menemukan asumsi lama yang tidak lagi benar saat aturan eksekusi dan produksi blok berubah [Ethereum Foundation](https://blog.ethereum.org/en/2026/08/17/plataberget-testnet).
Perubahan yang paling terasa bagi developer adalah *gas repricing*. EIP-8037 memisahkan biaya pembuatan state permanen dari gas eksekusi, sehingga membuat akun baru, mengisi slot storage kosong, atau memasang bytecode tidak lagi diperlakukan seperti sebelumnya. Konsekuensinya konkret: transfer ETH ke akun yang sudah ada dapat tetap berada pada pola biaya dasar lama, tetapi transfer yang sekaligus membuat akun baru memerlukan state gas tambahan; estimator yang hanya mengenal satu dimensi gas berisiko memberi angka terlalu rendah [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037).
Artikel ini membahas apa yang diuji Platåberget, mengapa perubahan tersebut penting, dan bagaimana tim melakukan audit kompatibilitas tanpa menyamakan testnet dengan jaminan kesiapan mainnet. Fokusnya adalah mitigasi teknis untuk wallet, dApp, smart contract, RPC, indexer, builder, validator, dan sistem observability—bukan prediksi harga ETH.
---
## Daftar Isi
01. [Apa Itu Platåberget dan Glamsterdam?](#01--apa-itu-platåberget-dan-glamsterdam)
02. [Mengapa Hal Ini Penting?](#02--mengapa-hal-ini-penting)
03. [Bagaimana Cara Melakukan Pengujian?](#03--bagaimana-cara-melakukan-pengujian)
04. [Kesalahan yang Sering Terjadi](#04--kesalahan-yang-sering-terjadi)
05. [Tips Tambahan](#05--tips-tambahan)
06. [Kesimpulan](#kesimpulan)
---
## 01 — Apa Itu Platåberget dan Glamsterdam?
Platåberget adalah jaringan publik yang sengaja disediakan sebagai arena uji awal untuk **Glamsterdam**, upgrade Ethereum yang mengubah sisi consensus dan execution sekaligus. Di consensus layer, *enshrined proposer-builder separation* atau **ePBS** membawa pemisahan proposer dan builder ke protokol, lengkap dengan alur builder baru serta pemeriksaan ketepatan waktu payload. Di execution layer, **block-level access lists** mencatat lokasi state yang disentuh beserta perubahan setelah transaksi, sementara paket repricing menyesuaikan biaya operasi agar peningkatan kapasitas tidak mengorbankan keberlanjutan node. Situs jaringan mencantumkan chain ID `7091047534`, peluncuran 13 Agustus 2026, validator set terbuka, dan masa hidup hingga Glamsterdam hadir di mainnet [Platåberget](https://plataberget.dev).
Glamsterdam juga memperbesar batas deployed contract dari 24 KiB menjadi 64 KiB dan initcode dari 48 KiB menjadi 128 KiB. Namun, kapasitas lebih besar tidak berarti penyimpanan permanen menjadi “murah tanpa batas”: EIP-8037 menetapkan *cost per state byte* (**CPSB**) dan reservoir state-gas tersendiri, sedangkan repricing akses state memperbarui biaya operasi yang membaca atau menulis database. Roadmap resmi menjelaskan target desainnya sebagai pertumbuhan state yang aman dan dapat diprediksi, sekitar 120 GiB per tahun, agar perangkat keras umum tetap mampu menjalankan jaringan [ethereum.org](https://ethereum.org/roadmap/glamsterdam/).
> **Highlight:** Platåberget sebaiknya diperlakukan sebagai tes migrasi asumsi—bukan hanya tes apakah transaksi berhasil dikirim.
---
## 02 — Mengapa Hal Ini Penting?
Gas adalah mekanisme pembatas sumber daya, bukan sekadar angka biaya yang ditempel pada transaksi. Ketika harga opcode, pembuatan state, ukuran kontrak, format data consensus, dan pipeline builder berubah bersamaan, kegagalan bisa muncul jauh dari smart contract: simulasi wallet berbeda dari eksekusi node, indexer salah mengurai data, alert memakai threshold usang, atau builder gagal mengirim payload tepat waktu. EIP-8037 bahkan mewajibkan penanganan `eth_estimateGas` memasukkan state-gas dan model reservoir; estimasi yang tertinggal dapat menghasilkan transaksi gagal walau saldo pengguna cukup [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037).
- **Wallet:** harus menguji transfer ke akun yang sudah ada dan alamat yang belum memiliki state, bukan hanya transfer standar.
- **dApp:** perlu mengukur ulang deployment, pembuatan storage slot, factory contract, batching, dan alur EIP-7702.
- **RPC dan gas estimator:** wajib mengikuti implementasi client terbaru, bukan konstanta lokal atau buffer persentase yang menutupi model keliru.
- **Indexer dan analytics:** perlu memvalidasi parsing data baru, rekonsiliasi state, serta asumsi tentang kapasitas blok.
- **Validator, builder, dan relay:** harus menguji alur ePBS, deposit builder, keterlambatan payload, failover, dan observability.
| Perubahan | Asumsi lama yang perlu dicurigai | Risiko praktis | Bukti uji minimum |
|---|---|---|---|
| State-gas EIP-8037 | Semua gas berada dalam satu dimensi | Underestimate, transaksi gagal | Estimasi vs receipt untuk state baru/lama |
| Gas repricing | Konstanta opcode stabil | Batas batching dan alert meleset | Profil gas per operasi dan skenario |
| ePBS | Pipeline builder tetap sama | Payload terlambat atau blok terlewat | Latency, fallback, dan PTC telemetry |
| Block-level access lists | Tool hanya membaca block body lama | Parsing/indexing tidak lengkap | Reindex dan cocokkan hasil state |
| Kontrak lebih besar | Deployment mentok di batas lama | Validasi lokal menolak artifact sah | Deploy artifact di atas 24 KiB |
---
## 03 — Bagaimana Cara Melakukan Pengujian?
### Step 01 — Inventarisasi asumsi dan baseline
Mulai dari daftar komponen, versi client, RPC provider, library signing, estimator, indexer, dashboard, serta proses validator/builder. Catat semua konstanta seperti `21000`, batas gas blok, batas ukuran bytecode, timeout payload, dan buffer estimasi. Ambil baseline dari skenario yang sama di lingkungan saat ini: transfer ke akun eksis, transfer ke alamat baru, deploy kontrak, `CREATE2`, penulisan slot kosong, batching, serta kegagalan karena gas. Baseline diperlukan agar tim dapat membedakan perubahan yang memang berasal dari fork dengan bug aplikasi lama.
### Step 02 — Jalankan matriks uji di Platåberget
Hubungkan hanya software dan test key khusus ke parameter jaringan resmi; jangan pernah memasukkan mnemonic atau keystore mainnet ke situs maupun faucet. Jalankan skenario deterministik dengan input identik, simpan request `eth_estimateGas`, gas limit yang dikirim, receipt, revert data, trace, serta state sebelum/sesudah. Uji sisi negatif juga: estimasi tanpa buffer, transaksi yang menciptakan banyak state, payload terlambat, restart client, RPC failover, dan reindex dari genesis/checkpoint. Jaringan ini ditujukan untuk node, staking, builder, serta infrastruktur Glamsterdam; untuk pengujian dApp EVM umum, halaman resminya tetap mengarahkan pengguna ke Sepolia [Platåberget](https://plataberget.dev).
### Step 03 — Bandingkan, perbaiki, lalu pasang gate rilis
Kelompokkan selisih menjadi perubahan yang diharapkan, incompatibility client, atau bug aplikasi. Hilangkan hardcode; ambil hasil estimasi dari node yang kompatibel, tetapi tetap validasi error dan beri margin berdasarkan pengukuran—bukan angka universal. Tambahkan regression test untuk akun baru versus akun eksis, state-writing versus read-only, ukuran kontrak, dan parsing data fork. Sebelum release, mintalah dua implementasi/client path bila memungkinkan, jalankan canary, dan siapkan rollback konfigurasi. Urutan resmi tetap bertahap: feedback Platåberget dan devnet, pengujian testnet jangka panjang seperti Sepolia/Hoodi, lalu mainnet setelah stabil—jadi jangan mengarang tanggal aktivasi final dari jadwal testnet awal [Ethereum Foundation](https://blog.ethereum.org/en/2026/08/17/plataberget-testnet).
```text
Inventarisasi asumsi
↓
Baseline pra-fork ──→ Matriks skenario Platåberget
↓ ↓
Bandingkan estimate / receipt / trace / state
↓
Perbaiki hardcode + regression test
↓
Canary → observability → gate rilis → rollback siap
```
---
## 04 — Kesalahan yang Sering Terjadi
> ⚠️ **Kesalahan #1 — Menganggap semua transfer selalu 21.000 gas**
> Transfer ke akun eksis dan transfer yang menciptakan akun baru dapat memiliki kebutuhan berbeda setelah repricing. Uji keduanya dan pastikan estimator memahami state-gas.
> ⚠️ **Kesalahan #2 — Menambah buffer tanpa memperbaiki model**
> Buffer besar mungkin menyamarkan underestimate pada satu skenario, tetapi gagal pada operasi state-heavy. Perbarui client/RPC dan hilangkan konstanta usang sebelum menyesuaikan margin.
> ⚠️ **Kesalahan #3 — Memakai key atau dana mainnet di testnet**
> Testnet tidak memerlukan mnemonic produksi. Gunakan akun disposable, test ETH, allowlist endpoint, dan rahasia yang terisolasi agar eksperimen tidak membuka jalur serangan ke aset nyata.
---
## 05 — Tips Tambahan
**Tip 01 — Rekam tiga angka, bukan satu.** Simpan hasil estimasi, gas limit transaksi, dan gas yang benar-benar terpakai; selisih ketiganya jauh lebih informatif daripada status sukses saja.
**Tip 02 — Uji lintas versi dan provider.** Jalankan corpus transaksi yang sama pada client atau RPC berbeda untuk menemukan implementasi yang belum mengikuti spesifikasi.
**Tip 03 — Pantau semantik, bukan hanya uptime.** Dashboard hijau tidak membuktikan hasil benar; tambahkan invariant untuk saldo, storage, event, state root yang relevan, latency payload, dan kelengkapan indexing.
---
## Kesimpulan
Platåberget memberi tim Ethereum kesempatan murah untuk menemukan masalah mahal sebelum Glamsterdam mencapai mainnet. Prioritasnya bukan sekadar berhasil terhubung ke chain, melainkan membongkar hardcode gas, menguji state-gas pada akun dan storage baru, memvalidasi parser serta indexer, dan menilai ulang pipeline proposer-builder. Tim yang membawa baseline, matriks skenario, telemetry, regression test, canary, dan rollback akan jauh lebih siap dibanding tim yang hanya menunggu pengumuman tanggal fork.
*Disclaimer: Artikel ini bersifat informatif dan bukan nasihat keuangan atau rekomendasi investasi.*
---
## Sumber
- [Announcing the Platåberget Testnet — Ethereum Foundation](https://blog.ethereum.org/en/2026/08/17/plataberget-testnet) — pengumuman resmi, perubahan Glamsterdam, dampak pada tooling, dan tahapan pengujian.
- [Platåberget Testnet — EthPandaOps](https://plataberget.dev) — parameter jaringan, status, cakupan penggunaan, validator, dan panduan keamanan test key.
- [EIP-8037: State Creation Gas Cost Increase — Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-8037) — spesifikasi CPSB, state-gas, reservoir, serta kewajiban kompatibilitas estimator dan node.
- [Glamsterdam roadmap — ethereum.org](https://ethereum.org/roadmap/glamsterdam/) — ringkasan resmi ePBS, block-level access lists, repricing, dan tujuan keberlanjutan state.
Tags: #Ethereum#Glamsterdam#Platåberget#EIP-8037#gas repricing#ePBS#block-level access lists#smart contract#testnet
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
