Crypto · 5 min read · 4 views
Fusaka dan PeerDAS: Cara Ethereum Memperbesar Kapasitas Rollup Tanpa Membebani Semua Node
Fusaka mengubah cara Ethereum menjamin ketersediaan data rollup melalui PeerDAS dan menaikkan kapasitas blob secara bertahap lewat BPO. Berikut mekanisme, dampak, batasan, dan metrik yang perlu dipantau tanpa narasi harga.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum mengaktifkan peningkatan jaringan Fusaka pada 3 Desember 2025 sebagai lanjutan Pectra. Perubahan ini penting bukan karena menjanjikan “koin lebih cepat naik”, melainkan karena membongkar salah satu hambatan teknis utama penskalaan: cara jaringan memastikan data transaksi dari layer-2 tersedia tanpa memaksa setiap node mengunduh semuanya. Dalam penjelasan resminya, Ethereum menyebut PeerDAS sebagai fitur utama Fusaka dan menempatkannya dalam jalur peningkatan kapasitas blob secara bertahap ([ethereum.org](https://ethereum.org/roadmap/fusaka/)).
Dampaknya perlu dibaca dengan hati-hati. Fusaka tidak otomatis membuat seluruh transaksi murah, tidak menghapus risiko smart contract, dan tidak menjamin penghematan langsung diteruskan kepada pengguna. Ia menyediakan fondasi agar rollup dapat memublikasikan lebih banyak data ke Ethereum dengan beban node yang lebih terkendali. Karena itu, ukuran keberhasilan yang lebih berguna adalah kapasitas data, kesehatan node, stabilitas biaya blob, serta respons operator layer-2—bukan pergerakan harga ETH.
## Daftar Isi
- [01 — Mengapa Data Rollup Menjadi Hambatan](#bagian-01)
- [02 — Cara Kerja PeerDAS Tanpa Jargon Berlebih](#bagian-02)
- [03 — BPO dan Strategi Menaikkan Kapasitas Bertahap](#bagian-03)
- [04 — Dampak bagi Pengguna, Rollup, dan Operator Node](#bagian-04)
- [05 — Metrik yang Layak Dipantau](#bagian-05)
- [Kesimpulan](#kesimpulan-artikel)
- [Sumber](#sumber-artikel)
<a id="bagian-01"></a>
## 01 — Mengapa Data Rollup Menjadi Hambatan
Rollup mengeksekusi banyak aktivitas di luar mainnet, lalu mengirimkan data yang diperlukan ke Ethereum agar hasilnya dapat diverifikasi. Sejak EIP-4844, data itu ditempatkan dalam “blob”, ruang sementara yang dirancang khusus untuk kebutuhan layer-2. Sebelum PeerDAS, node penuh harus menerima seluruh blob untuk memeriksa ketersediaannya; pola “semua mengunduh semuanya” makin mahal ketika jumlah blob dinaikkan. Dokumentasi PeerDAS menyebut perubahan ini sebagai peningkatan penskalaan terpenting sejak transaksi blob diperkenalkan, karena hambatan ketersediaan data—bukan sekadar kecepatan eksekusi—menentukan seberapa jauh kapasitas rollup bisa berkembang ([panduan PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/)).
> **Highlight:** Fusaka tidak memindahkan keamanan Ethereum ke satu penyedia data; ia mengubah cara node bekerja sama memeriksa bahwa data rollup memang tersedia.
<a id="bagian-02"></a>
## 02 — Cara Kerja PeerDAS Tanpa Jargon Berlebih
PeerDAS memperluas data blob dengan *erasure coding*, membaginya menjadi 128 kolom, lalu menyebarkan kolom tersebut melalui subnet jaringan. Node reguler berlangganan sedikitnya delapan subnet kolom sehingga, secara default, menerima sekitar seperdelapan data asli setelah memperhitungkan perluasan. Node kemudian mengambil sampel untuk menguji ketersediaan; data utuh dapat direkonstruksi ketika setidaknya separuh bagian yang diperluas tersedia. Hasilnya adalah batas penskalaan teoretis hingga delapan kali pola lama, sementara probabilitas data hilang lolos dari pemeriksaan dibuat sangat kecil secara kriptografis. Ini bukan “kompresi ajaib”: jaminannya berasal dari distribusi acak, sampling, rekonstruksi, dan partisipasi banyak node ([ethereum.org: PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/)).
| Aspek | Sebelum PeerDAS | Dengan PeerDAS |
|---|---|---|
| Data yang diterima node | Seluruh blob | Subset kolom yang ditugaskan |
| Cara memeriksa ketersediaan | Unduh keseluruhan data | Sampling dan rekonstruksi |
| Hambatan utama | Bandwidth dan penyimpanan per node | Distribusi kolom, kualitas jaringan, sampling |
| Jalur peningkatan kapasitas | Kenaikan blob lebih berat dikoordinasikan | Dapat dinaikkan bertahap melalui BPO |
| Yang tidak berubah | Node tetap memverifikasi aturan protokol | Keamanan tetap bergantung pada implementasi dan partisipasi sehat |
<a id="bagian-03"></a>
## 03 — BPO dan Strategi Menaikkan Kapasitas Bertahap
Fusaka memisahkan aktivasi mekanisme baru dari kenaikan agresif kapasitas. Ethereum Foundation menjelaskan bahwa *Blob Parameter Only* atau BPO adalah peningkatan konfigurasi minimal untuk mengubah target dan maksimum blob serta parameter biaya, tanpa menunggu *named fork* baru. Pada pengumuman mainnet, aktivasi Fusaka dijadwalkan pada slot 13.164.544, disusul BPO1 pada 9 Desember 2025 yang menaikkan target/maksimum blob dari 6/9 menjadi 10/15, serta BPO2 pada 7 Januari 2026 menjadi 14/21 ([Ethereum Foundation Blog](https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement)). Tahapan ini memberi pengembang kesempatan mengamati bandwidth, propagasi, dan stabilitas sebelum mendorong kapasitas lebih jauh.
**Urutan perubahan yang relevan:**
1. PeerDAS aktif dan mengubah distribusi serta pemeriksaan data blob.
2. Operator memperbarui execution client dan consensus client yang kompatibel.
3. BPO menaikkan parameter blob menurut konfigurasi yang telah disepakati.
4. Pengembang memantau efeknya pada node sebelum kenaikan berikutnya.
<a id="bagian-04"></a>
## 04 — Dampak bagi Pengguna, Rollup, dan Operator Node
Bagi pengguna, manfaat yang diharapkan bersifat tidak langsung: kapasitas data lebih besar dapat meredakan kelangkaan ruang blob dan membantu layer-2 mempertahankan biaya lebih rendah ketika permintaan meningkat. Namun biaya akhir tetap ditentukan desain rollup, kebijakan sequencer, kompresi, aktivitas jaringan, dan margin layanan. Bagi tim rollup, PeerDAS membuka ruang untuk *batch* yang lebih besar, tetapi mereka tetap harus menyesuaikan pengiriman blob dan menguji perilaku biaya. Bagi operator node, kebutuhan menyimpan seluruh blob berkurang, sementara kompleksitas jaringan meningkat karena node harus menangani kolom, subnet, dan konfigurasi custody secara benar. Ethereum Foundation juga mengingatkan operator untuk menjalankan versi execution dan consensus client yang mendukung Fusaka agar tetap tersinkron setelah aktivasi ([pengumuman mainnet](https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement)).
**Checklist pembacaan dampak:**
- Pengguna: bandingkan biaya aktual pada rollup, bukan klaim kapasitas teoretis.
- Pengembang aplikasi: uji latensi, finalitas, dan kegagalan penyedia RPC.
- Tim rollup: pantau pasar biaya blob dan kualitas propagasi data.
- Operator node: perbarui kedua jenis client dan ikuti advisori resmi.
- Peneliti: periksa sentralisasi node, bandwidth, dan distribusi custody.
<a id="bagian-05"></a>
## 05 — Metrik yang Layak Dipantau
Evaluasi Fusaka sebaiknya menggunakan beberapa kelompok indikator sekaligus. Pertama, target, maksimum, serta pemakaian blob per blok untuk melihat apakah kapasitas tambahan benar-benar digunakan. Kedua, blob base fee dan biaya transaksi layer-2 untuk menilai apakah pasokan data baru berpengaruh kepada pengguna. Ketiga, waktu propagasi, tingkat partisipasi node, distribusi client, dan kejadian reorganisasi untuk mendeteksi tekanan pada jaringan. Keempat, kebutuhan bandwidth serta penyimpanan operator rumahan agar penskalaan tidak dibayar dengan hambatan masuk yang lebih tinggi. Angka “delapan kali” dalam dokumentasi adalah batas teoretis rancangan, bukan janji throughput instan; kenaikan nyata bergantung pada parameter BPO dan kondisi jaringan.
<a id="kesimpulan-artikel"></a>
## Kesimpulan
Fusaka dan PeerDAS mengubah penskalaan Ethereum dari model setiap node mengunduh semua blob menjadi kerja terdistribusi berbasis kolom dan sampling. Desain itu menciptakan ruang bagi kapasitas layer-2 yang lebih besar tanpa menaikkan beban setiap node secara linear, sedangkan BPO membuat ekspansi berlangsung bertahap dan dapat diamati. Nilai teknisnya nyata, tetapi hasil bagi pengguna harus dibuktikan melalui data biaya, penggunaan blob, dan kesehatan jaringan. Artikel ini membahas teknologi protokol, bukan rekomendasi membeli atau menjual aset kripto.
<a id="sumber-artikel"></a>
## Sumber
1. [ethereum.org — Fulu-Osaka (Fusaka)](https://ethereum.org/roadmap/fusaka/) — ringkasan resmi aktivasi, fitur utama, dan kewajiban pembaruan client.
2. [ethereum.org — PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/) — penjelasan teknis kolom, subnet, sampling, rekonstruksi, serta batas penskalaan teoretis.
3. [Ethereum Foundation Blog — Fusaka Mainnet Announcement](https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement) — jadwal aktivasi, daftar EIP, dan tahapan parameter BPO.
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
