Lompat ke konten
Financial Context Wiki

Blobspace

Panduan berbasis verifikasi mengenai blobspace Ethereum, kapasitas terenkode dan yang dapat digunakan, sampling dan custody PeerDAS, retensi sementara, derivasi rollup, serta batas terkini yang bergantung pada fork.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban singkat

Blobspace adalah kapasitas sementara dan terbatas milik Ethereum untuk ketersediaan data blob yang commitment-nya disertakan bersama blok. Blobspace bukan ruang eksekusi EVM, penyimpanan kontrak, sistem berkas permanen, ataupun token. Transaksi tipe 3 memuat hash berversi; data blob terautentikasi berjalan melalui sidecar lapisan konsensus atau kolom data PeerDAS. EVM dapat memeriksa hash berversi dan memverifikasi pembukaan pada suatu titik, tetapi tidak dapat membaca payload blob secara langsung.

PeerDAS memperluas blob dengan erasure coding, membagi matriks yang diperluas menjadi 128 columns, serta memungkinkan node menyimpan dan mengambil sampel subset alih-alih mewajibkan setiap node mengunduh setiap blob secara penuh. Hal ini mendukung penilaian probabilistik lokal atas ketersediaan, bukan bukti validitas eksekusi rollup, finalitas Ethereum, keamanan bridge, atau akses permanen. Kapasitas berubah menurut fork. Per 2026-08-13, mainnet Ethereum setelah Fusaka BPO2 menargetkan 14 blobs per block dan mengizinkan maksimum 21; setiap transaksi blob dibatasi 6 blobs.

Cara kerja

  1. Tetapkan jaringan, blok atau slot, fork aktif dan jadwal Blob-Parameter-Only, beserta rollup dan versi derivasi. Jadwal historis 3/6, Pectra 6/9, jadwal terkini 14/21, testnet, dan parameter mendatang tidak dapat dipertukarkan.
  2. Identifikasi objek publikasi: transaksi tipe 3, hash berversi, commitment dan proof KZG, indeks blob, origin L1, serta apakah rollup benar-benar memakai blob Ethereum, bukan calldata atau DA alternatif. Commitment mengikat data, tetapi tidak dengan sendirinya membuktikan byte tersebut tersedia.
  3. Pisahkan satuan. Satu blob memiliki 4,096 field elements * 32 bytes = 131,072 encoded bytes; payload tanpa batasan format umumnya menggunakan 31 bytes per elemen field, atau 126,976 usable bytes. Kompresi, framing, padding, blob gas, cell yang diperluas dengan erasure coding, dan byte aplikasi adalah besaran berbeda.
  4. Verifikasi batas jadwal. Target mengarahkan umpan balik harga; target bukan kapasitas yang dicadangkan. Maksimum blok merupakan batas konsensus, bukan throughput yang diharapkan. Batas PeerDAS 6 blobs per transaction berbeda dari maksimum terkini 21 blobs per block.
  5. Verifikasi jalur ketersediaan. PeerDAS memakai perluasan erasure satu dimensi, cell dan kolom terautentikasi, gossip, serta permintaan peer. Node mengambil sampel sedikitnya 8 columns menurut parameter saat ini dan memiliki kewajiban custody; memperoleh sedikitnya 64 of 128 columns memungkinkan rekonstruksi matriks yang diperluas.
  6. Lacak status siklus hidup secara terpisah: commitment dimasukkan, kolom data diperoleh dan diverifikasi, pemeriksaan DA lokal lolos, blok L1 berstatus aman atau final, batch rollup didekode dan diderivasi, jendela layanan minimum masih aktif, serta arsip independen telah diuji. Ketersediaan tidak otomatis membuat semua status berikutnya benar.
  7. Simulasikan kolom hilang, eclipse atau partisi, propagasi terlambat, reorganisasi L1, ketidakcocokan jadwal atau klien, peningkatan format rollup, dan hilangnya arsip. Ambil, rekonstruksi, dan simpan data yang diperlukan sebelum jendela protokol berakhir; gunakan topik biaya blob terpisah untuk pembukuan biaya batcher dan pengguna.

