O cliente Reth da $BNB Chain ganhou um número que pode facilmente ser confundido com uma «aceleração já concretizada»: em 6 de novembro, a BNB Chain revelou que a configuração Reth 2.5.1 apresentou, em testes internos, um throughput cerca de 40% superior ao da configuração TrieDB anterior. Mas isso não representa um aumento do throughput de toda a cadeia em comparação com o Geth atualmente em produção, e a migração dos validadores está apenas prevista para começar no final de 2026.
Um conjunto anterior de benchmarks ajuda a entender melhor a controvérsia. A latência p95 de inserção de blocos do BSC-Reth foi de 71,6 milissegundos, abaixo dos 110 milissegundos do BSC-Geth; já a latência p95 de validação foi de 11,2 milissegundos, acima dos 9,05 milissegundos do Geth. Sincronização e execução mais rápidas não significam que o cálculo da raiz de estado, a persistência e o agendamento possam ser concluídos sem dificuldades dentro do intervalo de cerca de 0,45 segundo entre blocos na BSC. O artigo oficial também reconhece que, devido a esses gargalos, ainda serão necessários ajustes no cache, na pré-busca e no agendamento da construção de blocos.
A $ETH serve aqui de referência técnica: o Reth foi originalmente desenvolvido para a camada de execução do Ethereum, e a BSC aproveitou sua arquitetura, mas enfrenta uma escala de estado e um ritmo de produção de blocos diferentes. Portanto, não se pode simplesmente aplicar à BSC as mesmas proporções de otimização obtidas no Ethereum. A $CAKE representa o lado do uso em aplicações de negociação on-chain; apenas quando o desempenho dos nós se traduzir de forma consistente em confirmações de transações e custos mais favoráveis nos períodos de pico é que o avanço da infraestrutura poderá ter relevância prática para esse tipo de aplicação — e, naturalmente, isso não se converterá automaticamente em receita para a CAKE.
O que mais me interessa é o desempenho após a migração: produção contínua de blocos, blocos perdidos e comportamento sob carga elevada, e não uma única pontuação de benchmark. Os valores p95 e o aumento de 40% citados acima vêm de testes realizados em etapas diferentes, publicados no blog técnico da BNB Chain; não se devem combinar esses benchmarks. Aviso de risco: os testes internos de desempenho e os planos de implementação futura não garantem o desempenho na mainnet nem retornos com tokens.
Um conjunto anterior de benchmarks ajuda a entender melhor a controvérsia. A latência p95 de inserção de blocos do BSC-Reth foi de 71,6 milissegundos, abaixo dos 110 milissegundos do BSC-Geth; já a latência p95 de validação foi de 11,2 milissegundos, acima dos 9,05 milissegundos do Geth. Sincronização e execução mais rápidas não significam que o cálculo da raiz de estado, a persistência e o agendamento possam ser concluídos sem dificuldades dentro do intervalo de cerca de 0,45 segundo entre blocos na BSC. O artigo oficial também reconhece que, devido a esses gargalos, ainda serão necessários ajustes no cache, na pré-busca e no agendamento da construção de blocos.
A $ETH serve aqui de referência técnica: o Reth foi originalmente desenvolvido para a camada de execução do Ethereum, e a BSC aproveitou sua arquitetura, mas enfrenta uma escala de estado e um ritmo de produção de blocos diferentes. Portanto, não se pode simplesmente aplicar à BSC as mesmas proporções de otimização obtidas no Ethereum. A $CAKE representa o lado do uso em aplicações de negociação on-chain; apenas quando o desempenho dos nós se traduzir de forma consistente em confirmações de transações e custos mais favoráveis nos períodos de pico é que o avanço da infraestrutura poderá ter relevância prática para esse tipo de aplicação — e, naturalmente, isso não se converterá automaticamente em receita para a CAKE.
O que mais me interessa é o desempenho após a migração: produção contínua de blocos, blocos perdidos e comportamento sob carga elevada, e não uma única pontuação de benchmark. Os valores p95 e o aumento de 40% citados acima vêm de testes realizados em etapas diferentes, publicados no blog técnico da BNB Chain; não se devem combinar esses benchmarks. Aviso de risco: os testes internos de desempenho e os planos de implementação futura não garantem o desempenho na mainnet nem retornos com tokens.
