Ethereum EIP-8479 Explicado: PeerDAS Pós-Quântico e Blobs de Tamanho Variável

2026/11/03 16:03:00

E se o ethereum pudesse tornar sua infraestrutura de disponibilidade de dados mais resistente a futuros computadores quânticos, enquanto oferece às redes de Layer 2 maior flexibilidade sobre como publicam os dados das transações? Uma nova proposta apresentada pelo pesquisador da Ethereum Foundation Francesco Risitano em 1º de novembro de 2026 explora exatamente essa possibilidade. O rascunho, originalmente numerado como EIP-9999, propõe substituir os compromissos KZG no PeerDAS por compromissos Merkle Keccak-256 e provas LeanDA STARK. Também introduz blobs de tamanho variável, variando de 2 KiB a 512 KiB, permitindo que os rollups escolham capacidade de dados mais alinhada às suas necessidades. A thread de discussão dos Ethereum Magicians utiliza a designação EIP-8479, tornando a distinção na numeração importante ao acompanhar a proposta. Embora o design ainda esteja em estágio inicial de revisão, ele conecta três prioridades principais do desenvolvimento do ethereum: criptografia pós-quantum, disponibilidade de dados e escalabilidade de Layer 2. Seu potencial significado vai além da engenharia do protocolo, levantando questões sobre os custos dos rollups, a competitividade da infraestrutura do ethereum e o valor de longo prazo do ETH no ecossistema.

Principais conclusões

Uma nova proposta pós-quantum: o rascunho explora a substituição das compromissos KZG-based PeerDAS por compromissos Merkle baseados em Keccak-256 e provas LeanDA STARK.
Blobs de tamanho variável: o design permite tamanhos de blob que são potências de dois, de 2 KiB a 512 KiB, mantendo 128 colunas por blob.
Implicações da Layer 2: Rollups poderiam selecionar capacidades de dados mais alinhadas aos lotes de transações, potencialmente melhorando a utilização dos dados.
Alterações criptográficas: caminhos de autenticação Merkle substituiriam as provas de célula KZG, enquanto provas STARK verificariam a codificação Reed-Solomon e a derivação do compromisso.
Estágio inicial de desenvolvimento: A proposta permanece como um rascunho, com parâmetros do sistema de prova, integração de cliente e benchmarks de desempenho ainda necessitando de trabalho.
Relevância do mercado ETH: A proposta pode fortalecer a narrativa de infraestrutura de longo prazo do ethereum, mas não estabelece um catalisador imediato para os preços do ETH nem garante taxas de transação mais baixas.

O que é o Ethereum EIP-8479 e por que foi proposto?

A proposta aborda dois desafios interconectados: a segurança criptográfica de longo prazo da camada de disponibilidade de dados do Ethereum e a necessidade de capacidade de dados mais flexível para rollups. Sua especificação original é intitulada EIP-9999, com o fórum de discussão de novembro 1 utilizando o título EIP-8479. Foi escrita por Francesco Risitano, Thomas Coratger e Tom Wambsgans, e seu rascunho inicial data de 26 de outubro de 2026. A proposta é um EIP de Núcleo, Faixa de Padrões e atualmente possui status de Rascunho. Ela faz referência a várias propostas relacionadas, incluindo EIP-4844, EIP-7594, EIP-7892, EIP-8141 e EIP-8288.

Por que o PeerDAS existente precisa de uma abordagem criptográfica diferente

PeerDAS, ou Peer Data Availability Sampling, permite que nós Ethereum verifiquem se os dados de blob estão disponíveis sem baixar cada byte de um blob inteiro. O mecanismo distribui os dados em colunas, atribui responsabilidades de custódia aos nós e permite que os participantes amostram porções selecionadas. Isso reduz os requisitos de dados para validadores comuns, mantendo um método para verificar a disponibilidade dos dados.

O design atual utiliza compromissos KZG e provas de células para autenticar dados amostrados. O KZG depende da criptografia de emparelhamento de curvas elípticas, que é vulnerável, em princípio, a computadores quânticos tolerantes a falhas suficientemente capazes de executar o algoritmo de Shor. Embora computadores quânticos práticos capazes de quebrar as suposições criptográficas do ethereum não estejam atualmente disponíveis, pesquisadores do protocolo estão avaliando alternativas antes que tal ameaça se torne operacional. A discussão do EIP-8479 reflete, portanto, uma estratégia de segurança proativa, e não uma resposta a um ataque quântico imediato.

