Ir para o conteúdo
Financial Context Wiki

Taxas de blob e custos de rollups

Guia orientado por verificação sobre o gas de blob da Ethereum, os cronogramas vigentes, a utilização de lotes, a alocação de taxas de rollups e a diferença entre o custo de publicação na L1 e a cobrança de um usuário da L2.

Atualizado

Somente para fins educacionais; não constitui aconselhamento financeiro nem de segurança. Parâmetros de blobs, fórmulas de taxas dos rollups, políticas do sequenciador, taxas de câmbio e premissas de disponibilidade de dados podem mudar ou falhar.

Resposta direta

Uma taxa de blob da Ethereum é a cobrança do protocolo pela publicação de dados em blobs, não a taxa total paga por um usuário da L2. Uma transação que carrega blobs paga blob_count * 131,072 * blob_base_fee_per_blob_gas pelo gas de blob e, separadamente, pelo gas de execução comum. O rollup pode então alocar esse custo de L1 segundo suas próprias regras de compressão, escalares, custos indiretos e precificação do operador; por isso, o recibo do publicador do lote, a estimativa de custo do rollup, a cotação do usuário e a receita do operador são registros distintos.

Blobs são dados temporários anexos comprometidos por hashes KZG versionados. A EVM pode usar os compromissos, mas não ler diretamente os bytes do blob. O PeerDAS altera como os nós da Ethereum distribuem e amostram esses dados; não transforma blobs em arquivos permanentes nem torna universal a fórmula de cobrança de um rollup. A capacidade também depende do fork. Em 2026-08-13, a mainnet da Ethereum após o Fusaka BPO2 tem meta de 14 blobs e permite no máximo 21 blobs por bloco, substituindo os cronogramas anteriores 3/6 e 6/9.

Como funciona

  1. Fixe o contexto da medição: rede Ethereum, bloco ou slot, fork e cronograma Blob-Parameter-Only ativos, implantação do rollup e versão da fórmula, origem L1, token de taxa do usuário e instante da taxa de câmbio. Nunca aplique parâmetros atuais da mainnet a um bloco antigo, testnet ou fork futuro.
  2. Identifique o objeto de publicação com evidência on-chain. Registre a transação tipo 3, remetente, recibo, hashes versionados, quantidade de blobs, blob_gas_used, bytes codificados e úteis, compressão ou framing, e se o rollup usou blobs, calldata ou outra via de disponibilidade de dados.
  3. Leia os dois mercados de taxas. O gas de blob usa 131,072 blob gas per blob; diferencie o blob_base_fee_per_blob_gas realizado do teto max_fee_per_blob_gas do remetente. Registre à parte o gas de execução usado, seu preço efetivo e a gorjeta. Após a EIP-7918, preços baixos de blob mantêm relação de preço de reserva com o custo de execução, embora os recursos conservem contabilidade separada.
  4. Reconstrua o livro L1 efetivo do publicador: taxa de blob queimada, taxa de execução e gorjeta, além das transações correspondentes de saída de estado, prova, ponte ou publicação. A taxa de blob é cobrada mesmo se a execução falhar, e um teto não cobrado não é custo nem reembolso.
  5. Reproduza a fórmula vigente do rollup específico. Registre bytes comprimidos ou outra unidade medida, escalares, custo fixo, cobranças do operador ou de prioridade, reembolsos e regras de fallback. A documentação do OP Stack só comprova um deployment OP; outro rollup pode alocar custos de forma diferente.
  6. Mantenha quatro livros separados: custo L1 do publicador, custo L1 de dados atribuído pelo rollup, débito efetivo do usuário e receita ou margem do operador. A divisão igual pelo número de transações é apenas uma alocação analítica. Preenchimento do lote, padding, composição, atraso de publicação e subsídio cruzado podem divergir da cotação do protocolo.
  7. Concilie com recibos e submeta o resultado a estresse. Teste picos no preço de blobs, congestionamento de execução, câmbio de ETH e do token de taxa, baixa utilização, atraso do sequenciador, fallback para calldata, atualizações da fórmula, reorganização da L1, retenção temporária e falha de arquivo. Informe sempre bloco, unidades, premissas e custos não conciliados.

