Bitcoin Core 32.0 encara os últimos testes de olho no lançamento em 10 de outubro

Bitcoin Core 32.0 chega ao fim de um ciclo de desenvolvimento onde as mudanças mais visíveis não são necessariamente as mais interessantes. A versão candidata está agora disponível e os desenvolvedores miram 10 de outubro para a versão final. No menu: validação mais organizada, servidor HTTP revisado e várias correções de segurança. Uma auditoria auxiliada por IA também iniciou uma sequência de testes bem instrutiva: o primeiro diagnóstico ainda não havia contado toda a história.

Validação mais rápida sem mexer no funcionamento do Bitcoin

Bitcoin Core permite que um computador verifique por si mesmo as transações e blocos da rede, sem precisar delegar essa tarefa a um serviço externo. A versão 32.0 afeta principalmente os operadores de nós, desenvolvedores e serviços construídos ao redor dessa infraestrutura.

A mudança mais perceptível em desempenho refere-se à validação dos blocos. Para validar uma transação, o software deve encontrar as saídas anteriores que ela gasta, os famosos prevouts. Quando estão no disco, sua leitura pode retardar o trabalho. A nova versão permite pré-carregar esses dados em paralelo a partir da base chainstate.

Oito threads trabalham por padrão, com um máximo definido em dezesseis. Uma máquina mais modesta poderá reduzir esse número a zero e desativar o mecanismo.

O ganho não tornará a blockchain mais rápida nem reduzirá o intervalo entre dois blocos. Diz respeito ao trabalho realizado localmente pelo nó. Uma nuance técnica, discreta na tela, mas bastante concreta para quem mantém a infraestrutura dia após dia.

Auditoria com IA dá a pista e desenvolvedores vão além

A história começa com Matthew Zipkin, colaborador conhecido pelo pseudônimo pinheadmz. Auditando o novo servidor HTTP com Kimi K3, um modelo de inteligência artificial também usado pela Bitcoin Red Team, ele encontrou um cenário de esgotamento de memória.

O servidor podia continuar lendo os dados enviados por um cliente enquanto já processava uma requisição. Um cliente malicioso tinha assim a possibilidade de manter essa requisição ocupada e enviar sempre mais dados. Estes se acumulavam em memória.

Zipkin imaginava inicialmente que o ataque exigia autenticação. Depois a revisão do código mudou o cenário. O desenvolvedor jeanpablojp testou a interface REST e constatou que 16 conexões sem identificação podiam fazer o consumo de memória do nó subir de cerca de 46 MB para quase 3 GB em um minuto.

A IA havia portanto detectado um problema. Porém não encerrou a investigação. Um humano empurrou o teste mais adiante e descobriu um vetor mais amplo. Uma colaboração homem-máquina muito mais interessante do que uma simples competição para ver quem encontra mais bugs.

A primeira correção desacelerava demais o servidor

A primeira resposta de Zipkin seguia uma lógica bastante simples: quando uma requisição já está em processamento, não há necessidade de continuar a aspirar os dados seguintes para a memória da aplicação. Eles podem aguardar no sistema até que a pressão TCP freie naturalmente o remetente.

A solução deste patch consiste em não ler mais o socket quando estamos ocupados processando uma requisição.

Matthew Zipkin, GitHub PR #36123

Porém, o primeiro patch tinha um defeito. Em uma conexão persistente, jeanpablojp mediu uma latência média passando de cerca de 0,14 ms para 53 ms. A correção protegia a memória, mas fazia certas requisições esperarem inutilmente.

Nova versão, novos testes. Após revisão, 16 conexões REST não autenticadas adicionam agora apenas cerca de 3 MB em 90 segundos, contra 3,2 GB antes da revisão. A penalidade de cerca de 50 ms também desapareceu.

Nem tudo é grátis, porém. Em um nó inativo sujeito a pipelining contínuo, um revisor mediu uma taxa caindo de 383 para 18,9 requisições por segundo. Um caso muito específico, que ele diz não encontrar em nenhum cliente real. A segurança vence claramente, com um compromisso medido em vez de oculto.

O que muda para quem roda um nó a partir de outubro

A versão 32.0 não se resume a essa história de memória. Várias mudanças menos espetaculares virão com ela, se o cronograma for mantido. Quatro comandos relacionados a transações parcialmente assinadas usarão PSBT v2 por padrão. Aplicações que precisarem poderão ainda solicitar a versão anterior.

O servidor HTTP foi reescrito para substituir o libevent. Ele aplica regras mais rígidas e limita por padrão a dezesseis o número de clientes HTTP conectados simultaneamente. Outra economia apreciável: após reconstrução, o índice das transações txindex ocupará menos da metade do espaço em disco antigo.

No lado da carteira, exportwatchonlywallet permitirá exportar as informações necessárias para uma carteira de observação sem levar as chaves privadas.

Uma correção também fecha a falha walletnotify. Em sistemas que não sejam Windows, um usuário RPC autenticado com direitos apropriados podia criar certos nomes de carteiras para provocar a execução de comandos. Esses nomes agora são tratados literalmente.

Para o usuário de uma aplicação leve, nada disso muda o dia. Para quem mantém os nós da blockchain, os detalhes importam muito mais.

A reter antes de 10 de outubro

• O lançamento do Bitcoin Core 32.0 está previsto para 10 de outubro de 2026, uma data que pode mudar durante os últimos testes da versão candidata.
• A validação poderá pré-carregar certos dados com oito threads por padrão e dezesseis no máximo, sem alterar o ritmo da produção de blocos.
• Após correção, 16 conexões REST não autenticadas adicionavam cerca de 3 MB de memória em 90 segundos, contra 3,2 GB antes da revisão.
• Quatro comandos de carteira adotarão PSBT v2 por padrão, enquanto as aplicações poderão continuar a solicitar a versão anterior.
• Um txindex totalmente reconstruído ocupará menos da metade do espaço em disco, enquanto o novo servidor HTTP recebe várias medidas de proteção adicionais.

O calendário oferece aliás uma boa coincidência. Enquanto o Bitcoin Core mira outubro, o Ethereum prepara Glamsterdam, a próxima grande evolução da sua blockchain. Sepolia deve receber um teste em 6 de outubro, se os bugs ainda presentes nas devnets forem corrigidos. A rede principal é esperada para o quarto trimestre, com dezembro ainda possível. Dois projetos diferentes, um mesmo método: testar, quebrar às vezes, corrigir muito, e só então entregar.