USD
Prioridades da Hegotá no Ethereum colocam FOCIL em 1º enquanto avançam privacidade e RowDAS
Ranking do protocolo define prioridades da fork, enquanto custos de validação de privacidade e recuperação de blobs seguem como áreas ativas de pesquisa
TL;DR
- O Protocol Cluster do Ethereum publicou seu primeiro ranking unificado de propostas para a Hegotá, com o FOCIL surgindo como a principal prioridade da camada de consenso da fork.
- Espera-se que o trabalho de privacidade comece com a Hegotá, mas os limites atuais de validação da EIP-8141 seguem abaixo dos custos de prova medidos para transações de privacidade estudadas.
- Um design reduzido de RowDAS diminuiu drasticamente o trabalho de CPU simulado na reconstrução de blobs, mas ainda não entrega os recursos de resiliência planejados para o RowDAS completo.
Negocie com mais inteligência na Jupiter, a principal DEX da Solana, feita para execução rápida e liquidez profunda.
Faça swap de tokens com taxas competitivas, roteie automaticamente por múltiplas fontes de liquidez e acesse perpétuos, DCA e ferramentas avançadas de trading — tudo em um só lugar!
Ethereum’s Protocol Cluster classificou todas as 62 EIPs propostas para a Hegotá, colocando o FOCIL no topo das prioridades da fork, enquanto trabalhos separados sobre transações de privacidade e recuperação de blobs mostram tanto progresso quanto restrições técnicas ainda não resolvidas. O ranking unificado, publicado em 7 de setembro de 2026, marca a primeira vez que o Protocol Cluster apresenta uma visão única para toda a fork, em vez de deixar que equipes individuais publiquem posições separadas.
O sistema de níveis atribui a cada categoria um significado específico de entrega. Uma nota S significa que uma proposta define a fork e que o cronograma deve avançar antes que seu escopo seja sacrificado. Uma nota A sinaliza a expectativa de que o recurso será entregue e só pode ser removido após o trabalho de nível S estar seguro. Propostas de nível B são avaliadas individualmente e, em geral, exigem um protótipo, aprovação e especificação definida. Propostas de nível C ficam abaixo da linha principal de inclusão sem serem desqualificadas, enquanto DFI significa “recusado para inclusão”. Uma categoria separada TBD cobre propostas que aguardam dados adicionais da mainnet.
Apenas o FOCIL, EIP-7805, recebeu uma nota S sem ressalvas. A proposta pretende permitir que qualquer pessoa tenha uma transação elegível incluída sem depender de block builders centralizados, tornando-se o compromisso mais claro do ranking na camada de consenso. O FOCIL também recebeu nota máxima unânime com participação completa.
O processo de pontuação envolveu cerca de 60 pesquisadores e engenheiros trabalhando em nove equipes, ao lado de especialistas individuais por domínio. Contribuidores enviaram 16 templates de contribuição, com 12 fornecendo notas de nível de fato. Alguns participantes limitaram sua pontuação a propostas dentro de suas áreas de especialidade.
No total, os contribuidores produziram 397 notas, ou uma média de 6,4 por EIP, enquanto as propostas mais disputadas receberam até nove notas cada. Os contribuidores pontuaram de forma independente, e o Protocol Cluster disse que o Geth, como um client da camada de execução, ainda publicará sua própria lista independente.
Hegotá se conecta ao roadmap de privacidade e pós-quântica do Ethereum
O ranking da Hegotá também se encaixa em um plano de longo prazo para tornar a camada base do Ethereum resistente a quântica em execução, consenso e dados até dezembro de 2029. Esse objetivo se alinha aos cronogramas de migração estabelecidos de forma independente por Google, Cloudflare e Microsoft.
A Foundation está se planejando em torno de um hipotético “Q-day” em 2030 e caracteriza essa suposição como deliberadamente agressiva, porque estimativas críveis colocam computadores quânticos capazes de quebrar criptografia mais adiante no futuro, se é que eles chegam a existir. Ainda assim, o Ethereum pretende tratar seu prazo autoimposto como inegociável até uma reavaliação em janeiro de 2027 com especialistas externos.
Supondo que Glamsterdam seja lançada em dezembro de 2026, o Ethereum precisaria manter um ritmo médio de 7,2 meses por fork até uma quinta atualização futura, chamada de L*. A pesquisa do protocolo está atualmente organizada em cinco arcos sobrepostos: finality rápida, pós-quântica, privacidade, state e zkEVM.
Espera-se que o trabalho de privacidade comece durante a Hegotá, em vez de esperar por uma fork pós-quântica posterior. O Protocol Cluster afirmou: “Acreditamos que esse trabalho deve começar na Hegota para entregar transações privadas nativas, trustless e resistentes à censura no Ethereum L1.”
A sequência do Protocol Cluster prevê primeiro o trabalho de privacidade nativa e, depois, privacidade pós-quântica em escala. A própria Hegotá não é apresentada como a fork pós-quântica final; em vez disso, espera-se que influencie a velocidade com que o Ethereum atinge esse marco. As equipes de clients poderiam, de forma realista, iniciar a implementação da Hegotá no fim do Q4 de 2026.
Proposta de privacidade EIP-8141 enfrenta um gap no orçamento de validação
Uma questão separada de privacidade gira em torno da EIP-8141, o design proposto de transações Frames do Ethereum. Uma mudança enviada em 5 de setembro de 2026 pelo contribuidor AnkushinDaniil permitiria que nodes individuais aceitem transações que excedam a cota de validação pública compartilhada, embora isso não exigisse que a rede pública mais ampla retransmitisse essas transações. A mudança proposta segue em análise.
A modificação transformaria o máximo atual de validação em um piso obrigatório comum. Os nodes ainda teriam de propagar transações qualificadas que caibam dentro desse orçamento compartilhado, enquanto nodes com maior capacidade poderiam aceitar localmente transações mais caras.
Essa distinção importa para os designs do Tornado Cash e do RAILGUN analisados em um benchmark de privacidade. Substituir relayers off-chain por submissão pública comum exige provas de privacidade que os nodes aceitem e encaminhem pela rede pública. Uma transação aceita apenas por nodes mais capazes não teria essa garantia de propagação em toda a rede.
O rascunho atual da EIP-8141 limita checagens de assinatura e execução, da validação inicial até a aprovação de pagamento, a 100,000 gas. Gas, nesse contexto, mede trabalho computacional, e o limite visa restringir a carga de trabalho dos nodes e a exposição a ataques de negação de serviço.
Um benchmark publicado por mmjahanara em 2 de setembro de 2026 constatou que um verificador de prova Groth16 otimizado excedeu essa cota antes mesmo de incluir o custo total da transação modelada.
A contabilização do benchmark difere do rascunho companheiro atual da EIP-8250. A EIP-8250 cobra novas chaves de nonce contra state gas, um orçamento separado, em vez de execution gas. Assim, os totais do benchmark representam seu próprio modelo, e não custos verificados sob as propostas combinadas mais recentes, embora essa diferença de contabilização não elimine o gap de custo de execução reportado do verificador Groth16.
A cota recomendada também ficaria abaixo da transação modelada de eight-note. O benchmark assume que aplicações fariam mudanças adicionais, incluindo mover trabalho não relacionado à verificação para frames posteriores, otimizar verificadores e comprimir entradas de prova. A opção de compressão SHA-256 reduz requisitos de entrada on-chain, enquanto aumenta o trabalho de geração de prova nos dispositivos dos usuários.
Uma cota de validação maior resolveria apenas uma restrição. EIP-8250 também preserva uma transação pendente por remetente no mempool público, o que cria outra limitação para designs de privacidade que compartilham um endereço.
A propagação pública é separada da validade do bloco nas propostas. A EIP-8141 permite que transações fora de suas regras públicas compartilhadas entrem em mempools locais ou privados. A EIP-8369 descreve, separadamente, regras futuras para impor inclusão de transações, incluindo submissões customizadas ou diretas, mas exige uma extensão de protocolo vinculante.
O trade-off prático, portanto, é entre acomodar provas de privacidade caras e limitar o trabalho computacional que transações recebidas podem impor aos nodes. A mudança proposta na EIP-8141 daria flexibilidade adicional em nodes individuais, enquanto o acesso público garantido para os designs de privacidade estudados ainda exigiria uma cota em toda a rede capaz de suportar seus custos de validação de prova.
Design reduzido de RowDAS corta trabalho duplicado na recuperação de blobs
Pesquisadores do Ethereum também estão testando um caminho de implementação menor rumo ao RowDAS, focando primeiro em reduzir a computação duplicada na recuperação de blobs. O pesquisador Csaba Kiraly publicou os resultados em 3 de setembro de 2026, apresentando o design reduzido como um possível primeiro passo rumo ao RowDAS completo.
O protótipo reportou uma redução estimada de 11–18× no trabalho computacional de reconstrução em simulações com 1,000 nodes. Em vez de permitir que múltiplos nodes capazes reconstruam de forma independente os mesmos dados de blob ausentes, o design atribui blobs específicos a nodes de recuperação designados primeiro e permite que outros nodes obtenham as células reconstruídas por meio de canais de distribuição existentes.
Blobs carregam dados usados por rollups de camada 2. Sob o PeerDAS, nodes podem baixar apenas parte dos dados. Nodes de alta custódia retêm pelo menos 64 de 128 colunas de dados, o suficiente para reconstruir dados de blob ausentes, enquanto supernodes retêm todas as 128.
Reconstruções repetidas por múltiplos nodes de alta custódia podem gerar trabalho duplicado de processador. O design reduzido tenta suprimir essa duplicação, mantendo disponível um caminho de recuperação atrasado por alta custódia para dados que continuem ausentes.
As simulações produziram as seguintes estimativas de reconstrução em toda a rede:
Os totais de CPU-seconds medem o trabalho computacional acumulado na rede simulada, e não o tempo decorrido de recuperação. A contabilização usa um custo medido de 162 milissegundos por recuperação de blob em um processador AMD Ryzen 9 8945HS. Velocidade de transação e economia de taxas ficaram fora das medições.
O PeerDAS também recebeu crédito por controles de duplicação existentes na comparação. Sua linha de base modelada já inclui espera aleatória e checagens que podem evitar reconstrução desnecessária, em vez de assumir que todo node capaz executa imediatamente o mesmo trabalho.
O design reduzido distribui células recuperadas por canais existentes de distribuição de colunas e mantém nodes de alta custódia como um backstop atrasado. Essa abordagem evita adicionar imediatamente os novos canais de rede por linha previstos pelo RowDAS completo.
O rascunho da EIP-8371 iria além. O RowDAS completo criaria canais de linha que permitem que nodes menores façam pool de seus dados e reconstruam coletivamente informações assim que a informação combinada atingir o limiar de recuperação. O design reduzido mantém a dependência atual de nodes de alta custódia e, portanto, não oferece essa resiliência adicional.
As medições seguem sendo resultados de simulação produzidos por redes in-process usando criptografia real, e Kiraly não reportou resultados em devnet. A configuração proposta do RowDAS completo com 128 subnets de linhas também segue como uma extrapolação a partir de contagens menores de subnets, com simulações maiores e testes em rede real ainda por vir.
A EIP-8371 mantém inalterados os limites de blobs do Ethereum. A separação proposta entre atribuição de dever de recuperação e posterior rede por linhas também ainda não foi incorporada ao rascunho. Assim, o trabalho imediato se concentra em reduzir a demanda de processador relacionada à recuperação, enquanto as melhorias mais amplas de resiliência dependem da camada completa de rede por linhas.
Este artigo foi refinado e aprimorado pelo ChatGPT.