Exemplos resolvidos

  • Cobrança protocolar por blobs. Dois blobs consomem 2 * 131,072 = 262,144 blob gas. A 30 gwei per blob gas, a taxa é 262,144 * 30 * 10^-9 = 0.00786432 ETH. Com $2,500 per ETH, equivale a $19.6608. A taxa comum de execução fica de fora.
  • Dois livros para uma transação. Se a mesma transação tipo 3 usar 120,000 execution gas a um preço efetivo de 22 gwei, a execução custa 120,000 * 22 * 10^-9 = 0.00264 ETH. A cobrança L1 total é 0.00786432 + 0.00264 = 0.01050432 ETH, ou $26.2608 no câmbio informado. Gas de blob e gas de execução continuam sendo entradas distintas.
  • Utilização e alocação do lote. Some $4.0000 de custos conciliados de prova e publicação, levando o custo analítico do lote a $30.2608. Entre 2,000 included transactions, a alocação igual é $30.2608 / 2,000 = $0.0151304 per transaction; entre apenas 800, é $30.2608 / 800 = $0.0378260. Nenhum valor é automaticamente a cotação do usuário ou a margem realizada do operador.
  • Capacidade atual e unidades de bytes. No cronograma 14/21 específico da data, meta e máximo são 14 * 131,072 = 1,835,008 e 21 * 131,072 = 2,752,512 blob-gas units, correspondentes a 1.75 MiB e 2.625 MiB de blobs codificados. Como uma carga arbitrária geralmente usa 31 bytes de cada elemento de campo de 32 bytes, a carga útil é 14 * 126,976 = 1.6953125 MiB na meta e 21 * 126,976 = 2.54296875 MiB no máximo, antes de compressão e framing.

Riscos

  • Aplicar um fork ou cronograma Blob-Parameter-Only obsoleto.
  • Misturar parâmetros da mainnet, testnet ou de outra rede.
  • Confundir gas de blob, gas de execução, bytes codificados e bytes úteis.
  • Tratar max_fee_per_blob_gas como a taxa-base realizada.
  • Omitir a taxa comum de execução e a gorjeta da transação tipo 3.
  • Supor que falha de execução restitui a taxa de blob cobrada.
  • Usar estimativa RPC desatualizada em vez do bloco e recibo incluídos.
  • Atravessar mudança de taxa enquanto o sequenciador atrasa a publicação.
  • Subestimar pico de congestionamento ou comportamento do preço de reserva.
  • Ignorar congestionamento de execução da L1 porque o gas de blob está barato.
  • Alocar lotes incompletos ou com padding como se estivessem cheios.
  • Usar premissas erradas de compressão, framing ou composição do lote.
  • Contar duas vezes transações de prova, saída de estado, ponte ou publicação.
  • Aplicar fórmula obsoleta de escalar, overhead ou taxa do operador.
  • Confundir cotação, débito efetivo, reembolso e receita do operador.
  • Acionar fallback caro para calldata ou outro modelo de segurança de DA.
  • Converter ETH e tokens de taxa pelo preço ou instante incorretos.
  • Perder ou atribuir mal um lote após substituição ou reorganização da L1.
  • Tratar disponibilidade temporária do PeerDAS como recuperação arquivística permanente.
  • Ignorar falhas de sequenciador, validade, finalidade, ponte ou saída porque os blobs estavam disponíveis.

Erros comuns

  • A taxa-base de blob é toda a taxa L2 paga pelo usuário.
  • max_fee_per_blob_gas é o valor efetivamente cobrado.
  • Todos os 131,072 bytes codificados de um blob são carga útil arbitrária do usuário.
  • Uma taxa-base de blob menor reduz imediatamente e no mesmo percentual a taxa de todo usuário da L2.
  • Dados de blob ficam armazenados permanentemente na EVM e todo rollup usa capacidade fixa 3/6 ou 6/9.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...