EIP-4844 Proto-Danksharding Explicado | Ethereum IA

O EIP-4844, também conhecido como proto-danksharding, é uma das propostas de melhoria mais transformadoras já implementadas no Ethereum. Ativada como parte da atualização Dencun em março de 2024, essa EIP introduziu um novo tipo de transação que permite anexar grandes pacotes de dados temporários, chamados blobs, aos blocos do Ethereum. O resultado prático foi uma redução drástica nos custos operacionais das redes Layer 2, democratizando o acesso a transações baratas no ecossistema Ethereum.

Este artigo aprofunda os aspectos técnicos do EIP-4844, explicando seu funcionamento interno, as decisões de design por tras da proposta e como ela se encaixa no plano de longo prazo para a escalabilidade do Ethereum.

A Origem do Nome

O termo danksharding vem de Dankrad Feist, pesquisador da Ethereum Foundation que propos uma abordagem inovadora para o sharding de dados. Diferentemente das propostas anteriores de sharding, que envolviam multiplas cadeias paralelas com seus próprios validadores, o danksharding propoe que todos os dados sejam confirmados por um único propositor de bloco, com a disponibilidade dos dados sendo verificada através de amostragem (Data Availability Sampling).

O prefixo proto indica que o EIP-4844 implementa apenas uma versão preliminar dessa visao completa. Ele estabelece o formato dos blobs e o mecanismo de transações, mas sem o sharding de dados real e sem o DAS. E como construir a estrada antes de abrir para o trafego pesado.

Arquitetura Técnica

Uma blob transaction é um novo tipo de transação Ethereum (tipo 3), que estende o formato das transações EIP-1559 (tipo 2). Além dos campos habituais como destinatario, valor e gas, uma blob transaction inclui campos adicionais: max_fee_per_blob_gas, blob_versioned_hashes e, no nível de rede, os blobs propriamente ditos junto com suas provas criptográficas.

Cada blob contém exatamente 4096 elementos de campo, onde cada elemento tem 32 bytes. Isso resulta em aproximadamente 128 KB por blob. O protocolo permite no máximo 6 blobs por bloco, com uma meta de 3 blobs por bloco. Esses parâmetros definem a capacidade máxima de dados que pode ser transmitida por bloco.

Os blobs não são acessiveis pela EVM (Ethereum Virtual Machine). Contratos inteligentes não podem ler o conteúdo dos blobs diretamente. O que fica acessível na camada de execução são os versioned hashes, que são compromissos criptográficos (commitments) que permitem verificar a existência e a integridade dos dados sem acessar os dados em si.

KZG Commitments

Para garantir a integridade dos dados dos blobs, o EIP-4844 utiliza o esquema de compromisso polinomial KZG (Kate-Zaverucha-Goldberg). Cada blob e representado como um polinomio, e o KZG commitment é uma prova compacta que permite verificar propriedades do polinomio sem revelar todos os seus coeficientes.

O KZG foi escolhido porque ele possui uma propriedade essencial para o futuro danksharding: a capacidade de realizar Data Availability Sampling. Com KZG commitments, um no pode verificar que um blob está disponível baixando apenas algumas amostras aleatorias dos dados, em vez de baixar o blob inteiro.

A geracao dos parâmetros para KZG exigiu uma cerimonia de trusted setup, conhecida como KZG Ceremony. Em 2023, a Ethereum Foundation conduziu uma cerimonia com mais de 140.000 contribuidores. A segurança do esquema depende de pelo menos um participante ter sido honesto e ter descartado seus parâmetros secretos após a contribuição.

O Mercado de Taxas de Blob

O EIP-4844 cria um mercado de taxas completamente separado para blobs. Enquanto as transações regulares pagam gas segundo o mecanismo EIP-1559, os blobs possuem sua própria taxa base (blob base fee) que segue uma lógica analoga, mas independente.

A taxa base de blob se ajusta a cada bloco com base na utilização. Se o bloco anterior continha mais de 3 blobs (a meta), a taxa aumenta. Se continha menos, ela diminui. O fator de ajuste e exponencial: a taxa pode aumentar ou diminuir em até aproximadamente 12,5% por bloco.