Por que a flexibilidade do Blob importa para o ethereum

A segunda motivação diz respeito à maneira como os rollups compram e publicam capacidade de dados. Estruturas de dados de tamanho fixo podem criar ineficiências quando o lote de transações de um rollup não corresponde à capacidade disponível. Um lote menor pode deixar espaço não utilizado, enquanto aguardar para acumular um lote maior pode introduzir atrasos adicionais na publicação.

Blobs de tamanho variável visam dar aos operadores de rollup mais controle sobre esse compromisso. Em vez de tratar cada submissão como uma unidade de capacidade fixa, o design proposto permite que os tamanhos de blob suportados aumentem em potências de dois. Isso pode tornar a publicação de dados mais adaptável a diferentes volumes de transações e requisitos operacionais.

Como o EIP-8479 substitui o KZG por STARKs pós-quânticos?

A mudança criptográfica central é a substituição dos compromissos KZG e provas de célula por compromissos Merkle de Keccak-256, caminhos de autenticação Merkle e provas LeanDA STARK. O design separa a tarefa de autenticar amostras individuais de dados da tarefa de provar que o blob completo foi codificado e comprometido corretamente. Isso tem como objetivo eliminar a dependência das suposições de emparelhamento de curvas elípticas e eliminar a configuração confiável exigida pela construção KZG existente.

Compromissos Merkle Keccak-256

Uma árvore de Merkle organiza dados por meio de hash repetido. Elementos de dados individuais são primeiramente hashizados em nós folha, após os quais pares de hashes são combinados para criar nós de níveis superiores. O processo continua até que uma única raiz de Merkle represente a estrutura de dados subjacente.

No design proposto do PeerDAS, cada blob recebe um compromisso Merkle baseado no Keccak-256. Quando um node amostra uma célula de dados específica, pode receber o caminho de autenticação Merkle correspondente e verificar independentemente se a célula pertence ao blob comprometido. Isso fornece uma maneira de autenticar dados amostrados sem depender de provas de célula KZG.

Keccak-256 é particularmente relevante porque construções criptográficas baseadas em funções hash são geralmente consideradas mais adequadas para segurança pós-quantum do que esquemas baseados em logaritmos discretos de curva elíptica. Algoritmos de busca quântica ainda podem reduzir a segurança efetiva das funções hash, portanto, os parâmetros de segurança e os detalhes de implementação permanecem importantes. A proposta deve, portanto, ser entendida como um passo em direção a pressupostos criptográficos resistentes a quantum, e não como uma garantia contra todos os futuros ataques quânticos.

O que o LeanDA STARK verifica realmente?

A autenticação de Merkle estabelece que uma célula amostrada pertence a uma estrutura de dados comprometida específica, mas o protocolo também deve garantir que a codificação dos dados do blob e a geração do compromisso estejam corretas. É aí que o LeanDA STARK se torna importante.

A prova STARK proposta demonstra duas propriedades centrais: que o blob satisfaz sua relação de codificação Reed-Solomon e que o compromisso Merkle associado foi derivado corretamente. A codificação Reed-Solomon introduz redundância que permite reconstruir partes ausentes dos dados quando há suficientes partes válidas disponíveis. A prova permite que a rede verifique as relações de codificação e compromisso relevantes sem exigir que cada verificador repita todo o cálculo independentemente.

A proposta também conecta as provas LeanDA ao EIP-8288, que fornece um framework de agregação recursiva STARK em nível de bloco. Em vez de tratar cada prova como uma tarefa de verificação isolada, o design introduz quadros de dependência de disponibilidade de dados cujas provas podem ser integradas à agregação em nível de bloco mais ampla. Essa integração é tecnicamente significativa porque os custos de geração, agregação e verificação das provas influenciarão se o design é prático para clientes Ethereum.

Como os blobs de tamanho variável alteram a disponibilidade de dados do ethereum?

