A BNB Chain ativou o hard fork Pasteur na mainnet da BNB Smart Chain às 02:30 UTC de 25 de agosto, introduzindo três mudanças focadas na segurança da ponte, autorização de validadores e capacidade de bloco.
A rede confirmou que o Pasteur estava ativo após sua ativação programada. A BSC continuou a produzir blocos em seu intervalo existente de 450 milissegundos, sem grandes interrupções relatadas publicamente imediatamente após a atualização.
O Pasteur combina BEP-682, BEP-695 e BEP-675 sob o plano de atualização mais amplo BEP-673. As mudanças operaram na testnet Chapel da BSC desde 21 de julho antes de chegar à mainnet.
O BEP-682 muda a forma como a BSC verifica os light blocks submetidos através da infraestrutura cross-chain. Antes do Pasteur, o processo de verificação não rejeitava explicitamente entradas duplicadas em uma lista de validadores submetida.
Uma requisição elaborada poderia, portanto, incluir o mesmo validador mais de uma vez. Contar essas entradas separadamente corria o risco de fazer com que uma aprovação de ponte parecesse ter o suporte de mais validadores independentes do que realmente tinha.
O Pasteur rejeita entradas de validadores repetidas antes de calcular se o limiar de votação exigido foi alcançado. Cada aprovação agora deve vir de um validador distinto para que o light block satisfaça o requisito de supermaioria.
A BNB Chain não relatou que atacantes exploraram a falha ou atribuiu a ela qualquer perda de ativos anterior. A mudança é uma correção preventiva para a verificação de pontes, em vez de uma resposta a um roubo divulgado.
A infraestrutura cross-chain continua sendo uma grande preocupação de segurança em redes descentralizadas. Em cobertura relacionada, ataques a pontes causaram bilhões de dólares em perdas cumulativas através de chaves comprometidas, falhas de contrato e verificação fraca de mensagens.
O BEP-695 fecha lacunas envolvendo a rotação de chaves de validadores, penalidades e governança. Quando um validador substitui sua chave de operador, a chave anterior agora perde seus direitos de gerenciamento.
A proposta também impede que os validadores escapem de penalidades pendentes ao girar suas chaves. Os processos de slashing e remoção permanecem ligados ao validador, em vez de desaparecerem quando seu endereço de operador muda.
O Pasteur ainda bloqueia endereços restritos de usar assinaturas offchain para participar da governança. A BNB Chain já impedia endereços na lista negra de votar diretamente, mas essas contas poderiam potencialmente assinar votos e ter outro endereço para submetê-los.
Os contratos de governança atualizados verificam o signatário original antes de contar um voto delegado. Se esse signatário for restrito, o voto é rejeitado, independentemente de qual conta o submeta.
O BEP-675 introduz uma rota opcional para construtores especializados submeterem blocos que já executaram. Os validadores verificam o bloco proposto em relação às regras de consenso, assinam-no e o transmitem antes de completar a verificação completa da execução.
A rota anterior exigia que tanto o construtor quanto o validador executassem as transações antes que o validador assinasse. Essa duplicação consumia parte da curta janela de bloco da BSC e poderia deixar blocos abaixo de sua capacidade máxima durante períodos de alta demanda.
Os construtores podem continuar usando o processo anterior. A nova rota deve ser habilitada através da interface de chamada de procedimento remoto da rede, dando aos participantes tempo para integrá-la.
A BNB Chain disse que a rota poderia acomodar mais transações em cada bloco, mas seus números de desempenho publicados vieram de testes controlados, e não da atividade da mainnet.
Testes na QANet, um ambiente interno projetado para refletir validadores geograficamente distribuídos, aumentaram o rendimento de 1.237 para 2.324 transações por segundo. O consumo médio de gás por bloco aumentou de 46,35 milhões para 84,15 milhões, enquanto o limite de gás de 100 milhões permaneceu inalterado.
O Pasteur não aumenta o limite de gás do bloco nem reduz o intervalo de bloco de 450 milissegundos introduzido pela atualização Fermi. Seus ganhos de capacidade dependem de os construtores adotarem o BEP-675 e submeterem blocos mais completos.
A BNB Chain exigiu que os operadores de nós instalassem a versão 1.7.7 do cliente antes da ativação. Os operadores também precisavam remover o campo EnableBAL obsoleto porque deixá-lo no arquivo de configuração impediria o cliente atualizado de iniciar.
Conforme relatado anteriormente, a BNB Chain alertou os operadores para completarem a atualização obrigatória do Pasteur antes do fork. Operadores que usassem software incompatível corriam o risco de sair de sincronia com a mainnet.
A próxima evidência virá da utilização de blocos em tempo real, rendimento de transações, taxas de blocos perdidos e desempenho de validadores. Essas medições mostrarão se a melhoria de capacidade da QANet se traduz em demanda sustentada na mainnet.
BNB