Principales primitives cryptographiques derrière chaque blockchain

Chaque affirmation portée par une blockchain — « cette transaction est définitive », « cette adresse possède cet actif », « cet historique n’a pas été modifié » — se ramène en définitive à une poignée de primitives cryptographiques qui effectuent des tâches étroites et clairement définies. Aucune n’est une invention des blockchains. Les fonctions de hachage, les signatures numériques et les arbres de Merkle existaient des décennies avant Bitcoin. Les blockchains les ont simplement combinés dans un système où aucune partie unique n’a besoin d’être digne de confiance pour que ces affirmations tiennent.

Ce guide examine les primitives qui portent réellement cette charge : les fonctions de hachage qui servent d’empreinte aux données, les signatures numériques qui autorisent les transactions, les arbres de Merkle qui rendent de très grands jeux de données vérifiables par morceaux, les mathématiques des courbes elliptiques sur lesquelles reposent ces signatures, et les schémas d’engagement — la brique qui mène aux preuves à divulgation nulle de connaissance. Comprendre chacune d’elles est la manière la plus rapide de saisir ce qu’une blockchain fait réellement en coulisses.

Fonctions de hachage cryptographiques (SHA-256, Keccak)

Une fonction de hachage prend une entrée de taille quelconque et produit de façon déterministe une sortie de taille fixe — une « empreinte » — de sorte qu’inverser un seul bit de l’entrée bouleverse entièrement la sortie, et qu’il est infaisable en pratique de trouver deux entrées différentes qui donnent la même sortie de hachage. Cette propriété, la résistance aux collisions, permet d’utiliser un hachage comme empreinte compacte et révélatrice de toute altération, même pour des données arbitrairement volumineuses.

Bitcoin utilise SHA-256 partout : les en-têtes de blocs sont chaînés en intégrant le hachage SHA256(SHA256()) de l’en-tête précédent dans chaque nouvel en-tête ; modifier un bloc passé change donc son hachage et invalide chaque en-tête qui le suit (Bitcoin Developer Guide). Cette même construction à double SHA-256 hache les transactions dans l’arbre de Merkle du bloc (référence Bitcoin.org).

Ethereum standardise plutôt Keccak-256 (la soumission Keccak d’origine, distincte de la norme SHA-3 du NIST publiée plus tard) comme fonction de hachage généraliste. Chaque adresse de compte est dérivée en prenant les 20 derniers octets du hachage Keccak-256 de la Clé Publique du compte (ethereum.org), et cette même fonction sous-tend l’adressage par contenu clé/valeur utilisé dans le Merkle Patricia Trie qui stocke l’état d’Ethereum.

Le hachage relie aussi les en-têtes de blocs en une chaîne plutôt qu’en une simple collection d’enregistrements : modifier un en-tête change son hachage et rompt les références des en-têtes qui en descendent. L’obligation supplémentaire de refaire le travail ultérieur et de rattraper le réseau honnête est propre au consensus par preuve de travail de Bitcoin. Un attaquant qui modifie un ancien bloc doit refaire la preuve de travail de ce bloc et tout le travail qui le suit, puis rattraper la chaîne honnête (livre blanc de Bitcoin, §4). D’autres blockchains authentifient et finalisent leur historique selon des règles de consensus différentes ; le seul chaînage des hachages ne crée donc pas ce coût de preuve de travail. Les hachages liés des en-têtes sont la raison littérale pour laquelle cette structure de données s’appelle une blockchain.

Cryptographie à clé publique et signatures numériques (ECDSA, EdDSA, BLS)

Une blockchain n’a pas de formulaire de connexion ; elle a donc besoin d’un autre moyen de prouver que « cette transaction provient bien du propriétaire de ce compte ». La cryptographie à clé publique résout ce problème avec une paire de clés : une Clé Privée tenue secrète et une clé publique qui peut être librement partagée. Signer une transaction avec la clé privée produit une signature numérique que n’importe qui peut vérifier par rapport à la clé publique : l’autorisation est ainsi prouvée sans jamais révéler la clé privée elle-même.

Les comptes Ethereum dérivent leur clé publique de la clé privée au moyen de l’algorithme de signature numérique à courbe elliptique, ECDSA, sur la courbe secp256k1 — la même courbe que Bitcoin utilise (documentation ethereum.org sur les comptes; EIP-2, correctif de malléabilité des signatures secp256k1). ECDSA est rapide à vérifier et a été scruté pendant des décennies, mais présente une faiblesse opérationnelle pertinente pour les conceptions plus récentes : les signatures ECDSA individuelles ne s’agrègent pas efficacement ; en vérifier des milliers revient donc à effectuer des milliers de vérifications séparées.

