Fondamentaux de la blockchain : hachage, consensus, finalité et compromis

Retirez les graphiques de cours et le vocabulaire, et il reste une question étroite mais réellement difficile, à laquelle une blockchain répond : comment un groupe de parties qui ne se font pas confiance, et qui ne peuvent s'en remettre à aucune autorité unique, peuvent-elles s'accorder sur une même liste ordonnée de faits ? La recherche en systèmes distribués étudie ce problème depuis des décennies. La nouveauté de 2008 fut une manière de le résoudre dans un réseau ouvert où n'importe qui peut entrer, sortir ou mentir, sans savoir à l'avance qui sont les participants.

Cette solution a un coût réel, et c'est en comprenant à la fois le mécanisme et son coût qu'on passe de l'enthousiasme à un jugement d'ingénieur utile. Ce guide explique la mécanique en partant des primitives cryptographiques, compare honnêtement les familles de consensus et se termine par les cas où la bonne réponse est « utilisez une base de données ». Le versant programmable — contrats, gas, tokens — est traité dans Ethereum et les smart contracts.

Le problème de l'accord

Imaginez un registre partagé sans propriétaire. N'importe qui peut proposer des entrées ; certains participants sont hors ligne, d'autres malveillants, et les messages arrivent dans le désordre, voire pas du tout. Deux participants honnêtes doivent pourtant aboutir à un historique identique — sinon, une même unité de valeur pourrait être dépensée deux fois, une fois dans chaque version.

Les protocoles classiques résolvent ce problème au sein d'un ensemble connu de participants, en tolérant qu'une fraction d'entre eux se comporte de façon arbitraire. Leur limite tient justement à ce mot « connu » : dans un réseau ouvert, un attaquant peut créer autant d'identités qu'il le souhaite et mettre tout le monde en minorité. L'idée fondatrice des blockchains publiques consiste à rendre la participation à la décision coûteuse et mesurable — en brûlant de l'électricité ou en immobilisant du capital — pour que l'influence soit proportionnelle à une ressource rare plutôt qu'au nombre de noms que l'on invente.

Tout le reste en découle : la structure des blocs existe pour rendre l'historique peu coûteux à vérifier, les incitations pour rendre le comportement honnête plus rentable que l'attaque, et les caractéristiques de performance sont le prix à payer pour une participation ouverte.

Les briques cryptographiques

Trois primitives font tout le gros du travail. Aucune n'est propre aux blockchains ; c'est leur combinaison qui l'est.

Les fonctions de hachage cryptographiques associent à n'importe quelle entrée une empreinte de longueur fixe, de manière déterministe et irréversible, avec cette propriété : toute modification de l'entrée produit une sortie complètement différente.

sha256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
sha256("hellp") = fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7

Une lettre a changé et plus aucun bit de sortie n'a de rapport avec
les précédents. C'est l'effet avalanche, et c'est lui qui fait de
l'empreinte un témoin capable de trahir la moindre altération d'un
document, d'un bloc ou de tout un historique.

Vous pouvez l'essayer vous-même avec le générateur de hash, qui tourne dans le navigateur : collez un paragraphe, changez une virgule et comparez les empreintes.

Les signatures numériques garantissent l'authenticité sans secret partagé. Le détenteur d'une clé privée signe un message ; quiconque possède la clé publique correspondante peut vérifier la signature, mais ne peut pas en fabriquer une. Sur une blockchain, une adresse est dérivée d'une clé publique : « posséder » un actif ne signifie donc rien de plus que détenir la clé privée capable d'en autoriser le transfert. Il n'y a pas de réinitialisation de mot de passe. La garde des clés — portefeuilles matériels, schémas multi-signatures, signatures à seuil, dépositaires institutionnels — constitue par conséquent toute l'histoire de la sécurité pour l'utilisateur final, et les pertes proviennent dans leur immense majorité de clés perdues plutôt que de failles du protocole.

Les arbres de Merkle condensent un ensemble de transactions en une seule empreinte en hachant les empreintes deux à deux, de niveau en niveau, jusqu'à une racine unique.

        root = H( H12 || H34 )
        /                    \
  H12 = H(h1 || h2)     H34 = H(h3 || h4)
     /        \            /        \
   h1=H(tx1) h2=H(tx2)  h3=H(tx3) h4=H(tx4)

h(tx1) = 709b55bd3da0f5a838125bd0ee20c5bfdd7caba173912d4281cae816b79a201b
h(tx2) = 27ca64c092a959c7edc525ed45e845b1de6a7590d173fd2fad9133c8a779a1e3
H12    = bbea820f07f7f89aeea1ab4a354ecea39f2f72accd05c64371522ee371cd0c48

