Le vendredi 23 octobre 2026 à 08:41:36 UTC, un mineur a ajouté le bloc 972 742 à la blockchain de Bitcoin. pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">Il contenait 6 179 transactions et pesait 1 602 946 octets, d’après l’explorateur public mempool.space, qui l’attribue au pool de minage AntPool. Pourtant, la partie que tous les nœuds du réseau vérifient en premier, et la seule que les mineurs hachent sans cesse pendant qu’ils cherchent un bloc valide, mesure 80 octets. On l’appelle l’en-tête de bloc.
Alors, qu’est-ce qu’un bloc ? Un en-tête suivi d’une liste de transactions. L’en-tête est une courte étiquette de six champs, toujours longue de 80 octets sur Bitcoin. La liste, appelée corps du bloc, peut contenir une seule transaction ou plusieurs milliers, et elle commence toujours par une transaction spéciale qui crée de nouvelles pièces. L’étiquette s’engage sur toute la liste grâce à une empreinte unique de 32 octets, la racine de Merkle : modifier un seul octet d’une seule transaction changerait aussi l’étiquette.
Notre leçon sur le fonctionnement d’une blockchain a décrit la chaîne elle-même : comment les empreintes relient les blocs entre eux et pourquoi des milliers d’ordinateurs gardent une copie du même registre. Celle-ci reste à l’intérieur d’un seul bloc, le 972 742, ouvert champ par champ, avec un bloc Ethereum du même matin pour comparer. Tous les chiffres ci-dessous ont été relevés le 23 octobre 2026.
Un bloc blockchain, c’est un en-tête de 80 octets et une liste de transactions
Pensez à un colis muni d’une étiquette d’expédition. Le carton peut être petit ou lourd ; l’étiquette, elle, comporte toujours les mêmes cases à remplir. Sur Bitcoin, elle en a six, dont les tailles ne varient jamais : c’est pourquoi tous les en-têtes Bitcoin depuis 2009 mesurent exactement 80 octets.
| Champ | Taille | Ce qu’il enregistre |
|---|---|---|
| Version | 4 octets | le jeu de règles de validation que le bloc suit |
| Hash du bloc précédent | 32 octets | l’empreinte du bloc qui le précède |
| Racine de Merkle | 32 octets | une empreinte unique qui résume toutes les transactions du corps |
| Heure (time) | 4 octets | un horodatage en secondes, fixé par le mineur dans des limites |
| Bits | 4 octets | la cible que le hash du bloc doit rester en dessous, sous forme compacte |
| Nonce | 4 octets | un nombre que le mineur change jusqu’à ce que le hash respecte la cible |
Faisons la somme : 4 + 32 + 32 + 4 + 4 + 4 = 80. La documentation de référence pour les développeurs Bitcoin (en anglais) liste les mêmes six champs dans le même ordre, et cet ordre compte, car l’identité du bloc, son hash, se calcule sur ces 80 octets et rien d’autre.
Le corps vient après l’en-tête. Il commence par un compteur qui indique combien de transactions suivent, puis les transactions elles-mêmes, les unes après les autres. Le bloc 0, le tout premier, créé le 3 janvier 2009, contenait une seule transaction et pesait 285 octets en tout ; son histoire complète est racontée dans notre leçon sur le bloc de genèse et la crise de 2008. Le bloc 972 742 en contenait 6 179. Les deux ont un en-tête de 80 octets.
L’en-tête ne contient pas les transactions. Il en contient une empreinte. Un nœud qui ne détient que l’en-tête peut vérifier plus tard n’importe quelle transaction qu’on lui présente en la comparant à cette empreinte, sans avoir à faire confiance à celui qui la lui envoie.
Le bloc 972 742 lu champ par champ
Un explorateur affiche chaque bloc de deux façons : une page lisible, pleine de chiffres, et, sur demande, les octets bruts. L’en-tête brut du bloc 972 742, renvoyé par l’interface de mempool.space le 23 octobre 2026, est une chaîne de 160 caractères hexadécimaux (deux caractères par octet). Découpé en six champs, il se lit ainsi.
| Champ | Octets bruts (hexadécimal, tels que stockés) | Lecture |
|---|---|---|
| Version | 00a00320 | 0x2003a000, soit 537 108 480 |
| Hash du bloc précédent | 9da364f8 … 310c0000 00000000 00000000 | 0000…0c31167384b4…f864a39d (bloc 972 741) |
| Racine de Merkle | fae40539 … 84070b67 | 670b0784f7d7…3905e4fa |
| Heure | c01ddb6a | 1 792 744 896, soit le 23 octobre 2026 à 08:41:36 UTC |
| Bits | 93000217 | 0x17020093 |
| Nonce | 2e06d2b1 | 2 983 331 374 |
Un détail fait trébucher presque tous ceux qui comparent les octets bruts à la page de l’explorateur : l’ordre des octets est inversé. Les nombres sont stockés en little-endian, l’octet de poids faible d’abord, si bien que les quatre octets de version 00 a0 03 20 se lisent 0x2003a000 une fois retournés. Les hashes sont conservés dans ce que la documentation de référence appelle l’ordre d’octets interne, et les explorateurs les affichent à l’envers. Retournez la racine de Merkle brute fae40539… octet par octet et vous obtenez le 670b0784… que montre la page du bloc.
La vérification qui relie le tout tient en quelques lignes de code. Appliquez deux fois SHA-256 à ces 80 octets, retournez le résultat, et vous obtenez 00000000000000000000a1bf4e832b290e803eb681fd3fd0d48a845e141cc803, le hash que l’explorateur donne pour le bloc 972 742. Nous l’avons fait le 23 octobre 2026 : les deux valeurs concordent. Chaque nœud du réseau fait la même opération avant d’accepter le bloc.
Version : les règles que suit le bloc
Les quatre premiers octets indiquent aux nœuds quel jeu de règles de validation le bloc affirme suivre. La valeur 0x2003a000 commence par le motif de bits 001, la convention introduite par la proposition BIP9 : les bits restants peuvent être activés par les mineurs pour signaler qu’ils sont prêts pour un soft fork, une modification des règles compatible avec les anciennes versions. L’en-tête ne dit pas à lui seul quelle mise à jour, le cas échéant, ces bits désignent en octobre 2026, et cette leçon n’essaie pas de le décoder.
Hash du bloc précédent : le lien vers le bloc 972 741
Les 32 octets suivants sont le hash de l’en-tête du bloc 972 741, miné à 08:37:13 UTC le même matin avec 3 427 transactions, 4 minutes et 23 secondes avant le nôtre. Ce champ est la « chaîne » de la blockchain. Comme chaque en-tête inclut le hash du précédent, modifier un ancien bloc changerait son hash, casserait le lien enregistré dans l’en-tête suivant, et ainsi de suite jusqu’à aujourd’hui. La leçon sur le fonctionnement d’une blockchain suit cette réaction en chaîne en détail ; une leçon ultérieure de ce parcours explique pourquoi elle rend l’historique si difficile à réécrire.
Remarquez la longue suite de zéros au début des deux hashes. Le hash du bloc 972 742 commence par 20 chiffres hexadécimaux nuls, soit 80 bits à zéro. Ce n’est pas un hasard : c’est l’objet des deux champs suivants.
Racine de Merkle : une empreinte pour 6 179 transactions
Le troisième champ, 670b0784…3905e4fa une fois affiché à l’endroit, est la racine de Merkle. Elle se calcule à partir des identifiants des 6 179 transactions, dans leur ordre exact, repliés deux par deux jusqu’à ce qu’il ne reste qu’une valeur de 32 octets. Nous l’avons recalculée le 23 octobre 2026 à partir de la liste des identifiants publiée par mempool.space et obtenu la valeur de l’en-tête. Le mécanisme de repliement, et son utilité, sont expliqués dans une section dédiée plus bas.
Heure : un horodatage Unix aux règles souples
L’horodatage est un nombre de secondes écoulées depuis le 1er janvier 1970 à minuit UTC, la façon habituelle dont les ordinateurs stockent l’heure. Pour le bloc 972 742, il vaut 1 792 744 896, ce qui donne le vendredi 23 octobre 2026 à 08:41:36 UTC.
Personne n’attend ici une lecture d’horloge précise, et le réseau ne l’exige pas. La documentation de référence demande qu’il soit strictement supérieur à l’heure médiane des 11 blocs précédents, soit 1 792 742 614 (08:03:34 UTC) pour notre bloc. Le wiki Bitcoin (en anglais) ajoute une borne haute : moins que l’heure ajustée du réseau plus deux heures. Entre ces deux limites, les mineurs sont libres de la déplacer, et ils le font, en la mettant à jour toutes les quelques secondes pendant qu’ils cherchent un hash valide. Comme la règle porte sur la médiane et non sur le bloc juste avant, un bloc peut même porter une heure antérieure à celle de son prédécesseur.
Bits : la cible, écrite sous forme compacte
Les plans de cours appellent souvent ce champ la cible de difficulté, un nom un peu trompeur. L’en-tête ne stocke pas le nombre de la difficulté. Il stocke les « bits », un encodage de la cible que le hash du bloc doit égaler ou ne pas dépasser. La documentation de référence décrit ce format comme une notation scientifique en base 256 : le premier octet est un exposant, les trois autres une mantisse.
Pour le bloc 972 742, les bits valent 0x17020093. L’exposant 0x17 vaut 23, la mantisse 0x020093 ; la cible est donc 0x020093 multiplié par 256 puissance 20. Écrite en entier, c’est un nombre de 256 bits dont les 78 premiers bits sont des zéros. Le hash du bloc, lu comme un nombre, lui est inférieur ; nous l’avons vérifié. Tout hash supérieur aurait été rejeté par chaque nœud.
La difficulté se déduit de cette cible : elle dit combien de fois la cible actuelle est plus difficile à atteindre que la plus facile que le protocole autorise, celle du bloc 0, fixée à la difficulté 1. Pour le bloc 972 742, mempool.space donne une difficulté de 140 577 680 051 919,62, soit environ 140 600 milliards. Elle a été fixée au bloc 971 712 le 16 octobre 2026 à 12:37 UTC, en hausse de 5,92 %. Bitcoin la recalcule tous les 2 016 blocs, soit deux semaines au rythme prévu d’un bloc toutes les dix minutes, selon le wiki Bitcoin (en anglais). Le prochain recalcul tombe au bloc 973 728, 986 blocs après le nôtre. Pour la course au minage elle-même, voyez notre fiche du glossaire sur la preuve de travail.
Nonce : le nombre que les mineurs ne cessent de changer
En cryptographie, un nonce est un « nombre utilisé une seule fois » (de l’anglais number used once). Le mot n’a rien à voir avec le nonce apostolique ni avec « énoncé » : c’est un terme technique, resté en anglais. Dans un en-tête Bitcoin, ce sont les quatre derniers octets, et leur seul rôle est d’être modifiés. Le mineur remplit les cinq autres champs, fixe le nonce à une valeur, hache deux fois les 80 octets avec SHA-256 et compare le résultat à la cible. Trop haut ? Il change le nonce et recommence. Le nonce gagnant du bloc 972 742 était 2 983 331 374. Il n’a aucun sens en lui-même ; il se trouve simplement qu’il produisait un hash inférieur à la cible, les autres champs étant ce qu’ils étaient.
Quatre octets autorisent 232 valeurs, soit 4 294 967 296 en tout. Avec une difficulté supérieure à 140 000 milliards, c’est bien trop peu : la plupart du temps, toutes échouent. La page du wiki Bitcoin sur l’algorithme de hachage des blocs (en anglais) explique la suite. Quand le nonce est épuisé, le mineur modifie un champ appelé extraNonce dans la première transaction du corps. Cette transaction change, donc son identifiant change, donc la racine de Merkle change, et le mineur obtient un nouvel en-tête avec 4,3 milliards de nonces neufs à essayer. Mettre à jour l’horodatage produit un effet comparable.
Le mot a un second sens sur Ethereum, où chaque compte possède un nonce qui compte les transactions qu’il a envoyées. Ce compteur n’a rien à voir avec le minage ; le nonce de l’en-tête Bitcoin est celui que décrit cette leçon.
Le corps du bloc : 6 179 transactions, dont la première crée des pièces
Juste après l’en-tête vient la liste. La documentation de référence fixe une règle ferme pour son ordre : la première transaction d’un bloc doit être une transaction coinbase. La coinbase est celle par laquelle le mineur se paie lui-même. Elle ne dépense aucune pièce existante. Son unique entrée est un simple emplacement, et ses sorties envoient la récompense du bloc vers des adresses que le mineur a choisies.
Dans le bloc 972 742, la coinbase (identifiant 97a170a9…33386cb5) a versé 313 361 901 satoshis, soit 3,13361901 BTC, un satoshi valant un cent-millionième de bitcoin. Cette somme a deux parts, et l’arithmétique tombe juste :
- la subvention du bloc, 3,125 BTC (312 500 000 satoshis), de nouveaux bitcoins qui n’existaient pas avant ce bloc ;
- les frais payés par les 6 178 autres transactions, 861 901 satoshis au total, soit 0,00861901 BTC.
Une coinbase qui tenterait de verser plus que la subvention plus les frais rendrait tout le bloc invalide. La subvention vaut 3,125 BTC depuis le bloc 840 000, miné le 20 avril 2024, et elle est divisée par deux tous les 210 000 blocs, d’après le tableau de l’offre du wiki Bitcoin (en anglais). Au bloc 1 050 000, environ 77 000 blocs après le nôtre, elle tombera à 1,5625 BTC ; à dix minutes par bloc, cela représente à peu près un an et demi. Notre fiche du glossaire sur le halving du bitcoin détaille le calendrier et son historique. Nous ne donnons ici aucune valeur en euros pour la récompense : elle n’aurait de sens qu’avec le cours d’une minute précise.
La coinbase a un second usage. Son entrée porte un champ libre, dans lequel les mineurs écrivent. Décodée, la coinbase du bloc 972 742 contient le texte lisible « Mined by AntPool ». Ce texte est dans le bloc, alors que le nom du pool affiché par mempool.space est l’étiquette de l’explorateur. Ni l’un ni l’autre ne prouve qui faisait tourner les machines, mais les deux concordent. La même coinbase porte aussi des sorties de valeur nulle qui stockent des données, dont un engagement sur les données de témoin SegWit du bloc, abordées dans la section sur la taille.
Les 6 178 autres transactions sont des paiements et des transferts ordinaires. Ensemble, elles ont dépensé 8 155 entrées (des sorties antérieures consommées) et créé 12 724 nouvelles sorties, pour une taille moyenne d’environ 259 octets par transaction. La façon dont une transaction est construite, signée et tarifée, et la raison pour laquelle elle peut attendre avant d’être retenue, font l’objet de notre guide sur le fonctionnement des transactions crypto. Ce qui compte ici, c’est que le mineur a choisi les transactions à inclure et leur ordre, et que cet ordre est verrouillé dans la racine de Merkle.
L’arbre de Merkle : comment 6 179 empreintes se replient en une seule
Chaque transaction a un identifiant, son txid : le double hash SHA-256 de la transaction, sur 32 octets. Un bloc aurait pu les stocker tous dans l’en-tête, mais 6 179 txid pèsent près de 200 ko. L’arbre de Merkle, du nom du cryptographe Ralph Merkle, dont l’article de 1980 est cité par le livre blanc de Bitcoin, les comprime en un seul hash.
Prenons un petit bloc de huit transactions, de A à H. Dessinez l’arbre à l’envers, racine en haut. Sur la rangée du bas se trouvent les huit txid. Appariez-les depuis la gauche : A avec B, C avec D, E avec F, G avec H. Pour chaque paire, mettez les deux hashes bout à bout et hachez le résultat deux fois : cela donne quatre nouveaux hashes, AB, CD, EF et GH, sur la rangée du dessus. Recommencez et vous en obtenez deux, ABCD et EFGH. Encore une fois, et il n’en reste qu’un au sommet. Ce hash du sommet est la racine de Merkle inscrite dans l’en-tête. Huit feuilles, trois tours d’appariement.
Et si une rangée compte un nombre impair de hashes ? La règle de la documentation de référence est simple : le dernier txid est concaténé avec une copie de lui-même, puis haché. Avec cinq transactions, de A à E, la rangée du bas apparie A-B et C-D, puis E avec une copie de E. La rangée du dessus compte trois hashes, donc le troisième est de nouveau apparié avec lui-même, et ainsi de suite jusqu’à ce qu’il n’en reste qu’un.
Le bloc 972 742 a demandé 13 tours. Les rangées se réduisent ainsi : 6 179 txid, puis 3 090, 1 545, 773, 387, 194, 97, 49, 25, 13, 7, 4, 2 et enfin 1. Neuf de ces rangées avaient un nombre impair d’éléments et ont dupliqué leur dernier hash. Nous avons refait les 13 tours à partir de la liste publiée et obtenu 670b0784…3905e4fa, la valeur de l’en-tête.
Deux propriétés découlent de cette conception. D’abord, tout changement au bas de l’arbre remonte jusqu’au sommet : modifiez un octet d’une transaction et son txid change, puis le hash de sa paire, puis tous les hashes au-dessus, jusqu’à la racine. L’en-tête ne correspondrait plus au corps, et les nœuds rejetteraient le bloc. Ensuite, prouver qu’une transaction figure dans le bloc demande très peu de données. Pour montrer que C appartient au bloc de huit transactions, il suffit de D, AB et EFGH : avec C, vous reconstruisez CD, puis ABCD, puis la racine, et vous la comparez à l’en-tête. Un hash par tour.
Pour le bloc 972 742, une telle preuve, appelée branche de Merkle, tient en 13 hashes de 32 octets, soit 416 octets, plus l’en-tête de 80 octets : moins de 500 octets pour confirmer une transaction parmi un bloc de 1,6 Mo. Le livre blanc de Bitcoin (en anglais) s’appuie exactement là-dessus dans sa section 8, « Simplified Payment Verification » : un portefeuille léger ne garde que les en-têtes de blocs et demande au réseau la branche de Merkle des paiements qui le concernent. À quoi sert l’arbre de Merkle ? À cela : vérifier beaucoup avec peu.
Quelle est la taille d’un bloc Bitcoin ? De 1 Mo à 4 millions d’unités de poids
Demandez quelle taille peut atteindre un bloc Bitcoin et vous lirez souvent « 1 Mo ». C’était la règle pendant des années, et la documentation de référence la cite encore : un bloc n’est pas valide si sa taille sérialisée dépasse 1 Mo. Le bloc 972 742, avec ses 1 602 946 octets, l’aurait enfreinte. Il n’a rien enfreint, parce que la règle a changé en 2017.
Ce changement, c’est Segregated Witness, ou SegWit, défini dans le BIP141 (en anglais) et actif depuis le bloc 481 824, miné le 24 août 2017. SegWit a déplacé les signatures et les données associées d’une transaction, le « témoin » (witness), dans une partie distincte de la transaction, et remplacé la limite de taille par une limite de poids. Selon le BIP141, le poids d’un bloc est sa taille de base multipliée par 3, plus sa taille totale. La taille de base est celle du bloc sans les données de témoin, la taille totale celle du bloc avec. La règle : le poids du bloc ne doit pas dépasser 4 000 000.
En clair, chaque octet de données de témoin compte une fois, et chaque autre octet compte quatre fois. Les données de témoin bénéficient donc d’une remise de 75 %. Les explorateurs expriment le résultat en unités de poids (weight units, WU) ou le divisent par quatre pour obtenir des octets virtuels (vB), une unité comparable à l’ancienne règle de 1 Mo.
Le bloc 972 742 montre comment cela se passe. Son poids était de 3 994 021 WU, soit 99,85 % de la limite : le bloc était plein. Sa taille virtuelle était de 998 505,25 vB, juste sous le million d’autrefois. Sa taille réelle était de 1,6 million d’octets, car 6 119 de ses 6 179 transactions utilisaient SegWit. En remontant la formule, environ 797 025 octets étaient des données de base et environ 805 921 octets des données de témoin.
| Mesure (bloc 972 742, 23 octobre 2026) | Valeur |
|---|---|
| Transactions | 6 179 |
| Taille en octets | 1 602 946 |
| Poids | 3 994 021 WU (limite : 4 000 000) |
| Taille virtuelle | 998 505,25 vB |
| Transactions SegWit | 6 119 |
| En-tête | 80 octets |
| Récompense versée par la coinbase | 3,13361901 BTC (3,125 de subvention + 0,00861901 de frais) |
Il n’y a donc pas de réponse fixe en octets. Un bloc rempli de petites transactions sans données de témoin reste proche de 1 Mo ; un bloc riche en données de témoin peut aller bien au-delà. Ce qui est fixe, c’est le poids, et fin octobre 2026 les blocs le touchaient.
Pourquoi plafonner ? Une limite plus haute laisserait entrer plus de transactions, mais chaque nœud doit télécharger, vérifier et stocker chaque bloc, pour toujours. Le plafond maintient ce travail à la portée d’un ordinateur et d’une connexion internet ordinaires, pour que la vérification de la chaîne ne soit pas réservée aux centres de données. Son coût, c’est la concurrence : quand plus de transactions attendent qu’un bloc ne peut en contenir, les expéditeurs enchérissent avec leurs frais, et le mineur retient l’ensemble le plus rentable qui tienne sous 4 000 000 WU.
Pourquoi l’en-tête est limité à 80 octets
La taille de l’en-tête était un choix de conception dès le départ. La section 7 du livre blanc, « Reclaiming Disk Space », introduit l’arbre de Merkle pour qu’un jour les anciennes transactions dépensées puissent être élaguées sans que le hash du bloc cesse d’être valide. Satoshi Nakamoto y fait ensuite le calcul : un en-tête de bloc sans transaction pèserait environ 80 octets. À un bloc toutes les dix minutes, cela fait 80 octets fois 6 fois 24 fois 365, soit 4,2 Mo par an.
L’estimation a tenu. Le 23 octobre 2026, il y avait 972 743 blocs du bloc 0 au bloc 972 742 : les en-têtes de toute l’histoire de Bitcoin totalisent donc environ 77,8 millions d’octets, moins de 80 Mo. Un téléphone les stocke sans peine, et c’est ce qui rend possibles les portefeuilles légers : garder tous les en-têtes, vérifier que chacun pointe vers le précédent et respecte sa cible, et ne demander des branches de Merkle qu’en cas de besoin. Notre leçon sur le livre blanc de Bitcoin expliqué parcourt le reste du document.
Un bloc Ethereum du même matin fonctionne autrement
Toutes les blockchains ont des blocs, mais pas toutes la même étiquette. Douze minutes avant le bloc Bitcoin 972 742, à 08:29:11 UTC le 23 octobre 2026, Ethereum a produit le bloc 26 254 134. Nous l’avons lu via un nœud Ethereum public (publicnode.com). Il contenait 444 transactions et 16 retraits de staking, pour 382 756 octets.
| Bloc Bitcoin 972 742 | Bloc Ethereum 26 254 134 | |
|---|---|---|
| Heure (23 octobre 2026, UTC) | 08:41:36 | 08:29:11 |
| Transactions | 6 179 | 444 (plus 16 retraits) |
| Taille | 1 602 946 octets | 382 756 octets |
| Règle de capacité | 4 000 000 unités de poids | 60 000 000 de gaz (56 884 349 utilisés) |
| Rythme | environ 10 minutes en moyenne | un créneau toutes les 12 secondes |
| Qui ajoute le bloc | un mineur, par preuve de travail | un validateur, par preuve d’enjeu |
| Nonce | 2 983 331 374 | 0 (champ conservé, inutilisé) |
| Racines dans l’en-tête | une racine de Merkle (transactions) | racines d’état, de transactions, de reçus et de retraits |
Trois différences ressortent. La première tient à la façon de choisir le bloc. Depuis la Fusion (the Merge) du 15 septembre 2022, Ethereum utilise la preuve d’enjeu : le temps est découpé en créneaux de 12 secondes, et un validateur tiré au sort pour le créneau propose le bloc. Personne ne cherche de nonce, si bien que le champ nonce ne contient que des zéros et que le champ difficulté vaut 0 ; les deux subsistent par compatibilité.
La deuxième concerne le décompte de la capacité. Ethereum mesure le travail de calcul des transactions en gaz plutôt que leur taille en octets. Selon ethereum.org (en anglais), chaque bloc a un objectif de 30 millions de gaz et une limite de 60 millions ; celui-ci en a consommé 56,9 millions sur 60, soit environ 94,8 %. Ses frais de base étaient de 57 247 900 wei par unité de gaz, environ 0,057 gwei. Notre fiche du glossaire sur les frais de gaz explique ces unités.
La troisième porte sur ce à quoi l’en-tête s’engage. L’en-tête de Bitcoin n’a qu’une racine, celle des transactions. L’en-tête d’exécution d’Ethereum en porte plusieurs, dont une racine d’état qui résume tous les soldes de comptes et tous les contrats après le bloc, une racine des transactions et une racine des reçus qui consigne le résultat de chaque transaction. Elles sont construites avec un cousin de l’arbre de Merkle, mais le principe est le même : un hash court dans l’en-tête qui représente un ensemble de données bien plus vaste. Bitcoin n’a pas de racine d’état du tout, une différence qui vient de la façon dont chaque réseau suit qui possède quoi. Notre guide d’Ethereum décrit ce réseau plus largement.
Lire un bloc soi-même dans un explorateur
Rien dans cette leçon n’a demandé d’accès particulier. Les blocs Bitcoin sont publics, et des explorateurs comme mempool.space, dont le code est ouvert, les affichent gratuitement et sans compte. Consulter un explorateur n’est pas un service financier : aucune pièce d’identité n’est demandée, à la différence de la plateforme où vous achetez vos bitcoins, qui doit être agréée ou enregistrée auprès d’un régulateur, l’AMF en France (voir notre guide du règlement MiCA). Pour refaire l’exercice sur n’importe quel bloc :
- Ouvrez l’explorateur et saisissez une hauteur de bloc, par exemple 972742, dans la barre de recherche. La hauteur est simplement la position du bloc : le bloc 0 est le premier, donc le bloc 972 742 est précédé de 972 742 blocs.
- Sur la page du bloc, repérez les champs de l’en-tête : le hash du bloc précédent (souvent un lien vers lui), la racine de Merkle, l’horodatage, les bits, le nonce et la version, parfois derrière un bouton « détails ».
- Regardez la liste des transactions. La première entrée est la coinbase ; sa sortie est la subvention plus le total des frais indiqué pour le bloc.
- Comparez taille et poids. Divisez le poids par 4 000 000 pour voir à quel point le bloc était plein.
Ceux qui programment peuvent aller un cran plus loin, comme nous l’avons fait pour cette leçon : télécharger l’en-tête brut de 80 octets, le hacher deux fois avec SHA-256, retourner les octets et comparer le résultat au hash du bloc. Cela prend quelques lignes dans la plupart des langages et transforme les affirmations de la leçon en quelque chose que vous avez vérifié vous-même.
Le prochain recalcul de la difficulté est prévu au bloc 973 728, vers le 30 octobre 2026 si les blocs gardent un rythme de dix minutes. Une leçon ultérieure de ce parcours fait le pas suivant : pourquoi les liens entre ces en-têtes rendent un ancien bloc pratiquement impossible à modifier.
