Bitcoin protocolo vulnerabilidade: ataque de distorção temporal

Em março de 2025, a comunidade de desenvolvedores do Bitcoin propôs uma proposta de soft fork chamada "Limpeza do Grande Consenso". Esta proposta visa corrigir vários bugs e vulnerabilidades de longa data no protocolo Bitcoin, incluindo o problema de transações duplicadas que discutimos recentemente. Outra vulnerabilidade mais séria é chamada de "Ataque de Distorção Temporal", que é o foco principal deste artigo.

Mecanismo de proteção de timestamp de bloco do Bitcoin

Antes de discutir os ataques de distorção temporal, precisamos entender as regras de proteção contra manipulação de tempo na atual rede Bitcoin:

1. O tempo mediano passado (MPT) regra: O carimbo de data/hora do novo bloco deve ser posterior à mediana dos carimbos de data/hora dos 11 blocos anteriores.

2. Regras de tempo do bloco futuro: O carimbo de tempo do novo bloco não pode estar mais de 2 horas à frente do tempo médio dos nós da rede. Ao mesmo tempo, a diferença máxima de tempo permitida entre os nós é de 90 minutos, o que é uma outra garantia.

As regras MPT evitam que o timestamp do bloco seja excessivamente retroativo, enquanto as regras do bloco futuro limitam os timestamps excessivamente avançados. Vale ressaltar que não é possível impor restrições semelhantes às regras dos blocos futuros sobre timestamps passados, uma vez que isso pode afetar o processo de sincronização inicial da blockchain. O ataque de distorção temporal é realizado através da falsificação de timestamps muito retroativos.

O erro "falta um" de Satoshi Nakamoto

O ciclo de ajuste de dificuldade do Bitcoin inclui 2016 blocos, que, considerando um tempo de criação de bloco de 10 minutos, equivale a cerca de duas semanas. Ao calcular o ajuste da dificuldade de mineração, o protocolo calcula a diferença de timestamp entre o primeiro e o último bloco da janela de 2016 blocos. Esta janela contém na verdade 2015 intervalos de blocos (2016-1). Portanto, o tempo alvo que deveria ser usado teoricamente é 60 segundos × 10 minutos × 2015 intervalos = 1,209,000 segundos. No entanto, o protocolo Bitcoin utiliza o número 2016 para calcular o tempo alvo: 60 segundos × 10 minutos × 2016 = 1,209,600 segundos. Este é um típico erro de "um a menos", que provavelmente ocorreu porque Satoshi Nakamoto confundiu o número de blocos com o número de intervalos de blocos ao calcular.

Este erro fez com que o tempo alvo fosse 0,05% mais longo do que deveria ser. Em outras palavras, o intervalo real de blocos alvo do Bitcoin não é de 10 minutos, mas sim de 10 minutos e 0,3 segundos. Esta pequena diferença não é significativa em operação, pois desde o nascimento do Bitcoin, devido ao aumento contínuo da capacidade de cálculo, o intervalo médio de blocos tem permanecido em torno de 9 minutos e 36 segundos, significativamente inferior a 10 minutos. Isso também explica por que o recente evento de halving foi antecipado para abril de 2024 em vez de janeiro de 2025. Embora o erro de 0,3 segundos pareça insignificante, ele gerou uma falha mais grave.

Princípio do ataque de distorção temporal

A ataque de distorção temporal foi descoberto pela primeira vez em 2011, aproveitando-se de um erro de Satoshi Nakamoto no cálculo de dificuldade. Supondo que a mineração seja completamente centralizada, os mineradores podem definir os timestamps arbitrariamente dentro dos limites permitidos pelo protocolo. O atacante definiria os timestamps da maioria dos blocos para um segundo antes do bloco anterior, fazendo com que a blockchain avançasse lentamente no tempo, enquanto ainda cumpria as regras MTP. Para maximizar a lentidão do avanço do tempo, o atacante pode manter o mesmo timestamp por seis blocos consecutivos e então aumentar em um segundo no sétimo bloco, repetindo esse ciclo.

Esta operação fará com que o tempo da blockchain fique progressivamente atrasado em relação ao tempo real, enquanto a dificuldade continua a aumentar, tornando a mineração cada vez mais difícil. No entanto, para aumentar o efeito do ataque, o atacante definirá o timestamp do último bloco de cada ciclo de ajuste de dificuldade para o tempo do mundo real. O primeiro bloco do próximo ciclo será então definido de volta no passado, apenas um segundo antes do penúltimo bloco do ciclo anterior. Esta prática ainda está de acordo com as regras do MTP, uma vez que um único valor anômalo não afetará a mediana de 11 blocos.

Após a implementação deste ataque, a dificuldade do primeiro ciclo não será afetada. Mas a partir do segundo ciclo de ajuste, a dificuldade começará a diminuir significativamente. Em seguida, o atacante pode criar blocos a uma velocidade extremamente rápida, potencialmente cunhando uma grande quantidade de Bitcoin e lucrando com isso.

Análise de viabilidade de ataque

Embora teoricamente este tipo de ataque seja devastador, a sua implementação prática enfrenta muitos desafios:

1. Pode ser necessário controlar a maior parte da potência de cálculo da rede.
2. A existência de mineradores honestos aumentará a dificuldade de ataque.
3. As regras do MTP e o carimbo de tempo honesto limitarão o grau de retrocesso dos carimbos de tempo maliciosos.
4. Se um minerador honesto gerar o primeiro bloco da janela de ajuste de dificuldade, o ataque desse período falhará.
5. O processo de ataque é visível para todos e pode desencadear uma correção de soft fork de emergência.

Soluções potenciais

Existem várias maneiras de corrigir esta vulnerabilidade:

1. Alterar o algoritmo de ajuste de dificuldade, calculando a diferença de tempo entre janelas de 2016 blocos diferentes, ao mesmo tempo corrigindo o erro "faltar um". Mas isso pode exigir um hard fork.

2. Cancelar a regra MTP, exigindo que o tempo de cada bloco aumente estritamente. Mas isso pode levar a um avanço excessivo do carimbo de data/hora, ou a problemas devido a diferenças de relógio entre os mineradores.

3. Uma solução mais simples é exigir que o tempo do primeiro bloco do novo ciclo de dificuldade não seja anterior a um determinado número de minutos do último bloco do ciclo anterior. O intervalo de tempo atualmente discutido varia de 10 minutos a 2 horas.

Na mais recente proposta de limpeza do grande consenso, os desenvolvedores tendem a adotar um limite de 2 horas. Este período é cerca de 0,6% do tempo alvo do ciclo de ajuste de dificuldade, podendo limitar efetivamente o espaço para manipulação da dificuldade para baixo.

Independentemente da solução final adotada, corrigir esta vulnerabilidade de longa data irá reforçar ainda mais a segurança e a estabilidade da rede Bitcoin.