Le bénéfice, c'est la preuve de Merkle : pour prouver que tx1 figure dans un bloc d'un million de transactions, il suffit de fournir h2, H34 et la racine — un nombre logarithmique d'empreintes plutôt que le bloc entier. Les clients légers, les ponts inter-chaînes et les preuves de fraude des rollups reposent tous sur ce mécanisme.

Blocs, chaînes et état

Un bloc se compose d'un en-tête et d'une liste de transactions. L'en-tête contient l'empreinte de l'en-tête du bloc précédent, la racine de Merkle des transactions, un horodatage et des champs propres au protocole.

{
  "number": 21493087,
  "parentHash": "0x8f1c...a3d2",
  "transactionsRoot": "0xbbea...0c48",
  "stateRoot": "0x4d7e...91ab",
  "timestamp": 1757232000,
  "proposer": "0x2b9f...77c1"
}

Comme chaque en-tête porte l'empreinte de son parent, modifier une ancienne transaction change la racine de Merkle de son bloc, donc l'empreinte de son en-tête, donc la référence au parent de tous les blocs suivants. La falsification n'est pas empêchée : elle est rendue visible et coûteuse, et c'est la façon honnête de décrire l'immuabilité.

Il existe deux modèles comptables. Le modèle UTXO représente la valeur comme un ensemble de sorties non dépensées distinctes, chacune consommée en totalité et remplacée par de nouvelles sorties ; il se prête bien à la parallélisation de la validation et conserve un graphe d'audit propre. Le modèle par compte tient un solde par adresse et le modifie, ce qui est bien plus naturel pour des contrats programmables. Il exige en revanche un nonce explicite par émetteur pour empêcher qu'une transaction signée soit rejouée.

Les familles de consensus comparées

Le consensus décide qui peut ajouter le bloc suivant et comment les désaccords se résolvent.

En preuve de travail, les proposeurs cherchent un en-tête dont l'empreinte tombe sous une cible. La recherche relève de la force brute pure, la difficulté s'ajuste pour que les blocs arrivent à un rythme régulier, et réécrire l'historique exige de surpasser en calcul le reste du réseau. Il est facile de raisonner sur sa sécurité, et sa consommation d'énergie n'est pas un détail d'implémentation : c'est le mécanisme lui-même.

La preuve d'enjeu remplace le matériel par du capital immobilisé. Les validateurs bloquent des fonds, sont sélectionnés pour proposer et attester des blocs, et perdent une partie de leur enjeu — le slashing — en cas de mauvais comportement prouvable, comme la signature de deux blocs contradictoires. Ethereum a achevé cette transition, réduisant sa consommation d'énergie de plusieurs ordres de grandeur tout en conservant une participation ouverte. Le compromis passe de « l'énergie coûte cher » à « le capital se concentre », et une grande partie de l'effort de conception vise à décourager cette concentration.

Les protocoles tolérants aux fautes byzantines de la famille classique supposent une composition connue et parviennent à un accord par des tours de vote explicites, en tolérant jusqu'à environ un tiers de participants défaillants. Ils offrent une finalité immédiate et un débit élevé, et conviennent naturellement aux réseaux permissionnés ; mais la composition du groupe doit être gouvernée, ce qui est un problème politique plutôt que technique.

Public, privé et permissionné

Un réseau public sans permission laisse n'importe qui lire, émettre des transactions et valider. Son modèle de coût est un marché des frais, et son hypothèse de confiance est « aucune coalition majoritaire sur la ressource rare ».

Un réseau permissionné admet des organisations connues, souvent avec des canaux ou des groupes de confidentialité pour que chaque participant ne voie que les transactions qui le concernent. C'est là que se situent les plateformes de consortium d'entreprise : l'identité est délivrée par un service d'adhésion, le consensus est BFT ou tolérant aux pannes franches, le débit est bien plus élevé et la confidentialité devient atteignable.

Entre les deux, la question honnête est toujours la même : qui est l'adversaire ? Si les membres d'un consortium n'ont aucune raison de se frauder mutuellement et qu'un opérateur neutre est acceptable, une base de données répliquée avec un contrôle d'accès solide et des journaux d'audit cryptographiques apporte l'essentiel du bénéfice pour une fraction de la complexité. Bien des projets de consortium en sont arrivés là, sans bruit.

Forks, finalité et le problème des réorganisations

Lorsque deux blocs valides apparaissent à la même hauteur, le réseau se divise temporairement, puis converge en suivant la chaîne que le protocole privilégie. Les blocs laissés de côté deviennent orphelins et leurs transactions retournent dans le pool. C'est une réorganisation, un événement ordinaire et attendu — ce qui explique pourquoi les applications attendent des confirmations avant de considérer un paiement comme effectué. En preuve d'enjeu avec finalité explicite, attendre le point de contrôle finalisé offre la garantie la plus forte.

