Mart 2024, ikinci katman ekonomisini kökten değiştirdi. Dencun öncesinde Arbitrum veya Optimism gibi rollup'lar, ana ağa calldata basmak için ekiplerin bütçelerini yakıyordu. Ethereum akıllı sözleşmeleri, bu bayt dizisini kalıcı olarak global duruma yazıyor ve her validatörün bunu sonsuza dek saklamasını zorunlu kılıyordu. Bu durum, L2 kullanıcı maliyetlerinin yüzde doksanına kadarını oluşturuyordu.
EIP-4844, üçüncü tip işlem ve blob'ları getirerek bu mekanizmayı kırdı. Ancak komisyonların 10 ila 50 kat düştüğünü söyleyen havalı rakamların arkasında, pazarlamacıların genellikle susmayı tercih ettiği bir sürü mühendislik nüansı yatıyor.
Bellek ve konsensüs seviyesinde blob nasıl çalışır?
Blob, blockchain'e gönderilen sıradan bir dosya değildir. EVM yürütmesine paralel olarak var olan, tam olarak 131.072 bayt (128 KB) boyutunda izole edilmiş bir veri dizisidir. Ethereum'daki akıllı sözleşmeler, bir CALL veya STATICCALL çağrısının içinde blob içeriğini okuyamaz. Yalnızca tek bir bayt koduna, yani sürümü ve taahhüt hash'ini döndüren özel BLOBHASH opcode'una erişimleri vardır.
- Blok boyutu: Hedef gösterge 3 blob (~384 KB), zirvedeki maksimum değer ise 6 blobtur (~768 KB).
- Yaşam süresi: Yaklaşık 4096 epoch (yaklaşık 18 gün), sonrasında konsensüs nod'ları verileri disklerinden temizler.
- Mempool izolasyonu: Blob'lar standart execution mempool'da dönmez. Konsensüs istemci seviyesinde (P2P blob pool) kendilerine ait bir havuzları bulunur; bu da ana işlem kuyruklarını aşırı yüklenmeden (overload) korur.
Parametre | Klasik calldata | EIP-4844 Blobu (Type 3)
Verilerin saklandığı yer: Kalıcı EVM state'inde | Geçici P2P konsensüs havuzunda
Saklama süresi: Sonsuza kadar | ~18 gün
EVM'den erişim: Doğrudan (bayt okuma yoluyla) | Dolaylı (yalnızca hash ve KZG ile)
Fiyatlandırma: Ortak execution gas | Bağımsız blob gas piyasası (EIP-1559)
Proto-danksharding'in bariz olmayan özellikleri ve mimari tuzakları
Blob gas fiyatlandırmasının nasıl çalıştığına çok az kişi dikkat ediyor. DeFi'deki her küçük dalgalanmada zıplayan standart gazın aksine, blob piyasası bağımsız bir düzeltme algoritması tarafından yönetilir. Eğer rollup'lar hedeflenen üç blobun üzerinde slotları doldurursa, fiyat üssel olarak artmaya başlar. Slotlar boş kalırsa minimum eşiğe kadar düşer. Pratikte bu durum, sakin saatlerde blob göndermenin sentin mikroskopik bir kesrine mal olması, ancak ani bir ağ saldırısı/yoğunluğu anında fiyatın execution katmanına kıyasla yüzlerce kat daha hızlı fırlayabilmesi anlamına gelir.
Bir diğer hassas nokta ise KZG taahhütleri (Kate-Zaverucha-Goldberg) aracılığıyla yapılan kriptografik doğrulamadır. Validatörlerin verilerin doğruluğundan emin olmak için 128 KB'ın tamamını indirmesine gerek yoktur. 48 baytlık bir polinomu kontrol etmeleri yeterlidir. Bu, validatörlerin işlemci gereksinimlerini düşürür ancak tüm yükü ağ kanalına aktarır.
"Gereksiz" veriler pratikte nereye basılmalı?
Blob'ların geçici doğası; kalıcı muhasebeye ihtiyaç duymayan, ancak kısa bir doğrulama aralığında kriptografik olarak değiştirilemez olması gereken veriler için onları mükemmel bir konteyner yapar:
- Oracle dump'ları ve ham metrikler: Akıllı sözleşmede birleştirilmeden önce sağlayıcılar tarafından imzalanan ara veri dizileri.
- L3 durum anlık görüntüleri (snapshot) ve oyun dünyaları: Son bir hafta boyunca doğruluğunun kanıtlanması yeterli olan delta durum değişiklikleri.
- Backend denetim logları: Genel olarak doğrulanması gereken, ancak bir ay sonra operasyonel değerini yitiren işlem paketleri veya makbuzlar.
web3.py üzerindeki Python betikleri aracılığıyla bloba yük atmak; baytların polinomlar halinde ayrı ayrı paketlenmesini ve 0x01 önekiyle sürümlü bir hash oluşturulmasını gerektirir. Gönderim sırasında maxFeePerBlobGas değerini yanlış hesaplamak, işlemin mempool'da takılıp kalmasını garanti eder.
Teori ve ekonomi kısmı gayet net, ancak iş kod seviyesinde blob'larla çalışmaya gelince işler nasıl dönüyor? Standart send_transaction çağrısı doğrudan hata verecektir; çünkü 3. tip işlemler; KZG taahhütlerinin (commitment) manuel olarak hazırlanmasını, kanıtların (proof) üretilmesini ve ayrı bir gas limitinin hesaplanmasını gerektirir.
Python ile Type-3 İşlem (Transaction) Gönderimi
Aşağıda, Dencun yükseltmesini destekleyen bir node (Geth veya Reth) ile çalışırken blob göndermek için kullanılan çalışan bir örnek kalıp yer almaktadır:
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 # Alan elemanı başına 31 bayt veri
def encode_blob(data: bytes) -> bytes:
data = len(data).to_bytes(4, "big") + data
if len(data) > FE_COUNT * FE_PAYLOAD:
raise ValueError("payload tek bir bloba sığmıyor")
data = data.ljust(FE_COUNT * FE_PAYLOAD, b"\x00")
# Değerin BLS modülünden küçük olması için her elemanın en anlamlı baytı (high byte) = 0
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")
# Artış payı bırakılarak hesaplanan güncel blob gas ücreti
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, # Kontrat oluşturma değil: blob-tx'lerde `to` alanı zorunludur
"value": 0,
"data": b"",
}
# ckzg taahhüdü, kanıtları ve versioned hash'i hesaplar; sidecar ham işleme (raw tx) dahil edilir
signed = Account.sign_transaction(tx, key, blobs=[blob])
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f"Blob-tx gönderildi: {tx_hash.to_0x_hex()}")Eğer maxFeePerBlobGas dalgalanması hesaba katılmazsa, rollup'ların yoğun olduğu anlarda işlem, piyasa sakinleşene kadar konsensüs mempool'unda takılı kalır.
Arşiv Nodlarının Çıkmazı: Veriler 18 Gün Sonra Nereye Gidiyor?
Blob mimarisi tasarlanırken karşılaşılan en büyük tuzak, bu verilerin silinmesiyle ilgilidir. Konsensüs istemcileri (consensus clients) blob gövdelerini en az 4096 epoch boyunca (yaklaşık 18 gün) saklar ve ardından siler. İşlemin kendisi ve KZG taahhüdü blockchain üzerinde kalıcı olarak kalır, ancak bunlardan yola çıkarak blob içeriğini geri getirmek imkansızdır. Bir ay sonra blob verilerine erişmek gerektiğinde standart bir node hata dönecektir.
EIP-4844 üzerinde ürün inşa eden ekipler bu sorunu şu üç yoldan biriyle çözmek zorundadır:
- Özel arşiv toplayıcıları (scrapers): Blob'ların P2P ağında belirdiği anda onları yakalayıp soğuk depolamaya (S3 uyumlu bucket'lar) atan arka plan servisleri kurmak.
- Merkeziyetsiz arşivler: Uzun vadeli Veri Erişilebilirliği (Data Availability) depolaması için Celestia, Avail veya The Graph gibi ağları kullanmak.
- Derin tarihten vazgeçmek: Yerel indeksleri yalnızca aktif iki haftalık pencere için saklayıp, eski verileri sıkıştırılmış formatta dışarı aktarmak.
EXMON Pratiği: Depolama Optimizasyonu
EXMON altyapısında; ağır ara işlem loglarını, servis dump'larını ve doğrulama anlık görüntülerini (snapshot) ana akıştan çıkarmak için geçici blob alanlarını kullanıyoruz.
Bu yaklaşım aynı anda iki sorunu çözmemizi sağlıyor:
- Bütçe tasarrufu: Veri yayınlama maliyetleri, eski calldata yöntemlerine kıyasla katbekat azaldı.
- Blockchain temizliği: Ağın global durumu bir hafta içinde geçerliliğini yitiren çöplerle dolmuyor, aynı zamanda veri yaşam döngüsü boyunca %100 kriptografik doğrulanabilirlik korunuyor.