A proposta introduz tamanhos de blobs variando de 2 KiB a 512 KiB, com comprimentos de bytes suportados restritos a potências de dois. Cada blob mantém 128 colunas, o que significa que o comprimento em bytes das unidades de dados individuais muda, enquanto a estrutura geral de colunas permanece consistente. Isso representa uma grande diferença em relação ao modelo tradicional de blob de tamanho fixo utilizado pela infraestrutura atual de disponibilidade de dados do ethereum.

Da Capacidade Fixa para Publicação Flexível de Dados

Sob o design proposto, um rollup poderia selecionar um tamanho de blob que se aproxime mais da quantia de dados que precisa publicar. Um lote de transações pequeno poderia usar um blob menor, enquanto um lote maior poderia selecionar uma maior capacidade. O objetivo é reduzir o preenchimento desnecessário e oferecer aos rollups mais flexibilidade para equilibrar os custos de disponibilidade de dados em relação à frequência de publicação.

Os seguintes exemplos ilustram a faixa de capacidade proposta:

2 KiB: Uma pequena submissão de dados que exige capacidade limitada.
8 KiB–64 KiB: Tamanhos intermediários para lotes de transações relativamente compactos.
128 KiB: Um ponto de referência familiar correspondente à capacidade tradicional de blob.
256 KiB–512 KiB: Envios maiores que exigem capacidade adicional de dados.

A proposta também especifica alterações nas transações que transportam blobs. Em vez de depender exclusivamente da representação de hash versionado existente, a estrutura de transação proposta utiliza uma raiz Merkle e um campo de comprimento em bytes explícito. As transações que transportam blobs são representadas usando transações de quadro EIP-8141, vinculando a nova estrutura de dados ao design mais amplo do formato de transação.

Como os blobs de tamanho variável poderiam afetar os custos de gas?

A capacidade flexível de blobs pode melhorar a utilização de dados, mas a relação entre o tamanho do blob e as taxas não é tão simples quanto escolher um blob menor e pagar automaticamente menos. A proposta também altera os requisitos de rede e a contabilidade de gás, incluindo os custos associados à autenticação Merkle e ao novo processo de verificação.

Para operadores de rollup, o cálculo relevante envolve mais do que apenas a capacidade bruta de dados. Eles devem considerar o tamanho dos lotes de transações, a frequência de publicação de blobs, os custos de geração de provas, a propagação na rede e o preço de mercado do blob gas. Um blob menor pode ser mais eficiente para uma carga de trabalho, enquanto uma submissão maior pode ser preferível para outra.

O design, portanto, introduz uma oportunidade para otimizar a publicação de dados, em vez de prometer uma redução universal de taxas. Os economias reais dependerão dos benchmarks de implementação e de como os desenvolvedores de rollup adaptarão suas estratégias de agrupamento após a proposta passar por mais revisões.

O que o EIP-8479 pode significar para as redes Layer 2 do ethereum?

A proposta poderia tornar a infraestrutura de disponibilidade de dados do Ethereum mais adaptável às necessidades de Layer 2 networks, especialmente rollups que publicam dados de transações em lotes. Arbitrum, Optimism e Base são exemplos de principais ecossistemas de escalonamento do Ethereum cujos operadores têm interesse em publicação de dados eficiente e previsível. No entanto, o EIP-8479 não altera diretamente seus ambientes de execução nem garante reduções imediatas nas taxas de transação dos usuários.

Benefícios Potenciais para Operadores de Rollup

Rollups devem equilibrar a frequência de envio de lotes de transações com o custo de publicação de dados no ethereum. Blobs de capacidade fixa podem criar uma discrepância entre as necessidades reais de dados e a capacidade adquirida. Blobs de tamanho variável poderiam oferecer aos operadores mais opções ao projetar tamanhos de lote e cronogramas de publicação.

Por exemplo, um rollup com atividade de transações relativamente baixa pode preferir publicar lotes menores sem esperar acumular dados suficientes para preencher uma estrutura maior de capacidade fixa. Um rollup de alto volume pode, em vez disso, usar blobs maiores para consolidar mais dados em cada envio. Essas escolhas podem melhorar a flexibilidade operacional e ajudar os desenvolvedores a otimizar a relação entre os custos de disponibilidade de dados e a latência das transações.

