﻿---
title: "Frais de blob et coûts des rollups"
description: "Guide fondé sur la vérification du gas de blob d'Ethereum, des paramètres en vigueur, du remplissage des lots, de l'attribution des frais des rollups et de la différence entre coût de publication sur L1 et facture d'un utilisateur L2."
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.

# Frais de blob et coûts des rollups

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Réponse directe

Les frais de blob Ethereum sont les frais de protocole facturés pour publier des données dans des blobs, et non la totalité des frais payés par un utilisateur L2. Une transaction transportant des blobs paie `blob_count * 131,072 * blob_base_fee_per_blob_gas` pour le gas de blob et paie séparément le gas d'exécution ordinaire. Un rollup peut ensuite attribuer ce coût L1 selon ses propres règles de compression, coefficients, frais fixes et tarification de l'opérateur. Le reçu du batcher, l'estimation du rollup, le devis utilisateur et les recettes de l'opérateur constituent donc des registres distincts.

Les blobs sont des sidecars de données temporaires engagés par des hachages KZG versionnés. L'EVM peut exploiter les engagements, mais ne peut pas lire directement les octets du blob. PeerDAS modifie la distribution et l'échantillonnage de ces données par les nœuds Ethereum ; il ne transforme pas les blobs en archives permanentes et ne rend pas universelle la formule de frais utilisateur d'un rollup. La capacité dépend aussi du fork. Au `2026-08-13`, le mainnet Ethereum après Fusaka BPO2 cible `14 blobs` et autorise au maximum `21 blobs` par bloc, en remplacement des anciens paramètres `3/6` et `6/9`.

<a id="mechanism"></a>

## Fonctionnement

1. Fixez le contexte de mesure : réseau Ethereum, bloc ou slot, fork et calendrier Blob-Parameter-Only actifs, déploiement du rollup et version de sa formule, origine L1, token de frais utilisateur et instant du taux de change. N'appliquez jamais les paramètres actuels du mainnet à un ancien bloc, un testnet ou un fork futur.
2. Identifiez l'objet publié à partir des preuves on-chain. Relevez la transaction de type 3, l'émetteur, le reçu, les hachages versionnés, le nombre de blobs, `blob_gas_used`, les octets encodés et utilisables, la compression ou le framing, ainsi que la voie de DA employée : blobs, calldata ou autre.
3. Lisez les deux marchés de frais. Le gas de blob utilise `131,072 blob gas per blob` ; distinguez le `blob_base_fee_per_blob_gas` réalisé du plafond `max_fee_per_blob_gas` de l'émetteur. Relevez séparément le gas d'exécution consommé, son prix effectif et le pourboire. Après EIP-7918, les faibles prix de blob entretiennent une relation de prix plancher avec le coût d'exécution, sans fusionner les deux comptabilités.
4. Reconstituez le registre L1 effectif du batcher : frais de blob brûlés, frais d'exécution et pourboire, plus les transactions associées de sortie d'état, preuve, bridge ou publication. Les frais de blob sont prélevés même si l'exécution échoue ; un plafond non facturé n'est ni un coût ni un remboursement.
5. Reproduisez la formule en vigueur du rollup concerné. Relevez les octets compressés ou toute autre unité mesurée, les coefficients, frais fixes, frais opérateur ou prioritaires, remboursements et règles de fallback. La documentation OP Stack ne prouve que le fonctionnement d'un déploiement OP ; un autre rollup peut attribuer les coûts autrement.
6. Séparez quatre registres : coût L1 du batcher, coût L1 des données attribué par le rollup, débit utilisateur effectif et recettes ou marge de l'opérateur. Une division uniforme par nombre de transactions n'est qu'une attribution analytique. Remplissage, padding, composition du lot, publication différée et subventions croisées peuvent l'écarter du devis protocolaire.
7. Rapprochez le résultat des reçus et soumettez-le à des scénarios de stress. Testez flambée du prix des blobs, congestion de l'exécution, change ETH et fee token, faible remplissage, retard du séquenceur, fallback vers calldata, mise à niveau de la formule, réorganisation L1, rétention temporaire et défaillance d'archive. Indiquez toujours bloc, unités, hypothèses et coûts non rapprochés.

<a id="example"></a>

## Exemples détaillés

