Não existem hoje computadores quânticos capazes de quebrar a blockchain do Bitcoin. No entanto, os programadores já estão a considerar uma vaga de atualizações para construir defesas contra a ameaça potencial — e, com razão, já que a ameaça deixou de ser hipotética.
Esta semana, a Google publicou investigação sugerindo que um computador quântico suficientemente poderoso poderia decifrar a criptografia central do Bitcoin em menos de nove minutos — um minuto mais rápido do que o tempo médio de liquidação do bloco do Bitcoin. Alguns analistas acreditam que tal ameaça poderia tornar-se uma realidade até 2029.
Os riscos são elevados: cerca de 6,5 milhões de tokens de bitcoin, no valor de centenas de milhares de milhões de dólares, encontram-se em endereços que um computador quântico poderia visar diretamente. Algumas destas moedas pertencem ao criador pseudónimo do Bitcoin, Satoshi Nakamoto. Além disso, a eventual violação danificaria os princípios centrais do Bitcoin — “confie no código” e “dinheiro sólido”.
Eis como a ameaça se apresenta, juntamente com propostas em análise para a mitigar.
Duas formas de uma máquina quântica atacar o Bitcoin
Vamos primeiro compreender a vulnerabilidade antes de discutirmos as propostas.
A segurança do Bitcoin assenta numa relação matemática unidirecional. Quando cria uma carteira, é gerada uma chave privada e um número secreto, a partir dos quais se deriva uma chave pública.
Para gastar tokens de bitcoin é necessário provar a posse de uma chave privada, não revelando-a, mas usando-a para gerar uma assinatura criptográfica que a rede consegue verificar.
Este sistema é infalível porque os computadores modernos demorariam milhares de milhões de anos a quebrar a criptografia de curvas elípticas — especificamente o Elliptic Curve Digital Signature Algorithm (ECDSA) — para reengenheirar a chave privada a partir da chave pública. Por isso, diz-se que a blockchain é computacionalmente impossível de comprometer.
Mas um futuro computador quântico pode transformar esta via unidirecional numa via bidirecional, derivando a tua chave privada a partir da chave pública e drenando as tuas moedas.
A chave pública fica exposta de duas maneiras: Por moedas paradas onchain (o ataque de exposição prolongada) ou por moedas em movimento ou transações à espera na memory pool (ataque de exposição curta).
Os endereços Pay-to-public key (P2PK) (usados por Satoshi e pelos mineradores iniciais) e o Taproot (P2TR), o formato de endereços atualmente ativado em 2021, são vulneráveis ao ataque de exposição prolongada. As moedas nestes endereços não precisam de se mover para revelar as suas chaves públicas; a exposição já aconteceu e é legível por qualquer pessoa na Terra, incluindo um futuro atacante quântico. Aproximadamente 1,7 milhões de BTC estão em antigos endereços P2PK — incluindo as moedas de Satoshi.
A exposição curta está ligada à mempool — a sala de espera das transações não confirmadas. Enquanto as transações lá permanecem à espera de serem incluídas num bloco, a tua chave pública e a tua assinatura ficam visíveis para toda a rede.
Um computador quântico poderia aceder a esses dados, mas teria apenas uma janela breve — antes de a transação ser confirmada e enterrada sob blocos adicionais — para derivar a chave privada correspondente e agir sobre ela.
Iniciativas
BIP 360: Remover a chave pública
Como foi referido anteriormente, cada novo endereço do Bitcoin criado com o Taproot hoje expõe permanentemente uma chave pública onchain, dando a um futuro computador quântico um alvo que nunca desaparece.
A Proposta de Melhoria do Bitcoin (BIP) 360 remove a chave pública permanentemente incorporada onchain e visível para todos, introduzindo um novo tipo de saída chamado Pay-to-Merkle-Root (P2MR).
Recorda que um computador quântico estuda a chave pública, reengenheia a forma exata da chave privada e falsifica uma cópia funcional. Se removermos a chave pública, o ataque deixa de ter algo a partir do qual trabalhar. Entretanto, o resto de tudo — incluindo pagamentos Lightning, configurações de multis assinatura e outras funcionalidades do Bitcoin — permanece igual.
No entanto, se for implementada, esta proposta protege apenas as novas moedas para a frente. Os 1,7 milhões de BTC que já se encontram em endereços antigos expostos são um problema separado, abordado por outras propostas abaixo.
SPHINCS+ / SLH-DSA: Assinaturas pós-quânticas baseadas em hash
SPHINCS+ é um esquema de assinatura pós-quântica construído sobre funções de hash, evitando os riscos quânticos enfrentados pela criptografia de curvas elípticas usada pelo Bitcoin. Enquanto o algoritmo de Shor ameaça o ECDSA, desenhos baseados em hash como o SPHINCS+ não são vistos como igualmente vulneráveis.
O esquema foi padronizado pelo National Institute of Standards and Technology (NIST) em agosto de 2024 como FIPS 205 (SLH-DSA), após anos de revisão pública.
A compensação para a segurança é o tamanho. Enquanto as assinaturas atuais do bitcoin têm 64 bytes, as SLH-DSA têm 8 quilobytes (KB) ou mais de tamanho. Como tal, adotar SLH-DSA aumentaria de forma acentuada a exigência de espaço de bloco e elevaria as taxas de transação.
Como resultado, propostas como SHRIMPS (outro esquema de assinatura pós-quântica baseado em hash) e SHRINCS já foram introduzidas para reduzir o tamanho das assinaturas sem comprometer a segurança pós-quântica. Ambos assentam no SHPINCS+ enquanto procuram manter as suas garantias de segurança numa forma mais prática e eficiente em termos de espaço, adequada para uso em blockchain.
Esquema Commit/Reveal de Tadge Dryja: Um travão de emergência para a mempool
Esta proposta, um soft fork sugerido pelo co-criador da Lightning Network Tadge Dryja, visa proteger transações na mempool de um futuro atacante quântico. Faz isso ao separar a execução das transações em duas fases: Commit e Reveal.
Imagina informar um contrapartida de que vais enviar um email para ela e, de facto, enviar o email. A primeira é a fase de commit, e a segunda é a fase de reveal.
Na blockchain, isso significa que primeiro publicas uma impressão digital selada da tua intenção — apenas um hash, que não revela nada sobre a transação. A blockchain carimba essa impressão digital permanentemente com data e hora. Mais tarde, quando transmitires a transação real, a tua chave pública fica visível — e sim, um computador quântico a observar a rede poderia derivar a tua chave privada a partir dela e forjar uma transação concorrente para roubar o teu dinheiro.
Mas essa transação forjada é imediatamente rejeitada. A rede verifica: este gasto tem um compromisso anterior registado onchain? O teu tem. O do atacante não — ele criou-o momentos antes. A tua impressão digital previamente registada é a tua álibi.
O problema, porém, é o custo acrescido devido a a transação ser dividida em duas fases. Por isso, é descrita como uma ponte interina, prática para implementar enquanto a comunidade trabalha na construção de defesas quânticas.
Hourglass V2: Desacelerar o gasto de moedas antigas
Proposta pelo programador Hunter Beast, a Hourglass V2 visa a vulnerabilidade quântica ligada a cerca de 1,7 milhões de BTC detidos em endereços mais antigos e já expostos.
A proposta aceita que estas moedas poderiam ser roubadas num ataque quântico futuro e procura abrandar a hemorragia ao limitar as vendas a um bitcoin por bloco, de modo a evitar uma liquidação massiva catastrófica durante a noite que poderia abalar o mercado.
A analogia é uma corrida bancária: tu não consegues impedir as pessoas de levantarem dinheiro, mas podes limitar a velocidade dos levantamentos para evitar que o sistema colapse durante a noite. A proposta é controversa porque, mesmo esta restrição limitada, é vista por alguns na comunidade do Bitcoin como uma violação do princípio de que nenhuma parte externa pode alguma vez interferir com o teu direito de gastar as tuas moedas.
Conclusão
Estas propostas ainda não foram ativadas, e a governação descentralizada do Bitcoin, que abrange programadores, mineradores e operadores de nós, significa que qualquer atualização provavelmente demorará a materializar-se.
Ainda assim, o fluxo constante de propostas que antecedem o relatório desta semana da Google sugere que o problema esteve há muito tempo no radar dos programadores, o que pode ajudar a acalmar as preocupações do mercado.
