O Bitcoin Knots prepara um teste de fork com BLAKE2b para domingo, após a cadeia baseada no BIP-110 parar com apenas dois blocos. A iniciativa pretende substituir a prova de trabalho SHA-256d do Bitcoin pelo algoritmo BLAKE2b na rede proposta. Em 29 de agosto, o desenvolvedor Luke Dashjr orientou mineradores de SHA-2, no X, a interromper a mineração antes do teste de 30 de agosto. Na publicação, ele afirmou que o Bitcoin Knots 29.4.1rc4 definirá o último bloco SHA-2 antes da mudança.

Conforme o plano, uma versão final 29.4.1 poderá manter a nova cadeia a partir de 1º de setembro. Se o ensaio apresentar falhas, os desenvolvedores precisarão preparar outro candidato a lançamento. Contudo, a rede voltaria ao último bloco SHA-2 antes de uma nova tentativa.

Proposta busca reduzir dependência dos mineradores

Três semanas antes, o BIP-110 havia se separado da cadeia dominante do Bitcoin e estagnado após produzir dois blocos. Por isso, a nova proposta busca eliminar a dependência dos atuais mineradores de Bitcoin. Depois da ativação, a rede separada rejeitaria blocos produzidos com SHA-256d.

Na prática, a nova cadeia dependeria permanentemente de equipamentos compatíveis com a prova de trabalho BLAKE2b. Os defensores afirmam que máquinas fabricadas para minerar Sia poderiam operar no sistema. Por exemplo, a lista inclui os modelos Antminer A3, da Bitmain, e SC5, da Goldshell. Também foram publicadas instruções de mineração para a testnet4 e uma versão compatível do DATUM Gateway.

Ainda assim, o projeto não sabe se haverá mineradores suficientes para sustentar a rede. Um revisor da implementação aberta calculou uma demanda inicial de aproximadamente 870 terahashes por segundo para manter blocos a cada dez minutos. Nesse cálculo, a capacidade observada na testnet4 ficou entre 50 TH/s e 70 TH/s.

Estimativas ainda dependem do código definitivo

Embora os números revelem uma diferença relevante, eles usam código inacabado e não representam os parâmetros finais. Entretanto, a estimativa indica que a existência de equipamentos compatíveis não garante uma taxa de hash comprometida. Ao mesmo tempo, a participação dependerá das condições técnicas e econômicas oferecidas pela cadeia.

O cenário também mostra que o acesso a máquinas de mineração de Bitcoin não resolve sozinho o problema de coordenação. Dessa forma, os participantes precisarão reunir capacidade suficiente para produzir blocos com regularidade. Caso contrário, a cadeia poderá enfrentar uma paralisação semelhante à do BIP-110.

Regras de consenso permanecem em aberto

Em 29 de agosto, a página pública de lançamentos do Bitcoin Knots não exibia o rc4 nem uma versão final 29.4.1. Além disso, mudanças importantes relacionadas à prova de trabalho permaneciam abertas. A implementação do BLAKE2b e uma proposta associada à redução de dados também aguardavam definição. Até então, os materiais públicos não indicavam a altura de ativação na rede principal.

Havia ainda uma divergência sobre o limite temporário de peso dos blocos. A FAQ da proposta e o pull request indicavam um teto de 700 mil unidades de peso. Em contraste, um commit fixado estabelecia 800 mil unidades.

Com regras diferentes, os nós podem discordar sobre a validade de um bloco. Portanto, a configuração final do rc4 será decisiva para que todos acompanhem o mesmo livro-razão. Já a alteração da prova de trabalho terá caráter permanente. Por outro lado, as restrições de dados, incluindo o limite menor dos blocos, devem expirar em 2027.

Infraestrutura precisará acompanhar o fork

Mesmo que os mineradores produzam blocos sob regras comuns, o maior desafio de coordenação ocorrerá fora do Bitcoin Knots. A proposta altera o cabeçalho dos blocos para um formato de 164 bytes com BLAKE2b. Enquanto isso, clientes no estilo Electrum esperam os cabeçalhos de 80 bytes usados pelo Bitcoin com SHA-256d. Assim, carteiras leves, indexadores, exploradores e outros serviços podem precisar de adaptações.

Dashjr afirmou que a compatibilidade com clientes leves não faz parte do escopo do Bitcoin Knots. Além do mais, a proposta não identificou grandes exchanges, carteiras, custodiantes, exploradores ou implementações Lightning comprometidos com a cadeia. Apesar disso, o suporte desses serviços será necessário para criar uma economia funcional.

Divisão cria risco de replay entre as redes

A FAQ do projeto recomenda que exchanges suspendam depósitos e saques durante a divisão. Da mesma maneira, os serviços deveriam anunciar qual cadeia reconhecerão. Canais Lightning criados antes do fork também existiriam na rede BLAKE2b. Nesse caso, os dois participantes precisariam usar programas compatíveis e concordar com o mesmo livro-razão.

As duas redes herdariam o histórico de transações e os saldos anteriores ao fork. Com isso, uma transação que gaste fundos anteriores à divisão poderia ser válida em ambas as cadeias. Esse cenário cria risco de replay para carteiras e usuários. Para reduzir o problema, o Bitcoin Knots propôs o modo de assinatura SIGHASH_UNIFIED, que oferece proteção direcional quando selecionado explicitamente.

No entanto, o mecanismo não protegeria automaticamente todas as carteiras ou transações existentes. A mudança para BLAKE2b também não substitui endereços, chaves privadas ou assinaturas de transações do Bitcoin. Consequentemente, a proposta não protege as chaves de propriedade contra computação quântica.

Teste avaliará capacidade de manter a nova cadeia

O teste de domingo deverá mostrar se o projeto consegue produzir e sustentar uma cadeia BLAKE2b após a falha do BIP-110. Se a tentativa funcionar, o desafio seguinte será manter a produção regular de blocos. Depois disso, o projeto precisará atrair valor econômico e apoio de mineradores, exchanges, carteiras, custodiantes e usuários. Sem essa adesão, a nova rede poderá existir tecnicamente, mas terá dificuldade para desenvolver uma economia própria.