- **Frais protocolaires de blob.** Deux blobs consomment `2 * 131,072 = 262,144 blob gas`. À `30 gwei per blob gas`, les frais sont de `262,144 * 30 * 10^-9 = 0.00786432 ETH`. À `$2,500 per ETH`, cela représente `$19.6608`. Les frais ordinaires d'exécution ne sont pas inclus.
- **Deux registres de frais pour une transaction.** Si la même transaction de type 3 consomme `120,000 execution gas` à un prix effectif de `22 gwei`, l'exécution coûte `120,000 * 22 * 10^-9 = 0.00264 ETH`. La charge L1 totale est `0.00786432 + 0.00264 = 0.01050432 ETH`, soit `$26.2608` au taux indiqué. Gas de blob et gas d'exécution restent deux entrées distinctes.
- **Remplissage et attribution du lot.** Ajoutez `$4.0000` de coûts rapprochés de preuve et de publication : le coût analytique du lot devient `$30.2608`. Sur `2,000 included transactions`, l'attribution uniforme est `$30.2608 / 2,000 = $0.0151304 per transaction` ; sur seulement `800`, elle atteint `$30.2608 / 800 = $0.0378260`. Aucun montant ne correspond automatiquement au devis utilisateur ni à la marge réalisée de l'opérateur.
- **Capacité actuelle et unités en octets.** Avec les paramètres datés `14/21`, la cible et le maximum valent `14 * 131,072 = 1,835,008` et `21 * 131,072 = 2,752,512 blob-gas units`, soit `1.75 MiB` et `2.625 MiB` de blobs encodés. Une charge arbitraire utilisant généralement `31` octets par élément de champ de `32` octets, la charge utile est de `14 * 126,976 = 1.6953125 MiB` à la cible et de `21 * 126,976 = 2.54296875 MiB` au maximum, avant compression et framing.

<a id="risks"></a>

## Risques

- Appliquer un fork ou un calendrier Blob-Parameter-Only obsolète.
- Mélanger les paramètres du mainnet, d'un testnet ou d'une autre chaîne.
- Confondre gas de blob, gas d'exécution, octets encodés et octets utilisables.
- Traiter `max_fee_per_blob_gas` comme les frais de base réalisés.
- Omettre les frais ordinaires d'exécution et le pourboire de la transaction de type 3.
- Supposer qu'un échec d'exécution rembourse les frais de blob prélevés.
- Employer une estimation RPC périmée plutôt que le bloc et le reçu inclus.
- Traverser un changement de prix pendant que le séquenceur retarde la publication.
- Sous-estimer un pic de congestion ou le comportement du prix plancher.
- Ignorer la congestion d'exécution L1 parce que le gas de blob est bon marché.
- Attribuer des lots sous-remplis ou paddés comme s'ils étaient pleins.
- Retenir de mauvaises hypothèses de compression, framing ou composition du lot.
- Comptabiliser deux fois les transactions de preuve, sortie d'état, bridge ou publication.
- Appliquer une ancienne formule de coefficient, frais fixes ou frais opérateur.
- Confondre devis, débit effectif, remboursement et recettes de l'opérateur.
- Déclencher un fallback coûteux vers calldata ou un autre modèle de sécurité DA.
- Convertir ETH et fee tokens au mauvais prix ou au mauvais instant.
- Perdre ou mal attribuer un lot après remplacement ou réorganisation L1.
- Assimiler la disponibilité temporaire de PeerDAS à une récupération d'archive permanente.
- Ignorer un échec de séquenceur, validité, finalité, bridge ou sortie parce que les blobs étaient disponibles.

<a id="misconceptions"></a>

## Idées reçues

- Les frais de base de blob constituent tous les frais L2 payés par l'utilisateur.
- `max_fee_per_blob_gas` est le montant effectivement facturé.
- Les `131,072` octets encodés d'un blob sont tous une charge utile arbitraire de l'utilisateur.
- Une baisse des frais de base de blob réduit immédiatement et dans la même proportion les frais de chaque utilisateur L2.
- Les données des blobs sont stockées définitivement dans l'EVM et chaque rollup utilise une capacité fixe `3/6` ou `6/9`.

<a id="related"></a>

## Sujets connexes

- [Espace de blobs](/fr/crypto/blobspace/)
- [Disponibilité des données](/fr/crypto/data-availability/)
- [Rollup](/fr/crypto/rollup/)

<a id="sources"></a>

## Sources

- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté : 2026-08-13)
- [EIP-7691: Blob throughput increase](https://eips.ethereum.org/EIPS/eip-7691) - 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)
- [EIP-7918: Blob base fee bounded by execution cost](https://eips.ethereum.org/EIPS/eip-7918) - 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)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (consulté : 2026-08-13)
- [Transaction fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees) - Optimism Documentation (consulté : 2026-08-13)

Source: https://wiki.fcontext.com/fr/crypto/blob-fee-rollup-cost/index.mdx
