Crypto · 4 min read · 9 views
Repricing Gas Ethereum Glamsterdam: Dampak EIP-8037 dan EIP-8038 bagi Smart Contract
Glamsterdam mengubah biaya pembuatan dan akses state Ethereum agar mencerminkan beban node secara lebih akurat. Simak dampaknya pada smart contract, gas estimator, serta langkah pengujian yang perlu dilakukan developer.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Upgrade Ethereum **Glamsterdam** membawa perubahan yang mudah terlewat karena tidak menawarkan fitur pengguna yang mencolok: repricing atau penyesuaian ulang biaya gas untuk membuat dan mengakses *state*. State adalah data permanen jaringan, seperti akun, storage slot, dan bytecode kontrak, yang harus disimpan serta diproses oleh node.
Perubahan melalui EIP-8037 dan EIP-8038 ini penting bagi developer smart contract, wallet, indexer, dan penyedia RPC. Mayoritas kontrak diperkirakan tetap berjalan, tetapi asumsi gas yang ditulis permanen dapat menyebabkan transaksi gagal. Artikel ini membahas mekanisme perubahan dan cara menguji dampaknya tanpa menganggap jadwal mainnet sebagai kepastian.
---
## Daftar Isi
01. [Apa Itu Repricing Gas Glamsterdam?](#01--apa-itu-repricing-gas-glamsterdam)
02. [Mengapa Hal Ini Penting?](#02--mengapa-hal-ini-penting)
03. [Bagaimana Cara Mengevaluasi Dampaknya?](#03--bagaimana-cara-mengevaluasi-dampaknya)
04. [Kesalahan yang Sering Terjadi](#04--kesalahan-yang-sering-terjadi)
05. [Tips Tambahan](#05--tips-tambahan)
06. [Kesimpulan](#kesimpulan)
---
## 01 — Apa Itu Repricing Gas Glamsterdam?
Repricing berarti mengubah tarif gas agar lebih mendekati biaya nyata yang ditanggung node. [Ethereum Foundation](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing) menjelaskan bahwa EIP-8037 menangani pembuatan state baru, sedangkan EIP-8038 menyesuaikan akses dan penulisan state yang sudah ada.
[EIP-8037](https://eips.ethereum.org/EIPS/eip-8037) memperkenalkan **CPSB** (*cost per state byte*) sebesar 1.530 gas dan memisahkan pengukuran menjadi *execution-gas* serta *state-gas*. Proposal ini menghitung satu akun baru sebagai 120 byte dan satu storage slot baru sebagai 64 byte. Tujuannya bukan sekadar membuat transaksi mahal, tetapi mengendalikan pertumbuhan database sambil memberi ruang peningkatan throughput.
[EIP-8038](https://eips.ethereum.org/EIPS/eip-8038) memecah biaya operasi terkait state menjadi komponen akses, penulisan, dan pembuatan. Contohnya, biaya akses akun dingin direncanakan naik dari 2.600 menjadi 3.000 gas, sementara surcharge penulisan storage menjadi lebih eksplisit.
> **Highlight:** Gas murah tidak selalu efisien jika tarifnya gagal mencerminkan beban penyimpanan dan pembacaan data permanen oleh node.
## 02 — Mengapa Hal Ini Penting?
State Ethereum tumbuh seiring kontrak dan storage baru. EIP-8037 mencatat database state pada node Geth sekitar 390 GiB per Januari 2026; setelah gas limit naik dari 30 juta ke 60 juta, rata-rata state baru harian yang diamati meningkat dari sekitar 105 MiB menjadi 326 MiB. Repricing dirancang agar kenaikan kapasitas blok tidak langsung berubah menjadi beban penyimpanan yang sulit dipertahankan.
Dampak praktisnya meliputi:
- deployment kontrak dan pembuatan storage baru dapat memerlukan estimasi gas lebih tinggi;
- panggilan yang memakai angka gas tetap berisiko kehabisan gas;
- wallet dan RPC harus memperbarui `eth_estimateGas` serta konstanta cache;
- kontrak yang bergantung pada `gasleft()` bisa mengambil cabang logika berbeda;
- node memperoleh perlindungan lebih baik terhadap pertumbuhan state berlebihan.
Ethereum Foundation telah memutar ulang transaksi historis dengan jadwal baru. Hasilnya dibagi menjadi transaksi tanpa perubahan, tetap sukses dengan perbedaan gas, sukses setelah gas limit dinaikkan, dan berpotensi rusak. Mayoritas berada pada kelompok tidak terdampak, tetapi kontrak bermasalah tetap perlu ditangani sebelum aktivasi mainnet.
## 03 — Bagaimana Cara Mengevaluasi Dampaknya?
### Step 01 — Inventarisasi asumsi gas
Cari penggunaan `transfer` atau `send` dengan stipend 2.300 gas, nilai gas eksplisit pada low-level call, transaksi bertanda tangan dengan gas limit tetap, serta logika yang bercabang berdasarkan `gasleft()`. Periksa juga layanan off-chain yang menyimpan konstanta gas lama.
### Step 02 — Bedakan jenis operasi
Petakan jalur transaksi berdasarkan sumber bebannya, lalu prioritaskan operasi yang sering dipakai.
| Operasi | Perubahan utama | Risiko praktis |
|---|---|---|
| Membuat akun/kontrak | state baru dihitung per byte | estimasi deployment terlalu rendah |
| `SSTORE` | akses, write, dan state creation dipisah | transaksi penyimpanan gagal |
| `SLOAD`/akses akun | tarif mengikuti biaya pembacaan state | batch call memakai gas lebih besar |
| `EXTCODESIZE`/`EXTCODECOPY` | pembacaan kedua ikut dihitung | asumsi biaya opcode meleset |
### Step 03 — Uji pada jaringan yang sesuai
Gunakan alat pemeriksaan kontrak yang dirujuk Ethereum Foundation, lalu jalankan test suite dan simulasi transaksi pada **Platåberget** (`glam-devnet-8`). [Pengumuman testnet](https://blog.ethereum.org/2026/08/17/plataberget-testnet) menyebut jaringan ini sebagai lingkungan publik sementara untuk menguji perubahan Glamsterdam sebelum masuk ke testnet jangka panjang. Bandingkan hasil, gas used, revert reason, dan perilaku integrasi frontend—bukan hanya status sukses.
## 04 — Kesalahan yang Sering Terjadi
> ⚠️ **Kesalahan #1 — Hanya menaikkan gas limit secara membabi buta**
> Gas limit lebih tinggi dapat memperbaiki sebagian transaksi, tetapi tidak menyelesaikan kontrak yang memakai stipend tetap atau membuat keputusan berdasarkan sisa gas.
> ⚠️ **Kesalahan #2 — Menguji kontrak tanpa infrastruktur pendukung**
> Kontrak bisa lolos test, sementara wallet, bundler, indexer, atau RPC masih memakai estimasi lama. Uji alur pengguna secara end-to-end.
> ⚠️ **Kesalahan #3 — Menganggap parameter belum final sebagai jaminan mainnet**
> Status dan nilai EIP dapat berubah selama review. Ikuti spesifikasi serta pengumuman resmi terbaru sebelum merilis konfigurasi produksi.
## 05 — Tips Tambahan
**Tip 01 — Hilangkan magic number gas.** Gunakan estimasi dinamis dan buffer yang terukur, lalu dokumentasikan alasan jika nilai tetap memang tidak bisa dihindari.
**Tip 02 — Tambahkan skenario state-heavy.** Benchmark deployment besar, pembuatan slot baru, batch write, dan akses akun dingin agar regression test mewakili jalur termahal.
**Tip 03 — Pantau peran kontrak dan tooling.** Developer kontrak fokus pada call site, sedangkan operator wallet/RPC harus memastikan estimator memahami dua dimensi pengukuran dan jadwal tarif baru.
## Kesimpulan
Repricing Glamsterdam berusaha menyelaraskan gas dengan biaya aktual pembuatan, pembacaan, dan penulisan state. Langkah ini mendukung kenaikan throughput tanpa membiarkan database node tumbuh tanpa rem, tetapi konsekuensinya adalah asumsi gas lama harus diaudit.
Bagi pengguna biasa, tindakan langsung umumnya tidak diperlukan. Bagi developer, langkah terbaik adalah menginventarisasi nilai gas tetap, memetakan operasi state, dan menguji seluruh alur pada Platåberget sebelum perubahan mencapai jaringan utama.
*Disclaimer: Artikel ini bersifat informatif dan bukan nasihat keuangan atau rekomendasi investasi.*
---
## Sumber
- [Glamsterdam Repricing Impact for Smart Contract Developers — Ethereum Foundation](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing) — dampak replay transaksi historis dan panduan mitigasi bagi developer.
- [EIP-8037: State Creation Gas Cost Increase — Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-8037) — mekanisme CPSB, multidimensional metering, dan data pertumbuhan state.
- [EIP-8038: State-access gas cost update — Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-8038) — perubahan tarif akses, penulisan, dan opcode terkait state.
- [Announcing the Platåberget Testnet — Ethereum Foundation](https://blog.ethereum.org/2026/08/17/plataberget-testnet) — tujuan testnet dan ruang pengujian perubahan Glamsterdam.
Tags: #Ethereum#Glamsterdam#EIP-8037#EIP-8038#gas repricing#smart contract#state growth#Plataberget#EVM
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
