Pesquisadores do Ethereum relataram propagação mediana inferior a um segundo para um payload de execução simulado de 1 MiB usando o design de transmissão segmentada do EIP-8411, em comparação com aproximadamente cinco segundos ao enviar o payload como uma única mensagem.
Resumo
- Os testes reduziram a propagação mediana de um payload de 1 MiB de cinco segundos para menos de um segundo.
- O EIP-8411 divide os payloads de execução em blocos que os nós podem verificar e encaminhar antes da conclusão total.
- Uma raiz de Merkle na oferta de execução permite que os nós validem cada segmento de payload recebido de forma independente.
- Os testes do protótipo usaram 500 nós simulados, largura de banda de home-builder, latência geográfica e dez sementes de rede aleatorizadas.
- Os desenvolvedores do Ethereum discutirão o EIP-8411 para inclusão no Hegotá no ACDC em 17 de setembro de 2026 hoje.
O Ethereum Research publicou os resultados mais recentes dos testes em 17 de setembro, detalhando um protótipo que divide os payloads de execução em pedaços menores para que os nós possam verificar e encaminhar cada segmento antes de receber o payload completo. As descobertas vêm de simulações e código de cliente protótipo, não de medições da mainnet do Ethereum.
A proposta permanece como um EIP de rede em Rascunho no repositório de EIPs do Ethereum. Seu design atual substitui o tópico único de gossip execution_payload introduzido pelo EIP-7732 por um tópico execution_payload_chunks e compromete as peças por meio de uma raiz de Merkle incluída na oferta de execução do builder.
O EIP-8411 do Ethereum elimina a espera pelo payload completo
O modelo de gossip existente do Ethereum pode exigir que um nó receba e valide uma mensagem grande antes de encaminhá-la aos pares. Os pesquisadores por trás do EIP-8411 descrevem o atraso resultante como um problema de armazenar-e-encaminhar, porque o payload completo precisa atravessar um salto de rede antes de iniciar o próximo.
Com a propagação segmentada, um builder divide o payload em peças fixas. Cada segmento carrega uma prova de inclusão de Merkle vinculada à raiz comprometida na oferta de execução. Um nó receptor pode verificar um segmento e começar a enviá-lo adiante enquanto as peças restantes ainda estão chegando.
Além disso, a discussão do EIP no Ethereum Magicians descreve a mudança planejada como a substituição da mensagem única de payload do EIP-7732 por blocos verificáveis independentemente. O rascunho atualmente propõe 64 blocos e uma estrutura de prova de Merkle que vincula cada peça ao compromisso original do payload. Os pesquisadores afirmaram que o compromisso de Merkle representa a principal adição em nível de consenso necessária para a segmentação básica. O protótipo de pesquisa mais recente mantém intactos o formato de transmissão existente do gossipsub, a construção da malha de rede, o grau de pares e o sistema de pontuação, enquanto altera como as peças do payload são publicadas e encaminhadas.
A documentação do Ethereum atualmente descreve os payloads de execução como dados relacionados a transações e estado gerados pelo cliente de execução e transportados pelo processo de consenso. Os validadores recebem os blocos propostos por meio da rede de gossip de consenso antes de enviar os dados de execução aos seus clientes de execução para validação.
Simulação reduz a mediana de 1 MiB de cinco segundos
Os números de desempenho mais expressivos no relatório de 17 de setembro vêm de uma simulação controlada. Os pesquisadores modelaram 500 nós usando latência de rede geográfica, capacidade de upload de 50 Mbps e capacidade de download de 100 Mbps, com um payload de 1 MiB originado de um home builder e sem nós de data center de alta largura de banda.
Nessa configuração, enviar o payload como uma única mensagem completa do gossipsub levou aproximadamente cinco segundos para alcançar metade dos nós receptores e perto de seis segundos na cauda. Uma versão segmentada ajustada alcançou uma mediana próxima de 0,75 segundos e uma cauda próxima de um segundo.
Os pesquisadores enfatizam que as medições vêm de um ambiente de simulação executando código real do Prysm e do go-libp2p-pubsub contra uma rede simulada e um relógio virtual. Cada medição usou dez configurações de rede aleatorizadas. As condições da mainnet podem diferir da topologia, largura de banda e suposições de tráfego modeladas.
Seu design básico de Nível 1 combina segmentação com publicação em lote. Usando segmentos de 16 KiB, o relatório afirma que a propagação mediana de um payload de 1 MiB caiu de cinco segundos para menos de um segundo, enquanto a latência de cauda caiu de aproximadamente seis segundos para pouco mais de um segundo.
A publicação em lote muda a forma como a origem envia as partes. Em vez de enviar cada cópia de um segmento antes de começar o próximo, o construtor distribui diferentes partes para diferentes pares antecipadamente, permitindo que várias seções do payload comecem a se mover pela rede ao mesmo tempo. Os pesquisadores disseram que o Tier 1 exigiu aproximadamente um terço a mais de bytes recebidos do que a abordagem atual de mensagem inteira. O tradeoff vem do envio de muitas partes identificadas independentemente e das mensagens de controle extras necessárias para anunciá-las.
Tiers mais avançados reduzem o tráfego de rede duplicado
Um segundo tier proposto aborda dados duplicados. Em vez de enviar cada segmento para todos os pares elegíveis da malha, os nós podem enviar partes para um grupo limitado enquanto anunciam a disponibilidade aos outros. Os pares solicitam segmentos ausentes apenas quando necessário.
O protótipo combina esse sistema com o que seus autores chamam de pulls disciplinados. Um nó inicialmente solicita um segmento a um par, aguarda um timeout definido e passa para outra fonte se o primeiro par não conseguir entregar.
Com um tamanho de payload de 1 MiB, a pesquisa diz que os pulls disciplinados reduziram o tráfego recebido para cerca de 1,5 cópias do payload por nó, em comparação com muito mais tráfego duplicado em variantes menos controladas. Os pesquisadores descobriram que reduzir duplicatas se tornou cada vez mais útil quando a largura de banda de upload disponível era limitada.
A abordagem cria outro tradeoff. Um par malicioso ou sobrecarregado poderia anunciar um segmento e então se recusar a fornecê-lo. Os pesquisadores testaram um cenário de retenção no qual alguns nós anunciavam segmentos, mas não respondiam às solicitações. Em níveis mais altos de retenção, o design ajustado baseado em pull mostrou latência de cauda crescente. Os autores testaram timeouts mais curtos e múltiplas fontes de solicitação possíveis como métodos para limitar essa exposição.
Seu terceiro tier adiciona codificação de apagamento Reed-Solomon. Um payload é comprimido, codificado com partes de paridade extras e dividido em segmentos. Os nós podem reconstruir o payload após coletar partes suficientes sem esperar por cada segmento original.
Os pesquisadores disseram que o modelo codificado teve a menor latência de cauda em seus testes e permaneceu funcional quando alguns segmentos foram retidos. O custo foi maior largura de banda na origem de publicação porque os dados de paridade aumentam a quantidade enviada.
EIP-8411 agora enfrenta uma discussão de inclusão no Hegotá
EIP-8411 não é atualmente um recurso ativado do Ethereum. A proposta no GitHub foi aberta em 4 de setembro e permanece rotulada como um EIP de rede em Rascunho aguardando revisão. A proposta requer o EIP-7732, o design de separação proposer-builder consagrado do Ethereum.
Os desenvolvedores do Ethereum solicitaram que o EIP-8411 recebesse o status PFI, ou Proposed for Inclusion, para o Hegotá, a atualização de rede esperada após o Glamsterdam. Durante a discussão de Execução do All Core Developers de 10 de setembro, os desenvolvedores disseram que a proposta deveria ser considerada pela chamada de desenvolvedores da camada de consenso, porque a mudança afeta principalmente a rede de consenso.
O pedido veio após o prazo normal de PFI do Hegotá. Seus proponentes propuseram o EIP-8411 como substituto do EIP-8142, que havia explorado a colocação de blocos em blobs, mas levantou preocupações sobre a prova KZG do lado do construtor e a reutilização de sub-redes de disponibilidade de dados.
A agenda do ACDC #187 programa uma discussão de PFI do EIP-8411 para 17 de setembro às 14:00 UTC. No momento deste relatório, a chamada ainda não havia ocorrido, então nenhuma decisão de incluir o EIP-8411 no Hegotá havia sido registrada.
Os desenvolvedores vêm reduzindo o conjunto de recursos do Hegotá em abstração de contas, escalabilidade, resistência à censura e outros trabalhos de protocolo. O EIP-8411 entrou nesse processo mais tarde do que muitas propostas e ainda precisa de uma decisão de inclusão dos desenvolvedores principais.
A proposta de rede está ligada ao trabalho do Ethereum de aumentar a capacidade da Camada 1. Limites de gas maiores podem levar a payloads de execução maiores, aumentando a quantidade de dados que os validadores devem receber dentro de prazos de consenso fixos. O limite de gas do Ethereum atingiu 60 milhões no final de 2025 depois que os validadores sinalizaram apoio ao aumento.
Vitalik Buterin descreveu maior capacidade da Camada 1, PeerDAS e trabalho futuro de ZK-EVM como partes do plano de escalabilidade do Ethereum. A entrega mais rápida de payloads está sendo pesquisada junto com essas mudanças, porque mensagens de rede maiores colocam mais pressão na largura de banda dos nós e nos prazos de propagação.
O código protótipo está disponível, mas permanece experimental
Os pesquisadores publicaram implementações protótipo para Prysm e go-libp2p-pubsub. O branch recomendado variant-a do Prysm contém uma série de alterações por trás de uma flag –enable-segmented-payload-gossip, enquanto o branch libp2p que o acompanha implementa políticas de encaminhamento e requisição usadas no estudo.
Os autores descrevem explicitamente seu branch de pesquisa como “um harness, não uma proposta”. Alguns recursos medidos no artigo, incluindo configurações avançadas de erasure-coding, permanecem componentes experimentais do ambiente de teste e não são necessariamente parte da especificação mínima do EIP-8411.
Questões em aberto identificadas pelos pesquisadores incluem o aumento do tráfego de mensagens de controle, custos de CPU decorrentes do processamento de muitas mensagens menores, mapeamentos alternativos de segmentos, gerenciamento de filas, ajuste de temporizadores e se uma pilha de rede mais nova focada em QUIC poderia produzir resultados diferentes.
Os autores planejam mais comparações entre o design de tópico único usado pela variante A, abordagens de mensagem parcial e modelos que atribuem tópicos de gossip separados a segmentos individuais. O protótipo atual mantém peças de 16 KiB como sua linha de base recomendada, após simulações mostrarem que peças menores de 8 KiB não produziram ganhos adicionais de latência enquanto aumentavam o tráfego de controle.
