Chaînes de blocs, wallets et cryptographie économique

Chaînes de blocs, wallets et cryptographie économique

Une chaîne de blocs n’est pas une primitive cryptographique : c’est un assemblage de fonctions de hachage, de signatures, de protocoles de consensus et d’incitations financières. Les deux premiers ingrédients relèvent de la cryptographie et se prouvent ; les deux derniers relèvent de l’économie et se parient. Cette fiche démonte la machine pièce par pièce : registre chaîné, portefeuilles et graines, signatures collectives, preuves à divulgation nulle et contrats programmables, en indiquant à chaque étape ce qui est garanti par les mathématiques et ce qui ne l’est que par l’intérêt bien compris des participants.

Explication de la marmotte

Un grand cahier de comptes recopié par des milliers de personnes, où chaque page scelle la précédente, rend toute retouche discrète presque impossible. Ce chapitre explique ce que ce cahier garantit vraiment, à quoi sert le code secret qui permet de dépenser, et pourquoi perdre ce code revient à perdre l’argent pour toujours.

→ Lire l’explication complète de la marmotte

Hachage et registre

Un bloc regroupe des transactions et un en-tête. Dans Bitcoin, cet en-tête fait 80 octets : version, condensé de l’en-tête précédent, Merkle root (racine de l’arbre de Merkle des transactions), horodatage, cible de difficulté encodée et nonce. Le condensé d’un en-tête est un double SHA-256 (Secure Hash Algorithm, 256 bits). Comme chaque en-tête contient le condensé du précédent, modifier une transaction ancienne change la racine de Merkle de son bloc, donc l’en-tête, donc tous les en-têtes suivants. Le registre est un historique append-only : on ajoute, on ne réécrit pas sans que cela se voie. Les propriétés du hachage qui fondent ce chaînage sont détaillées dans Condensés cryptographiques : propriétés, constructions et familles.

L’arbre de Merkle hache les transactions deux à deux jusqu’à une racine unique. Une preuve d’inclusion contient les condensés frères le long du chemin : pour un bloc de 4 000 transactions, douze condensés de 32 octets suffisent (2¹² = 4 096), soit 384 octets au lieu de plusieurs mégaoctets. C’est ce qui permet aux clients légers de vérifier qu’une transaction figure dans un bloc sans télécharger le bloc.

La proof of work (preuve de travail) décide qui ajoute le bloc suivant. Le mineur fait varier le nonce jusqu’à obtenir un condensé d’en-tête numériquement inférieur à une cible. Aucun raccourci connu n’existe : il faut essayer, en moyenne un nombre de fois inversement proportionnel à la cible. L’idée vient de Hashcash (Adam Back, 1997), conçu comme fonction de coût contre le pourriel. Bitcoin ajuste la difficulté tous les 2 016 blocs pour viser un bloc toutes les dix minutes environ. Certaines chaînes préfèrent des fonctions dites « memory-hard », comme scrypt, pour limiter l’avantage des circuits spécialisés.

Ici se situe la frontière décisive. La cryptographie garantit que réécrire un bloc oblige à refaire le travail de tous les blocs suivants ; elle ne garantit pas que personne ne le fera. Un acteur disposant de plus de la moitié de la puissance de calcul peut produire une chaîne concurrente plus lourde et l’imposer. Ce qui l’en dissuade est le coût, comparé au gain : c’est de la sécurité économique. La finalité d’une transaction est donc probabiliste : la convention de six confirmations rend une réorganisation improbable, jamais impossible. Ethereum, passé à la preuve d’enjeu en septembre 2022, offre une finalité économique explicite : un bloc finalisé ne peut être annulé sans qu’au moins un tiers des validateurs perde son dépôt.

On rencontre enfin le hachage algébrique : des fonctions comme Poseidon, conçues pour coûter peu de contraintes dans un circuit de preuve, alors que SHA-256 y est très coûteux. Elles servent dans les systèmes à preuves succinctes présentés plus bas.

Clés et wallets

Un wallet (portefeuille) ne contient pas d’argent : il contient des clés privées. Les fonds sont des inscriptions dans le registre, que seule une signature valide peut déplacer.

La seed (graine) est la racine de tout. La norme BIP-39 (Bitcoin Improvement Proposal 39) la représente par une phrase de récupération de 12 à 24 mots pris dans une liste de 2 048. Douze mots codent 128 bits d’entropie plus 4 bits de somme de contrôle (12 × 11 = 132 bits) ; vingt-quatre mots codent 256 bits plus 8. La phrase est transformée en graine binaire de 512 bits par PBKDF2-HMAC-SHA512 (Password-Based Key Derivation Function 2 avec HMAC, Hash-based Message Authentication Code) avec 2 048 itérations, le sel valant « mnemonic » suivi d’une phrase de passe optionnelle.