C’est précisément ce que comblent les signatures EdDSA et BLS. EdDSA (employé par des chaînes comme Solana et Stellar) utilise une construction de courbe différente, déterministe et résistante à certains écueils d’implémentation qui ont historiquement provoqué des bogues de réutilisation de nonce avec ECDSA. Les signatures BLS vont plus loin : grâce à la propriété mathématique d’appariement des courbes qu’elles utilisent, de nombreuses signatures BLS peuvent être réunies en une signature agrégée unique qui les vérifie toutes en une seule fois. La couche de consensus par preuve d’enjeu d’Ethereum repose exactement sur ce mécanisme : les validateurs signent des attestations avec des clés BLS afin que la beacon chain puisse agréger les votes de centaines de milliers de validateurs en signatures assez compactes pour être vérifiées rapidement. C’est ce qui rend la preuve d’enjeu à grande échelle praticable (ethereum.org, The Beacon Chain). Ethereum expose aussi des opérations sur la courbe BLS12-381 sous forme de précompilations EVM, précisément pour prendre en charge la vérification de signatures BLS dans les smart contracts (EIP-2537).

Arbres de Merkle

Un arbre de Merkle permet à une blockchain de résumer des milliers de transactions dans un unique hachage de 32 octets sans obliger chaque participant à stocker chaque transaction. Les feuilles sont les hachages d’éléments de données individuels (transactions, états de compte) ; chaque paire de hachages est concaténée puis hachée de nouveau, jusqu’à ce qu’il ne reste qu’un hachage — la racine (Bitcoin Developer Guide). Cette racine est stockée directement dans l’en-tête du bloc, ce qui permet à un nœud complet de prendre un engagement cryptographique sur l’intégralité du contenu d’un bloc avec presque aucun espace supplémentaire.

Le gain est la taille de la preuve. Pour démontrer qu’une transaction est incluse dans un bloc, le bloc entier n’est pas nécessaire : il suffit de la transaction et d’une « branche de Merkle », c’est-à-dire les hachages frères le long du chemin de cette feuille à la racine, soit en général de l’ordre de log₂(n) hachages pour n transactions. C’est le fondement de la vérification de paiement simplifiée (SPV) : un client léger qui ne possède que les en-têtes de blocs peut encore vérifier qu’une transaction précise a eu lieu en comparant sa branche de Merkle à la racine de l’en-tête, sans télécharger l’intégralité de la blockchain (Bitcoin Developer Guide).

Ethereum étend cette idée avec le Merkle Patricia Trie, un hybride d’arbre de Merkle et de trie de préfixes (radix) utilisé pour stocker l’état complet des comptes, et non une simple liste de transactions. Chaque en-tête de bloc contient trois racines de trie distinctes — stateRoot, transactionsRoot et receiptsRoot — chacune pouvant être prouvée indépendamment (ethereum.org). C’est ce qui permet à un smart contract ou à un client léger de vérifier le solde d’un compte ou un emplacement de stockage donné sans rejouer toute la chaîne.

Cryptographie sur courbes elliptiques

La cryptographie sur courbes elliptiques (ECC) est le fondement mathématique sur lequel reposent ECDSA, EdDSA et BLS. Au lieu de s’appuyer sur la difficulté de factoriser de grands nombres (comme le RSA classique), l’ECC repose sur la difficulté du problème du logarithme discret sur courbe elliptique : étant donné un point de la courbe obtenu en ajoutant un point de base à lui-même de très nombreuses fois, il est infaisable en pratique de retrouver le nombre d’additions — alors que calculer ce point dans le sens direct est facile. Cette asymétrie (facile dans un sens, difficile à inverser) est précisément ce qui permet d’utiliser une clé privée pour signer tout en publiant sans risque la clé publique qui en est dérivée.

La courbe précise et le schéma de signature comptent. Bitcoin et Ethereum utilisent tous deux secp256k1, une courbe de Koblitz normalisée par le Standards for Efficient Cryptography Group avec des paramètres de 256 bits bien étudiés (SEC 2: Recommended Elliptic Curve Domain Parameters). D’autres écosystèmes font des compromis différents : Ed25519 est un schéma de signature EdDSA concret instancié sur la courbe Edwards25519 (RFC 8032, §5.1), et la RFC 8032 le situe autour d’un niveau de sécurité classique de 128 bits (§8.5). BLS12-381 est une courbe adaptée aux appariements, choisie pour des opérations telles que l’agrégation de signatures BLS ; l’EIP-2537 décrit un niveau de sécurité supérieur à 120 bits (EIP-2537). Ces estimations ne signifient pas que les systèmes offrent une même « sécurité par bit de clé » : ils emploient des groupes, des encodages et des hypothèses différents, et la longueur nominale d’une clé ne constitue pas en elle-même sa force de sécurité. Le NIST associe par exemple une sécurité classique de 128 bits à des clés ECC ordinaires de 256 à 383 bits, mais à des clés RSA de 3 072 bits (NIST SP 800-57 Part 1 Rev. 5, tableau 2). Cela aide à comprendre pourquoi les systèmes sur courbes elliptiques sont devenus la norme pour les comptes blockchain.

Schémas d’engagement (un pont vers la divulgation nulle)

Un schéma d’engagement permet de « verrouiller » une valeur — publier un élément qui vous lie à une donnée précise — sans révéler cette donnée, puis d’« ouvrir » l’engagement plus tard pour prouver de quelle valeur il s’agissait. L’analogie courante est l’enveloppe scellée : vous pouvez remettre aujourd’hui une enveloppe fermée à quelqu’un comme preuve que vous avez déjà choisi une réponse, sans qu’il la voie avant que vous décidiez de l’ouvrir, et une fois l’enveloppe scellée, vous ne pouvez pas échanger la réponse qu’elle contient.

