Crypto · 5 min read · 6 views
PeerDAS Ethereum: Cara EIP-7594 Menskalakan Data Rollup Tanpa Membebani Semua Node
Analisis teknis PeerDAS (EIP-7594), mekanisme sampling kolom yang memperluas kapasitas data availability Ethereum bagi rollup tanpa mewajibkan setiap node mengunduh seluruh blob.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum memasuki fase penskalaan ketika kapasitas *data availability* (DA), bukan semata eksekusi transaksi di layer-1, menjadi pengungkit utama bagi rollup. PeerDAS—singkatan dari *Peer Data Availability Sampling* dan distandardisasi sebagai EIP-7594—mengubah cara node memastikan data blob tersedia: node tidak harus mengunduh seluruh data, melainkan memeriksa sampel terautentikasi dari rekan jaringan. Spesifikasi resminya menyebut pendekatan ini memakai distribusi gossip, penemuan peer berdasarkan data yang mereka simpan, dan permintaan peer untuk sampling ([EIP-7594](https://eips.ethereum.org/EIPS/eip-7594)).
Topik ini penting karena rollup memublikasikan data ke Ethereum agar transaksi dapat diverifikasi, sementara memaksa setiap node mengambil semua blob akan membuat kenaikan kapasitas berhadapan langsung dengan kebutuhan bandwidth dan penyimpanan. Akun resmi Ethereum menyebut PeerDAS sebagai peningkatan utama dalam Fusaka dan mengaitkannya dengan peningkatan *data throughput* hingga delapan kali untuk rollup; artikel ini memperlakukan unggahan X tersebut sebagai sinyal komunikasi, lalu mendasarkan uraian teknis pada EIP final dan dokumentasi resmi Ethereum ([Ethereum di X](https://x.com/ethereum/status/1998849926210678830)).
## Daftar Isi
- [01 — Dari Blob Penuh ke Sampel Kolom](#bagian-01)
- [02 — Mekanisme PeerDAS dalam Satu Slot](#bagian-02)
- [03 — Apa yang Berubah bagi Rollup dan Node](#bagian-03)
- [04 — Jaminan, Asumsi, dan Batas Keamanan](#bagian-04)
- [05 — Indikator Implementasi yang Perlu Dipantau](#bagian-05)
- [Kesimpulan](#kesimpulan-artikel)
- [Sumber](#sumber-artikel)
<a id="bagian-01"></a>
## 01 — Dari Blob Penuh ke Sampel Kolom
EIP-4844 lebih dahulu memperkenalkan blob sebagai ruang data berbiaya khusus bagi rollup, tetapi pola sederhana “setiap node mengunduh semuanya” tetap membatasi pertumbuhan. PeerDAS memperluas blob dengan *one-dimensional erasure coding*: data dan fragmen pemulihannya disusun menjadi sel serta kolom, lalu setiap kolom dipetakan ke subnet gossip. Menurut spesifikasi, node menjaga seperangkat subnet kolom yang ditentukan dari ID node dan mengambil sampel kolom dari peer pada setiap slot. Bila sedikitnya 50% kolom diperoleh, matriks data lengkap dapat direkonstruksi; target operasionalnya bukan selalu melakukan rekonstruksi, melainkan memperoleh keyakinan probabilistik bahwa data benar-benar tersedia ([EIP-7594](https://eips.ethereum.org/EIPS/eip-7594)).
> **Highlight:** PeerDAS memisahkan verifikasi ketersediaan dari kewajiban mengunduh seluruh blob—kapasitas jaringan dapat naik tanpa memaksa kebutuhan bandwidth setiap node naik secara sebanding.
<a id="bagian-02"></a>
## 02 — Mekanisme PeerDAS dalam Satu Slot
Dalam alur sederhananya, pengirim transaksi blob menyertakan *cell proofs* berbasis KZG; node memeriksa kesesuaian komitmen, blob, dan bukti, lalu mengelola kolom yang menjadi tanggung jawabnya. Node membangun kumpulan peer yang beragam, meminta kolom sampel, dan menilai ketersediaan data sebelum mengikuti kepala rantai. EIP menempatkan pembuatan bukti yang relatif mahal pada pengirim, sedangkan verifikasi oleh penerima lebih murah. Desain kolom juga memungkinkan sebuah sampel mencakup potongan dari seluruh blob dalam blok, bukan satu blob utuh. Ini menjadikan distribusi, custody, sampling, dan rekonstruksi sebagai satu sistem; bukan sekadar kompresi data.
| Tahap | Pelaku utama | Fungsi |
|---|---|---|
| Pembentukan sel dan bukti | Pengirim transaksi blob | Membuat sel serta bukti KZG yang dapat diverifikasi |
| Distribusi kolom | Jaringan gossip | Menyebarkan kolom melalui subnet yang ditentukan |
| Custody | Full node dan validator | Menyimpan kolom sesuai kewajiban protokol |
| Sampling | Node kepada peer | Meminta sebagian kolom untuk menguji ketersediaan |
| Rekonstruksi | Node saat diperlukan | Memulihkan matriks dari sekurangnya separuh kolom |
<a id="bagian-03"></a>
## 03 — Apa yang Berubah bagi Rollup dan Node
Bagi rollup, tambahan kapasitas DA berarti ruang lebih besar untuk memublikasikan data batch, sehingga biaya blob berpotensi menjadi lebih stabil ketika permintaan naik—bukan jaminan bahwa biaya pengguna selalu turun, karena harga juga dipengaruhi permintaan, kebijakan fee, kompresi, dan operasi sequencer. Bagi operator node, keuntungan arsitekturalnya adalah kebutuhan unduhan minimum berupa fraksi konstan; rasional EIP menyebut parameter saat ini sekitar seperdelapan data total, dengan kemungkinan diperkecil pada masa depan. Validator memikul kewajiban custody tambahan yang meningkat bersama jumlah validator agar sumber daya yang lebih besar ikut menopang tulang punggung jaringan. Gambaran ini sejalan dengan arah *danksharding* Ethereum: sampling memungkinkan kapasitas blob berkembang tanpa semua validator menyimpan seluruh dataset ([Ethereum.org](https://ethereum.org/en/roadmap/danksharding/)).
<a id="bagian-04"></a>
## 04 — Jaminan, Asumsi, dan Batas Keamanan
PeerDAS bukan “data gratis” dan bukan penghapusan risiko. Keamanannya bergantung pada keragaman peer, penyebaran custody yang memadai, verifikasi bukti kriptografis, dan ketahanan jaringan terhadap peer yang menahan data atau membentuk pandangan terisolasi. Redundansi peer membantu karena sampel yang gagal dari satu pihak dapat diminta dari pihak lain, tetapi kualitas konektivitas tetap penting. EIP juga membatasi enam blob per transaksi dan mengharuskan klien memvalidasi batas itu saat penerimaan, produksi, serta pemrosesan blok. Konsekuensinya, implementasi klien, interoperabilitas, pengujian serangan jaringan, dan observabilitas kegagalan sampling sama pentingnya dengan rumus kapasitas nominal.
- [ ] Tingkat keberhasilan sampling lintas wilayah dan implementasi klien
- [ ] Distribusi kolom serta beban bandwidth pada node rumahan
- [ ] Latensi propagasi blob ketika pemakaian mendekati target
- [ ] Ketersediaan peer alternatif saat subnet mengalami gangguan
- [ ] Kemampuan rekonstruksi ketika sebagian sumber data menghilang
<a id="bagian-05"></a>
## 05 — Indikator Implementasi yang Perlu Dipantau
Penilaian pascapenerapan sebaiknya tidak berhenti pada klaim “8x”. Ukuran yang lebih bermakna mencakup target dan pemakaian blob per blok, latensi sampling, persentase permintaan kolom yang gagal atau terlambat, konsumsi bandwidth menurut jenis node, serta apakah biaya blob rollup benar-benar membaik dalam periode permintaan tinggi. Perlu pula dibedakan antara kapasitas protokol yang tersedia dan kapasitas yang aman dipakai: peningkatan parameter lazim dilakukan bertahap agar pengembang klien dan operator dapat mengamati dampak nyata. Untuk pengguna, PeerDAS adalah infrastruktur latar belakang; manfaat akhirnya baru terasa jika rollup meneruskan efisiensi DA melalui kebijakan biaya dan operasi yang sehat.
<a id="kesimpulan-artikel"></a>
## Kesimpulan
PeerDAS adalah perubahan mendasar pada pembagian kerja jaringan Ethereum: alih-alih setiap node mengambil semua blob, node memelihara dan menyampel kolom data yang dapat dibuktikan, sementara *erasure coding* menyediakan jalur rekonstruksi. Desain tersebut membuka ruang penskalaan DA bagi rollup dengan menjaga tuntutan node tetap lebih terkendali, tetapi hasilnya harus dinilai melalui metrik jaringan dan implementasi klien, bukan slogan kapasitas. Ini analisis teknologi protokol, bukan rekomendasi membeli atau menjual aset kripto.
<a id="sumber-artikel"></a>
## Sumber
1. [EIP-7594 — PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) — spesifikasi final, mekanisme sampling, custody, rekonstruksi, dan pertimbangan keamanan.
2. [Ethereum.org — Danksharding](https://ethereum.org/en/roadmap/danksharding/) — konteks resmi tentang blob, data availability sampling, dan peta jalan penskalaan.
3. [Ethereum di X — PeerDAS dalam Fusaka](https://x.com/ethereum/status/1998849926210678830) — sinyal komunikasi akun resmi mengenai posisi PeerDAS dan klaim throughput; diverifikasi terhadap sumber teknis non-X di atas.
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
