Hash d'en-tête du bloc précédent

Chaque bloc pointe vers l'arrière, jamais vers l'avant. Comme ce pointeur se trouve dans les 80 octets qui sont hachés, modifier quoi que ce soit dans un ancien bloc change son hash et casse tous les blocs construits au-dessus, si bien qu'annuler un paiement d'il y a un an suppose de refaire environ 52 000 blocs de preuve de travail. C'est cela, et non une quelconque règle sur la suppression de données, que l'on désigne lorsqu'on dit que le bitcoin est immuable.

Comment cela fonctionne

Le hash d'en-tête du bloc précédent est produit en appliquant SHA-256 deux fois sur les 80 octets de l'en-tête du parent, et c'est la seule référence qu'un bloc conserve vers quelque chose d'extérieur à lui-même.

Comme l'en-tête du parent contient le hash de son propre parent, et ainsi de suite jusqu'au début, un champ de 32 octets engage tout l'historique qui le précède. Un nœud qui a vérifié la pointe a implicitement vérifié que la chaîne qui y mène est cohérente en interne. Modifiez une transaction dans un bloc miné l'été dernier et le hash d'en-tête de ce bloc change, donc la copie qu'en détient l'enfant ne correspond plus, donc l'enfant est invalide, et tout ce qui suit l'est aussi. Réparer les dégâts suppose de miner à nouveau chacun de ces blocs, à raison d'environ 144 blocs par jour, soit 52 560 par an.

Le bloc de genèse est l'exception, et il doit l'être : rien ne le précède, le champ contient donc 32 octets nuls.

Rien dans un bloc ne pointe vers l'avant. Quand Bitcoin Core rapporte un nextblockhash, il lit son propre index, pas le bloc, et c'est précisément pourquoi cette valeur peut changer lors d'une réorganisation alors que le hash d'en-tête du bloc précédent ne change jamais. Deux blocs nommant le même parent ne constituent pas non plus une erreur. C'est à cela que ressemble une fourche du point de vue des données, et le réseau la résout en préférant la branche au travail cumulé le plus élevé plutôt qu'en déclarant l'un ou l'autre pointeur faux.

Où le voir

Le hash d'en-tête du bloc précédent apparaît sous des noms légèrement différents selon ce que vous consultez.

Bitcoin Core le renvoie sous le nom previousblockhash depuis getblockheader et getblock. Pour le bloc 0, le champ est simplement absent de la réponse, car il n'y a aucun parent à nommer. Les explorateurs de blocs l'étiquettent généralement Previous Block et en font un lien, ce qui permet de remonter l'historique en cliquant.

C'est aussi toute la substance d'une synchronisation de chaîne d'en-têtes. Un nœud qui télécharge des en-têtes vérifie deux choses par en-tête : que celui-ci nomme le dernier, et que son hash atteint la cible. Ce n'est qu'une fois cette chaîne cohérente qu'il commence à demander les corps de blocs. Les portefeuilles légers ne vont jamais plus loin, conservant les liens et le travail, rien d'autre.

Si vous construisez un jour ce champ à la main, attendez-vous à une dispute avec vos propres yeux, car les octets de l'en-tête ne sont pas écrits dans l'ordre dans lequel le hash est normalement cité.

Hash d'en-tête du bloc précédent vs ordre des octets interne

Le hash d'en-tête du bloc précédent est stocké dans l'ordre d'octets inverse de celui que tout le monde cite, ce qui déroute presque tous ceux qui tentent de vérifier un en-tête manuellement. Le bloc 1 porte le hash de son parent sous la forme 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000. Il s'agit du hash de genèse, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, écrit à l'envers octet par octet. Les zéros de tête que produit la preuve de travail se retrouvent à la fin dans le champ brut. Rien ne cloche lorsque les deux ne semblent pas correspondre : inversez les octets et ils correspondent.