Análise da vulnerabilidade do ataque de distorção temporal do Bitcoin
No dia 26 de março de 2025, os desenvolvedores do Bitcoin propuseram uma proposta de soft fork chamada "Grande Limpeza de Consenso", com o objetivo de corrigir várias falhas e fraquezas de longa data no protocolo do Bitcoin. A mais notável delas é a vulnerabilidade da "ataque de distorção temporal".
Mecanismo de proteção de timestamp de bloco do Bitcoin
Bitcoin atualmente utiliza dois mecanismos para evitar a manipulação de timestamps:
Tempo mediano passado (MPT) regra: o carimbo de data/hora do novo bloco deve ser posterior ao tempo mediano dos 11 blocos anteriores.
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.
Estas duas regras evitam que o timestamp dos blocos esteja demasiado atrasado ou adiantado. No entanto, o ataque de distorção temporal explora precisamente as vulnerabilidades dessas regras, retrocedendo significativamente o tempo do bloco através da falsificação de timestamps.
O erro "um a menos" de Satoshi Nakamoto
O período de ajuste de dificuldade do Bitcoin é de 2016 blocos, cerca de 14 dias. Ao calcular o ajuste de dificuldade, o protocolo compara a diferença de timestamp entre o primeiro e o último bloco da janela de 2016 blocos. Teoricamente, deveria usar um intervalo de 2015 blocos (2016-1), ou seja, 1.209.000 segundos como tempo alvo. Mas no código real, foi utilizado 2016 como multiplicador, resultando em um tempo alvo de 600 segundos a mais.
Este pequeno erro fez com que o tempo real de geração de blocos do Bitcoin fosse de 10 minutos e 0,3 segundos. Embora este erro pareça insignificante, ele cria a possibilidade de ataques de distorção temporal.
Princípio do Ataque de Distorção Temporal
O ataque de distorção temporal foi descoberto por volta de 2011. Os atacantes manipulam os timestamps dos blocos, fazendo com que o tempo da blockchain fique gradualmente atrás do tempo real, afetando assim o mecanismo de ajuste de dificuldade.
Os passos específicos são os seguintes:
Para a maioria dos blocos, definir o carimbo de data/hora para avançar apenas 1 segundo em relação ao bloco anterior.
A cada 6 blocos, o carimbo de tempo avança 1 segundo, para cumprir as regras do MPT.
No último bloco de cada ciclo de dificuldade, definir o carimbo de data/hora como o tempo real.
O primeiro bloco do novo ciclo retrocedeu novamente o timestamp para 1 segundo após o penúltimo bloco do ciclo anterior.
Esta operação pode levar a um encurtamento artificial do ciclo de cálculo da dificuldade, desencadeando assim uma redução da dificuldade. Após vários ciclos de ataque, a dificuldade pode diminuir significativamente, fazendo com que a velocidade de geração de blocos aumente anormalmente.
Impacto e viabilidade do ataque
Teoricamente, esse tipo de ataque pode reduzir a dificuldade em quase 2,8 vezes a cada ciclo. Após um ataque contínuo por um período, a velocidade de geração de blocos pode alcançar mais de 10 por segundo.
No entanto, a implementação desse ataque enfrenta muitos desafios:
É necessário controlar a maior parte da potência de cálculo.
A existência de mineradores honestos interferirá na manipulação de timestamps.
O processo de ataque é completamente visível e pode desencadear uma correção de emergência.
Solução
Para evitar ataques de distorção temporal, a forma mais simples é definir um limite inferior para o timestamp do primeiro bloco do novo período de dificuldade. A proposta mais recente sugere que esse limite seja de 2 horas, ou seja, o timestamp do primeiro bloco do novo período não pode ser anterior a 2 horas do último bloco do período anterior.
Esta medida de correção é simples e eficaz, e pode minimizar ao máximo o risco de geração acidental de blocos inválidos. A janela de tempo de 2 horas representa apenas cerca de 0,6% do ciclo de ajuste de dificuldade, podendo efetivamente conter a possibilidade de manipulação artificial da dificuldade.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
15 Curtidas
Recompensa
15
4
Repostar
Compartilhar
Comentário
0/400
TooScaredToSell
· 5h atrás
Bitcoin ainda precisa corrigir tantas vulnerabilidades, não está muito bom.
Ver originalResponder0
BearMarketSurvivor
· 5h atrás
Veterano de batalha há dez anos data/hora esta linha de defesa está muito fraca
Ver originalResponder0
WealthCoffee
· 5h atrás
Finalmente alguém consertou essa falha. Já deveria ter sido corrigida.
Ver originalResponder0
MEVHunter
· 5h atrás
meh... outra falha de protocolo explorada. típico descuido do satoshi, para ser sincero
Bitcoin pretende corrigir a vulnerabilidade de distorção de tempo para prevenir a manipulação da dificuldade de redireccionamento
Análise da vulnerabilidade do ataque de distorção temporal do Bitcoin
No dia 26 de março de 2025, os desenvolvedores do Bitcoin propuseram uma proposta de soft fork chamada "Grande Limpeza de Consenso", com o objetivo de corrigir várias falhas e fraquezas de longa data no protocolo do Bitcoin. A mais notável delas é a vulnerabilidade da "ataque de distorção temporal".
Mecanismo de proteção de timestamp de bloco do Bitcoin
Bitcoin atualmente utiliza dois mecanismos para evitar a manipulação de timestamps:
Tempo mediano passado (MPT) regra: o carimbo de data/hora do novo bloco deve ser posterior ao tempo mediano dos 11 blocos anteriores.
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.
Estas duas regras evitam que o timestamp dos blocos esteja demasiado atrasado ou adiantado. No entanto, o ataque de distorção temporal explora precisamente as vulnerabilidades dessas regras, retrocedendo significativamente o tempo do bloco através da falsificação de timestamps.
O erro "um a menos" de Satoshi Nakamoto
O período de ajuste de dificuldade do Bitcoin é de 2016 blocos, cerca de 14 dias. Ao calcular o ajuste de dificuldade, o protocolo compara a diferença de timestamp entre o primeiro e o último bloco da janela de 2016 blocos. Teoricamente, deveria usar um intervalo de 2015 blocos (2016-1), ou seja, 1.209.000 segundos como tempo alvo. Mas no código real, foi utilizado 2016 como multiplicador, resultando em um tempo alvo de 600 segundos a mais.
Este pequeno erro fez com que o tempo real de geração de blocos do Bitcoin fosse de 10 minutos e 0,3 segundos. Embora este erro pareça insignificante, ele cria a possibilidade de ataques de distorção temporal.
Princípio do Ataque de Distorção Temporal
O ataque de distorção temporal foi descoberto por volta de 2011. Os atacantes manipulam os timestamps dos blocos, fazendo com que o tempo da blockchain fique gradualmente atrás do tempo real, afetando assim o mecanismo de ajuste de dificuldade.
Os passos específicos são os seguintes:
Esta operação pode levar a um encurtamento artificial do ciclo de cálculo da dificuldade, desencadeando assim uma redução da dificuldade. Após vários ciclos de ataque, a dificuldade pode diminuir significativamente, fazendo com que a velocidade de geração de blocos aumente anormalmente.
Impacto e viabilidade do ataque
Teoricamente, esse tipo de ataque pode reduzir a dificuldade em quase 2,8 vezes a cada ciclo. Após um ataque contínuo por um período, a velocidade de geração de blocos pode alcançar mais de 10 por segundo.
No entanto, a implementação desse ataque enfrenta muitos desafios:
Solução
Para evitar ataques de distorção temporal, a forma mais simples é definir um limite inferior para o timestamp do primeiro bloco do novo período de dificuldade. A proposta mais recente sugere que esse limite seja de 2 horas, ou seja, o timestamp do primeiro bloco do novo período não pode ser anterior a 2 horas do último bloco do período anterior.
Esta medida de correção é simples e eficaz, e pode minimizar ao máximo o risco de geração acidental de blocos inválidos. A janela de tempo de 2 horas representa apenas cerca de 0,6% do ciclo de ajuste de dificuldade, podendo efetivamente conter a possibilidade de manipulação artificial da dificuldade.