Besu v26.8.0
o que muda para quem roda um nó Ethereum
Besu v26.8.0
o que muda para quem roda um nó Ethereum
Lançada em 19 de agosto de 2026, a nova versão do cliente de execução em Java corrige falhas de exaustão de recursos no discovery e no snap sync, remove flags legadas e reorganiza a Plugin API. A recomendação oficial é atualizar o quanto antes.
01O essencial em 30 segundos
Besu é o cliente de execução Ethereum escrito em Java, mantido sob a Linux Foundation Decentralized Trust. A 26.8.0 é uma release de segurança: não muda regras de consenso, mas fecha dois vetores de exaustão de recursos que podiam derrubar nós expostos.
Atualize o quanto antes. As correções endereçam divulgações responsáveis da EF Security e de terceiros, e a configuração --discovery-mode=V4 — que é o padrão — estava exposta ao vetor de flood do DiscV4.
Pipeline de pacotes DiscV4 limitado
Máximo de 256 pacotes em voo; o excesso é descartado na entrada em vez de enfileirado sem limite. Elimina a exaustão de memória por flood na porta UDP de discovery.
Teto para requisições snap
Novos limites de concorrência por peer (8) e globais (200) para requisições GET_* do snap/1-2, evitando esgotamento de threads no EthScheduler.
Discovery, genesis e env vars
Sai a flag experimental --Xv5-discovery-enabled, sai a chave v5Bootnodes do genesis e sai o prefixo legado PANTHEON_ de variáveis de ambiente.
Checkpoint, logs JSON e IPv6
Nova opção --checkpoint para ancorar o snap sync, --logging-format com saídas estruturadas e suporte dual-stack IPv6 em DiscV4/RLPx.
02Correções de segurança
Duas classes de abuso de recursos por peer malicioso. Ambas exploráveis remotamente contra nós com portas P2P abertas, o que inclui a esmagadora maioria dos validadores e nós públicos.
1. Flood de pacotes DiscV4 (exaustão de memória)
- O pipeline de pacotes inbound passa a ser limitado a 256 pacotes em voo. Acima disso, os pacotes são descartados imediatamente na entrada, em vez de acumularem numa fila sem teto.
- Os descartes são contabilizados na métrica
discovery_packets_dropped_total— vale adicionar ao painel de monitoramento e alertar em picos. - O modo padrão
--discovery-mode=V4estava exposto: quem nunca mexeu nessa configuração estava vulnerável.
2. Requisições snap concorrentes (exaustão de threads)
- Novo limite por peer:
--Xsnapsync-server-max-concurrent-requests-per-peer, padrão 8. - Novo limite global:
--Xsnapsync-server-max-concurrent-requests, padrão 200. - Requisições recusadas recebem resposta vazia — comportamento previsto pelo protocolo, sem quebrar peers legítimos.
- Evita que um peer force a criação de threads nativas até derrubar o
EthScheduler.
O repositório do Besu publicou uma sequência de advisories de exaustão de recursos ao longo de agosto de 2026 — incluindo trabalho de bloco não limitado disparado por anúncios repetidos de NEW_BLOCK_HASHES/NEW_BLOCK, buffers de mensagens BFT limitados só por contagem e não por bytes, e estruturas de filtros e assinaturas WebSocket sem teto de memória. Consulte a página de security advisories do projeto para os IDs GHSA exatos e as faixas de versões afetadas antes de assumir que o seu nó está coberto.
03Breaking changes
Três mudanças exigem revisão da configuração antes de subir a nova versão. Uma delas falha em silêncio — que é o pior tipo.
| O que mudou | Detalhe | O que fazer |
|---|---|---|
Flag --Xv5-discovery-enabled removida |
O discovery agora é controlado apenas por --discovery-mode, com padrão V4. |
Se você dependia de DiscV5, passe a usar --discovery-mode=V5 ou BOTH explicitamente. |
Chave v5Bootnodes removida do genesis |
ENRs agora vão no array unificado bootnodes, junto com os enodes. Arquivos oficiais já foram migrados. |
Genesis customizado que ainda usar a chave antiga terá os ENRs silenciosamente ignorados. Migre manualmente. |
Prefixo PANTHEON_ removido |
Herança do nome original do projeto; agora só BESU_ é reconhecido. |
Varra seus docker-compose, systemd units, Helm charts e scripts de deploy atrás de variáveis PANTHEON_*. |
Rodar --discovery-mode=BOTH causa aumento perceptível de consumo de CPU. A correção está prevista para a próxima release (issue #11027). Em redes que dependem de DiscV5, prefira V5 puro até o patch sair.
04Deprecações — o que quebra depois
Nada aqui quebra hoje, mas tudo aqui quebra em alguma release futura. Trate como backlog de manutenção, não como aviso a ignorar.
| Item | Situação |
|---|---|
--min-block-occupancy-ratio | Depreciada; será removida. |
--Xmax-tracked-seen-txs-per-peer | Renomeada para --Xmax-tracked-seen-txs. O nome antigo segue como alias depreciado. |
xemptyblockperiodseconds (BFT) | Renomeada para emptyblockperiodseconds. |
--Xsnapsync-synchronizer-pivot-block-distance-before-caching | Convertida em no-op silencioso — aceita, mas não faz nada. |
--Xbft-legacy-protocol-encoding | Será removida quando a linha Besu 25.x chegar ao fim de vida. |
--rpc-tx-feecap 0 | Hoje 0 significa “sem limite”; passará a significar limite de fee igual a zero. Mudança de semântica silenciosa e perigosa. |
PluginTransactionSelectorFactory.create(SelectorsStateManager) | Marcada para remoção na Plugin API. |
--rpc-tx-feecap 0
É a única deprecação da lista que inverte o significado de um valor já existente em vez de renomear ou remover. Quem usa 0 como “ilimitado” precisa mudar a configuração antes da versão que aplicar a nova semântica, ou passará a rejeitar transações sem perceber.
05Novidades e melhorias
Além do endurecimento de segurança, a release traz ganhos reais de operabilidade — especialmente para quem roda Besu em infraestrutura com observabilidade centralizada.
--checkpoint
Formato <hash>:<número>:<totalDifficulty>. Ancora o snap sync a um checkpoint confiável, sobrescrevendo o do genesis. Ignorado em modo FULL.
--logging-format
Logs estruturados em JSON nos formatos ECS, GCP, LOGSTASH e GELF, além do PLAIN padrão. Elimina parsing frágil de log em texto puro.
Teto de passos EVM no tracing
Limite server-side de steps capturados em debug_trace* e trace_call. Protege nós RPC públicos de requisições de tracing abusivas.
Plugin API modularizada
Dividida em besu-plugin-api-core, -metrics, -permissioning e -security, com re-export via besu-plugin-api para manter compatibilidade.
IPv6 dual-stack
Suporte melhorado em DiscV4 e RLPx, com possibilidade de compartilhar a mesma porta e novas métricas de discovery e RLPx.
--p2p-tx-feecap
Equivalente P2P do fee cap de RPC: aplica validação de teto de fee também às transações recebidas pela rede, não só pelo endpoint JSON-RPC.
--graphql-max-blocks-range
Limite configurável de intervalo de blocos por consulta, padrão 5000. O rpc-max-logs-range também passou a valer para mais métodos de filtro.
Resíduos de Verkle removidos
O módulo Verkle trie, já descontinuado, teve o código residual retirado da base.
06Principais correções de bugs
A lista completa está no changelog; abaixo, as que mais afetam operação em produção.
- DNS discovery (EIP-1459): registros TXT com mais de 255 bytes voltaram a ser remontados corretamente — antes vinham truncados, quebrando listas de bootnodes baseadas em DNS.
- Deadlocks no sync: corrigidos em full sync e nos loops de retry do checkpoint sync; melhoria na fila e no retry de alvos de backward sync.
- Denylist de peers: peers com incompatibilidades permanentes passam a ser bloqueados em vez de reconectados indefinidamente.
- Tracers: ajustes no
prestateTracere nodiffMode, e melhor reporte de erro em traces de bloco e consultas GraphQL. - QBFT/IBFT pós-Merge: tratamento de terminal difficulty, conflitos de coordenador na migração IBFT2 → QBFT e disponibilidade de métodos JSON-RPC em redes migradas.
- Txpool com EIP-7702: correção no tratamento de delegações e rejeição de transações tipadas encapsuladas em RLP.
eth_getBlockByNumber("safe"/"finalized"): deixou de retornar Unknown block em nós com a cadeia completa mas sem peers.admin_nodeInfo: correção no mapeamento de portas com NAT; e recuperação de restart no heal sync do FlatDB.- DiscV5: timeout elevado de 30 para 60 segundos.
07Como atualizar
Os binários estão publicados no GitHub com hashes SHA, e a imagem Docker já está disponível para amd64 e arm64.
# Docker — versão fixada (recomendado em produção) docker pull hyperledger/besu:26.8.0 # Verificação dos binários publicados besu-26.8.0.zip sha256 d19de7996560d522016927dbe232cbc68ab479f1ab064eecec2ee363c86a7c10 besu-26.8.0.tar.gz sha256 4f80f17b129ac970135263f3aa8a5c290366aec50c50bbcdadda0af127dd5540
Checklist antes de subir
- Varra a configuração de discovery. Se havia
--Xv5-discovery-enabledem qualquer lugar, o nó não sobe. Substitua por--discovery-mode. - Audite o genesis customizado. Se ainda tiver
v5Bootnodes, mova os ENRs para o arraybootnodes— a falha aqui é silenciosa, não gera erro. - Procure variáveis
PANTHEON_*. Em compose files, unidades systemd, Helm charts, Ansible e pipelines de CI. - Confirme a semântica de
--rpc-tx-feecap. Se usa0como “sem limite”, planeje a troca agora. - Suba primeiro em um nó não crítico e observe
discovery_packets_dropped_total, uso de CPU e contagem de peers por pelo menos uma janela de algumas horas. - Se usa DiscV5, fique em
V5puro em vez deBOTHaté o patch de CPU da próxima release. - Se mantém plugins, revise as dependências contra os novos artifacts modulares e os métodos de factory marcados para remoção.
A release é classificada como de impacto baixo: não há mudança de regra de consenso nem hard fork associado. O risco real do upgrade está na configuração — flags removidas e genesis não migrado —, não no comportamento em cadeia.
08Onde isso se encaixa na rede
Uma release de cliente não é uma atualização de protocolo. Vale separar as duas coisas — sobretudo em um ano em que a Ethereum tem uma bifurcação relevante no horizonte.
Fusaka ativada em mainnet
Trouxe PeerDAS e a expansão de disponibilidade de dados de blobs — a linha de continuidade do trabalho de escalabilidade via camada de dados.
Besu 26.8.0
Release de manutenção e segurança de um dos clientes de execução. Não altera regras de consenso; endurece o nó contra abuso de recursos e limpa configuração legada.
Glamsterdam
Sucessora da Fusaka, com dois headliners: EIP-7732 (ePBS, separação proposer-builder incorporada ao protocolo) e EIP-7928 (Block-Level Access Lists, que mapeiam o estado tocado por bloco e abrem caminho para leitura de disco e validação de transações em paralelo). As datas discutidas ao longo de 2026 foram descritas pelos próprios acompanhantes do processo como aspiracionais e dependentes da maturidade das devnets — confirme o cronograma vigente antes de planejar janelas de manutenção.
Em qualquer bifurcação, nós de execução e de consenso precisam estar atualizados antes da ativação, sob pena de saírem da cadeia canônica. Manter a cadência de releases de segurança reduz o tamanho do salto quando a atualização de protocolo chegar — e o custo de operar um nó desatualizado nesse momento é bem maior do que o de um upgrade de rotina.