Contoh perhitungan

  • Satuan byte satu blob. Kapasitas terenkode adalah 4,096 * 32 = 131,072 bytes = 128 KiB. Payload arbitrer umum adalah 4,096 * 31 = 126,976 bytes = 124 KiB. Selisihnya 4,096 bytes, atau 3.125% dari kapasitas terenkode; kompresi dan framing rollup semakin mengurangi payload aplikasi.
  • Kapasitas per blok terkini. Pada target, kapasitasnya 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB dan 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. Pada maksimum, kapasitasnya 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB dan 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. Ini adalah batas per blok mainnet yang terkait tanggal sebelum kompresi dan framing.
  • Batas transaksi dan blok. Transaksi dengan 6 blobs membawa 786,432 encoded bytes = 0.75 MiB dan 761,856 usable bytes = 0.7265625 MiB. Blok maksimum 21-blob memerlukan sedikitnya 4 transactions, misalnya 6 + 6 + 6 + 3; blok target 14-blob dapat berupa 6 + 6 + 2. Tidak satu pun alokasi tersebut merupakan reservasi per rollup.
  • Jendela layanan dan volume nominal. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. Pada nominal 7,200 slots per day dan target 14-blob, volume terenkode adalah 100,800 blobs per day = 12.3046875 GiB per day, sedangkan volume yang umumnya dapat digunakan adalah 11.920166015625 GiB per day. Slot yang terlewat dan inklusi aktual mengubah total terealisasi, dan jendela layanan bukan janji arsip permanen.

Risiko

  • Menerapkan fork atau jadwal Blob-Parameter-Only yang usang.
  • Mencampur batas mainnet, testnet, atau jaringan lain.
  • Menganggap target sebagai kapasitas yang dijamin atau dicadangkan.
  • Menganggap maksimum sebagai throughput normal yang diharapkan.
  • Mencampur batas enam blob per transaksi dengan batas blok.
  • Mencampur satuan terenkode, dapat digunakan, terkompresi, berframing, dan blob gas.
  • Mengabaikan padding atau overhead format rollup.
  • Menyebut calldata atau DA alternatif sebagai blobspace Ethereum.
  • Menerima hash berversi yang tidak cocok dengan commitment blob.
  • Menganggap pembukaan KZG valid sebagai bukti bahwa byte tersedia.
  • Menganggap sampling sebagai unduhan lokal lengkap setiap blob.
  • Mencampur ketersediaan data dengan validitas transisi state.
  • Mencampur pemeriksaan DA lokal dengan finalitas L1 atau rollup.
  • Kehilangan kolom akibat penundaan, eclipse, partisi, atau peer berkorelasi.
  • Gagal merekonstruksi atau meminta peer meski kapasitas nominal tersedia.
  • Kehilangan atau mengubah urutan commitment dalam reorganisasi L1.
  • Membiarkan jendela layanan minimum berakhir sebelum derivasi atau challenge.
  • Bergantung pada arsip atau indexer yang tidak tersedia, rusak, atau tidak lengkap.
  • Gagal menderivasi rollup setelah peningkatan kompresi atau protokol.
  • Menganggap bridge atau exit aman hanya karena data blob tersedia.

Kesalahpahaman umum

  • Blobspace adalah penyimpanan permanen yang dapat dibaca kontrak seperti calldata.
  • Setiap byte dalam blob 128 KiB merupakan payload aplikasi tanpa batasan.
  • Setiap node Ethereum mengunduh dan menyimpan permanen setiap blob penuh dalam PeerDAS.
  • Commitment KZG, sampel yang berhasil, atau inklusi final membuktikan state rollup benar dan pengguna dapat keluar.
  • Kapasitas mainnet tetap selamanya pada 3/6, 6/9, atau jadwal terkini 14/21.

Topik terkait

Sumber

Navigasi

Cari di wiki...