Les changements délibérés de protocole provoquent eux aussi des forks. Un soft fork durcit les règles, de sorte que les anciens nœuds continuent d'accepter les nouveaux blocs ; un hard fork les assouplit ou les modifie, et tous les nœuds doivent alors se mettre à jour, faute de quoi le réseau se scinde définitivement. Ce sont des événements de gouvernance autant que d'ingénierie.

La règle pratique, pour quiconque développe une intégration : ne jamais tenir un événement on-chain pour définitif dès sa première apparition. Abonnez-vous aux signaux de confirmation ou de finalité, rendez vos handlers idempotents et soyez prêt à annuler un effet applicatif si une réorganisation fait disparaître la transaction — la même discipline que pour toute transaction distribuée avec compensations.

Scalabilité, coût et layer 2

Le trilemme de la scalabilité résume la contrainte : décentralisation, sécurité et scalabilité, on n'en obtient confortablement que deux. Augmenter le débit en agrandissant les blocs renchérit le coût d'exploitation d'un nœud, ce qui réduit le nombre de validateurs indépendants, et donc la décentralisation.

La réponse dominante est le layer 2 : exécuter les transactions hors de la chaîne principale et ne s'en servir que pour le règlement et la disponibilité des données. Les optimistic rollups publient des résultats par lots et ménagent une fenêtre de contestation pendant laquelle une preuve de fraude peut les invalider. Les zero-knowledge rollups publient une preuve de validité succincte : la correction est vérifiée mathématiquement et les retraits ne nécessitent aucune période de contestation. Les canaux de paiement permettent à deux parties d'effectuer des transactions en privé hors chaîne et de ne régler que le solde final. Tous héritent de la sécurité de la couche de base tout en déplaçant l'exécution ailleurs, et tous ajoutent un risque lié aux ponts, historiquement le lieu des pertes les plus importantes.

Autant énoncer les coûts clairement : sur la couche de base, les transactions sont mesurées et tarifées selon la demande, le stockage est de loin la ressource la plus chère, et la latence de confirmation va de quelques secondes à quelques minutes. Comparez avec les schémas de paiement instantané décrits dans les fondamentaux des systèmes de paiement, qui transfèrent des montants de détail en moins de dix secondes pour un coût marginal quasi nul : une blockchain ne rivalise ni sur le débit ni sur le prix — elle n'a sa place que là où l'absence d'opérateur de confiance est précisément l'exigence.

Quand une blockchain est la mauvaise réponse

Être vraiment utile sur ce sujet, c'est accepter de dire non. Un registre partagé n'est pas le bon outil lorsque :

• Une seule organisation contrôle les données. Vous avez réinventé une base de données, avec une latence dégradée et sans DELETE.
• Les participants font déjà confiance à un intermédiaire. L'intermédiaire coûte moins cher.
• Vous avez besoin de confidentialité. Tout ce qui figure sur une chaîne publique reste visible pour toujours ; la confidentialité exige une machinerie supplémentaire considérable.
• Vous devez supprimer ou corriger des enregistrements. Le droit à l'effacement et les journaux en ajout seul sont fondamentalement en tension.
• Les données naissent hors chaîne. Aucun mécanisme de consensus ne peut vérifier qu'une livraison est réellement arrivée ; c'est le problème de l'oracle, qui reporte la confiance sur celui qui rapporte l'information.
• Vous avez besoin de milliers de transactions par seconde à faible latence. Les couches de base ne sont pas conçues pour cela.

La liste complémentaire est courte mais bien réelle : le règlement entre établissements qui n'ont pas d'opérateur commun naturel, les attestations de provenance et d'intégrité où les données sous-jacentes restent hors chaîne, et une infrastructure financière ouverte et programmable dont l'accès sans permission est la raison d'être. Jugez une proposition en vous demandant si retirer la chaîne retire quelque chose d'essentiel : si la réponse honnête est qu'un journal d'audit signé suffirait, construisez le journal d'audit signé.

Points clés à retenir

• Une blockchain résout l'accord entre des participants inconnus qui se méfient les uns des autres ; c'est pour cette garantie étroite que vous payez en coût, en latence et en confidentialité.
• Le chaînage par hachage et les arbres de Merkle rendent la falsification visible et les preuves d'inclusion peu coûteuses ; les signatures numériques font de la garde des clés tout le modèle de sécurité des utilisateurs.
• La preuve de travail achète la sécurité avec de l'énergie, la preuve d'enjeu avec du capital exposé, et les protocoles BFT avec une composition connue et une finalité immédiate.
• La finalité est probabiliste sur certaines chaînes et explicite sur d'autres : attendez toujours les confirmations et concevez des handlers qui survivent à une réorganisation.
• Le trilemme repousse le débit hors de la couche de base, vers les rollups et les canaux, qui en héritent la sécurité mais ajoutent le risque lié aux ponts.
• Si une seule organisation possède les données, si la suppression est requise, si la confidentialité compte ou si un opérateur de confiance existe déjà, choisissez une base de données et dites-le.