--- title: "Espace de blobs" description: "Guide fondé sur la vérification de l'espace de blobs Ethereum, de sa capacité encodée et utile, de l'échantillonnage et de la conservation PeerDAS, de la rétention temporaire, de la dérivation des rollups et des limites actuelles selon le fork." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Espace de blobs > À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes. ## Réponse directe L'espace de blobs est la capacité limitée et temporaire d'Ethereum consacrée à la disponibilité des données de blobs engagés avec les blocs. Ce n'est ni le blockspace d'exécution EVM, ni le stockage d'un contrat, ni un système de fichiers permanent, ni un token. Une transaction de type 3 contient des hachages versionnés ; les données authentifiées du blob circulent dans des sidecars de la couche de consensus ou des colonnes de données PeerDAS. L'EVM peut consulter un hachage versionné et vérifier une ouverture ponctuelle, mais pas lire directement la charge du blob. PeerDAS étend les blobs par codage d'effacement, divise la matrice étendue en `128 columns` et permet aux nœuds de conserver et d'échantillonner des sous-ensembles, sans imposer à chaque nœud de télécharger chaque blob complet. Cela permet un jugement probabiliste local de disponibilité, et non une preuve de validité de l'exécution du rollup, de finalité Ethereum, de sécurité du bridge ou de récupération permanente. La capacité varie selon le fork. Au `2026-08-13`, le mainnet Ethereum après Fusaka BPO2 cible `14 blobs per block` et en autorise au maximum `21` ; chaque transaction de blobs est limitée à `6 blobs`. ## Fonctionnement 1. Fixez le réseau, le bloc ou slot, le fork et le calendrier Blob-Parameter-Only actifs, ainsi que le rollup et sa version de dérivation. Les paramètres historiques `3/6`, ceux de Pectra `6/9`, les paramètres actuels `14/21`, ceux des testnets et les futurs ne sont pas interchangeables. 2. Identifiez l'objet publié : transaction de type 3, hachages versionnés, engagements et preuves KZG, indices de blobs, origine L1, et vérifiez si le rollup a réellement utilisé les blobs Ethereum plutôt que calldata ou une DA alternative. Un engagement lie les données, mais ne prouve pas à lui seul que les octets étaient disponibles. 3. Séparez les unités. Un blob contient `4,096 field elements * 32 bytes = 131,072 encoded bytes` ; une charge sans restrictions emploie généralement `31 bytes` par élément de champ, soit `126,976 usable bytes`. Compression, framing, padding, gas de blob, cellules étendues par codage d'effacement et octets applicatifs sont des quantités distinctes. 4. Vérifiez les limites du calendrier. La cible guide la rétroaction tarifaire ; ce n'est pas une capacité réservée. Le maximum par bloc est un plafond de consensus, pas le débit attendu. La limite PeerDAS de `6 blobs per transaction` diffère du maximum actuel de `21 blobs per block`. 5. Vérifiez la voie de disponibilité. PeerDAS emploie une extension d'effacement unidimensionnelle, des cellules et colonnes authentifiées, le gossip et des requêtes aux pairs. Avec les paramètres actuels, un nœud échantillonne au moins `8 columns` et a des obligations de conservation ; obtenir au moins `64 of 128 columns` permet de reconstruire la matrice étendue. 6. Suivez séparément les états du cycle de vie : engagement inclus, colonnes obtenues et vérifiées, contrôle DA local réussi, bloc L1 safe ou finalized, lot du rollup décodé et dérivé, fenêtre minimale de service active et archive indépendante testée. La disponibilité n'implique aucun état ultérieur. 7. Simulez colonnes manquantes, eclipse ou partition, propagation tardive, réorganisation L1, divergence de calendrier ou de client, mise à niveau du format rollup et perte d'archive. Récupérez, reconstruisez et conservez les données requises avant l'expiration de la fenêtre ; utilisez le sujet distinct sur les frais de blob pour la comptabilité du batcher et des utilisateurs. ## Exemples détaillés - **Unités en octets d'un blob.** La capacité encodée est `4,096 * 32 = 131,072 bytes = 128 KiB`. La charge arbitraire générale est `4,096 * 31 = 126,976 bytes = 124 KiB`. La différence vaut `4,096 bytes`, soit `3.125%` de la capacité encodée ; compression et framing du rollup réduisent davantage la charge applicative. - **Capacité actuelle par bloc.** À la cible, `14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB` et `14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB`. Au maximum, `21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB` et `21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB`. Ce sont des limites mainnet datées, par bloc, avant compression et framing. - **Limites de transaction et de bloc.** Une transaction avec `6 blobs` transporte `786,432 encoded bytes = 0.75 MiB` et `761,856 usable bytes = 0.7265625 MiB`. Un bloc maximal de `21-blob` nécessite au moins `4 transactions`, par exemple `6 + 6 + 6 + 3` ; un bloc cible de `14-blob` peut contenir `6 + 6 + 2`. Aucune répartition ne réserve une capacité à un rollup. - **Fenêtre de service et volume nominal.** `4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days`. Avec `7,200 slots per day` nominaux et une cible de `14-blob`, le volume encodé est `100,800 blobs per day = 12.3046875 GiB per day`, contre `11.920166015625 GiB per day` généralement utilisables. Les slots manqués et l'inclusion réelle modifient le total ; la fenêtre ne promet pas une archive permanente. ## Risques - Appliquer un fork ou un calendrier Blob-Parameter-Only obsolète. - Mélanger les limites du mainnet, d'un testnet ou d'un autre réseau. - Traiter la cible comme une capacité garantie ou réservée. - Traiter le maximum comme le débit normal attendu. - Confondre la limite de six blobs par transaction avec celle du bloc. - Mélanger unités encodées, utiles, compressées, encadrées et de gas de blob. - Omettre le padding ou les surcoûts du format rollup. - Qualifier calldata ou une DA alternative d'espace de blobs Ethereum. - Accepter un hachage versionné qui ne correspond pas à l'engagement du blob. - Traiter une ouverture KZG valide comme preuve que les octets étaient disponibles. - Assimiler l'échantillonnage au téléchargement local complet de chaque blob. - Confondre disponibilité des données et validité de la transition d'état. - Confondre contrôle DA local et finalité L1 ou du rollup. - Perdre des colonnes par retard, eclipse, partition ou pairs corrélés. - Échouer à reconstruire ou interroger les pairs malgré la capacité nominale. - Perdre ou réordonner l'engagement lors d'une réorganisation L1. - Laisser expirer la fenêtre minimale avant dérivation ou contestation. - Dépendre d'une archive ou d'un indexeur indisponible, corrompu ou incomplet. - Échouer à dériver après une mise à niveau de compression ou de protocole. - Présumer bridge ou sortie sûrs au seul motif que les blobs étaient disponibles. ## Idées reçues - L'espace de blobs est un stockage permanent que les contrats lisent comme calldata. - Chaque octet d'un blob de `128 KiB` est une charge applicative sans restrictions. - Avec PeerDAS, chaque nœud Ethereum télécharge et conserve définitivement chaque blob complet. - Un engagement KZG, un échantillon réussi ou une inclusion finalisée prouve que l'état du rollup est correct et que les utilisateurs peuvent sortir. - La capacité mainnet est définitivement fixée à `3/6`, `6/9` ou au calendrier actuel `14/21`. ## Sujets connexes - [Frais de blob et coûts des rollups](/fr/crypto/blob-fee-rollup-cost/) - [Échantillonnage de disponibilité des données](/fr/crypto/data-availability-sampling/) - [Rollup](/fr/crypto/rollup/) ## Sources - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté : 2026-08-13) - [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consulté : 2026-08-13) - [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (consulté : 2026-08-13) - [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (consulté : 2026-08-13) - [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (consulté : 2026-08-13) - [Fulu -- Data Availability Sampling Core](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/das-core.md) - Ethereum Consensus Specifications (consulté : 2026-08-13) - [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consulté : 2026-08-13) - [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (consulté : 2026-08-13) Source: https://wiki.fcontext.com/fr/crypto/blobspace/index.mdx