O que é uma Transação Blob
Um tipo de transação introduzido no EIP-4844 do Ethereum, projetado para reduzir as taxas de transação, armazenando blobs de dados separadamente dos dados principais da transação.
Transações blob, introduzidas através da Proposta de Melhoria do Ethereum (EIP) 4844 (também conhecida como Proto-Danksharding), representam uma mudança arquitetônica significativa voltada para a redução das taxas de transação, especialmente para soluções de escalabilidade de Camada 2. Ao contrário das transações Ethereum tradicionais que incorporam dados diretamente no calldata principal da transação, as transações blob utilizam uma estrutura de dados separada, embora ainda on-chain, chamada 'blobs'. Esses blobs são projetados para serem mais baratos de publicar e estão sujeitos a limites de gas e mecanismos de precificação diferentes dos dados de transação regulares. A principal motivação é reduzir o custo de disponibilidade de dados para rollups. Rollups agrupam transações off-chain e publicam um resumo comprimido ou prova na cadeia principal do Ethereum (Camada 1). O custo de publicar esses dados na Camada 1 é um gargalo importante. O EIP-4844 introduz um novo tipo de transação que permite aos rollups publicar maiores quantidades de dados de forma mais barata, separando-os nesses blobs. Esses blobs não são processados diretamente pela Máquina Virtual Ethereum (EVM), mas sim comprometidos através de um esquema de compromisso de polinômio KZG (Kalai-Shen-Goldwasser). Esse compromisso é incluído no cabeçalho do bloco, garantindo a disponibilidade de dados sem exigir que cada nó baixe e armazene os dados completos do blob indefinidamente. Essa separação e tratamento especializado reduzem significativamente o custo de gas associado à disponibilidade de dados, tornando os rollups mais economicamente viáveis e, assim, aprimorando a escalabilidade geral do Ethereum.
graph LR
Center["O que é uma Transação Blob"]:::main
Rel_eip_4844["eip-4844"]:::related -.-> Center
click Rel_eip_4844 "/terms/eip-4844"
Rel_layer_2["layer-2"]:::related -.-> Center
click Rel_layer_2 "/terms/layer-2"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Teste de conhecimento
🧒 Explique como se eu tivesse 5 anos
Imagine enviar um pacote grande (sua transação) onde você costumava pagar muito para incluir todo o papel de embalagem dentro. Transações blob permitem que você envie o papel de embalagem separadamente e muito mais barato, tornando o custo total da sua entrega muito menor.
🤓 Expert Deep Dive
O EIP-4844 altera fundamentalmente a estratégia de disponibilidade de dados do Ethereum ao introduzir 'blobs' e compromissos KZG. Blobs são pedaços contíguos de dados anexados a um bloco, com um tamanho máximo e um limite de gas separado, distinto do calldata. Crucialmente, blobs não são diretamente acessíveis pela lógica de contrato da EVM; seu propósito principal é a verificação da disponibilidade de dados. O compromisso com os dados do blob é alcançado usando compromissos de polinômio KZG, onde os dados do blob representam coeficientes de um polinômio e o compromisso é um ponto em uma curva elíptica. Isso permite a geração e verificação eficientes de provas. Os nós são obrigados a baixar os dados do blob por um período limitado (por exemplo, ~4096 blocos ou ~27 horas) para fins de verificação, após o qual podem descartá-los, reduzindo o inchaço do estado. O custo de gas para publicar blobs é significativamente menor do que o calldata, calculado com base no tamanho do blob e em um 'preço de gas de blob' separado. Esse mecanismo é um precursor do Danksharding completo, onde o espaço de blob será expandido e distribuído por vários shards. As desvantagens incluem a complexidade do esquema de compromisso KZG e o requisito de armazenamento temporário para os nós, mas o benefício principal é uma redução substancial nos custos de publicação de dados de rollups.