---
title: "Commissioni dei blob e costi dei rollup"
description: "Guida basata sulla verifica del gas dei blob di Ethereum, dei parametri correnti, dell'utilizzo dei batch, dell'attribuzione delle commissioni dei rollup e della differenza tra costo di pubblicazione su L1 e addebito a un utente 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.
# Commissioni dei blob e costi dei rollup
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Una commissione di blob di Ethereum è l'addebito del protocollo per pubblicare dati nei blob, non l'intera commissione pagata da un utente L2. Una transazione che trasporta blob paga `blob_count * 131,072 * blob_base_fee_per_blob_gas` per il gas dei blob e, separatamente, il normale gas di esecuzione. Il rollup può poi attribuire quel costo L1 mediante proprie regole di compressione, scalari, costi generali e prezzi dell'operatore; pertanto, la ricevuta del batch submitter, la stima dei costi del rollup, il preventivo dell'utente e i ricavi dell'operatore sono registri distinti.
I blob sono sidecar di dati temporanei vincolati da hash KZG con versione. L'EVM può usare i commitment, ma non leggere direttamente i byte del blob. PeerDAS cambia il modo in cui i nodi Ethereum distribuiscono e campionano tali dati; non trasforma i blob in archivi permanenti né rende universale la formula delle commissioni utente di un rollup. Anche la capacità dipende dal fork. Al `2026-08-13`, la mainnet Ethereum dopo Fusaka BPO2 ha un obiettivo di `14 blobs` e consente al massimo `21 blobs` per blocco, sostituendo i precedenti parametri `3/6` e `6/9`.
## Come funziona
1. Fissa il contesto di misurazione: rete Ethereum, blocco o slot, fork e pianificazione Blob-Parameter-Only attivi, deployment del rollup e versione della formula, origine L1, token della commissione utente e istante del cambio. Non applicare mai i parametri attuali della mainnet a un vecchio blocco, una testnet o un fork futuro.
2. Identifica l'oggetto pubblicato mediante evidenze on-chain. Registra transazione di tipo 3, mittente, ricevuta, hash con versione, numero di blob, `blob_gas_used`, byte codificati e utilizzabili, compressione o framing, e se il rollup ha usato blob, calldata o un'altra via di disponibilità dei dati.
3. Leggi entrambi i mercati delle commissioni. Il gas dei blob usa `131,072 blob gas per blob`; distingui il `blob_base_fee_per_blob_gas` realizzato dal tetto `max_fee_per_blob_gas` del mittente. Registra separatamente gas di esecuzione consumato, prezzo effettivo e priority fee. Dopo EIP-7918, a bassi prezzi dei blob esiste una relazione di prezzo minimo con il costo di esecuzione, pur restando separate le contabilità delle due risorse.
4. Ricostruisci il registro L1 effettivo del batch submitter: commissione del blob bruciata, commissione di esecuzione e mancia, più le transazioni correlate di state output, prova, bridge o pubblicazione. La commissione del blob viene addebitata anche se l'esecuzione fallisce; un tetto non addebitato non è né costo né rimborso.
5. Riproduci la formula vigente dello specifico rollup. Registra byte compressi o altra unità misurata, scalari, costi fissi, commissioni dell'operatore o di priorità, rimborsi e regole di fallback. La documentazione OP Stack comprova soltanto un deployment OP; un altro rollup può attribuire i costi diversamente.
6. Separa quattro registri: costo L1 del batcher, costo L1 dei dati attribuito dal rollup, addebito effettivo all'utente e ricavo o margine dell'operatore. La divisione uniforme per numero di transazioni è solo un'attribuzione analitica. Riempimento, padding, mix, pubblicazione ritardata e sovvenzioni incrociate possono divergere dal preventivo del protocollo.
7. Riconcilia con le ricevute e sottoponi il risultato a stress test. Verifica picchi del prezzo dei blob, congestione dell'esecuzione, cambio di ETH e fee token, scarso utilizzo, ritardo del sequencer, fallback su calldata, aggiornamenti della formula, riorganizzazione L1, conservazione temporanea e guasto dell'archivio. Indica sempre blocco, unità, ipotesi e costi non riconciliati.
## Esempi svolti
- **Addebito protocollare per i blob.** Due blob consumano `2 * 131,072 = 262,144 blob gas`. A `30 gwei per blob gas`, la commissione è `262,144 * 30 * 10^-9 = 0.00786432 ETH`. Con `$2,500 per ETH`, equivale a `$19.6608`. La normale commissione di esecuzione è esclusa.
- **Due registri per una transazione.** Se la stessa transazione di tipo 3 usa `120,000 execution gas` a un prezzo effettivo di `22 gwei`, l'esecuzione costa `120,000 * 22 * 10^-9 = 0.00264 ETH`. L'addebito L1 totale è `0.00786432 + 0.00264 = 0.01050432 ETH`, ossia `$26.2608` al cambio indicato. Gas dei blob e gas di esecuzione restano input distinti.
- **Utilizzo e attribuzione del batch.** Aggiungendo `$4.0000` di costi riconciliati di prova e pubblicazione, il costo analitico del batch diventa `$30.2608`. Su `2,000 included transactions`, l'attribuzione uniforme è `$30.2608 / 2,000 = $0.0151304 per transaction`; su sole `800`, è `$30.2608 / 800 = $0.0378260`. Nessun importo coincide automaticamente con il preventivo utente o il margine realizzato dall'operatore.
- **Capacità attuale e unità in byte.** Con i parametri `14/21` validi alla data, obiettivo e massimo sono `14 * 131,072 = 1,835,008` e `21 * 131,072 = 2,752,512 blob-gas units`, equivalenti a `1.75 MiB` e `2.625 MiB` di blob codificati. Poiché una payload arbitraria usa in genere `31` byte di ogni elemento di campo da `32` byte, la payload utilizzabile è `14 * 126,976 = 1.6953125 MiB` all'obiettivo e `21 * 126,976 = 2.54296875 MiB` al massimo, prima di compressione e framing.
## Rischi
- Applicare un fork o una pianificazione Blob-Parameter-Only obsoleti.
- Mescolare parametri di mainnet, testnet o un'altra rete.
- Confondere gas dei blob, gas di esecuzione, byte codificati e byte utilizzabili.
- Trattare `max_fee_per_blob_gas` come la commissione base realizzata.
- Omettere la normale commissione di esecuzione e la mancia della transazione di tipo 3.
- Presumere che un'esecuzione fallita rimborsi la commissione del blob.
- Usare una stima RPC obsoleta invece di blocco e ricevuta inclusi.
- Attraversare una variazione di prezzo mentre il sequencer ritarda la pubblicazione.
- Sottostimare un picco di congestione o il comportamento del prezzo minimo.
- Ignorare la congestione dell'esecuzione L1 perché il gas dei blob è economico.
- Attribuire batch incompleti o con padding come se fossero pieni.
- Usare ipotesi errate su compressione, framing o mix di transazioni.
- Contabilizzare due volte transazioni di prova, state output, bridge o pubblicazione.
- Applicare una formula obsoleta per scalari, costi generali o commissioni dell'operatore.
- Confondere preventivo, addebito effettivo, rimborso e ricavi dell'operatore.
- Attivare un costoso fallback su calldata o un diverso modello di sicurezza DA.
- Convertire ETH e fee token con prezzo o istante errati.
- Perdere o attribuire male un batch dopo sostituzione o riorganizzazione L1.
- Trattare la disponibilità temporanea PeerDAS come recupero archivistico permanente.
- Ignorare guasti di sequencer, validità, finalità, bridge o uscita perché i blob erano disponibili.
## Errori comuni
- La commissione base del blob è l'intera commissione L2 pagata dall'utente.
- `max_fee_per_blob_gas` è l'importo effettivamente addebitato.
- Tutti i `131,072` byte codificati di un blob sono payload arbitraria dell'utente.
- Una commissione base del blob più bassa riduce subito e nella stessa percentuale la commissione di ogni utente L2.
- I dati dei blob sono archiviati permanentemente nell'EVM e ogni rollup usa una capacità fissa `3/6` o `6/9`.
## Argomenti correlati
- [Blobspace](/it/crypto/blobspace/)
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Rollup](/it/crypto/rollup/)
## Fonti
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7691: Blob throughput increase](https://eips.ethereum.org/EIPS/eip-7691) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7918: Blob base fee bounded by execution cost](https://eips.ethereum.org/EIPS/eip-7918) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (consultato: 2026-08-13)
- [Transaction fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees) - Optimism Documentation (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/blob-fee-rollup-cost/index.mdx