Pesquisadores do Ethereum relataram uma propagação mediana abaixo de um segundo para uma carga de execução simulada de 1 MiB usando o design de transmissão segmentada da EIP-8411, em comparação com aproximadamente cinco segundos ao enviar a carga como uma única mensagem.
A Ethereum Research publicou os últimos resultados de testes em 17 de setembro, detalhando um protótipo que divide as cargas de execução em peças menores para que os nós possam verificar e encaminhar cada segmento antes de receber a carga completa. 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 um EIP de rede em rascunho no repositório de EIPs do Ethereum. Seu design atual substitui o tópico de fofoca (gossip topic) único `execution_payload` introduzido através da EIP-7732 por um tópico `execution_payload_chunks` e confirma as peças por meio de uma raiz Merkle incluída na proposta de execução do construtor.
O modelo de fofoca (gossip) existente do Ethereum pode exigir que um nó receba e valide uma mensagem grande antes de encaminhá-la para os pares. Pesquisadores por trás da EIP-8411 descrevem o atraso resultante como um problema de "armazenar e encaminhar" (store-and-forward) porque a carga completa deve atravessar um salto de rede antes de iniciar o próximo.
Com a propagação segmentada, um construtor divide a carga em peças fixas. Cada segmento carrega uma prova de inclusão Merkle ligada à raiz comprometida na proposta de execução. Um nó receptor pode verificar um segmento e começar a enviá-lo enquanto as peças restantes ainda estão chegando.
Além disso, a discussão da EIP no Ethereum Magicians descreve a mudança planejada como a substituição da mensagem de carga única da EIP-7732 por pedaços verificáveis independentemente. O rascunho atualmente propõe 64 pedaços e uma estrutura de prova Merkle que vincula cada peça ao compromisso original da carga. Os pesquisadores disseram que o compromisso 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 o formato de wire gossipsub existente, a construção da malha de rede, o grau de pares e o sistema de pontuação intactos, enquanto muda a forma como as peças da carga são publicadas e encaminhadas.
A documentação do Ethereum atualmente descreve as cargas de execução como dados relacionados a transações e estados gerados pelo cliente de execução e transportados através do processo de consenso. Os validadores recebem blocos propostos através da rede de fofoca de consenso antes de enviar dados de execução para seus clientes de execução para validação.
Os números de desempenho mais fortes 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 uma carga de 1 MiB originada de um construtor doméstico e sem nós de data center de alta largura de banda.
Nessa configuração, enviar a carga como uma mensagem gossipsub completa levou aproximadamente cinco segundos para atingir metade dos nós receptores e perto de seis segundos na cauda. Uma versão segmentada otimizada atingiu 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 harness de simulação executando código real Prysm e go-libp2p-pubsub contra uma rede simulada e relógio virtual. Cada medição usou dez configurações de rede aleatórias. As condições da mainnet podem diferir da topologia modelada, largura de banda e suposições de tráfego.
Seu design básico de Nível 1 combina segmentação com publicação em lote. Usando segmentos de 16 KiB, o relatório diz que a propagação mediana para uma carga 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 fonte envia as peças. Em vez de enviar cada cópia de um segmento antes de iniciar o próximo, o construtor distribui diferentes peças para diferentes pares mais cedo, permitindo que várias seções da carga comecem a se mover pela rede de uma só vez. Os pesquisadores disseram que o Nível 1 exigiu aproximadamente um terço a mais de bytes recebidos do que a abordagem de mensagem completa de hoje. A desvantagem vem do envio de muitas peças identificadas independentemente e das mensagens de controle extras necessárias para anunciá-las.
Uma segunda camada proposta aborda dados duplicados. Em vez de empurrar cada segmento para todos os pares de malha elegíveis, os nós podem empurrar peças para um grupo limitado enquanto anunciam a disponibilidade para outros. Os pares solicitam segmentos ausentes apenas quando necessário.
O protótipo combina esse sistema com o que seus autores chamam de "disciplined pulls" (puxões disciplinados). Um nó inicialmente solicita um segmento de um par, aguarda um tempo limite definido e passa para outra fonte se o primeiro par não conseguir entregar.
Em um tamanho de carga de 1 MiB, a pesquisa diz que os "puxões disciplinados" reduziram o tráfego recebido para cerca de 1,5 cópias de carga por nó, em comparação com um tráfego duplicado consideravelmente maior em variantes menos controladas. Os pesquisadores descobriram que a redução de duplicatas se tornava cada vez mais útil quando a largura de banda de upload disponível era limitada.
A abordagem cria outra desvantagem. 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 falhavam em responder às solicitações. Em níveis mais altos de retenção, o design baseado em "puxões" otimizado mostrou um aumento da latência de cauda. Os autores testaram tempos limites mais curtos e várias fontes de solicitação possíveis como métodos para limitar essa exposição.
Sua terceira camada adiciona a codificação de correção de erros Reed-Solomon. Uma carga é compactada, codificada com peças de paridade extras e dividida em segmentos. Os nós podem reconstruir a carga após coletar peças 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 uma largura de banda maior na fonte de publicação porque os dados de paridade aumentam a quantidade enviada.
A EIP-8411 não é atualmente um recurso ativado do Ethereum. A proposta do GitHub foi aberta em 4 de setembro e permanece rotulada como um EIP de rede em rascunho aguardando revisão. A proposta exige a EIP-7732, o design de separação de proponente-construtor consagrado do Ethereum.
Os desenvolvedores do Ethereum solicitaram que a EIP-8411 receba o status PFI, ou Proposta para Inclusão, para Hegotá, a atualização de rede esperada após Glamsterdam. Durante a discussão de Execução dos Desenvolvedores Core em 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 de Hegotá. Seus proponentes propuseram a EIP-8411 como substituição da 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 da ACDC #187 programa uma discussão de PFI da 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 a EIP-8411 em Hegotá havia sido registrada.
Os desenvolvedores têm restringido o conjunto de recursos de Hegotá em abstração de contas, escalabilidade, resistência à censura e outros trabalhos de protocolo. A EIP-8411 entrou nesse processo mais tarde do que muitas propostas e ainda precisa de uma decisão de inclusão dos desenvolvedores core.
A proposta de rede está ligada ao trabalho do Ethereum de aumentar a capacidade da Camada 1. Limites de gás maiores podem levar a cargas de execução maiores, aumentando a quantidade de dados que os validadores devem receber dentro de prazos de consenso fixos. O limite de gás do Ethereum atingiu 60 milhões no final de 2025 depois que os validadores sinalizaram apoio para o aumento.
Vitalik Buterin descreveu a maior capacidade da Camada 1, PeerDAS e o futuro trabalho com ZK-EVM como partes do plano de escalabilidade do Ethereum. A entrega mais rápida de cargas está sendo pesquisada juntamente com essas mudanças porque mensagens de rede maiores exercem mais pressão sobre a largura de banda dos nós e os prazos de propagação.
Os pesquisadores publicaram implementações de protótipo para Prysm e go-libp2p-pubsub. A variante recomendada — um branch do Prysm — contém uma série de mudanças por trás de uma flag `--enable-segmented-payload-gossip`, enquanto o branch libp2p que a acompanha implementa as políticas de encaminhamento e solicitaçã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 codificação de correção de erros, permanecem componentes experimentais do ambiente de teste e não são necessariamente parte da especificação mínima da EIP-8411.
Questões abertas identificadas pelos pesquisadores incluem o aumento do tráfego de mensagens de controle, custos de CPU devido ao processamento de muitas mensagens menores, mapeamentos alternativos de segmentos, gerenciamento de fila, ajuste de temporizadores e se uma pilha de rede mais recente focada em QUIC poderia produzir resultados diferentes.
Os autores planejam novas comparações entre o design de tópico único usado pela variante A, abordagens de mensagem parcial e modelos que atribuem tópicos de fofoca 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.
ETH