O benefício não será necessariamente idêntico entre as redes. Rollups diferem em volume de transações, técnicas de compressão, modelos de sequenciamento e estratégias de publicação de dados. Consequentemente, os desenvolvedores precisarão avaliar se a flexibilidade adicional supera os custos de implementação e geração de provas.

Implicações para a competição de Layer 2 do ethereum

O ethereum compete com ecossistemas alternativos de blockchain que oferecem abordagens diferentes para execução, liquidação de transações e disponibilidade de dados. Melhorar a eficiência de sua infraestrutura de blobs pode apoiar a posição do ethereum como camada de liquidação e disponibilidade de dados para aplicações baseadas em rollup.

No entanto, a competitividade da rede depende de mais do que a capacidade de blobs. Desenvolvedores e usuários também consideram taxas de transação, desempenho de aplicações, liquidez, interoperabilidade, segurança e suporte ao ecossistema. A EIP-8479 aborda uma parte importante dessa equação mais ampla: a infraestrutura criptográfica e de disponibilidade de dados subjacente ao escalonamento por rollup.

Sua contribuição potencial é, portanto, melhor avaliada como uma melhoria na infraestrutura que poderá fortalecer o ambiente de desenvolvimento da Layer 2 do Ethereum ao longo do tempo, e não como uma vantagem competitiva imediata já demonstrada.

Como o EIP-8479 se encaixa no roteiro pós-quântico do ethereum?

EIP-8479 aborda o componente de disponibilidade de dados da agenda de pesquisa pós-quântica mais ampla do Ethereum. Ele não substitui todas as primitivas criptográficas utilizadas pela rede e não torna o Ethereum totalmente resistente a quantum. Assinaturas de consenso, autenticação de contas e outros sistemas criptográficos exigem suas próprias estratégias de migração.

Três áreas criptográficas requerem atenção

A arquitetura criptográfica do ethereum inclui vários componentes com diferentes suposições de segurança:

Assinaturas de consenso: Validadores da Ethereum usam assinaturas BLS para participar do consenso e aglomerar atestações. Como o BLS depende da criptografia de emparelhamento de curva elíptica, pesquisadores estão explorando sistemas alternativos de assinatura que possam oferecer propriedades de segurança pós-quântica mais robustas.

Assinaturas de conta: Contas externas proprietárias padrão usam assinaturas ECDSA. Um computador quântico suficientemente poderoso poderia, teoricamente, usar o algoritmo de Shor para derivar informações da chave privada a partir de chaves públicas expostas sob as suposições relevantes da curva elíptica. A abstração de conta e mecanismos alternativos de verificação de assinatura estão entre as abordagens que poderiam suportar a migração futura.

Compromissos de disponibilidade de dados: os compromissos KZG são o componente diretamente visado por esta proposta. Substituí-los por compromissos Merkle baseados em hash e provas STARK resolveria uma parte específica da exposição criptográfica do protocolo.

Essas áreas estão relacionadas, mas não podem ser atualizadas por meio de uma única variação. A transição pós-quântica do ethereum exigirá trabalho coordenado em consenso, execução, rede e infraestrutura de aplicações.

Por que os projetos baseados em STARK são importantes

Os sistemas STARK utilizam funções hash e construções de prova transparentes, em vez de depender de emparelhamentos de curvas elípticas e uma configuração confiável convencional. Suas propriedades os tornam candidatos para aplicações pós-quânticas, embora o tamanho da prova, o desempenho de verificação, a complexidade de implementação e os parâmetros de segurança do hash ainda precisem ser avaliados.

O EIP-8479 também demonstra a importância de conectar a pesquisa criptográfica com a engenharia de protocolos. Um sistema de prova teoricamente seguro não é suficiente por si só: ele deve funcionar dentro das restrições de tempo de bloco da Ethereum, largura de banda, recursos dos validadores e compatibilidade dos clientes. A integração da proposta com o EIP-8288 reflete essa necessidade de considerar a verificação da prova ao nível do bloco como um todo.

Qual é o status atual do EIP-8479?

