Bitcoin segurança vulnerabilidades: ataque de distorção temporal

Recentemente, o desenvolvedor de Bitcoin Antoine Poinsot propôs uma proposta de soft fork chamada "Grande Limpeza de Consenso". Esta proposta visa corrigir várias falhas e vulnerabilidades que existem há muito tempo no protocolo Bitcoin, incluindo o problema de transações duplicadas que discutimos recentemente, bem como a mais grave vulnerabilidade de "ataques de distorção temporal" que será enfatizada neste artigo.

Mecanismo de Proteção do Carimbo de Tempo do Bitcoin

Antes de discutir o ataque de distorção temporal, precisamos entender as atuais regras de proteção contra manipulação de tempo:

1. Tempo mediano passado (MPT) regras: O carimbo de data/hora do bloco deve ser posterior ao tempo mediano dos 11 blocos anteriores.

2. Regras de tempo de bloco no futuro: o carimbo de tempo do bloco não pode exceder duas horas acima do tempo médio dos pares de nós. A diferença máxima permitida entre o tempo do nó e o relógio do sistema local é de 90 minutos.

As regras MPT evitam que os timestamps dos blocos estejam demasiado distantes do passado, enquanto as regras dos blocos futuros limitam que os timestamps entrem excessivamente no futuro. É importante notar que não é possível implementar um mecanismo semelhante às regras dos blocos futuros para impedir timestamps do passado, pois isso poderia afetar a sincronização inicial da blockchain. O ataque de distorção temporal explora precisamente a possibilidade de falsificar timestamps antigos.

O erro "um a menos" de Satoshi Nakamoto

O período de ajuste de dificuldade do Bitcoin inclui 2016 blocos, que, com base em um tempo alvo de 10 minutos por bloco, equivale a cerca de duas semanas. Ao calcular o ajuste de dificuldade da mineração, o protocolo calcula a diferença de timestamp entre o primeiro e o último bloco na janela de 2016 blocos relacionada. Esta janela de 2016 blocos contém, na realidade, 2015 intervalos de blocos (ou seja, 2016 menos 1). Portanto, o tempo alvo correto deve ser 60 segundos × 10 minutos × 2015 intervalos = 1,209,000 segundos. No entanto, o protocolo do Bitcoin usou o número 2016 para calcular o alvo: 60 segundos × 10 minutos × 2016 = 1,209,600 segundos. Este é um típico erro de um a menos, que pode ter confundido Satoshi Nakamoto ao interpretar o conceito de bloco e intervalo de bloco.

Este erro leva a que o tempo alvo seja 0,05% mais longo do que deveria. Na verdade, o intervalo de tempo alvo do Bitcoin não é de 10 minutos, mas sim de 10 minutos e 0,3 segundos. Embora esta falha pareça insignificante, desde o lançamento do Bitcoin, o intervalo médio entre blocos tem sido de 9 minutos e 36 segundos, significativamente inferior a 10 minutos. Isto deve-se principalmente ao aumento constante da potência de cálculo desde 2009. Isto também explica por que o recente evento de halving ocorreu em abril de 2024, e não em janeiro de 2025. Na verdade, adiantámo-nos no cronograma. A longo prazo, quando o preço e a potência de cálculo se estabilizarem, este erro de 0,3 segundos poderá ajudar-nos a regressar ao cronograma original.

Ataque de Distorção Temporal

O ataque de distorção temporal foi descoberto pela primeira vez por volta de 2011, aproveitando um erro de Satoshi Nakamoto no cálculo da dificuldade. Supondo que a mineração seja totalmente centralizada, os mineradores podem definir qualquer timestamp dentro do que o protocolo permite. O atacante ajustaria os timestamps da maioria dos blocos para apenas um segundo antes do bloco anterior, avançando o tempo da blockchain o mais lentamente possível, enquanto cumpre as regras do MTP. Para maximizar a desaceleração do avanço do tempo, os mineradores podem manter o mesmo timestamp em seis blocos consecutivos e, em seguida, aumentar o tempo em um segundo no sétimo bloco, repetindo esse ciclo.

Esse tipo de ataque fará com que o tempo da blockchain fique cada vez mais atrasado em relação ao tempo real, enquanto a dificuldade continuará a aumentar, tornando a mineração cada vez mais difícil. No entanto, para aumentar o efeito do ataque, no último bloco de cada ciclo de ajuste de dificuldade, os mineradores definirão o timestamp para o tempo do mundo real. Em seguida, o timestamp do primeiro bloco do novo ciclo de ajuste de dificuldade será definido de volta ao passado, apenas um segundo antes do penúltimo bloco do ciclo anterior. Essa operação ainda está em conformidade com as regras do MTP, uma vez que uma única anomalia 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 ser reduzida. Nesse momento, os mineradores poderão criar blocos a uma velocidade extremamente rápida, possivelmente criando uma grande quantidade de Bitcoin em um curto período, obtendo assim benefícios indevidos.

Viabilidade e Desafios do Ataque

Apesar de esta ataque ter um potencial devastador em teoria, a sua implementação prática enfrenta múltiplos desafios:

1. Pode ser necessário controlar a maior parte do poder de computação.
2. A existência de mineradores honestos aumentará a dificuldade de ataque.
3. As regras MTP e o carimbo de tempo dos mineradores honestos limitarão o grau de retrocesso dos carimbos de tempo maliciosos.
4. Se um minerador honesto gerar o primeiro bloco de qualquer janela de ajuste de dificuldade, o ataque desse ciclo falhará.
5. O processo de ataque é visível para todos, o que pode dar à comunidade tempo suficiente para lançar uma correção de soft fork de emergência.

Solução

Existem várias maneiras de corrigir esta vulnerabilidade:

1. Mudar o algoritmo de ajuste de dificuldade, calcular a diferença de tempo entre blocos em diferentes janelas de 2016 e corrigir completamente o erro de diferença. Mas isso pode exigir um hard fork.

2. Cancelar a regra MTP, exigindo que o tempo avance sempre em cada bloco. Mas isso pode fazer com que o tempo fique preso em um futuro distante, causando problemas para os mineradores que utilizam o relógio do sistema.

3. Uma solução mais simples é exigir que o tempo do primeiro bloco do novo ciclo de dificuldade não seja anterior a um número específico de minutos antes do último bloco do ciclo anterior. Na proposta de limpeza de consenso de Poinsot, esse tempo é definido como 2 horas.

Esta limitação de 2 horas tem as seguintes vantagens:

• Minimizar o risco de blocos inválidos acidentais
• Correspondente às regras de timestamp de bloco futuro
• Em comparação com as regras atuais, é uma mudança mais conservadora
• A amplitude de ajuste de 0,6% é bastante pequena

Embora isso ainda permita que os atacantes manipulem a dificuldade para baixo em cerca de 0,6% a cada ciclo, isso será apenas uma alteração única e não pode ser acumulada. No geral, essa solução alcança um bom equilíbrio entre a proteção da segurança da rede e a manutenção da estabilidade do sistema.