EIP-4844 Blob Transactions — Comment Ça Marche Vraiment

// Transaction rollup pré-EIP-4844
// publie ~100KB de compressed tx data
0x1234...abcd (calldata)
  → coût : 16 gas/byte non-zéro
  → ~100,000 bytes × 16 = 1.6M gas
  → à 50 gwei et 3000$/ETH ≈ 240$ par batch

Problème : calldata est cher. Même compressé, poster des transactions L2 sur L1 représentait 80-90% du coût opérationnel d'un rollup.

La Solution : Blob Transactions

EIP-4844 introduit un nouveau type de données : les blobs.

Un blob = 128KB de données temporaires attachées à une transaction.

Différences clés vs calldata :

| | Calldata | Blob |

|---|---|---|

| Taille max | Illimitée | 128KB (4096 field elements) |

| Coût | 16 gas/byte | ~1 gas/byte (marché séparé) |

| Accessibilité | Toujours disponible | Élagué après ~18 jours |

Format d'un Blob

Un blob = 4096 field elements de 32 bytes.

// Structure interne d'un blob
struct Blob {
    bytes32[4096] data;  // 4096 × 32 = 131,072 bytes
}

// Chaque field element < BLS_MODULUS
// (pas vraiment des bytes32 arbitraires)

Les blobs utilisent des commitments KZG (polynomial commitments) pour permettre la vérification sans télécharger l'intégralité du blob.

blob data → polynomial → KZG commitment → versioned hash

Type de Transaction 3

Les blobs arrivent via un nouveau type de transaction (type 3).

// Transaction type 3 (EIP-4844)
{
  type: 3,
  chainId: 1,
  nonce: 42,
  maxPriorityFeePerGas: 2000000000,
  maxFeePerGas: 50000000000,
  maxFeePerBlobGas: 10000000000,  // ← Nouveau champ
  gas: 21000,
  to: 0x...,
  value: 0,
  data: 0x,
  blobVersionedHashes: [  // ← Nouveau champ
    0x01abcd...
  ],
  // Les blobs ne sont PAS dans la transaction
  // (transmis séparément dans le P2P)
}

Points clés :

• maxFeePerBlobGas : prix max que vous acceptez de payer par gas de blob

• blobVersionedHashes : commitments KZG des blobs attachés (max 6 blobs par tx)

• Les blobs eux-mêmes sont transmis hors bande (pas inclus dans le block body)

Usage par les Rollups

Les rollups utilisent les blobs pour publier leurs batches de transactions.

// Contrat sequencer d'un rollup (simplifié)
contract RollupSequencer {
    event BatchSubmitted(uint256 indexed batchIndex, bytes32 blobHash);

    function submitBatch(
        bytes calldata compressedTxs,  // Avant : données ici
        uint256 batchIndex
    ) external onlySequencer {
        // Maintenant : données dans le blob
        bytes32 blobHash = blobhash(0);  // Premier blob
        require(blobHash != bytes32(0), "No blob");

        emit BatchSubmitted(batchIndex, blobHash);
        // Le blob contient compressedTxs (jusqu'à 128KB)
    }
}

Cycle de vie :

Économies de Coûts

Avant vs après EIP-4844 (batch de 100KB) :

Avant (calldata) :
  100,000 bytes × 16 gas/byte = 1,600,000 gas
  À 50 gwei et 3000$/ETH ≈ 240$

Après (blob) :
  1 blob (128KB) × ~0.01$ (marché blob actuel) ≈ 0.01$
  + ~21,000 gas pour la tx ≈ 3$
  Total ≈ 3$

Économie : ~98% 🚀

Le marché des blobs est séparé du marché du gas classique. Il utilise un mécanisme EIP-1559-like avec une cible de 3 blobs/block et un max de 6.

Accès Solidity aux Blobs

Vos smart contracts ne peuvent pas lire directement le contenu des blobs (trop gros pour l'EVM).

Mais vous pouvez accéder aux hashes :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract BlobReader {
    // Opcode BLOBHASH (0x49)
    function getBlobHash(uint256 index) public view returns (bytes32) {
        return blobhash(index);  // Index 0-5 (max 6 blobs)
    }

    // Opcode BLOBBASEFEE (0x4a)
    function getCurrentBlobBaseFee() public view returns (uint256) {
        return block.blobbasefee;  // Prix actuel du marché blob
    }

    // Vérifier qu'un blob est attaché
    function verifyBlobPresent() external view {
        bytes32 hash = blobhash(0);
        require(hash != bytes32(0), "No blob attached");
    }
}

Usage typique : vérifier le commitment, pas lire le contenu.

Cycle de Vie et Élagage

Les blobs sont temporaires :

Block N : blob publié
  ↓
Block N + ~18 jours : blob élagué des full nodes
  ↓
Seul le blobVersionedHash reste dans le block

Pourquoi 18 jours ?

• Assez long pour la dispute period des rollups optimistic (~7 jours)

• Assez court pour limiter la croissance de l'état

• Les archive nodes gardent les blobs indéfiniment (optionnel)

Si vous avez besoin d'un blob après élagage : utilisez un blob archiver (Etherscan, Blobscan, etc.).

Marché des Blobs

Le prix des blobs suit un mécanisme EIP-1559-like :

// Calcul du blob base fee
blobBaseFee = prevBlobBaseFee × exp((blobsInPrevBlock - TARGET) / ADJUST)

TARGET = 3 blobs/block
MAX = 6 blobs/block

Actuellement (avril 2026) :

• Utilisation moyenne : ~2-3 blobs/block

• Blob base fee : ~0.001-0.01 gwei (quasi gratuit)

• Pics : pendant les pics de congestion L2, monte à ~1-10 gwei

Rollups majeurs (Arbitrum, Optimism, Base, zkSync) postent ~1-2 blobs toutes les 1-5 minutes selon le trafic.

Limites et Trade-offs

Avantages :

• ~100× moins cher que calldata

• Marché séparé → pas d'impact sur le gas L1 classique

• Scalabilité L2 immédiate

Inconvénients :

• Données temporaires (élagué après 18 jours)

• Pas accessible depuis l'EVM (seulement le hash)

• Limité à 6 blobs/block (congestion possible)

Pour les rollups, le trade-off est clair : économiser 98% sur les coûts justifie largement l'élagage.

Conclusion

EIP-4844 a changé la donne pour les L2. Les blobs ont rendu les rollups économiquement viables en réduisant drastiquement leur coût opérationnel.

Points clés :

• Blobs = 128KB de données temporaires (~18 jours)