La HD derivation (dérivation hiérarchique déterministe, BIP-32) tire de cette graine un arbre de clés. Un chemin comme m/84'/0'/0'/0/5 désigne une clé précise ; l’apostrophe signale une dérivation renforcée. La distinction compte : avec une dérivation non renforcée, la clé publique étendue d’un compte (xpub) et une seule clé privée enfant suffisent à reconstituer la clé privée du compte. Publier une xpub pour suivre un solde est donc acceptable ; la publier avec une clé fille fuitée ne l’est plus.

Une adresse est une représentation de la clé publique ou d’un script. Dans Bitcoin, une adresse SegWit v0 encode RIPEMD-160(SHA-256(clé publique)) au format bech32 ; une adresse Taproot encode une clé publique de 32 octets en bech32m. Dans Ethereum, l’adresse est formée des 20 derniers octets du Keccak-256 de la clé publique. La signature utilise ECDSA (Elliptic Curve Digital Signature Algorithm) sur la courbe secp256k1, ou des signatures de Schnorr (BIP-340) depuis l’activation de Taproot en novembre 2021. Les courbes elliptiques sont présentées dans Courbes elliptiques : compacité, validation et pièges.

La récupération est le cœur du risque. Perdre la graine sans sauvegarde rend les fonds définitivement inaccessibles ; la divulguer permet à quiconque de les prendre. Aucun service client ne réinitialise une clé privée, ce qui constitue à la fois la promesse et la malédiction du système. Le hardware wallet (portefeuille matériel) garde la clé dans un composant isolé et affiche sur son propre écran ce qui va être signé. Son apport principal n’est pas le stockage, c’est cet affichage : un ordinateur compromis peut présenter une transaction à l’utilisateur et en soumettre une autre à la signature. Signer sans lire l’écran du boîtier revient à signer à l’aveugle, et les contrats Ethereum, dont les données de transaction sont souvent illisibles, aggravent ce risque.

Un wallet non custodial est celui dont l’utilisateur détient les clés ; un compte custodial, sur une plateforme d’échange, est une créance sur un tiers qui détient les clés à sa place. Le second ressemble à un compte bancaire, avec les garanties en moins.

Signatures collectives

Plusieurs signataires peuvent contrôler des fonds, avec des mécanismes très différents.

La multisignature classique (multisig) inscrit dans le script la politique « 2 sur 3 » et publie sur la chaîne autant de signatures que nécessaire. Simple et vérifiable, elle révèle la politique et coûte en taille.

La Schnorr multisig exploite la linéarité des signatures de Schnorr : plusieurs signataires produisent une seule signature valide pour une clé agrégée. L’agrégation naïve, qui additionne les clés publiques, tombe sous une rogue-key attack (attaque par clé malhonnête) : un participant publie X₂ = X* − X₁, où X* est une clé dont il connaît le secret, et la clé agrégée X₁ + X₂ vaut X*, qu’il contrôle seul. MuSig puis MuSig2 (BIP-327) corrigent ce défaut en pondérant chaque clé par un coefficient dérivé de l’ensemble des clés.

Les signatures BLS (Boneh-Lynn-Shacham, 2001) reposent sur des pairings (couplages), applications bilinéaires e : G₁ × G₂ → G_T qui vérifient e(aP, bQ) = e(P, Q)^(ab). Elles permettent l’agrégation : n signatures sur n messages différents se compressent en une seule. La couche de consensus d’Ethereum utilise BLS sur la courbe BLS12-381. La parade aux clés malhonnêtes y passe par une preuve de possession de la clé privée.

La signature threshold (à seuil) répartit une clé unique en parts de Shamir : t participants parmi n coopèrent pour signer, sans que la clé soit jamais reconstituée. FROST (Flexible Round-Optimized Schnorr Threshold), normalisé par le RFC 9591 en 2024, en est un exemple. Sur la chaîne, le résultat est une signature ordinaire : la politique reste invisible, mais toute la sécurité repose sur la cérémonie hors chaîne. Une signature agrégée combine les signatures de tous ; une signature à seuil n’exige qu’un sous-ensemble. Le partage de secret sous-jacent est traité dans Partager un secret et distribuer la confiance.

ZK et smart contracts

