Miért zuhantak 90%-ot az Ethereum L2 díjak? Az EIP-4844 hatása

Az Ethereum fejlesztői közösségben egyre több szó esik az EIP-4844-ről – és joggal. A proto-danksharding nevű mechanizmus, amelyet a Dencun upgrade hozott el 2024 márciusában, alapvetően forgatta fel a rollupok adatköltségeit. Ha Ethereum-alapú alkalmazást fejlesztesz, vagy egyszerűen csak érdekel, hogy a Layer 2 díjak miért zuhantak látványosan, érdemes mélyen beleásni ebbe a témába.

Mi az az EIP-4844, és miért számít?

Az Ethereum skálázhatóságának egyik legnagyobb szűk keresztmetszete hagyományosan az volt, hogy a Layer 2 rollupok a tranzakciós adataikat az L1 calldata-jában tárolták. Ez drága volt – a calldata minden bájtja gas-ba kerül, és verseng az összes többi blokkláncon belüli aktivitással.

Az EIP-4844 erre a problémára hozott megoldást egy teljesen új tranzakciótípussal: a blob-carrying transaction-nel (3-as típusú tranzakció). A blob-ok rövid élettartamú adatcsomagok – nagyjából 128 KB méretűek, és az Ethereum konszenzusrétege csak körülbelül 4096 epocháig (kb. 18 napig) tárolja őket, utána eldobja. Ez pontosan annyi idő, amennyit egy rollupnak szüksége van az adatok ellenőrzéséhez.

A Dencun-frissítés óta a rollup-díjak egyes L2 hálózatokon 80-90%-kal csökkentek. Magyar felhasználóknak ez konkrétan annyit jelent, hogy egy Arbitrum vagy Base hálózaton végrehajtott DeFi-tranzakció töredékébe kerül a korábinak.

Amit fejlesztőként feltétlenül tudni kell: az EVM nem látja a blobokat

Ez az egyik legkritikusabb pont, ahol félreértések szoktak születni. Az EVM nem fér hozzá közvetlenül a blob tartalmához. Ha egy okosszerződést írasz, és azt várod, hogy a blob adatait blokkláncon belüli logikában tudod majd feldolgozni – tévedsz.

Amit az EVM valóban lát, az a versioned hash: egy 32 bájtos azonosító, amelyet a blob kriptográfiai ujjlenyomatából (KZG commitment-ből) képeznek. Az opcode neve BLOBHASH, az indexe 0x49. Ez lehetővé teszi, hogy egy szerződés ellenőrizze: egy adott blob valóban csatolva volt-e a tranzakcióhoz, de a tartalmát nem olvassa.

• BLOBHASH opcode: visszaadja az i-edik blob verziózott hash-ét
• POINT_EVALUATION precompile (0x0A cím): KZG proof-ok ellenőrzésére használható blokkláncon belüli
• A blob tényleges adatai csak a konszenzusrétegen érhetők el, az EVM execution rétegén nem

Ez az architektúra szándékos. A cél az, hogy az adatelérhetőség olcsó legyen, nem pedig az, hogy az EVM mindenhez hozzáférjen – ez utóbbi egyébként szörnyű teljesítményromlást okozna.

A blob gas piac: teljesen független rendszer

Az EIP-4844 bevezette a blob gas market fogalmát – egy önálló díjpiacot, amely párhuzamosan működik a hagyományos execution gas piacával. A kettő teljesen független egymástól. Ha a hálózat blob-forgalma alacsony, a blob gas ára a minimumra süllyed, miközben a normál gas lehet egészen magas, és fordítva.

Jelenleg a protokoll blokkönként 3 blob-ot céloz meg (target), és legfeljebb 6 blob-ot enged per blokk. Az árazás EIP-1559-hez hasonló mechanizmussal működik:

1. Ha az aktuális blob-felhasználás meghaladja a 3-as target-et, a blob_base_fee emelkedik
2. Ha alatta marad, csökken
3. A minimális blob base fee 1 wei – extrém alacsony lehet szabad kapacitás esetén

Fejlesztői szempontból ez azt jelenti, hogy a blob gas árat külön kell figyelni. A szokásos eth_gasPrice vagy eth_maxFeePerGas lekérdezések nem adnak róla információt. Az új eth_blobBaseFee RPC endpoint vagy a BeaconBlock fejléc excess_blob_gas mezője az, amire szükséged van.

