O Bitcoin Core v32.0rc1 abriu uma janela concentrada de testes para operadores de nós, provedores de carteiras e serviços que usam RPCs. A tag assinada da versão candidata recebeu verificação em 14 de setembro. Enquanto isso, o cronograma prevê 10 de outubro como meta para a tag final do v32.0. Até lá, as equipes poderão avaliar possíveis incompatibilidades antes do lançamento definitivo.

O intervalo entre as duas datas soma 26 dias. Uma previsão anterior indicava 10 de setembro como meta para o RC1. Contudo, o cronograma atualizado passou a apontar 14 de setembro, uma diferença de quatro dias que não confirma o descumprimento de um prazo inalterado.

Versão candidata concentra testes de compatibilidade

A tag v32.0rc1 identifica um software de pré-lançamento, e não uma atualização final para ambientes de produção. Além disso, a versão não ativa novas regras de consenso. Uma mudança ligada ao rascunho do BIP 323 modifica o tratamento de bits de sinalização e avisos sobre implantações desconhecidas. A proposta, porém, continua com o status Draft.

Os operadores podem seguir o padrão descrito no guia de testes para versões candidatas. Assim, devem avaliar os recursos usados regularmente em diretórios temporários separados e comparar o candidato com a edição anterior. A página oficial de downloads apresenta o Bitcoin Core 31.1 como base atual. Essa versão fornece uma referência para identificar alterações inesperadas.

Pré-busca paralela altera desempenho do nó

A comparação pode revelar diferenças na inicialização do nó, no comportamento das carteiras e nas respostas RPC. Por esse motivo, os operadores não devem tratar a versão candidata como uma atualização rotineira de produção. O período de testes permite identificar desvios antes da publicação da tag final.

A principal alteração de desempenho nas notas preliminares do v32 envolve a pré-busca paralela de saídas de transações durante a conexão de blocos. A configuração utiliza oito trabalhadores por padrão, aceita até 16 e permite a desativação do recurso. Dessa forma, ambientes com validação limitada pelo disco podem medir os ganhos de velocidade. Também podem verificar possíveis custos adicionais de CPU, memória ou latência de armazenamento.

PSBTv2 e estimativas de taxas exigem atenção

Carteiras e integrações de serviços enfrentam um risco separado de falha. Quatro RPCs passarão a usar PSBTv2 por padrão. Por sua vez, outras interfaces removem campos obsoletos ou rejeitam argumentos aceitos por versões anteriores. Essas alterações podem afetar aplicações que dependem dos padrões antigos.

Portanto, equipes que criam, convertem ou aumentam taxas de PSBTs devem acompanhar as transações em analisadores e signatários posteriores. O tratamento de taxas também exige testes específicos para caminhos de falha. Nesse contexto, o fluxo padrão de estimatesmartfee combina estimadores da política de blocos e da mempool. O processo pode retornar uma estimativa menor e gerar erro quando um dos componentes falha.

Operadores devem observar esse comportamento durante a inicialização e em períodos com pouca atividade na mempool. Também precisam confirmar o funcionamento das ferramentas de monitoramento e das alternativas explícitas para a política de blocos. Desse modo, as equipes podem detectar mudanças que prejudiquem cálculos de taxas ou processos automatizados.

Servidor HTTP amplia os pontos de compatibilidade

A reescrita do servidor HTTP amplia os testes para componentes que operam além do nó. Ela estabelece um limite de 8.192 bytes para cabeçalhos e adota um tratamento mais rígido para estruturas malformadas. Ao mesmo tempo, o servidor passa a aplicar um teto padrão de 16 conexões RPC. A atualização ainda adiciona controles de cache REST e desconecta imediatamente endereços de clientes não autorizados.

Essas mudanças podem afetar proxies reversos, verificações de integridade, pools de clientes e rotinas de tratamento de erros. Consequentemente, os responsáveis pelas integrações precisam reproduzir condições reais de tráfego antes da atualização final. Os testes devem incluir conexões simultâneas, cabeçalhos extensos e respostas a solicitações inválidas.

Downgrade e transmissão pelo Tor trazem riscos

A reversão para uma versão anterior também exige atenção. Um índice de transações reconstruído ocupa menos da metade do espaço em disco, mas versões antigas não conseguem ler o novo formato. Assim, um downgrade pode exigir outra reconstrução, processo que pode durar horas. Esse cenário torna importante testar previamente os procedimentos de recuperação.

Operadores focados em privacidade devem reproduzir falhas de transmissão privada relacionadas à correção do fallback do Tor. Os casos incluem a fila de 10 mil entradas, o limite de mil tentativas e o comportamento de retransmissão sob carga. No entanto, a data da tag final ainda representa apenas uma meta do cronograma. Até o lançamento, esses casos extremos formam o trabalho prático da janela de testes e podem evitar interrupções temporárias em aplicações.
 

	Receba nossas últimas notícias em primeira mão.  Adicione-nos como sua fonte preferida no Google  e toque em “Favorito” para priorizar nossas atualizações.