Ir para o conteúdo
Financial Context Wiki

Espaço de blobs

Guia orientado por verificação sobre o espaço de blobs da Ethereum, capacidade codificada e útil, amostragem e custódia no PeerDAS, retenção temporária, derivação de rollups e limites vigentes conforme o fork.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

O espaço de blobs é a capacidade limitada e temporária da Ethereum para disponibilidade de dados em blobs comprometidos junto aos blocos. Não é espaço de execução da EVM, armazenamento de contratos, sistema de arquivos permanente nem token. Uma transação tipo 3 contém hashes versionados; os dados autenticados do blob trafegam em sidecars da camada de consenso ou em colunas de dados do PeerDAS. A EVM pode consultar um hash versionado e verificar um ponto aberto, mas não ler diretamente a carga do blob.

O PeerDAS amplia os blobs por codificação de apagamento, divide a matriz estendida em 128 columns e permite que os nós custodiem e amostrem subconjuntos, sem exigir que cada nó baixe cada blob completo. Isso fundamenta uma avaliação probabilística local de disponibilidade, não uma prova de validade da execução do rollup, finalidade da Ethereum, segurança da ponte ou recuperação permanente. A capacidade muda por fork. Em 2026-08-13, a mainnet da Ethereum após o Fusaka BPO2 tem meta de 14 blobs per block e permite no máximo 21; cada transação de blobs está limitada a 6 blobs.

Como funciona

  1. Fixe rede, bloco ou slot, fork e cronograma Blob-Parameter-Only ativos, além do rollup e da versão de derivação. Os parâmetros históricos 3/6, os do Pectra 6/9, os atuais 14/21, os de testnet e os futuros não são intercambiáveis.
  2. Identifique o objeto publicado: transação tipo 3, hashes versionados, compromissos e provas KZG, índices de blobs, origem L1 e se o rollup realmente usou blobs da Ethereum em vez de calldata ou DA alternativa. Um compromisso vincula dados, mas sozinho não prova que os bytes estavam disponíveis.
  3. Separe as unidades. Um blob tem 4,096 field elements * 32 bytes = 131,072 encoded bytes; a carga sem restrições geralmente usa 31 bytes por elemento de campo, ou 126,976 usable bytes. Compressão, framing, padding, gas de blob, células ampliadas por codificação de apagamento e bytes de aplicação são quantidades distintas.
  4. Verifique os limites do cronograma. A meta orienta a resposta de preços; não é capacidade reservada. O máximo do bloco é um teto de consenso, não o throughput esperado. O limite PeerDAS de 6 blobs per transaction difere do máximo atual de 21 blobs per block.
  5. Verifique o caminho de disponibilidade. O PeerDAS usa extensão de apagamento unidimensional, células e colunas autenticadas, gossip e solicitações a pares. Nos parâmetros atuais, um nó amostra ao menos 8 columns e tem deveres de custódia; obter ao menos 64 of 128 columns permite reconstruir a matriz estendida.
  6. Acompanhe estados separados do ciclo de vida: compromisso incluído, colunas obtidas e verificadas, verificação DA local aprovada, bloco L1 seguro ou finalizado, lote do rollup decodificado e derivado, janela mínima de serviço ativa e arquivo independente testado. Disponibilidade não torna verdadeiros todos os estados seguintes.
  7. Ensaie colunas ausentes, eclipse ou partição, propagação atrasada, reorganização L1, divergência de cronograma ou cliente, atualização do formato do rollup e perda de arquivo. Recupere, reconstrua e preserve os dados necessários antes de a janela expirar; use o tópico separado de taxas de blobs para contabilizar custos do batcher e do usuário.

Exemplos resolvidos

  • Unidades de bytes de um blob. A capacidade codificada é 4,096 * 32 = 131,072 bytes = 128 KiB. A carga arbitrária geral é 4,096 * 31 = 126,976 bytes = 124 KiB. A diferença é 4,096 bytes, ou 3.125% da capacidade codificada; compressão e framing do rollup reduzem ainda mais a carga da aplicação.
  • Capacidade atual por bloco. Na meta, 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB e 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. No máximo, 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB e 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. São limites de mainnet específicos da data, antes de compressão e framing.
  • Limites de transação e bloco. Uma transação com 6 blobs carrega 786,432 encoded bytes = 0.75 MiB e 761,856 usable bytes = 0.7265625 MiB. Um bloco máximo de 21-blob requer ao menos 4 transactions, por exemplo 6 + 6 + 6 + 3; um bloco-meta de 14-blob pode ser 6 + 6 + 2. Nenhuma alocação reserva capacidade para um rollup.
  • Janela de serviço e volume nominal. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. Com 7,200 slots per day nominais e meta de 14-blob, o volume codificado é 100,800 blobs per day = 12.3046875 GiB per day, enquanto o volume geralmente utilizável é 11.920166015625 GiB per day. Slots perdidos e inclusão efetiva mudam o total, e a janela de serviço não promete arquivo permanente.

Riscos

  • Aplicar fork ou cronograma Blob-Parameter-Only obsoleto.
  • Misturar limites da mainnet, testnet ou de outra rede.
  • Tratar a meta como capacidade garantida ou reservada.
  • Tratar o máximo como throughput normal esperado.
  • Confundir o limite de seis blobs por transação com o limite do bloco.
  • Misturar unidades codificadas, úteis, comprimidas, enquadradas e de gas de blob.
  • Omitir padding ou overhead do formato do rollup.
  • Rotular calldata ou DA alternativa como espaço de blobs da Ethereum.
  • Aceitar hash versionado que não corresponda ao compromisso do blob.
  • Tratar uma abertura KZG válida como prova de que os bytes estavam disponíveis.
  • Tratar amostragem como download local completo de cada blob.
  • Confundir disponibilidade de dados com validade da transição de estado.
  • Confundir verificação DA local com finalidade da L1 ou do rollup.
  • Perder colunas por atraso, eclipse, partição ou pares correlacionados.
  • Falhar em reconstrução ou solicitação a pares apesar da capacidade nominal.
  • Perder ou reordenar o compromisso em uma reorganização L1.
  • Deixar a janela mínima expirar antes da derivação ou contestação.
  • Depender de arquivo ou indexador indisponível, corrompido ou incompleto.
  • Falhar a derivação após atualização de compressão ou protocolo do rollup.
  • Presumir que ponte ou saída são seguras apenas porque os blobs estavam disponíveis.

Erros comuns

  • O espaço de blobs é armazenamento permanente que contratos leem como calldata.
  • Cada byte de um blob de 128 KiB é carga de aplicação sem restrições.
  • Com PeerDAS, todo nó da Ethereum baixa e armazena para sempre cada blob completo.
  • Um compromisso KZG, amostra bem-sucedida ou inclusão finalizada prova que o estado do rollup está correto e que usuários podem sair.
  • A capacidade da mainnet está fixada para sempre em 3/6, 6/9 ou no cronograma atual 14/21.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...