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

A BNB Chain está se preparando para outra grande atualização, e desta vez o foco não é apenas na velocidade da rede, mas em quão bem ela consegue se sustentar quando usuários reais começarem a utilizá-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 usuários 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 traz mudanças como um limite de gás de transação a nível de protocolo sob o BEP-652, além de correções relacionadas a blobs e à execução na versão da rede principal.

Esse timing é importante 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 longe, para blocos de 0,75 segundos, enquanto a bifurcação Fermi mais recentemente levou o BSC a cerca de 0,45 segundos e enfatizou um desempenho previsível sob uso crescente da rede. Juntas, essas atualizações transformaram a BNB Chain em uma das redes EVM mais rápidas, mas também aumentaram a importância da estabilidade, consistência de gás e qualidade de 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 fortalecer o comportamento da cadeia sob pressão. Isso significa menos surpresas durante congestionamentos, 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. Em uma rede que já opera em velocidade abaixo de 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.

Buscando 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 usuários casuais percebem de imediato, mas é exatamente o tipo de regra que ajuda uma cadeia a permanecer 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, ao invés 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 Osaka inclui o EIP-7823 para limites superiores em MODEXP, EIP-7825 para limites de gás de transação, EIP-7883 para aumentos no custo de gás do ModExp, EIP-7918 para limitar as taxas base de blobs pelo custo de execução, EIP-7934 para limites de tamanho de bloco de execução, EIP-7939 para o opcode CLZ e EIP-7951 para suporte à curva secp256r1. Na prática, 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 ficam fora do stack padrão do Ethereum.

Essa questão da criptografia é especialmente importante para desenvolvedores que constroem infraestrutura que precisa se comunicar com mais de um ecossistema. O suporte ao 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 ponte entre modelos de segurança onchain e offchain. O opcode CLZ é uma adição que a maioria dos usuários provavelmente nunca verá, mas os desenvolvedores podem usá-lo para tornar a execução mais eficiente na nível de bytecode, 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 por número de 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 confirmações permaneçam rápidas, confiáveis e resistentes à 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, por fim, para 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 glamouroso, mas muitas vezes mais importante, de garantir que a velocidade realmente sobreviva à demanda do mundo real, cálculos pesados e aos casos de uso complexos que surgem uma vez que 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 manter o momentum, mas também de refinar o propósito. A BNB Chain ainda está se movendo rapidamente, mas desta vez ela 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 pode ficar mais rápida do que antes. Será se ela consegue manter essa velocidade sem fazer os desenvolvedores ou usuários pagarem por esse privilégio.