Chaînes de hachage et liaison de blocs

Une chaîne de hachage relie des blocs de données de sorte que chaque bloc contienne le hachage du bloc précédent. La modification d’un bloc quelconque modifie son hachage et invalide tous les blocs suivants. Cela crée un registre en ajout uniquement qui permet de détecter toute altération.

Chaque bloc contient : (1) une charge utile de données (transactions), (2) le hachage du bloc précédent (pointeur vers le bloc antérieur), (3) un horodatage, (4) un nonce (pour le PoW), (5) la racine de Merkle des transactions. Le premier bloc (genesis) a previous_hash = "0"*64.

import hashlib, json class Block: def __init__(self, data, prev_hash): self.data = data self.prev_hash = prev_hash self.hash = hashlib.sha256( json.dumps({'data':data,'prev':prev_hash}).encode() ).hexdigest()

Si un attaquant modifie les données du bloc 3, le hachage du bloc 3 change. Le bloc 4 référence l’ancien hachage du bloc 3 : la chaîne est rompue au niveau du bloc 4. L’attaquant doit recalculer les hachages des blocs 3, 4, 5, ... jusqu’à l’extrémité de la chaîne. Avec le PoW, cela est irréalisable sur le plan informatique.

Les chaînes de hachage permettent de détecter les altérations, mais ne garantissent pas à elles seules l’immutabilité. Sans mécanismes supplémentaires (PoW, signatures numériques, distribution), un attaquant qui contrôle la chaîne peut la réécrire. En pratique, c’est le consensus distribué qui rend la chaîne de blocs résistante aux altérations.

Règle de la chaîne la plus longue de Bitcoin : la chaîne valide ayant accumulé le plus de preuves de travail est la chaîne canonique. Si un attaquant crée une branche, les mineurs honnêtes prolongent la chaîne honnête plus rapidement (hypothèse des 51 %). La branche de l’attaquant est plus courte et est rejetée.

Les clients SPV de Bitcoin (vérification simplifiée des paiements) téléchargent uniquement les en-têtes de blocs de 80 octets (contenant le hachage précédent, la racine de Merkle, le nonce, l’horodatage et le champ bits). Les nœuds complets stockent toutes les transactions. Les clients SPV vérifient une transaction au moyen d’une preuve de Merkle par rapport à la racine de Merkle de l’en-tête.

Le bloc genesis de Bitcoin (bloc 0, 3 janvier 2009) a prev_hash = 0x000...0. Satoshi a intégré le titre « The Times 03/Jan/2009 Le chancelier au bord d’un deuxième renflouement des banques » dans la transaction coinbase comme preuve de l’horodatage.

Les chaînes de hachage sont antérieures à la chaîne de blocs. Utilisations : listes de révocation de certificats (reliées par hachage), intégrité des journaux (hachage de l’entrée de journal précédente), chaîne de confiance DNSSEC. Le concept se généralise à toute structure en ajout uniquement où chaque entrée engage toutes les entrées précédentes.

Pour accélérer la synchronisation initiale, Bitcoin Core inscrit en dur des points de contrôle : des hachages de blocs connus comme valides à certaines hauteurs. Un client qui commence sa synchronisation peut ignorer la vérification du PoW pour les blocs antérieurs au point de contrôle et faire confiance au hachage inscrit en dur. Compromis : cela réduit la capacité à minimiser la confiance accordée.

Git utilise le même principe : chaque validation est identifiée par SHA-1/SHA-256 du contenu et du hachage de la validation parente. L’extraction d’une validation particulière avec git checkout restitue exactement cet état. L’historique complet de Git est un arbre d’objets reliés par hachage.

Pourquoi un attaquant doit-il recalculer tous les hachages des blocs suivants après avoir modifié un bloc ?

Les chaînes de hachage relient les blocs au moyen de pointeurs cryptographiques. Toute modification se propage à tous les blocs suivants. Combinées au PoW et au consensus distribué, elles rendent la chaîne de blocs immuable en pratique. Ensuite : les arbres de Merkle pour garantir efficacement l’intégrité des transactions.