Vai al contenuto
Financial Context Wiki

Commissioni dei blob e costi dei rollup

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...