Maret 2024 mengubah lanskap ekonomi layer-2 selamanya. Sebelum Dencun, rollup seperti Arbitrum atau Optimism menghabiskan anggaran tim hanya untuk memompa calldata ke mainnet. Smart contract Ethereum memahat susunan byte tersebut ke dalam state global secara permanen, memaksa setiap validator menyimpannya selamanya. Ini memakan hingga sembilan puluh persen biaya pengguna L2.
EIP-4844 mendobrak skema tersebut dengan mengenalkan transaksi tipe ketiga dan blob. Namun, di balik angka manis penurunan biaya sebesar 10–50 kali lipat, tersimpan segudang nuansa teknis yang sering kali ditutup-tutupi oleh tim pemasaran.
Anatomi blob di level memori dan konsensus
Blob bukan sekadar file yang dikirim ke blockchain. Ini adalah array data terisolasi berukuran tepat 131.072 byte (128 KB) yang berjalan secara paralel dengan eksekusi EVM. Smart contract di Ethereum tidak dapat membaca isi blob di dalam panggilan CALL atau STATICCALL. Mereka hanya memiliki akses ke satu bytecode—opcode khusus bernama BLOBHASH—yang mengembalikan versi dan hash komitmen.
- Ukuran blok: targetnya adalah 3 blob (~384 KB), dengan puncak maksimum mencapai 6 blob (~768 KB).
- Masa aktif: sekitar 4.096 epoch (kurang lebih 18 hari), setelah itu node konsensus membersihkan data tersebut dari disk.
- Isolasi mempool: blob tidak berputar di execution mempool biasa. Mereka memiliki pool tersendiri di level client konsensus (P2P blob pool), yang melindungi antrean transaksi utama dari kelebihan beban (overload).
Parameter | Calldata Klasik | Blob EIP-4844 (Type 3)
Lokasi data: Di EVM state permanen | Di p2p-pool konsensus sementara
Durasi penyimpanan: Selamanya | ~18 hari
Akses dari EVM: Langsung (lewat pembacaan byte) | Tidak langsung (hanya via hash dan KZG)
Mekanisme harga: Execution gas bersama | Pasar blob gas independen (EIP-1559)
Fitur tersembunyi dan jebakan arsitektur proto-danksharding
Hanya sedikit yang menyoroti cara kerja penentuan harga blob gas. Berbeda dari gas standar yang melonjak setiap kali ada gejolak kecil di DeFi, pasar blob dikendalikan oleh algoritma penyesuaian independen. Jika rollup memenuhi slot melebihi target tiga blob, harganya akan meroket secara eksponensial. Sebaliknya, jika slot kosong, harganya turun ke batas minimum. Dalam praktiknya, mengirim blob di jam sepi hanya membiayai sebagian kecil dari satu sen, tetapi saat jaringan mendadak padat, harganya bisa melonjak ratusan kali lebih cepat dibandingkan execution layer.
Satu detail krusial lainnya adalah verifikasi kriptografi melalui KZG commitment (Kate-Zaverucha-Goldberg). Validator tidak perlu mengunduh seluruh 128 KB untuk memastikan keabsahan data. Mereka cukup memverifikasi polinomial 48-byte. Cara ini meringankan beban CPU validator, namun mengalihkan beban berat tersebut ke bandwidth jaringan.
Tempat membuang data "sampah" secara praktis
Sifat sementara dari blob menjadikannya kontainer ideal untuk data yang tidak membutuhkan pembukuan abadi, tetapi memerlukan keabadian kriptografis dalam jendela validasi yang singkat:
- Dump oracle dan metrik mentah: array data perantara yang ditandatangani oleh penyedia sebelum diagregasikan ke dalam smart contract.
- Snapshot state L3 dan dunia game: perubahan delta state yang cukup dibuktikan kebenarannya untuk rentang seminggu terakhir.
- Log audit backend: sekumpulan transaksi atau kuitansi yang harus dapat diverifikasi secara publik, tetapi kehilangan nilai operasionalnya setelah sebulan.
Memasukkan beban kerja ke dalam blob melalui skrip Python dengan web3.py menuntut pengemasan byte secara terpisah ke dalam polinomial dan pembuatan hash versi dengan awalan 0x01. Salah menghitung maxFeePerBlobGas saat pengiriman dijamin akan membuat transaksi Anda tersangkut di mempool.
Teori dan aspek ekonominya sudah jelas, tapi bagaimana praktiknya bekerja dengan blob di level kode? Menggunakan panggilan send_transaction standar bakal menghasilkan error, karena transaksi tipe ketiga memerlukan persiapan manual untuk KZG commitment, pembuatan proof, dan perhitungan batas gas tersendiri.
Mengirim Transaksi Type-3 dengan Python
Berikut adalah pola kerja untuk mengirim blob menggunakan library node terkini (seperti Geth atau Reth) yang sudah mendukung upgrade Dencun:
import os
from eth_account import Account
from web3 import Web3
w3 = Web3(Web3.HTTPProvider("http://127.0.0.1:8545"))
key = os.environ["OPERATOR_KEY"]
acct = Account.from_key(key)
FE_COUNT, FE_PAYLOAD = 4096, 31 # 31 byte data per elemen field
def encode_blob(data: bytes) -> bytes:
data = len(data).to_bytes(4, "big") + data
if len(data) > FE_COUNT * FE_PAYLOAD:
raise ValueError("payload tidak muat dalam satu blob")
data = data.ljust(FE_COUNT * FE_PAYLOAD, b"\x00")
# byte atas dari setiap elemen = 0 agar nilainya < modulus BLS
return b"".join(b"\x00" + data[i:i + FE_PAYLOAD]
for i in range(0, len(data), FE_PAYLOAD))
blob = encode_blob(b"EXMON Infrastructure DA Payload: batch #98412")
# Harga blob gas saat ini dengan buffer untuk lonjakan
blob_base_fee = int(w3.provider.make_request("eth_blobBaseFee", [])["result"], 16)
base_fee = w3.eth.get_block("latest")["baseFeePerGas"]
tx = {
"type": 3,
"chainId": w3.eth.chain_id,
"nonce": w3.eth.get_transaction_count(acct.address),
"gas": 21000,
"maxPriorityFeePerGas": w3.to_wei(1, "gwei"),
"maxFeePerGas": base_fee * 2 + w3.to_wei(1, "gwei"),
"maxFeePerBlobGas": max(blob_base_fee * 2, w3.to_wei(1, "gwei")),
"to": acct.address, # bukan pembuatan kontrak: `to` wajib ada untuk blob-tx
"value": 0,
"data": b"",
}
# ckzg menghitung commitment, proof, dan versioned hash; sidecar disisipkan ke raw tx
signed = Account.sign_transaction(tx, key, blobs=[blob])
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f"Blob-tx terkirim: {tx_hash.to_0x_hex()}")Jika Anda tidak memperhitungkan volatilitas maxFeePerBlobGas, saat rollup mengalami lonjakan trafik puncak, transaksi Anda akan tersangkut di konsensus mempool sampai pasar kembali stabil.
Masalah Archive Node: Kemana Perginya Data Setelah 18 Hari
Jebakan utama dalam merancang arsitektur berbasis blob berkaitan dengan proses penghapusannya. Klien konsensus menyimpan isi blob setidaknya selama 4096 epoch (sekitar 18 hari), setelah itu mereka akan menghapusnya. Transaksi itu sendiri dan KZG commitment akan tetap ada di blockchain selamanya, tetapi Anda tidak bisa memulihkan isi blob dari data tersebut. Jika sebulan kemudian Anda perlu mengambil data blob tersebut, node standar akan mengembalikan error.
Tim yang membangun produk di atas EIP-4844 terpaksa harus mengatasi masalah ini melalui salah satu dari tiga cara berikut:
- Penyedot arsip mandiri: Menjalankan layanan latar belakang (background service) yang menarik blob dari jaringan P2P begitu data tersebut muncul dan menyimpannya ke cold storage (bucket yang kompatibel dengan S3).
- Arsip terdesentralisasi: Memanfaatkan jaringan seperti Celestia, Avail, atau The Graph untuk penyimpanan ketersediaan data (Data Availability) jangka panjang.
- Mengabaikan histori mendalam: Menyimpan indeks lokal hanya untuk rentang aktif dua minggu, lalu membuang agregat lama dalam bentuk terkompresi.
Praktik EXMON: Optimisasi Penyimpanan
Di infrastruktur EXMON, kami menggunakan ruang blob sementara untuk memindahkan log transaksi interim yang berat, dump layanan, dan snapshot verifikasi.
Langkah ini memungkinkan kami menyelesaikan dua hal sekaligus:
- Efisiensi anggaran: Biaya publikasi data turun drastis hingga beberapa kali lipat dibandingkan metode lama menggunakan calldata.
- Kebersihan blockchain: State global jaringan tidak dipenuhi sampah yang kehilangan relevansinya dalam waktu seminggu, sementara verifikasi kriptografis seratus persen tetap terjaga selama siklus hidup data tersebut.