Les preuves à divulgation nulle, présentées dans Prouver sans révéler : ZK et identification, servent deux objectifs distincts. La validité : un rollup ZK exécute des milliers de transactions hors de la chaîne principale et y publie une preuve succincte, SNARK (Succinct Non-interactive ARgument of Knowledge) ou STARK (Scalable Transparent ARgument of Knowledge), que la transition d’état est correcte. Rien n’y est forcément caché ; le gain est la compression. La confidentialité : Zcash, lancé en 2016, utilise des zk-SNARKs pour prouver qu’une transaction conserve les montants sans révéler émetteur, destinataire ni montant. Dans les deux cas, l’énoncé est traduit en circuits de contraintes, et une erreur dans le circuit est une erreur dans la sécurité : la preuve établit fidèlement un énoncé faux.

Un smart contract est un programme dont l’exécution est répliquée et vérifiée par le réseau. La cryptographie garantit qu’il s’exécute tel qu’écrit, pas qu’il est bien écrit. Les smart contract bugs relèvent du génie logiciel : la reentrancy (réentrance) permet à un contrat appelé de rappeler l’appelant avant que celui-ci ait mis à jour son état ; c’est le mécanisme exploité contre The DAO en 2016, qui a conduit Ethereum à une scission de chaîne.

Les oracles injectent des données extérieures, un cours de change ou un résultat sportif. Le contrat fait confiance à l’oracle, signature comprise : une signature valide sur un cours faux reste un cours faux. Enfin, le front-running exploite la visibilité des transactions en attente : un acteur voit un ordre d’achat important, place le sien avant et revend après. On parle plus largement de MEV (Maximal Extractable Value), la valeur qu’un producteur de bloc peut extraire en ordonnant, insérant ou excluant des transactions.

L’ensemble prolonge une histoire plus ancienne. L’argent électronique de David Chaum, commercialisé par DigiCash dans les années 1990, utilisait des signatures aveugles pour offrir des paiements non traçables par la banque émettrice. Bitcoin a fait le choix inverse : un registre public, pseudonyme et non anonyme. Les analyses de chaîne relient les adresses par des heuristiques, comme celle qui attribue au même propriétaire toutes les entrées d’une même transaction. Promettre une confidentialité transactionnelle sans étudier ces métadonnées, ni les adresses IP des nœuds, ni les plateformes d’échange qui connaissent leurs clients, relève de l’optimisme publicitaire.

Exemples et ateliers

Vérifier une preuve Merkle. Un bloc contient quatre transactions T0 à T3. La preuve d’inclusion de T2 contient h(T3) et h01 = h(h(T0) || h(T1)). Le vérificateur calcule :

h2   = H(T2)
h23  = H(h2 || h(T3))        T2 est à gauche : son condensé vient en premier
root = H(h01 || h23)         h23 est à droite
comparer root à la Merkle root de l'en-tête

La position gauche ou droite fait partie de la preuve ; l’oublier rend la vérification fausse. Bitcoin duplique le dernier élément d’un niveau impair, ce qui a déjà produit une vulnérabilité (CVE-2012-2459) : deux listes de transactions différentes donnaient la même racine. Les conventions de construction comptent autant que la fonction de hachage.

Sauvegarde de seed 2 sur 3. Découper une phrase de 24 mots en trois morceaux de 8 mots est une mauvaise idée : un seul morceau réduit la recherche à 16 mots inconnus, et deux morceaux livrent l’essentiel. Deux approches correctes existent. La première est un partage de Shamir de la graine, normalisé par SLIP-0039 : chaque part seule ne révèle rien. La seconde est un wallet multisig 2 sur 3 avec trois graines indépendantes, à conserver en trois lieux ; il faut alors sauvegarder aussi le descripteur du wallet, c’est-à-dire les trois clés publiques étendues et la politique, sans lesquels deux graines ne suffisent pas à retrouver les fonds.

Multisignature ou threshold wallet ?

Critère	Multisig sur la chaîne	Threshold (MPC, FROST)
Politique visible	Oui	Non
Taille de transaction	Croît avec le nombre de signatures	Une signature
Changer de signataires	Nouvelle adresse	Renouvellement des parts possible
Audit	Lisible sur la chaîne	Dépend des journaux de la cérémonie
Complexité	Faible	Élevée, implémentations à auditer

Ce que la cryptographie ne protège pas dans un smart contract : la logique métier, l’ordre des appels, la valeur fournie par l’oracle, l’ordre des transactions dans le bloc, la clé d’administration capable de mettre le contrat à jour, et la compréhension par l’utilisateur de ce qu’il signe.

Pièges classiques

Confondre immuabilité et exactitude : un registre infalsifiable conserve aussi fidèlement les erreurs que les vérités. Perdre une seed, ou la photographier dans un service de stockage en ligne. Signer une transaction ambiguë dont le portefeuille affiche une suite hexadécimale. Ignorer les oracles, alors qu’ils sont souvent le maillon le plus faible du contrat. Promettre une confidentialité transactionnelle sans analyse des métadonnées.

