Anatomie d'une blockchain

Une carte d'identité de 80 octets

Un bloc se compose d'un en-tête (petit, de taille fixe dans Bitcoin) et d'un corps (la liste des transactions). L'en-tête résume le bloc et le relie à la chaîne. Commençons par Bitcoin, dont le format est le plus simple : l'en-tête fait exactement 80 octets.

Les entiers de 4 octets sont en petit-boutiste : l'octet de poids faible vient en premier. L'empreinte du bloc (souvent appelée « hash du bloc ») est le SHA-256 appliqué deux fois à ces 80 octets. Dans Bitcoin, les explorateurs affichent ce résultat avec les octets en ordre inversé ; l'ordre « interne » est celui du calcul.

Lire des champs à la main

Version : les octets 00 00 00 20 lus en petit-boutiste donnent l'entier 0x20000000, soit 536 870 912 en décimal.

Horodatage : les octets 00 3c 9a 65 donnent 0x659a3c00 = 1 704 606 720 secondes, c'est-à-dire le 7 janvier 2024 à 05:52:00 UTC. (Valeur d'exemple choisie pour l'exercice, sans rapport avec un bloc précis.)

Nonce : les octets 2a 00 00 00 donnent 0x2a = 42.

L'outil bytes ci-dessous fait ces lectures pour vous : collez de l'hexadécimal, découpez des plages, lisez en petit- ou grand-boutiste, inversez l'ordre.

Le champ « bits » : la cible en format compact

Les 4 octets ff ff 00 1d se lisent 0x1d00ffff. L'octet de poids fort, 0x1d = 29, est l'exposant ; les trois suivants, 0x00ffff, sont la mantisse. La cible vaut mantisse × 256^(exposant − 3), ici 0xffff × 256^26. L'empreinte d'un bloc, lue comme un grand nombre, doit être inférieure ou égale à la cible. Une cible plus petite exige plus de zéros au début de l'empreinte affichée : c'est la difficulté.

Et ailleurs ?

Tous les réseaux n'ont pas cet en-tête. Un en-tête Ethereum contient, entre autres, l'empreinte du parent, une racine d'état, une racine des transactions, une racine des reçus, un numéro de bloc, un horodatage et des champs liés aux frais. Un en-tête CometBFT contient, entre autres, l'identifiant du bloc précédent, l'empreinte de l'ensemble des validateurs et un champ app_hash qui engage l'état de l'application. Les noms et les tailles changent ; l'idée reste la même : un petit objet qui s'engage sur tout le reste.

Ce que cela ne garantit PAS

• L'horodatage est annoncé par le mineur : il est contraint par des règles de tolérance, mais ce n'est pas une horloge exacte.
• Le champ version ne prouve pas qu'un mineur applique réellement les règles qu'il annonce.
• Une empreinte de bloc basse prouve du travail effectué, pas que les transactions du corps sont valides.

À retenir

L'en-tête est un engagement de 80 octets (dans Bitcoin) : parent, résumé des transactions, difficulté, nonce. Son double SHA-256 est l'identité du bloc.

Où va une transaction après « Envoyer » ?

Awa envoie 50 unités à Bineta depuis son téléphone. Rien n'est « envoyé » à Bineta : la transaction signée est diffusée dans un réseau pair à pair. Suivons-la.