Monitorozási pontok fejlesztőknek

Ha L2-t üzemeltetsz, rollup szekvencer vagy épp egy olyan alkalmazást építesz, amelynek fontos a blob piac állapota, az alábbi metrikákat érdemes folyamatosan szemmel tartani:

• blob_base_fee: az aktuális blob gas ára weiből számítva – ezt az execution client adja vissza
• excess_blob_gas: a beacon block fejlécében található, a blob base fee kiszámításának alapja
• blob_gas_used per blokk: mennyit használtak a maximálisan engedélyezettből (786 432 blob gas = 6 blob maximum)
• Blob pool telítettsége: az Ethereum node-ok külön mempoolt tartanak fenn blob tranzakcióknak – ez szűk keresztmetszet lehet nagy forgalomnál

Praktikus tanács: a blobscan.com és az Etherscan blob explorer funkciói jó kiindulópontok vizuális monitorozáshoz. Termelési környezetben azonban saját alerting nélkül ne menj live-ba.

Mit nyernek rajta a rollupok – és a felhasználók?

Az Optimism, az Arbitrum, a Base és a többi EVM-kompatibilis rollup mind átállt a blob-alapú adatközlésre. A mechanizmus lényege: ahelyett, hogy a rollup minden batch-et calldata-ként posztolna az L1-re, blob-tranzakciókat küld – amelyek olcsóbbak, mert nem kerülnek be az Ethereum állapotfájába, nem maradnak örökre a láncon.

A rollup szempontjából a megtakarítás forrása kettős:

• Alacsonyabb adatköltség: a blob gas historikusan töredéke volt az ekvivalens calldata-költségnek a Dencun után
• Dedikált kapacitás: a blob-ok nem versenyeznek az ERC-20 transzferekkel vagy az NFT mintingekkel a normál gas-ért

Egy konkrét példa: az Optimism L1 adatköltségei a Dencun aktiválása után néhány nappal akár 95%-kal is csökkentek egyes időszakokban. Magyar DeFi-felhasználók számára ez kézzel fogható különbség: egy swap, amely korábban 1-2 dollárba kerülhetett az L2-n, azóta jellemzően néhány cent alatt marad, ha a blob gas piac nem telített.

Mire figyelj, ha szerződést írsz EIP-4844 kontextusban?

Az EVM fejlesztőknek nem feltétlenül kell mélyen belemerülniük a blob mechanizmusba – de ha rollup bridge-et, DA (data availability) réteget vagy bizonyítékokat ellenőrző logikát írsz, a következők kritikusak:

• A BLOBHASH opcode csak tranzakción belül érhető el; statikus hívásokból (STATICCALL) nem működik
• A verziózott hash első bájtja jelenleg mindig 0x01 – ez a KZG commitment verziójára utal; jövőbeli verzióknál változhat
• Ha a blob hash-t blokkláncon belüli tárolod, gondolj arra, hogy maga az adat 18 nap után eltűnik – archivált adatelérhetőséghez külső DA megoldás kell
• A tx.type == 3 ellenőrzéssel megállapítható, hogy egy tranzakció blob-carrying-e, de ez ritkán szükséges alkalmazáslogikában

Összefoglalás

Az EIP-4844 nem csodaszer – a teljes danksharding, amely végleges formájában sokszorta több blob-ot tesz lehetővé, még előttünk van. De az, ami 2024 márciusa óta élesben fut, már most érzékelhető változást hozott a rollup ökoszisztémában.

Fejlesztőként a legfontosabb szempontok:

• Az EVM nem látja a blob tartalmát, csak a verziózott hash-eket – tervezz ennek megfelelően
• A blob gas piac független a normál gas piactól – külön kell monitorozni
• A blob-ok 18 nap után törlődnek – tartós adattárolásra nem alkalmasak önmagukban
• A rollupok drasztikusan olcsóbbak lettek, ami a végfelhasználói élményt közvetlenül javítja

A blob gas target és az excess_blob_gas alakulása hosszú távon meghatározza, hogy a rollup ökoszisztéma valóban tömegek számára elérhető marad-e, vagy újra megdrágul. Ezt érdemes szemmel tartani – nemcsak fejlesztőként, hanem befektetőként is. Az Ethereum skálázhatóság még korántsem befejezett projekt, és a kockázatokat – technikai és piaci oldalon egyaránt – nem szabad figyelmen kívül hagyni.