A BNB Chain prepara a atualização Osaka/Mendel para melhorar a execução e a finalização

A BNB Chain está a caminho de outra grande atualização, e desta vez o foco não está em quão mais rápido a rede pode ficar, mas em quão bem ela consegue resistir quando utilizadores reais começam a pressioná-la intensamente. A bifurcação dura Osaka/Mendel está agendada para 28 de abril de 2026, às 02h30 UTC, e as próprias notas de lançamento da BNB Chain afirmam que a atualização da rede principal é obrigatória para os utilizadores do BSC, com a versão 1.7.2 listada como a versão necessária antes da bifurcação. A atualização inclui nove BEPs e incorpora mudanças como um limite de gás de transação a nível de protocolo sob o BEP-652, juntamente com correções relacionadas a blobs e à execução na versão da rede principal.

Esse timing importa porque a BNB Chain passou o último ano perseguindo agressivamente a velocidade. A bifurcação dura Lorentz reduziu o tempo de bloco de 3 segundos para 1,5 segundos, preparando o terreno para confirmações mais rápidas e uma sincronização mais forte dos validadores. Maxwell então levou o BSC ainda mais abaixo, para 0,75 segundos por bloco, enquanto a bifurcação dura Fermi levou recentemente o BSC a cerca de 0,45 segundos e enfatizou um desempenho previsível sob o aumento do uso da rede. Juntas, essas atualizações transformaram a BNB Chain numa das redes EVM mais rápidas, mas também aumentaram a importância da estabilidade, da consistência do gás e da qualidade da execução.

Osaka/Mendel parece ser o próximo passo nessa história, mas com uma ênfase diferente. Em vez de tentar reduzir ainda mais a produção de blocos, a bifurcação visa reforçar o comportamento da cadeia sob pressão. Isso significa menos surpresas durante congestionamentos, um comportamento de gás mais previsível e uma experiência mais limpa para os desenvolvedores que precisam modelar como as transações realmente irão se comportar em condições reais. Numa rede que já opera a velocidades inferiores a um segundo, a diferença entre uma cadeia que é apenas rápida e uma que é rápida e consistente torna-se muito mais visível.

Visando Refinar o Desempenho da Rede

Uma das mudanças mais claras na documentação do Mendel é a introdução de um limite de gás por transação a nível de protocolo através do BEP-652, que implementa o EIP-7825 e rejeita transações acima de 16.777.216 de gás durante a validação. Essa não é uma mudança que utilizadores casuais percebem de imediato, mas é exatamente o tipo de regra que ajuda uma cadeia a manter-se estável quando há picos de atividade. Ao estabelecer limites rígidos para transações pesadas, a BNB Chain tenta manter a execução previsível, em vez de permitir que cargas de trabalho atípicas distorçam o processamento de blocos.

O lado Osaka da atualização também traz várias mudanças de execução alinhadas ao Ethereum que apontam na mesma direção. No changelog do BSC, a sincronização do código do Osaka inclui o EIP-7823 para limites superiores em MODEXP, o EIP-7825 para limites de gás de transação, o EIP-7883 para aumentos no custo de gás do ModExp, o EIP-7918 para limitar as taxas base de blobs pelo custo de execução, o EIP-7934 para limites de tamanho de bloco de execução, o EIP-7939 para o opcode CLZ, e o EIP-7951 para suporte à curva secp256r1. Em termos práticos, isso significa regras de execução mais precisas, cálculos de baixo nível mais eficientes e melhor compatibilidade com padrões criptográficos que estão fora do stack usual do Ethereum.

Essa questão da criptografia é especialmente importante para desenvolvedores que constroem infraestruturas que precisam comunicar-se com mais de um ecossistema. O suporte à secp256r1 facilita a conexão com sistemas que dependem de padrões diferentes da curva padrão do Ethereum, o que pode ser relevante para fluxos de autenticação, integrações empresariais e aplicações que precisam fazer a ponte entre modelos de segurança onchain e offchain. O opcode CLZ é uma adição que a maioria dos utilizadores provavelmente nunca verá, mas os desenvolvedores podem usá-lo para tornar a execução mais eficiente ao nível do bytecode, que é exatamente onde pequenas otimizações começam a fazer diferença uma vez que a rede já está operando rapidamente.

As notas de lançamento do Mendel também mostram que a BNB Chain está prestando muita atenção ao comportamento relacionado a blobs e à finalização rápida. O changelog inclui suporte à validação de blobs sidecar para lances, enquanto notas anteriores do testnet Osaka/Mendel mostram o BEP-657 para limitar a inclusão de transações de blobs pelo número do bloco e o BEP-655 para verificações de tamanho de bloco. Notas separadas da BNB Chain também fazem referência ao BEP-648, descrito como uma finalização rápida aprimorada via um pool de votação na memória. Juntos, esses ajustes sugerem que a bifurcação trata de mais do que apenas throughput. Trata-se de garantir que as confirmações permaneçam rápidas, confiáveis e resilientes à medida que o uso aumenta.

Há também uma mensagem estratégica mais ampla na bifurcação. A BNB Chain já provou que consegue passar de blocos de 3 segundos para 1,5 segundos, depois para 0,75 segundos, e finalmente atingir a meta de 0,45 segundos do Fermi. Osaka/Mendel sugere que a cadeia agora está mudando de ganhos brutos de velocidade para maturidade. Em outras palavras, a rede já venceu a corrida de manchetes. O que vem a seguir é o trabalho menos glamoroso, mas muitas vezes mais importante, de garantir que a velocidade realmente sobreviva à demanda do mundo real, a computação pesada e aos casos de uso complexos que surgem quando uma blockchain é utilizada por milhões, e não apenas medida em laboratório.

Por isso, Osaka/Mendel parece ser significativo mesmo que não venha acompanhado de um novo recorde dramático de velocidade. Trata-se de uma manutenção do momentum, mas também de um refinamento de propósito. A BNB Chain ainda está a avançar rapidamente, mas desta vez tenta garantir que a velocidade venha acompanhada de disciplina. Se a atualização ocorrer conforme planejado em 28 de abril, o verdadeiro teste não será se a BNB Chain consegue ser mais rápida do que antes. Será se ela consegue manter essa velocidade sem fazer os desenvolvedores ou utilizadores pagarem por esse privilégio.