Em 2 de novembro de 2026, a proposta permanece como um rascunho em estágio inicial, e não como uma atualização aprovada da rede Ethereum. Sua discussão em 1º de novembro e o pull request no GitHub convidam comentários de desenvolvedores de rollup, equipes de consenso e cliente de execução, contribuidores de rede e pesquisadores em criptografia. A especificação identifica explicitamente várias questões não resolvidas, o que significa que ainda resta muito trabalho de design e implementação antes que qualquer implantação no mainnet possa ser considerada.

Desafios Técnicos Excepcionais

O primeiro problema é a conclusão do programa de convidado LeanDA e seu hash da chave de verificação. Esses componentes são importantes porque definem o cálculo sendo comprovado e os parâmetros utilizados pelos verificadores para verificar a prova STARK resultante.

O segundo problema é a implementação do cliente. A proposta exige alterações coordenadas nos componentes de camada de execução, camada de consenso e rede. Os desenvolvedores devem garantir que diferentes clientes interpretem consistentemente os compromissos de blob, campos de transação e procedimentos de autenticação de dados.

A terceira questão diz respeito ao desempenho. A geração de provas, a agregação recursiva, os caminhos de autenticação Merkle e a largura de banda do PeerDAS devem ser benchmarkados em diferentes configurações de node. Um design que funcione em um ambiente de pesquisa controlado também deve permanecer prático para a rede mais ampla de validadores.

Finalmente, os operadores de rollup precisam confirmar se a distribuição proposta do tamanho dos blobs corresponde à demanda do mundo real. Comentários sobre as capacidades preferidas ajudarão a determinar se os blobs de tamanho variável oferecem benefícios significativos além da complexidade adicional do protocolo.

O que desenvolvedores e investidores devem observar a seguir?

Os desenvolvimentos mais importantes serão o avanço na especificação, a publicação de um protótipo funcional, a revisão criptográfica independente e os resultados de desempenho. O feedback das equipes de rollup também ajudará a determinar se a faixa de capacidade proposta é útil para cargas de trabalho reais de publicação de dados.

O status das propostas relacionadas também importa. O EIP-8288 fornece o framework de agregação de provas recursivas referenciado pelo LeanDA, enquanto o EIP-8141 fornece a estrutura proposta de transação de quadro. O progresso de sua implementação pode influenciar o caminho de integração para o novo design.

Para investidores, a distinção entre uma proposta de pesquisa e uma atualização programada é essencial. Uma Draft EIP pode influenciar a narrativa de desenvolvimento de longo prazo do ethereum, mas não deve ser tratada como evidência de que um recurso específico alcançará o mainnet ou produzirá uma variação mensurável na demanda por ETH.

O EIP-8479 poderia afetar o preço do ETH e a adoção do ethereum?

O EIP-8479 tem implicações potenciais de longo prazo para a infraestrutura do Ethereum, mas seu impacto imediato sobre ETH valuation provavelmente será mais influenciado por expectativas de mercado do que por mudanças diretas na economia da rede. A proposta ainda não foi implementada, e não há cronograma confirmado de ativação no mainnet. Consequentemente, ainda não fornece evidências mensuráveis de taxas de rollup mais baixas, maior utilização de blobs ou maior demanda por transações em ETH.

No curto prazo, traders e analistas são mais propensos a monitorar a atividade de negociação à vista do ETH, a posição em derivados, os fluxos de ETFs e as condições de mercado mais amplas. Notícias sobre a proposta podem fortalecer o interesse na rota técnica do Ethereum, mas uma especificação em rascunho sozinha não é suficiente para estabelecer um catalisador de preço sustentado.

No longo prazo, a implementação bem-sucedida poderia apoiar o papel do Ethereum como uma camada segura de disponibilidade de dados e liquidação. Uma capacidade de blob mais flexível pode ajudar os rollups a gerenciar a publicação de dados, enquanto compromissos baseados em hash e provas STARK podem contribuir para a transição pós-quantum da rede. Essas melhorias podem fortalecer a confiança dos desenvolvedores e a participação no ecossistema se entregarem benefícios práticos de desempenho.

No entanto, a avaliação mais ampla do ETH continuará dependendo da atividade da rede, staking, dinâmica de oferta, adoção de aplicações e concorrência de outros ecossistemas de blockchain. O EIP-8479 deve, portanto, ser visto como um componente do desenvolvimento de infraestrutura de longo prazo do Ethereum, e não como uma tese de investimento independente.