Quando a demanda por espaço de blob é baixa, as taxas convergem para o mínimo (1 wei por blob gas). Quando a demanda é alta e sustentada, as taxas aumentam até que a demanda se equilibre com a oferta. Esse mecanismo garante que os blobs não fiquem permanentemente lotados e que os custos reflitam a real demanda por disponibilidade de dados.

Disponibilidade Temporaria de Dados

Uma das decisões de design mais importantes do EIP-4844 e a temporariedade dos dados de blob. Os nos da rede armazenam os blobs por aproximadamente 18 dias (4096 epochs), após o que os dados são descartados. Apenas o KZG commitment permanece como parte do registro permanente do bloco.

Essa decisão foi motivada por duas razoes. Primeiro, armazenamento permanente e caro e levaria a um crescimento insustentavel do estado da rede. Segundo, os rollups não precisam de armazenamento permanente na camada base. Eles precisam que os dados estejam disponíveis por tempo suficiente para permitir verificação e resolução de disputas.

O período de 18 dias oferece uma margem confortavel. Nos rollups optimistic, o período de desafio típico e de 7 dias. Nos rollups ZK, a verificação da prova é praticamente instantânea. Em ambos os casos, 18 dias são mais que suficientes para garantir a segurança.

Impacto nos Rollups

Os rollups são os principais beneficiários do EIP-4844. Antes dessa atualização, publicar dados na mainnet via calldata custava caro porque o calldata consome gas da mesma pool que todas as outras operações. Com blobs, os rollups passaram a ter um canal dedicado é mais econômico.

Para rollups optimistic como Arbitrum e Optimism, os dados publicados via blob incluem as transações completas processadas na Layer 2. Esses dados precisam estar disponíveis para que qualquer pessoa possa reconstruir o estado da L2 e, se necessário, submeter uma prova de fraude.

Para rollups ZK como zkSync e StarkNet, os dados publicados incluem as diferenças de estado (state diffs) resultantes da execução das transações. Como as provas de validade já garantem que as transações foram executadas corretamente, os dados servem para garantir que qualquer pessoa possa reconstruir o estado atual da L2.

Limitações Atuais

Apesar dos avanços, o EIP-4844 possui limitações conhecidas que serão abordadas em atualizações futuras. A capacidade de aproximadamente 384 KB por bloco (6 blobs de 128 KB) e insuficiente para suportar a demanda de dezenas ou centenas de rollups operando em alta capacidade.

Além disso, sem Data Availability Sampling, cada no precisa baixar todos os blobs, o que limita a quantidade de dados que a rede pode processar sem comprometer a descentralização. O DAS permitirá que a capacidade de dados cresca sem exigir que cada no processe tudo.

Outra limitação e a ausência de mecanismos nativos para garantir o armazenamento de longo prazo dos dados de blob. Embora existam serviços externos e protocolos de arquivamento que preservam esses dados, a responsabilidade não recai sobre o protocolo Ethereum em si.

O Caminho Para o Danksharding Completo

O proto-danksharding foi projetado para ser um degrau em direcao ao danksharding completo. As proximas etapas incluem a implementação de PeerDAS (Peer Data Availability Sampling), que permite que nos verifiquem a disponibilidade de dados sem baixar todos os blobs. Com PeerDAS, a meta e aumentar o número de blobs por bloco significativamente, potencialmente para 64 ou mais.

O danksharding completo combinara PeerDAS com codificacao de apagamento (erasure coding), permitindo que os dados sejam reconstruidos mesmo que partes estejam indisponiveis. Isso maximiza a capacidade de dados enquanto mantém a segurança e a descentralização.

Cada etapa dessa evolução foi cuidadosamente planejada para ser retrocompativel com as anteriores. Os rollups que já usam blob transactions não precisarao de mudanças fundamentais quando o danksharding completo for ativado.

Consideracoes Finais

O EIP-4844 representa um março na estratégia de escalabilidade do Ethereum. Ao criar um canal dedicado para dados de rollup, com precificação independente e armazenamento temporário, ele reduziu dramaticamente os custos para usuários de Layer 2 e estabeleceu a base técnica para expansoes futuras.

Aviso: Este conteúdo e apenas informativo e não constitui aconselhamento financeiro. Consulte um profissional qualificado antes de tomar decisões de investimento.