1. Création et signature. Le portefeuille construit la transaction (destinataire, montant, frais, nonce) et la signe avec la clé privée d'Awa (atelier 105).
2. Diffusion. Le portefeuille l'envoie à un nœud, qui la relaie à ses pairs par bavardage (gossip) : chacun la transmet à ses voisins.
3. Validation locale. Chaque nœud vérifie, selon les règles de son réseau, la signature, la forme, le solde ou les entrées, le nonce (dans les modèles à comptes) et les frais avant de la garder ou de la relayer. Une transaction invalide est jetée.
4. Mempool. Les transactions valides mais non confirmées attendent dans le mempool (« memory pool », la file d'attente) du nœud. Il n'y a pas un mempool global : chaque nœud a le sien, qui peut différer légèrement de celui du voisin selon ce qu'il a reçu et ses propres règles.
5. Sélection. Le proposant du prochain bloc choisit des transactions dans son mempool, en général celles qui paient le mieux par unité d'espace, dans la limite de la taille du bloc.
6. Bloc et propagation. Il construit le bloc, calcule la racine de Merkle des transactions, remplit l'en-tête, fait ce que son consensus exige (loterie de hachage ou vote), puis diffuse le bloc.
7. Validation du bloc. Chaque nœud complet rejoue le bloc : en-tête valide, parent connu, chaque transaction valide.
8. Confirmation puis finalité. Le bloc devient la pointe de la chaîne ; ensuite, selon la famille (atelier 109), il gagne des confirmations ou est finalisé.

Exemple détaillé

Un bloc a une place pour 4 transactions (valeur de jeu). Le mempool d'un proposant contient : T1 frais 2, T2 frais 9, T3 frais 5, T4 frais 1, T5 frais 7, T6 frais 4. Il remplit le bloc par frais décroissants : T2 (9), T5 (7), T3 (5), T6 (4). T1 et T4 restent en attente du bloc suivant. Si Awa avait mis des frais de 1, sa transaction pourrait attendre longtemps : les frais sont le prix d'accès à un espace rare (atelier 111).

Et si le bloc est abandonné ?

Si une réorganisation remplace le bloc, ses transactions retournent dans le mempool, sauf si la branche gagnante les contient déjà. Une transaction peut alors changer de bloc, ou même, si elle entre en conflit avec une autre transaction déjà confirmée sur la branche gagnante, devenir invalide.

Ce que cela ne garantit PAS

• Être dans un mempool ne garantit pas l'inclusion : un nœud peut expulser des transactions quand sa file est pleine.
• Voir sa transaction dans votre nœud ne veut pas dire que les autres la voient.
• Aucun nœud n'est obligé d'inclure une transaction précise : un proposant peut la censurer, et le réseau compte sur la rotation des proposants.
• « Inclus dans un bloc » n'est pas « finalisé » : voir l'atelier 109.

À retenir

Signer, diffuser, valider, attendre dans le mempool de chaque nœud, être choisi, être mis dans un bloc, voir ce bloc validé par tous, puis gagner en finalité. Chaque étape a sa propre garantie, aucune n'implique la suivante.

Deux choses à ne pas confondre : transactions et état

Les transactions sont des événements (« Awa paie 50 à Bineta »). L'état est le résultat de tous les événements depuis la genèse : qui possède quoi maintenant. Dans un modèle à comptes (atelier 111), l'état est, par exemple, la table des soldes et des nonces. Un nœud qui rejoue toutes les transactions reconstruit l'état. Mais comment deux nœuds vérifient-ils rapidement qu'ils sont d'accord sur cet état ?

L'idée : une empreinte de l'état

On organise l'état en arbre de Merkle (atelier 106), dont les feuilles sont les comptes. La racine de cet arbre est la racine d'état (state root). Un en-tête qui contient la racine d'état s'engage sur l'état de tous les comptes après ce bloc.

Exemple jouet : quatre comptes, feuille = « nom:solde:nonce ».

Awa a payé 50 plus 1 de frais à un proposant (qui a ici le compte Dayo, qui reçoit 1) : le solde d'Awa passe de 200 à 149, son nonce de 7 à 8, Bineta gagne 50, Dayo gagne 1. Ces trois feuilles changent, donc la racine change. Si deux nœuds calculent la même racine après le même bloc, ils ont le même état ; s'ils obtiennent deux racines différentes, au moins un des deux a exécuté le bloc autrement. Essayez dans merkle-explorer : modifiez une feuille et regardez la racine changer.

À quoi sert la racine d'état ?

1. Accord rapide : comparer 32 octets suffit à vérifier que deux nœuds ont le même état.
2. Preuves pour clients légers : un client qui ne garde que les en-têtes peut recevoir un solde accompagné d'une preuve de Merkle et la vérifier contre la racine de l'en-tête.
3. Synchronisation : un nouveau nœud peut vérifier un instantané d'état contre une racine.

Tous les réseaux n'en ont pas la même

• Dans Bitcoin, l'en-tête ne contient pas de racine d'état : il contient la racine de Merkle des transactions. Pour savoir ce qui n'est pas encore dépensé, les nœuds complets maintiennent l'ensemble des sorties non dépensées (UTXO) localement, sans que l'en-tête s'y engage.
• Dans Ethereum, l'en-tête contient une racine d'état, ainsi qu'une racine des transactions et une racine des reçus. L'état y est organisé en un arbre plus élaboré qu'un arbre de Merkle binaire (un trie de Merkle-Patricia), mais le principe d'engagement est le même.
• Dans CometBFT (Cosmos), l'en-tête contient un champ app_hash, calculé par l'application, qui engage l'état de l'application. Le calcul est effectué avec un décalage : le app_hash d'un bloc reflète l'état après l'exécution du bloc précédent.

Ce que cela ne garantit PAS

• Une racine d'état dans un en-tête ne prouve pas qu'elle est correcte : seule l'exécution des transactions la vérifie. Un mineur ou un validateur malveillant peut proposer une racine fausse ; les nœuds complets la rejettent en rejouant le bloc.
• Un client léger qui vérifie une preuve contre une racine suppose que l'en-tête, lui, est valide (consensus).
• La racine d'état ne dit pas pourquoi l'état a changé : il faut les transactions pour l'historique.

À retenir

Transactions = événements, état = conséquences, racine d'état = empreinte unique des conséquences. C'est ce qui permet à des nœuds de se mettre d'accord, et à des clients légers de vérifier un solde.

Le client qui ne télécharge que les en-têtes

Un téléphone à connexion mesurée ne peut pas télécharger des centaines de gigaoctets de blocs. Le chapitre sur la vérification de paiement simplifiée de l'article de Nakamoto (Bitcoin: A Peer-to-Peer Electronic Cash System) décrit un client qui garde seulement les en-têtes de la plus longue chaîne (en pratique, celle qui cumule le plus de travail) et demande une branche de Merkle pour une transaction qui l'intéresse. Que peut-il vraiment conclure ?

Ce qu'un en-tête permet de vérifier à lui seul

• Le lien avec le parent : l'empreinte du parent est dans l'en-tête, donc une chaîne d'en-têtes se vérifie de proche en proche.
• Le travail (preuve de travail) : l'empreinte de l'en-tête est-elle sous la cible, et cette cible est-elle bien celle que les règles d'ajustement de difficulté exigent à cette hauteur ? Un en-tête qui déclare lui-même une cible très facile ne prouve presque rien : il faut aussi comparer le champ bits à celui des blocs précédents. Le calcul à refaire reste un double SHA-256 de 80 octets.
• L'inclusion d'une transaction, avec une preuve de Merkle : la transaction est-elle sous la racine de l'en-tête ? (atelier 106)
• Un solde, dans un réseau qui a une racine d'état, avec une preuve contre cette racine.

Ce qui exige encore le corps (et l'exécution)

• La validité des transactions : signatures correctes, pas de double dépense, soldes suffisants. Un en-tête peut s'engager sur des transactions invalides.
• L'exactitude de la racine d'état : seule l'exécution des transactions la vérifie.
• La disponibilité des données : l'en-tête ne prouve pas que le corps a été publié.
• L'absence d'une transaction : une preuve d'inclusion montre qu'un élément est présent, pas qu'un autre est absent (sauf structure particulière : atelier 106).
• Le fait d'être sur la bonne chaîne : un client léger voit les en-têtes que ses pairs lui montrent ; si tous sont malveillants ou s'il est éclipsé (atelier 107), il peut suivre une chaîne que le reste du monde a abandonnée.

Exemple : une preuve qui échoue

Le client reçoit une transaction T, sa preuve (les frères à chaque niveau) et la racine annoncée par l'en-tête. Il recalcule : empreinte de T, puis combine avec chaque frère, du bas vers le haut. Si le résultat final égale la racine, T est dans le bloc ; sinon, soit la transaction a été modifiée, soit la preuve est fausse, soit le serveur ment. Un seul octet de T modifié change le résultat (avalanche, atelier 104). Vous le ferez dans l'exercice de sécurité.

Ce que cela ne garantit PAS

• Une preuve de Merkle valide ne dit rien sur la profondeur du bloc ni sur sa finalité : il faut aussi savoir où l'en-tête se situe dans la chaîne.
• Elle ne dit pas que la transaction a réussi : dans les chaînes à contrats, une transaction incluse peut avoir échoué à l'exécution (le reçu l'indique).
• Les clients légers font confiance au consensus : si la majorité de la puissance (ou plus d'un tiers des validateurs) est malveillante, un en-tête invalide peut paraître valide.

À retenir

L'en-tête prouve le lien, un travail conforme à la cible exigée ou la signature du consensus, et (avec une preuve) l'inclusion. Il ne prouve ni la validité des transactions, ni l'exactitude de l'état, ni la disponibilité des données.