Cette primitive paraît modeste, mais elle soutient la plupart des systèmes de preuve à divulgation nulle. La conception de disponibilité des données d’Ethereum fondée sur les blobs utilise par exemple des engagements polynomiaux KZG pour réduire chaque blob à un petit engagement cryptographique. Une preuve KZG peut authentifier une évaluation ou une cellule échantillonnée par rapport à cet engagement, mais elle ne prouve pas à elle seule que le blob complet est disponible. La disponibilité vient des règles de distribution et d’échantillonnage de la couche de consensus, tandis que KZG contrôle l’intégrité des données reçues (EIP-4844 ; EIP-7594, PeerDAS). Cette séparation permet à un vérificateur de contrôler une petite partie d’un blob sans confondre une preuve compacte d’évaluation avec la preuve que toutes les données du blob ont été publiées. Une racine de Merkle est d’ailleurs elle-même un schéma d’engagement simple : elle engage un jeu de données entier au moyen de son hachage racine, et une branche de Merkle est l’« ouverture » qui révèle l’un de ses éléments. Les ZK-rollups s’appuient sur des schémas d’engagement plus avancés (engagements polynomiaux et vectoriels) pour compresser l’exécution d’un lot entier de transactions dans une preuve peu coûteuse à vérifier onchain — un sujet traité en profondeur dans Preuve à divulgation nulle parfaite vs computationnelle.

Comparaison : primitives cryptographiques blockchain

Lien avec les domaines tokenisés

Chacune de ces primitives intervient directement lorsque vous tokenisez un domaine. Le NFT qui représente la propriété est protégé par les règles d’autorisation des comptes et des jetons de la chaîne. S’il est détenu par un compte externe (EOA), la clé privée de ce compte autorise les actions du compte ; un compte de contrat ne possède aucune clé privée et son code en assure le contrôle (ethereum.org, Comptes Ethereum). Pour un jeton ERC-721, une adresse approuvée ou un opérateur peut également déclencher un transfert (ERC-721). C’est pourquoi les portefeuilles matériels et la conservation rigoureuse de la phrase de récupération comptent pour une détention autogérée via un EOA, tandis que les portefeuilles fondés sur des smart contracts et les portefeuilles sous garde introduisent des périmètres d’autorisation et de confiance différents. L’enregistrement de propriété du domaine se trouve dans le même état dont l’engagement cryptographique est assuré par une racine de Merkle, qui sécurise chaque autre solde de compte et chaque Smart contract de la chaîne. C’est exactement ce qui confère à un domaine tokenisé la même résistance à l’altération que tout autre actif on-chain : il est transférable, vérifiable et sa propriété est démontrable sans que la base de données d’un bureau d’enregistrement soit l’unique source de vérité.

Comprendre ces primitives clarifie aussi ce que la tokenisation change, et ce qu’elle ne change pas : l’enregistrement DNS et le statut au registre du domaine suivent toujours les règles de l’ICANN, mais la preuve de propriété s’appuie désormais sur la cryptographie décrite ci-dessus plutôt que sur un compte de bureau d’enregistrement protégé par des identifiants de connexion. Découvrez le tableau d’ensemble dans Mécanismes de consensus blockchain et Approches de mise à l’échelle des blockchains, ou commencez à tokeniser sur namefi.io.

Sources et lectures complémentaires

• Bitcoin Developer Guide — Block Chain, chaînage via SHA256(SHA256()) de l’en-tête précédent
• Bitcoin — Bitcoin: A Peer-to-Peer Electronic Cash System, réécriture de l’historique de preuve de travail et travail cumulé
• Bitcoin Developer Reference — Block Chain, construction de la racine de Merkle
• Bitcoin Developer Guide — Operating Modes, SPV et branches de Merkle
• ethereum.org — Ethereum Accounts, ECDSA et dérivation d’adresse Keccak-256 ; contrôle des EOA et des comptes de contrat
• ethereum.org — Merkle Patricia Trie, racines d’état/de transactions/de reçus
• ethereum.org — Danksharding, engagements polynomiaux KZG
• EIP-4844 — Shard Blob Transactions, engagements de blobs, preuves et disponibilité sur la couche de consensus
• EIP-7594 — PeerDAS, preuves de cellules et échantillonnage de disponibilité des données
• ERC-721 — Non-Fungible Token Standard, propriété des jetons, approbations et opérateurs
• EIP-2 — Homestead Hard-fork Changes, contraintes de signature secp256k1
• EIP-2537 — Precompile for BLS12-381 curve operations
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA), schéma, courbe et niveau de sécurité d’Ed25519
• SEC 2: Recommended Elliptic Curve Domain Parameters — secg.org
• NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management, niveaux de sécurité comparables de l’ECC et du RSA
• The Eth2 Book — Signatures and BLS aggregation
• NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards