Bitcoin vulnérabilité de sécurité : attaque de distorsion temporelle
Récemment, le développeur Bitcoin Antoine Poinsot a proposé une proposition de soft fork appelée "Grande Nettoyage de Consensus". Cette proposition vise à réparer plusieurs vulnérabilités et faiblesses longtemps présentes dans le protocole Bitcoin, y compris le problème des transactions en double que nous avons récemment discuté, ainsi que la vulnérabilité plus grave des "attaques de distorsion temporelle" que cet article mettra en avant.
Mécanisme de protection des timestamps de bloc Bitcoin
Avant de discuter des attaques par distorsion temporelle, nous devons comprendre les règles actuelles de protection contre la manipulation du temps :
Temps médian passé ( MPT ) Règle : Le timestamp du bloc doit être postérieur au temps médian des 11 blocs précédents.
Règles de temps des blocs à venir : l'horodatage du bloc ne doit pas dépasser 2 heures de la médiane de temps des pairs des nœuds. La différence maximale autorisée entre le temps des nœuds et l'horloge système locale est de 90 minutes.
Les règles MPT empêchent les horodatages des blocs d'être trop éloignés dans le passé, tandis que les règles des blocs futurs limitent les horodatages à ne pas entrer excessivement dans le futur. Il convient de noter qu'il n'est pas possible d'implémenter un mécanisme similaire aux règles des blocs futurs pour empêcher les horodatages passés, car cela pourrait affecter la synchronisation initiale de la blockchain. L'attaque par distorsion temporelle exploite précisément la possibilité de falsifier des horodatages anciens.
L'erreur "un de trop" de Satoshi Nakamoto
Le cycle d'ajustement de la difficulté de Bitcoin comprend 2016 blocs, ce qui correspond à environ deux semaines en calculant sur la base d'un temps de blocage cible 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 dans la fenêtre des 2016 blocs concernés. Cette fenêtre de 2016 blocs contient en réalité 2015 intervalles de blocs (c'est-à-dire 2016 moins 1). Par conséquent, le temps cible correct devrait être de 60 secondes × 10 minutes × 2015 intervalles = 1 209 000 secondes. Cependant, le protocole Bitcoin utilise le nombre 2016 pour calculer l'objectif : 60 secondes × 10 minutes × 2016 = 1 209 600 secondes. C'est une erreur typique d'un de moins, ce qui pourrait indiquer que Satoshi Nakamoto a confondu les blocs et les intervalles de blocs.
Cette erreur a conduit à ce que le temps cible soit 0,05 % plus long que prévu. En réalité, l'intervalle de temps cible pour Bitcoin n'est pas de 10 minutes, mais de 10 minutes et 0,3 seconde. Bien que ce bogue semble insignifiant, depuis le lancement de Bitcoin, l'intervalle moyen entre les blocs a toujours été de 9 minutes 36 secondes, ce qui est clairement inférieur à 10 minutes. Cela est principalement dû à l'augmentation constante de la puissance de calcul depuis 2009. Cela explique également pourquoi le dernier événement de réduction de moitié a eu lieu en avril 2024, et non en janvier 2025. Nous avons en fait avancé le calendrier. À long terme, lorsque le prix et la puissance de calcul tendront à se stabiliser, cette erreur de 0,3 seconde pourrait nous aider à revenir sur le calendrier prévu.
Attaque de distorsion temporelle
L'attaque par distorsion temporelle a été découverte pour la première fois vers 2011, elle exploite une erreur de Satoshi Nakamoto dans le calcul de la difficulté. Supposons que le minage soit complètement centralisé, les mineurs peuvent définir des horodatages arbitraires dans la limite permise par le protocole. L'attaquant définira l'horodatage de la plupart des blocs pour qu'il soit avancé d'une seconde par rapport au bloc précédent, afin de ralentir autant que possible l'avancement du temps de la blockchain, tout en respectant les règles MTP. Pour maximiser le ralentissement de l'avancement temporel, les mineurs peuvent maintenir le même horodatage pendant six blocs consécutifs, puis augmenter d'une seconde dans le septième bloc, et ainsi de suite.
Cette attaque peut entraîner un retard croissant de la blockchain par rapport au temps réel, tandis que la difficulté continue d'augmenter, rendant le minage de plus en plus difficile. Cependant, pour renforcer l'effet de l'attaque, à la fin de chaque cycle d'ajustement de difficulté, les mineurs régleront le timestamp du dernier bloc sur l'heure du monde réel. Ensuite, le timestamp du premier bloc du nouveau cycle d'ajustement de difficulté sera réglé en arrière dans le temps, seulement une seconde avant le bloc avant-dernier du cycle précédent. Cette opération respecte toujours les règles de MTP, car un seul abnorme n'affecte pas la médiane de 11 blocs.
Après avoir mis en œuvre cette attaque, la difficulté du premier cycle ne sera pas affectée. Cependant, à partir du deuxième cycle d'ajustement, la difficulté commencera à diminuer. À ce stade, les mineurs peuvent créer des blocs à une vitesse extrêmement rapide, ce qui pourrait leur permettre de générer une grande quantité de Bitcoin en peu de temps, obtenant ainsi des bénéfices indus.
Faisabilité et défis de l'attaque
Bien que cette attaque soit théoriquement dévastatrice, sa mise en œuvre pratique fait face à de multiples défis :
Il peut être nécessaire de contrôler la majeure partie de la puissance de calcul.
La présence de mineurs honnêtes augmentera la difficulté des attaques.
Les règles MTP et le timestamp des mineurs honnêtes limiteront le degré de rétrogradation des timestamps malveillants.
Si un mineur honnête génère le premier bloc de n'importe quelle fenêtre d'ajustement de la difficulté, l'attaque de ce cycle échouera.
Le processus d'attaque est visible pour tous et peut donner à la communauté suffisamment de temps pour lancer une réparation d'urgence via un hard fork.
Solution
Il existe plusieurs méthodes possibles pour corriger cette vulnérabilité :
Modifier l'algorithme d'ajustement de la difficulté, calculer l'intervalle de temps entre les blocs dans différentes fenêtres de 2016, et réparer complètement l'erreur de décalage. Mais cela pourrait nécessiter un hard fork.
Annuler la règle MTP, exigeant que le temps avance toujours dans chaque bloc. Mais cela pourrait entraîner un blocage du temps dans un avenir lointain et causer des problèmes aux mineurs utilisant l'horloge système.
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 avant le dernier bloc du cycle précédent. Dans la proposition de nettoyage du consensus de Poinsot, ce temps est fixé à 2 heures.
Cette limite de 2 heures présente les avantages suivants :
Réduire au maximum le risque de blocs invalides accidentels
Correspondre aux règles de l'horodatage des blocs futurs
Par rapport aux règles actuelles, il s'agit d'un changement plus conservateur.
La variation de 0,6 % est assez petite.
Bien que cela permette encore aux attaquants de manipuler la difficulté d'environ 0,6 % à chaque cycle, cela ne sera qu'un changement unique, non cumulatif. Dans l'ensemble, cette solution parvient à trouver un bon équilibre entre la protection de la sécurité du réseau et le maintien de la stabilité du système.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
20 J'aime
Récompense
20
7
Partager
Commentaire
0/400
ColdWalletGuardian
· Il y a 20h
Je serai rassuré une fois ce bug corrigé.
Voir l'originalRépondre0
BridgeNomad
· Il y a 20h
été brûlé par suffisamment d'exploits de bridge pour savoir - ce vecteur d'attaque me donne un ptsd de bridge juno fr
Voir l'originalRépondre0
fren.eth
· Il y a 20h
Personne n'est idiot, qui ne veut pas profiter gratuitement.
Voir l'originalRépondre0
NotAFinancialAdvice
· Il y a 20h
Après avoir corrigé les failles, les mineurs ne peuvent plus jouer.
Voir l'originalRépondre0
retroactive_airdrop
· Il y a 20h
J'ai réparé un vide.
Voir l'originalRépondre0
GmGmNoGn
· Il y a 20h
Encore en train de corriger des bugs, en résolvant un, un autre arrive.
Voir l'originalRépondre0
quiet_lurker
· Il y a 20h
En théorie, les mineurs devraient faire sauter la casserole.
Analyse des vulnérabilités de l'attaque par distorsion du temps de Bitcoin : principes, impacts et solutions de réparation
Bitcoin vulnérabilité de sécurité : attaque de distorsion temporelle
Récemment, le développeur Bitcoin Antoine Poinsot a proposé une proposition de soft fork appelée "Grande Nettoyage de Consensus". Cette proposition vise à réparer plusieurs vulnérabilités et faiblesses longtemps présentes dans le protocole Bitcoin, y compris le problème des transactions en double que nous avons récemment discuté, ainsi que la vulnérabilité plus grave des "attaques de distorsion temporelle" que cet article mettra en avant.
Mécanisme de protection des timestamps de bloc Bitcoin
Avant de discuter des attaques par distorsion temporelle, nous devons comprendre les règles actuelles de protection contre la manipulation du temps :
Temps médian passé ( MPT ) Règle : Le timestamp du bloc doit être postérieur au temps médian des 11 blocs précédents.
Règles de temps des blocs à venir : l'horodatage du bloc ne doit pas dépasser 2 heures de la médiane de temps des pairs des nœuds. La différence maximale autorisée entre le temps des nœuds et l'horloge système locale est de 90 minutes.
Les règles MPT empêchent les horodatages des blocs d'être trop éloignés dans le passé, tandis que les règles des blocs futurs limitent les horodatages à ne pas entrer excessivement dans le futur. Il convient de noter qu'il n'est pas possible d'implémenter un mécanisme similaire aux règles des blocs futurs pour empêcher les horodatages passés, car cela pourrait affecter la synchronisation initiale de la blockchain. L'attaque par distorsion temporelle exploite précisément la possibilité de falsifier des horodatages anciens.
L'erreur "un de trop" de Satoshi Nakamoto
Le cycle d'ajustement de la difficulté de Bitcoin comprend 2016 blocs, ce qui correspond à environ deux semaines en calculant sur la base d'un temps de blocage cible 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 dans la fenêtre des 2016 blocs concernés. Cette fenêtre de 2016 blocs contient en réalité 2015 intervalles de blocs (c'est-à-dire 2016 moins 1). Par conséquent, le temps cible correct devrait être de 60 secondes × 10 minutes × 2015 intervalles = 1 209 000 secondes. Cependant, le protocole Bitcoin utilise le nombre 2016 pour calculer l'objectif : 60 secondes × 10 minutes × 2016 = 1 209 600 secondes. C'est une erreur typique d'un de moins, ce qui pourrait indiquer que Satoshi Nakamoto a confondu les blocs et les intervalles de blocs.
Cette erreur a conduit à ce que le temps cible soit 0,05 % plus long que prévu. En réalité, l'intervalle de temps cible pour Bitcoin n'est pas de 10 minutes, mais de 10 minutes et 0,3 seconde. Bien que ce bogue semble insignifiant, depuis le lancement de Bitcoin, l'intervalle moyen entre les blocs a toujours été de 9 minutes 36 secondes, ce qui est clairement inférieur à 10 minutes. Cela est principalement dû à l'augmentation constante de la puissance de calcul depuis 2009. Cela explique également pourquoi le dernier événement de réduction de moitié a eu lieu en avril 2024, et non en janvier 2025. Nous avons en fait avancé le calendrier. À long terme, lorsque le prix et la puissance de calcul tendront à se stabiliser, cette erreur de 0,3 seconde pourrait nous aider à revenir sur le calendrier prévu.
Attaque de distorsion temporelle
L'attaque par distorsion temporelle a été découverte pour la première fois vers 2011, elle exploite une erreur de Satoshi Nakamoto dans le calcul de la difficulté. Supposons que le minage soit complètement centralisé, les mineurs peuvent définir des horodatages arbitraires dans la limite permise par le protocole. L'attaquant définira l'horodatage de la plupart des blocs pour qu'il soit avancé d'une seconde par rapport au bloc précédent, afin de ralentir autant que possible l'avancement du temps de la blockchain, tout en respectant les règles MTP. Pour maximiser le ralentissement de l'avancement temporel, les mineurs peuvent maintenir le même horodatage pendant six blocs consécutifs, puis augmenter d'une seconde dans le septième bloc, et ainsi de suite.
Cette attaque peut entraîner un retard croissant de la blockchain par rapport au temps réel, tandis que la difficulté continue d'augmenter, rendant le minage de plus en plus difficile. Cependant, pour renforcer l'effet de l'attaque, à la fin de chaque cycle d'ajustement de difficulté, les mineurs régleront le timestamp du dernier bloc sur l'heure du monde réel. Ensuite, le timestamp du premier bloc du nouveau cycle d'ajustement de difficulté sera réglé en arrière dans le temps, seulement une seconde avant le bloc avant-dernier du cycle précédent. Cette opération respecte toujours les règles de MTP, car un seul abnorme n'affecte pas la médiane de 11 blocs.
Après avoir mis en œuvre cette attaque, la difficulté du premier cycle ne sera pas affectée. Cependant, à partir du deuxième cycle d'ajustement, la difficulté commencera à diminuer. À ce stade, les mineurs peuvent créer des blocs à une vitesse extrêmement rapide, ce qui pourrait leur permettre de générer une grande quantité de Bitcoin en peu de temps, obtenant ainsi des bénéfices indus.
Faisabilité et défis de l'attaque
Bien que cette attaque soit théoriquement dévastatrice, sa mise en œuvre pratique fait face à de multiples défis :
Solution
Il existe plusieurs méthodes possibles pour corriger cette vulnérabilité :
Modifier l'algorithme d'ajustement de la difficulté, calculer l'intervalle de temps entre les blocs dans différentes fenêtres de 2016, et réparer complètement l'erreur de décalage. Mais cela pourrait nécessiter un hard fork.
Annuler la règle MTP, exigeant que le temps avance toujours dans chaque bloc. Mais cela pourrait entraîner un blocage du temps dans un avenir lointain et causer des problèmes aux mineurs utilisant l'horloge système.
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 avant le dernier bloc du cycle précédent. Dans la proposition de nettoyage du consensus de Poinsot, ce temps est fixé à 2 heures.
Cette limite de 2 heures présente les avantages suivants :
Bien que cela permette encore aux attaquants de manipuler la difficulté d'environ 0,6 % à chaque cycle, cela ne sera qu'un changement unique, non cumulatif. Dans l'ensemble, cette solution parvient à trouver un bon équilibre entre la protection de la sécurité du réseau et le maintien de la stabilité du système.