Bitcoin protocole vulnérabilité : attaque de distorsion temporelle

En mars 2025, la communauté de développement de Bitcoin a proposé une proposition de soft fork appelée "Nettoyage du Grand Consensus". Cette proposition vise à corriger plusieurs vulnérabilités et faiblesses qui existent depuis longtemps dans le protocole Bitcoin, y compris le problème des transactions en double que nous avons récemment discuté. Une autre vulnérabilité plus grave est connue sous le nom d'"attaque par distorsion temporelle", c'est précisément le sujet sur lequel cet article se concentrera.

Mécanisme de protection des timestamps de bloc Bitcoin

Avant de discuter des attaques par distorsion temporelle, nous devons comprendre les règles de protection contre la manipulation du temps dans le réseau Bitcoin actuel :

1. Règle de temps médian passé (MPT) : L'horodatage du nouveau bloc doit être postérieur à la médiane des horodatages des 11 blocs précédents.

2. Règles de temps des blocs futurs : le timestamp d'un nouveau bloc ne peut pas être en avance de plus de 2 heures par rapport à la médiane du temps des nœuds du réseau. En même temps, la différence de temps maximale autorisée entre les nœuds est de 90 minutes, ce qui constitue une autre garantie.

Les règles MPT empêchent les horodatages des blocs d'être trop rétroactifs, tandis que les règles des blocs futurs limitent les horodatages à ne pas être trop avancés. Il convient de noter qu'il n'est pas possible d'appliquer des restrictions similaires aux règles des blocs futurs sur les horodatages passés, car cela pourrait affecter le processus de synchronisation initial de la blockchain. L'attaque par distorsion temporelle est réalisée en falsifiant des horodatages rétroactifs.

L'erreur "différent d'un" de Satoshi Nakamoto

Le cycle d'ajustement de la difficulté du Bitcoin comprend 2016 blocs, ce qui représente environ deux semaines avec un temps de bloc de 10 minutes. Lors du calcul de l'ajustement de la difficulté minière, le protocole calcule la différence de timestamp entre le premier et le dernier bloc de la fenêtre de 2016 blocs. Cette fenêtre contient en réalité 2015 intervalles de blocs (2016-1). Par conséquent, le temps cible théorique devant être utilisé est de 60 secondes × 10 minutes × 2015 intervalles = 1 209 000 secondes. Cependant, le protocole Bitcoin utilise le chiffre 2016 pour calculer le temps cible : 60 secondes × 10 minutes × 2016 = 1 209 600 secondes. C'est une erreur typique de "un de moins", et il est probable que Satoshi Nakamoto ait confondu le nombre de blocs avec le nombre d'intervalles de blocs lors de ce calcul.

Cette erreur a entraîné un temps cible qui est 0,05 % plus long que ce qu'il devrait être en réalité. En d'autres termes, l'intervalle de bloc cible réel pour Bitcoin n'est pas de 10 minutes, mais plutôt de 10 minutes et 0,3 seconde. Cette petite différence n'est pas significative dans la pratique, car depuis la création de Bitcoin, l'intervalle moyen de génération des blocs a toujours été d'environ 9 minutes et 36 secondes, ce qui est clairement inférieur à 10 minutes. Cela explique également pourquoi le récent événement de réduction de moitié a été avancé à avril 2024 au lieu de janvier 2025. Bien que cette erreur de 0,3 seconde puisse sembler insignifiante, elle a engendré un problème plus grave.

Principe de l'attaque par distorsion du temps

L'attaque par distorsion temporelle a été découverte pour la première fois en 2011, exploitant une erreur de Satoshi Nakamoto dans le calcul de la difficulté. Supposons que le minage soit entièrement centralisé, les mineurs peuvent définir des timestamps comme bon leur semble dans les limites autorisées par le protocole. L'attaquant réglerait les timestamps de la plupart des blocs pour qu'ils soient avancés d'une seule seconde par rapport au bloc précédent, ralentissant ainsi la progression temporelle de la blockchain tout en respectant les règles MTP. Pour maximiser le ralentissement du temps, l'attaquant peut maintenir le même timestamp pendant six blocs consécutifs, puis ajouter une seconde au septième bloc, et ainsi de suite.

Cette opération entraînera un retard progressif de l'heure de la blockchain par rapport à l'heure réelle, tout en augmentant continuellement la difficulté, rendant le minage de plus en plus difficile. Cependant, pour renforcer l'effet de l'attaque, l'attaquant définira le timestamp du dernier bloc de chaque cycle d'ajustement de la difficulté à l'heure du monde réel. Le premier bloc du cycle suivant sera alors reculé dans le temps, n'étant qu'une seconde en avance sur l'avant-dernier bloc du cycle précédent. Cette pratique respecte toujours les règles MTP, car une seule valeur aberrante n'affectera pas la médiane des 11 blocs.

Après avoir mis en œuvre cette attaque, la difficulté du premier cycle ne sera pas affectée. Mais à partir du deuxième cycle d'ajustement, la difficulté commencera à diminuer de manière significative. Par la suite, l'attaquant pourra créer des blocs à une vitesse très rapide, potentiellement frapper une grande quantité de Bitcoin et en tirer profit.

Analyse de la faisabilité de l'attaque

Bien que cette attaque soit théoriquement dévastatrice, sa mise en œuvre pratique fait face à de nombreux défis :

1. Il peut être nécessaire de contrôler la majeure partie de la puissance de calcul du réseau.
2. L'existence de mineurs honnêtes augmentera la difficulté des attaques.
3. Les règles MTP et les horodatages honnêtes limiteront le degré de rétroaction des horodatages malveillants.
4. Si un mineur honnête produit le premier bloc de n'importe quelle fenêtre d'ajustement de difficulté, l'attaque de ce cycle échouera.
5. Le processus d'attaque est visible par tous, ce qui pourrait déclencher une réparation d'urgence par soft fork.

Solutions potentielles

Il existe plusieurs méthodes possibles pour corriger cette vulnérabilité :

1. Modifier l'algorithme d'ajustement de la difficulté, calculer l'écart de temps entre les différentes fenêtres de 2016 blocs, tout en corrigeant l'erreur "différent d'un". Cependant, cela pourrait nécessiter un hard fork.

2. Annuler la règle MTP, exigeant que le temps de chaque bloc soit strictement croissant. Mais cela pourrait entraîner un avancement excessif des horodatages ou causer des problèmes en raison des différences d'horloge entre les mineurs.

3. Une solution plus simple consiste à exiger que le temps du premier bloc du nouveau cycle de difficulté ne soit pas antérieur à un certain nombre de minutes du dernier bloc du cycle précédent. La plage de temps actuellement discutée varie de 10 minutes à 2 heures.

Dans la dernière proposition de nettoyage du consensus, les développeurs ont tendance à adopter une limite de 2 heures. Cette période représente environ 0,6 % du temps cible du cycle d'ajustement de la difficulté, ce qui peut efficacement limiter l'espace pour manipuler la difficulté à la baisse.

Quelle que soit la solution finalement adoptée, la correction de cette vulnérabilité de longue date renforcera davantage la sécurité et la stabilité du réseau Bitcoin.