Conclusão

O proposto PeerDAS pós-quantum e o design de blob de tamanho variável do ethereum representam uma importante direção de pesquisa para a infraestrutura de disponibilidade de dados da rede. Ao substituir os compromissos KZG e as provas de célula por compromissos Merkle Keccak-256 e verificação LeanDA STARK, a proposta explora uma arquitetura criptográfica melhor alinhada com os objetivos de segurança pós-quantum de longo prazo. Seu design de blob de tamanho variável, variando de 2 KiB a 512 KiB, também introduz maior flexibilidade para rollups que precisam publicar volumes diferentes de dados de transações.

No entanto, a proposta ainda está em estágio inicial de rascunho. Seus parâmetros de prova, integração de cliente, alterações de rede e requisitos de desempenho ainda precisam ser abordados por meio de revisão técnica e testes de implementação. Para o ethereum, a importância desse desenvolvimento reside na combinação de resiliência criptográfica e eficiência de dados da Layer 2. Se acabará melhorando a economia dos rollups ou influenciando a adoção do ETH dependerá da implementação bem-sucedida e dos benefícios mensuráveis para o ecossistema. Por enquanto, a EIP-8479 é melhor compreendida como uma proposta de infraestrutura voltada para o futuro dentro da agenda mais ampla de escalabilidade e pesquisa pós-quântica do ethereum.

Perguntas frequentes

Qual é a diferença entre um EIP e um ERC?

Uma Proposta de Melhoria do Ethereum (EIP) descreve mudanças propostas ao protocolo, padrões ou processos de desenvolvimento do Ethereum. Um Pedido de Comentários do Ethereum (ERC) geralmente especifica padrões de camada de aplicação, como interfaces de tokens e convenções de contratos inteligentes. O EIP-8479 é uma proposta Core porque diz respeito à disponibilidade fundamental de dados e ao comportamento do protocolo.

O que significa PeerDAS?

PeerDAS significa Peer Data Availability Sampling. É um mecanismo que permite que nós de ethereum amostram partes dos dados de blob distribuídos em vez de baixar cada elemento de dados. Essa abordagem ajuda a reduzir os requisitos de dados individuais dos nós, mantendo uma maneira de verificar a disponibilidade dos dados.

O que é a codificação Reed-Solomon?

A codificação Reed-Solomon é um código de correção de erros que adiciona redundância aos dados. Isso permite reconstruir partes ausentes quando há partes válidas suficientes disponíveis. É relevante para o PeerDAS, pois a disponibilidade distribuída de dados depende da capacidade da rede de recuperar os dados originais a partir de componentes amostrados e distribuídos.

O que é um Setup Confiável em Criptografia?

Uma configuração confiável é um processo de inicialização usado por certos sistemas criptográficos para gerar parâmetros públicos. Se as informações secretas não forem destruídas adequadamente, podem criar riscos de segurança. Os compromissos KZG dependem de uma configuração confiável, enquanto o design proposto baseado em STARK visa evitar esse requisito por meio de uma construção de prova transparente.

Como os usuários podem acompanhar o progresso de uma Proposta de Melhoria do Ethereum?

Os usuários podem seguir o repositório Ethereum EIPs no GitHub, revisar discussões técnicas no Ethereum Magicians e monitorar atualizações dos desenvolvedores do Ethereum. Marcos importantes incluem revisões de especificações, revisões independentes, implementações de protótipos, testes de clientes e qualquer decisão formal sobre inclusão em uma futura atualização da rede.

Isenção de responsabilidade: Esta informação geral de mercado, possivelmente proveniente de fontes terceirizadas, comerciais ou patrocinadas, é fornecida apenas para referência e fins educacionais e não constitui aconselhamento financeiro ou de investimento, oferta, solicitação ou garantia. Renunciamos à responsabilidade por sua precisão, completude, confiabilidade e quaisquer perdas decorrentes. Investimentos/operações envolvem riscos; desempenho passado não garante resultados futuros. Os usuários devem pesquisar, julgar com prudência e assumir total responsabilidade. Para mais detalhes, consulte os Termos de Uso e Divulgação de Risco da KuCoin.

Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.