À ne pas confondre

Une blockchain n’est pas une base de données : elle sacrifie le débit et la possibilité de correction pour se passer d’un administrateur de confiance ; lorsqu’un administrateur de confiance existe, une base de données journalisée et signée fait mieux. La proof of work prouve qu’un calcul a été dépensé ; une preuve de stockage prouve qu’une donnée est conservée. Un wallet détient des clés ; un compte custodial est une promesse d’un tiers. Une signature agrégée combine les signatures de tous ; une signature à seuil n’en exige qu’un quorum.

Conclusion

Une chaîne de blocs combine deux sécurités qu’il faut évaluer séparément. La sécurité cryptographique, hachage, arbres de Merkle, signatures et preuves, se démontre et tient tant que les primitives tiennent. La sécurité économique, consensus et incitations, tient tant qu’attaquer coûte plus que cela ne rapporte. Autour, les clés restent le point de rupture le plus fréquent, et les contrats ajoutent tous les défauts du logiciel ordinaire, gravés dans un registre qui ne pardonne rien.

🐝 Ce qui arrive si on s’en passe

Sans gestion sérieuse de la graine et des signatures, le registre fait exactement ce qu’il promet, et c’est bien le problème : une opération signée avec une clé volée est inscrite, recopiée et scellée comme n’importe quelle autre, sans recours ni annulation, puisque l’immuabilité ne distingue pas l’opération légitime de l’opération dérobée. Une graine perdue ne se réinitialise pas, et aucun guichet n’existe pour la redemander. Une transaction signée sans en comprendre le contenu engage son signataire aussi définitivement qu’une transaction réfléchie. Immuable ne veut pas dire exact ; cela veut dire irréparable, ce qui figure plus rarement sur les brochures.

🦫 Explication de la marmotte 🍫

Une chaîne de blocs est un registre partagé entre de nombreux ordinateurs. Les opérations y sont regroupées en blocs. Chaque bloc contient une empreinte, c’est-à-dire un court résumé calculé à partir du bloc précédent : modifier un ancien bloc changerait son empreinte et casserait tous les suivants. Dans un bloc, les opérations sont rangées en arbre d’empreintes, ce qui permet de prouver qu’une opération précise y figure sans tout transmettre. Pour décider qui ajoute le bloc suivant, certains réseaux imposent un calcul long et coûteux, la preuve de travail : réécrire l’histoire coûterait alors plus que ce qu’on y gagnerait. C’est la partie économique de la sécurité, distincte de la partie mathématique. Le portefeuille, lui, garde les clés secrètes. À partir d’une graine, souvent notée sous forme de phrase de récupération, il fabrique une série de clés et d’adresses. Dépenser consiste à signer une opération avec une clé secrète. Perdre la graine rend les fonds définitivement inaccessibles ; la voler permet de les prendre. D’où les sauvegardes partagées, par exemple deux morceaux sur trois nécessaires, et les signatures à plusieurs. Enfin, les programmes enregistrés sur la chaîne peuvent contenir des erreurs, et les données extérieures qu’ils reçoivent peuvent être fausses : la cryptographie garantit que le registre n’a pas été modifié, pas que son contenu est exact.

À lire aussi

• Hachage dans les systèmes: intégrité, arbres et preuvesRegrouper les usages systémiques du hachage: empreintes, arbres, preuves, déduplication, chaînes d’intégrité et limites de sécurité.
• Signer numériquement : preuve publique, politiques de vérificationChoisir, intégrer et exploiter des signatures numériques sans signer une représentation ambiguë ni déléguer la vérification à une politique permissive.
• Équité, vote, contrats et divulgation contrôléeConserver les protocoles avancés classiques en les réorganisant autour des problèmes d’équité, de décision collective et de divulgation contrôlée.
• Calculer, engager et anonymiser avec des primitives spécialiséesRegrouper les primitives avancées qui protègent des calculs, des engagements ou des identités, tout en exposant leurs coûts et leurs fuites résiduelles.

Pages voisines

La citent

• Hachage dans les systèmes: intégrité, arbres et preuves

Chaînes de blocs, wallets et cryptographie économique

Elle cite

• ⇄Lien dans les deux sens :Partager un secret et distribuer la confiance
• ⇄Lien dans les deux sens :Prouver sans révéler : ZK et identification
• Condensés cryptographiques : propriétés, constructions et familles
• Courbes elliptiques : compacité, validation et pièges
• Architecture de journalisation d’audit immuable centralisée
• Consensus distribué et tolérance aux pannes byzantines

⇄ : les deux pages se citent l’une l’autre.