Aller au contenu
Financial Context Wiki

Frais de blob et coûts des rollups

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.

Mis à jour

À 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

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.

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.

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.

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.

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.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...