BNB Chain ativa hard fork Pasteur em 25 de agosto para reforçar segurança e elevar capacidade

A BNB Chain vai ativar o hard fork "Pasteur" na BNB Smart Chain (BSC) às 02:30 UTC de 25 de agosto de 2026. A atualização é obrigatória e exige o client v1.7.7. O pacote inclui três propostas no nível de protocolo para endurecer a segurança de bridges, reduzir brechas ligadas a validadores e aumentar a capacidade de processamento de blocos. Todos os nós do mainnet da BSC precisam estar no novo client antes da ativação. Para usuários comuns e para a maioria dos desenvolvedores de dApps, não é necessário mover fundos nem alterar softwares. Principais mudanças BEP-682 — verificação mais robusta entre cadeias A BSC passará a validar assinaturas de validadores antes de aceitar dados de blocos vindos de outra cadeia. A atualização também impede conjuntos de validadores construídos para "duplicar" o peso de voto de um mesmo validador: entradas repetidas serão rejeitadas, fazendo com que o limiar de votação reflita de fato uma supermaioria. BEP-695 — reforço de chaves de consenso e governança Na rotação de chaves de consenso, a chave antiga perde privilégios administrativos e não mantém autoridade após a troca. Eventos de slash/eviction pendentes passam a acompanhar o validador na nova chave, reduzindo tentativas de escapar de penalidades por troca de chave. A proposta também impede que endereços em blacklist contornem restrições por meio de votação de governança baseada em assinatura. As mudanças alcançam os contratos de sistema de staking e governança, mas são implementadas no nível de protocolo/contratos de sistema, sem exigir migração de aplicações existentes. BEP-675 — caminho mais rápido para blocos pré-executados (builders) Builders poderão enviar blocos já executados. Validadores poderão assinar e propagar esses blocos rapidamente e concluir a verificação completa fora do caminho crítico de produção. Para usar essa opção, builders precisam operar nós completos, pois serão responsáveis por produzir blocos totalmente executados. Lances legados de blocos continuam existindo, mas com menos tempo para preenchimento de blocos para os builders. Resultados de testes no QANet A BNB Chain testou o Pasteur no QANet, ambiente interno que espelha a configuração de validadores cross-region da BSC, e observou ganhos relevantes em cenário controlado: - Tempo de processamento no caminho crítico caiu de 125 ms para 15 ms. - Gas médio por bloco subiu de 46,35M para 84,15M (contra o limite atual de 100M). - Throughput aumentou de ~1.237 para ~2.324 transações por segundo. - Intervalo de bloco permaneceu em 450 ms e a latência de finalização não mudou. A BNB Chain ressalta que os números são de laboratório (QANet) e que melhorias equivalentes no mainnet ainda não estão confirmadas. Após a ativação, operadores e desenvolvedores devem acompanhar quanto dos ganhos se sustenta sob tráfego real. Checklist obrigatório para operadores de nó - Instalar o client v1.7.7 antes do horário de ativação; nós do mainnet que não atualizarem ficarão para trás. - Remover "[Eth] EnableBAL" do arquivo config.toml; manter essa configuração fará o client atualizado falhar na inicialização. - Recomenda-se remover "[TxPool] OverflowPoolSlots" (se permanecer, o client vai ignorar silenciosamente o campo). - Algumas flags de linha de comando ficaram obsoletas ou inativas, incluindo "journalfile", "enablebal" e "txpool.overflowpoolslots". Contexto O foco do Pasteur difere de upgrades recentes da BSC que priorizaram reduzir o tempo de bloco. Desta vez, o objetivo é aproveitar melhor a capacidade atual dos blocos e fechar lacunas de segurança em transferências cross-chain e na autoridade de validadores. O Pasteur está em execução no testnet da BSC desde 21 de julho; a chegada ao mainnet será o teste decisivo para verificar se os ganhos de capacidade e throughput vistos no QANet se confirmam em condições reais. Para quem opera nós, valida ou constrói no nível de protocolo: atualize para o client v1.7.7 e aplique as orientações de configuração antes de 02:30 UTC de 25 de agosto para evitar interrupções. Usuários comuns e a maioria dos desenvolvedores de apps não devem precisar agir.