Les principales technologies de confidentialité des blockchains : preuves à divulgation nulle, FHE, MPC, TEE et signatures en anneau

Chaque transaction sur une Blockchain publique est, par défaut, visible par quiconque la consulte. Les soldes, les montants transférés et les contreparties demeurent à jamais dans le registre public. Cette transparence est à l’origine des garanties de confiance d’une blockchain, mais elle constitue aussi un handicap : aucune banque ne publie les soldes de ses clients, et aucune entreprise ne souhaite que ses paiements à ses fournisseurs ou ses versements de salaires soient lisibles par ses concurrents.

Les technologies de confidentialité des blockchains cherchent à combler cet écart sans abandonner les propriétés qui rendent les chaînes utiles au départ : la vérifiabilité, la décentralisation et la possibilité pour des inconnus de réaliser des transactions sans intermédiaire de confiance. Cinq techniques dominent le paysage actuel : les preuves à divulgation nulle, le chiffrement entièrement homomorphe (FHE), le calcul multipartite sécurisé (MPC), les environnements d’exécution de confiance (TEE) et les signatures en anneau avec adresses furtives. Chacune masque une partie différente du problème, repose sur une hypothèse de confiance différente et exige une quantité de calcul différente. Ce guide détaille les cinq, les compare côte à côte et explique pourquoi ce choix compte pour toute personne qui construit sur le Web3 ou cherche simplement à le comprendre.

Preuves à divulgation nulle

Une preuve à divulgation nulle (zero-knowledge proof, ZKP) permet à une partie — le prouveur — de convaincre une autre partie — le vérificateur — qu’un énoncé public est vrai sans révéler le témoin privé utilisé pour le prouver, au-delà de ce qu’impliquent déjà l’énoncé et sa validité. Dans une affirmation telle que « je connais un x tel que H(x) = y », le vérificateur voit normalement l’énoncé et la valeur publique y ; la divulgation nulle protège x. Les applications peuvent masquer séparément certaines parties de leurs entrées publiques ou les lier par un engagement cryptographique, mais masquer l’énoncé lui-même ne fait pas partie de la définition générale des ZKP (Thaler, Proofs, Arguments, and Zero-Knowledge).

Pour qu’un système de preuve constitue un véritable protocole à divulgation nulle, il doit satisfaire trois propriétés : la complétude (un vérificateur honnête accepte une affirmation vraie), la solidité (un prouveur malhonnête ne peut faire accepter une affirmation fausse par un vérificateur honnête, sauf avec la probabilité d’erreur bornée du système de preuve) et la divulgation nulle elle-même (la preuve ne révèle aucune information supplémentaire sur le témoin privé au-delà de ce qui découle de l’énoncé public). Les protocoles interactifs classiques utilisent souvent un engagement, un défi du vérificateur et une réponse du prouveur. Les SNARK et STARK modernes non interactifs regroupent les données de preuve nécessaires sans défi en direct du vérificateur, tout en préservant les mêmes objectifs généraux de complétude, de solidité et de divulgation nulle.

Ce qu’elle masque : le témoin privé, par exemple des données secrètes ou les entrées privées d’un calcul. L’énoncé public et les entrées publiques restent visibles, sauf si l’application les lie séparément par un engagement cryptographique ou les chiffre.

Utilisation actuelle : les rollups ZK constituent le principal usage des ZKP en production pour le passage à l’échelle des blockchains. Ils « regroupent (ou “roll up”) les transactions en lots exécutés hors chaîne », puis génèrent une unique preuve de validité qu’Ethereum vérifie avant de finaliser les changements d’état du lot (ethereum.org). zkSync Era, créé par Matter Labs, est « un ZK Rollup compatible EVM… alimenté par sa propre zkEVM » (ethereum.org), tandis que Starknet, créé par StarkWare, est un rollup de validité qui exécute sa propre machine virtuelle Cairo plutôt que l’EVM (les contrats Solidity y sont reliés séparément). L2BEAT répertorie les deux comme des rollups sécurisés par des preuves de validité plutôt que par la fenêtre de contestation par preuve de fraude utilisée par les rollups optimistes (l2beat.com). Côté confidentialité, Zcash a été pionnier des zk-SNARK (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) pour les transactions protégées, où « les adresses des utilisateurs, le montant de leurs transactions » et d’autres détails restent chiffrés, tandis que le réseau confirme toujours la validité de la transaction (z.cash).

Le compromis : générer une preuve ZK est coûteux en calcul — les circuits de preuve parcourent chaque transaction d’un lot et en réexécutent les vérifications — de sorte que le temps de génération et le coût du matériel constituent de véritables contraintes, même si la vérification on-chain est bon marché et rapide. La sécurité repose sur les hypothèses cryptographiques du système de preuve, la génération sûre de ses paramètres et l’implémentation correcte du circuit et du protocole ; pour certains systèmes, elle dépend aussi d’une cérémonie unique de configuration de confiance. La documentation d’Ethereum note qu’une entropie compromise lors de cette configuration peut permettre de produire de fausses preuves et que des erreurs d’implémentation peuvent fragiliser le modèle de sécurité (ethereum.org).

Chiffrement entièrement homomorphe (FHE)

Le chiffrement entièrement homomorphe adopte une approche différente : au lieu de prouver un fait au sujet de données cachées, il permet de calculer directement sur des données chiffrées et d’obtenir un résultat chiffré qui se déchiffre pour donner la même réponse que si le calcul avait été effectué sur des données en clair. Zama, l’une des principales entreprises de recherche et d’infrastructure FHE, le décrit ainsi : « le FHE permet de traiter des données sans les déchiffrer : les entreprises fournissent des services sans accéder aux données des utilisateurs, tandis que les utilisateurs conservent les mêmes fonctionnalités » (zama.org).

Ce qu’il masque : les entrées brutes, l’état intermédiaire et les sorties d’un calcul ; toute personne autre que le détenteur de la clé ne voit que le texte chiffré, y compris la partie qui effectue le calcul.

Fonctionnement, à haut niveau : les schémas FHE encodent des valeurs en clair dans des textes chiffrés fondés sur des mathématiques de réseaux euclidiens, puis définissent des équivalents chiffrés de l’addition et de la multiplication afin que des circuits arbitraires puissent s’exécuter sur ces textes chiffrés. Appliqué à une blockchain, cela signifie qu’un smart contract peut déplacer des jetons ou évaluer une logique sans jamais voir les montants concernés ; comme le formule l’exemple de Zama, « la blockchain a vérifié qu’Alice disposait de fonds suffisants sans jamais voir les montants réels » (zama.org). Zama note également que les schémas FHE fondés sur les réseaux sont « intrinsèquement résistants aux attaques quantiques », ce qui importe pour toute personne qui réfléchit au risque cryptographique à long terme (zama.org).

Exemples de projets : Zama développe les bibliothèques FHE open source (TFHE-rs, Concrete) et la fhEVM utilisée pour ajouter l’exécution confidentielle de smart contracts aux chaînes EVM. Fhenix est une blockchain conçue spécifiquement pour permettre aux « développeurs de construire des smart contracts respectueux de la confidentialité en utilisant le chiffrement entièrement homomorphe », afin que « les données sensibles restent chiffrées pendant tout le calcul » ; elle propose une bibliothèque JavaScript (Cofhejs) pour le chiffrement côté client et une bibliothèque Solidity FHE pour les opérations chiffrées on-chain (cofhe-docs.fhenix.zone).

Le compromis : la garantie distinctive du FHE est que les calculs pris en charge peuvent s’exécuter sans déchiffrer les entrées ni les valeurs intermédiaires, mais sa sécurité concrète dépend toujours du schéma et du choix des paramètres ; c’est pourquoi HomomorphicEncryption.org publie des tableaux de sécurité propres à chaque schéma et des recommandations pour sélectionner les paramètres (HomomorphicEncryption.org). Il reste aussi, de très loin, l’approche la plus coûteuse en calcul de cette liste par rapport à une exécution sur données en clair. C’est pourquoi les chaînes fondées sur le FHE exécutent aujourd’hui la logique critique pour la confidentialité plutôt que chaque transaction, et pourquoi l’accélération matérielle du FHE fait l’objet d’une course active de recherche.

Calcul multipartite sécurisé (MPC)

Le calcul multipartite sécurisé résout un problème proche, mais distinct : au lieu qu’une partie calcule sur des données chiffrées, plusieurs parties qui détiennent chacune une portion privée de l’entrée calculent conjointement une fonction sans révéler leurs entrées individuelles les unes aux autres. Selon la définition formelle, le MPC est « un sous-domaine de la cryptographie dont l’objectif est de créer des méthodes permettant à des parties de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées privées » ; ainsi, pour trois participants, « Alice, Bob et Charlie peuvent toujours apprendre F(x, y, z) sans révéler qui produit quoi » (Wikipedia).

Ce qu’il masque : l’entrée individuelle de chaque partie pour toutes les autres ; seule la sortie convenue est révélée, et aucun participant ne voit jamais le secret complet.

Hypothèse de confiance : il n’existe pas de seuil de corruption universel pour le MPC. Dans le résultat classique BGW pour un réseau complet, la confidentialité face aux fautes passives tient pour t < n/2, tandis que la robustesse face aux fautes byzantines tient pour t < n/3 (ACM). Ces bornes décrivent ce modèle de protocole, et non l’ensemble du MPC : des protocoles à sécurité parfaite peuvent atteindre t < n/2 lorsqu’un canal de diffusion est supposé (TCC 2021), tandis que le protocole SPDZ, fondé sur la sécurité calculatoire, assure une sécurité active avec jusqu’à n - 1 parties corrompues dans son modèle de prétraitement (IACR). Cette garantie avec majorité malhonnête est une sécurité avec avortement — une partie corrompue peut encore interrompre le calcul — et non une garantie d’équité ou de production du résultat (PoPETs). Une mise en œuvre concrète doit donc préciser le protocole, le modèle de corruption passive ou active, les hypothèses de synchronie, de canaux et de configuration — y compris la diffusion — ainsi que le recours à une majorité honnête ou malhonnête.

Utilisation actuelle — la conservation par signature à seuil : l’application blockchain la plus visible du MPC consiste à répartir une clé privée entre des parties indépendantes, de sorte qu’aucun appareil ou individu ne détienne jamais la clé complète. Le fournisseur d’infrastructure de conservation Fireblocks le décrit directement : « le calcul multipartite (MPC) est une méthode cryptographique qui divise une clé privée en parts distinctes réparties entre plusieurs parties indépendantes » et, surtout, « la clé complète n’est jamais assemblée en un seul endroit, à aucun moment » (fireblocks.com). Lorsqu’une transaction doit être signée, un quorum de points de terminaison valide chacun la transaction et apporte une signature partielle ; « à aucun moment la clé privée n’est assemblée », de sorte que « même si un point de terminaison est compromis… les parts de clé détenues ailleurs sont inutiles isolément » (fireblocks.com). Ce modèle de signature à seuil sous-tend désormais l’essentiel de la conservation institutionnelle de cryptoactifs et de nombreux portefeuilles à signatures multiples.

Le compromis : le MPC évite le point de défaillance unique d’une clé privée stockée sur un seul appareil, mais il ajoute des tours de communication entre les parties (de la latence) et exige une conception de protocole rigoureuse. Sa garantie ne vaut que les hypothèses cryptographiques, de corruption et de réseau du protocole choisi, ainsi que l’indépendance opérationnelle des parties ; le MPC peut supprimer le détenteur unique d’une clé sans éliminer la confiance de la conception du système.

Environnements d’exécution de confiance (TEE)

Un environnement d’exécution de confiance emprunte une autre voie : plutôt que de chiffrer les données pendant tout le calcul, il isole le calcul dans une région d’une puce protégée par le matériel — une enclave sécurisée — que même le système d’exploitation de la machine ne peut pas inspecter. SGX (Software Guard Extensions) d’Intel, l’implémentation la plus connue, est décrit sur Wikipedia comme « un ensemble de codes d’instruction mettant en œuvre un environnement d’exécution de confiance, intégré à certaines unités centrales de traitement (CPU) Intel » (Wikipedia). Mécaniquement, « SGX implique le chiffrement par le CPU d’une portion de mémoire (l’enclave) » ; « les données et le code provenant de l’enclave sont déchiffrés à la volée au sein du CPU, ce qui les protège contre l’examen ou la lecture par d’autres codes », notamment « du code exécuté à des niveaux de privilège supérieurs, tels que le système d’exploitation et les hyperviseurs sous-jacents » (Wikipedia).

Ce qu’il masque : les données et le code contenus dans l’enclave pour tous les autres processus de la même machine, y compris un système d’exploitation compromis ; c’est utile lorsqu’il faut faire confiance à l’exécution d’un morceau de code précis sans faire confiance à l’opérateur du serveur.

Hypothèse de confiance : la distinction n’oppose pas des « mathématiques pures » pour les ZKP, le FHE et le MPC à une confiance exclusivement placée dans le fournisseur pour un TEE. Les systèmes cryptographiques déployés dépendent aussi de leurs hypothèses de difficulté déclarées, de leurs paramètres ou de leur configuration, d’implémentations correctes et — pour le MPC — du modèle de participants et de communication du protocole. Un TEE ajoute à ce modèle de confiance une isolation soutenue par le matériel et l’attestation. Intel définit la base informatique de confiance de SGX comme le matériel, le firmware du processeur et les logiciels de la plateforme nécessaires pour atteindre les objectifs de sécurité de SGX ; l’attestation permet à l’entité qui s’y fie d’évaluer l’identité de l’enclave et le niveau de correctifs de la plateforme (Intel). Cette frontière de confiance a été mise à l’épreuve : SGX « ne protège pas contre les attaques par canal auxiliaire », et les chercheurs ont démontré à plusieurs reprises des compromissions concrètes, depuis l’extraction de « clés RSA d’enclaves SGX exécutées sur le même système en cinq minutes » (2017) jusqu’à l’attaque Foreshadow, qui « combine l’exécution spéculative et le dépassement de tampon pour contourner SGX » (2018), en passant par des vulnérabilités plus récentes, dont Plundervolt, LVI, SGAxe et ÆPIC Leak (Wikipedia). Cet historique explique pourquoi les TEE sont généralement présentés comme un compromis pragmatique et plus rapide plutôt que comme une garantie cryptographiquement étanche.

Exemples de projets : le réseau Sapphire d’Oasis Protocol exécute des smart contracts à l’intérieur d’enclaves matérielles afin que les utilisateurs puissent « exécuter du code dans des enclaves sécurisées par le matériel », où « les données restent chiffrées même pour les opérateurs de serveurs », tandis que « chaque exécution produit une preuve cryptographique que les utilisateurs peuvent vérifier sans confiance aveugle ». Il fournit ainsi des « smart contracts confidentiels » qui préservent « la compatibilité et la composabilité EVM » (oasis.net). Secret Network et plusieurs produits de confidentialité liés au restaking reposent aussi sur des TEE, souvent associés à d’autres techniques pour une défense en profondeur.

Le compromis : les TEE s’exécutent à une vitesse proche de la vitesse native — bien plus vite que le FHE ou la génération lourde de preuves ZK — ce qui les rend attrayants pour les applications sensibles à la latence. Mais cette vitesse s’accompagne d’une base informatique de confiance matérielle et logicielle plus étendue, avec un historique réel et documenté de compromissions par canal auxiliaire. La comparaison porte donc sur des hypothèses de système différentes, et non sur la confiance dans le matériel face à une « cryptographie pure » dépourvue d’hypothèses.

Signatures en anneau et adresses furtives

La dernière paire de techniques protège une cible plus limitée, mais très concrète : masquer qui a envoyé une transaction et qui l’a reçue, même si la transaction elle-même est visible on-chain. Monero en est le principal exemple en production pour les deux.

Les signatures en anneau masquent l’expéditeur. La documentation de Monero explique qu’« une signature en anneau est un type de signature numérique qui peut être produite par n’importe quel membre d’un groupe d’utilisateurs possédant chacun des clés » et qu’« il doit être impossible, du point de vue du calcul, de déterminer laquelle des clés des membres du groupe a servi à produire la signature » (getmonero.org). En pratique, une transaction Monero mélange la clé du véritable dépensier avec des clés publiques leurres « extraites de la blockchain au moyen d’une méthode de distribution gamma », de sorte que, dans un « anneau » de signataires possibles, tous les membres de l’anneau sont égaux et valides, et « aucun observateur extérieur ne peut déterminer lequel des signataires possibles d’un groupe de signatures appartient à votre compte » (getmonero.org).

Les adresses furtives masquent le destinataire. Au lieu de réutiliser une adresse publique, « l’expéditeur [crée] des adresses aléatoires à usage unique pour chaque transaction au nom du destinataire », de sorte que les paiements entrants « sont envoyés vers des adresses uniques sur la blockchain, où ils ne peuvent être reliés ni à l’adresse publiée du destinataire ni aux adresses d’aucune autre transaction » (getmonero.org). Un destinataire utilise une clé de visualisation privée pour parcourir la chaîne à la recherche de paiements et une clé de dépense privée pour les déplacer ; ainsi, « seuls l’expéditeur et le destinataire peuvent déterminer où un paiement a été envoyé » (getmonero.org).

Ce qu’elles masquent : l’identité de l’expéditeur (signatures en anneau) et celle du destinataire (adresses furtives) ; les montants des transactions sont masqués par un mécanisme distinct (Confidential Transactions / RingCT), qui n’est pas couvert par ces deux techniques seules.

Le compromis : les deux techniques s’exécutent efficacement sur du matériel ordinaire, sans surcharge de génération de preuve ni dépendance à une enclave, ce qui les rend bien adaptées à un réseau de paiements actif. Leur modèle de confiance repose toutefois sur l’impossibilité statistique de distinguer les ensembles de leurres du véritable signataire : une mauvaise sélection des leurres ou des heuristiques d’analyse de blockchain ont, par le passé, réduit les ensembles d’anonymat dans les premiers déploiements de signatures en anneau. Les choix de paramètres (taille de l’anneau, distribution des leurres) comptent donc autant que la primitive sous-jacente.

Comparaison des cinq approches

Aucune technologie ne l’emporte sur tous les axes ; c’est pourquoi la recherche actuelle les combine de plus en plus, par exemple des preuves ZK qui vérifient la correction d’un calcul MPC, ou des TEE utilisés avec le FHE pour une défense en profondeur.

Le lien avec les domaines tokenisés

Les domaines tokenisés héritent de la même transparence par défaut que tout autre actif on-chain : les transferts de propriété, les enchères et les mises à jour de métadonnées sont lisibles publiquement. C’est surtout une fonctionnalité — la provenance et l’historique de propriété sont précisément ce qui rend un domaine tokenisé digne de confiance en tant qu’actif négociable — mais cela signifie aussi que les avoirs et les prix de vente d’un portefeuille de domaines sont visibles par toute personne qui observe la chaîne.

Les technologies de confidentialité décrites ici indiquent la direction que pourrait prendre l’infrastructure de domaines sous forme de NFT : la conservation à seuil fondée sur le MPC sécurise déjà les portefeuilles institutionnels qui détiennent des NFT de domaine de la même manière qu’elle sécurise d’autres actifs numériques ; les preuves ZK pourraient un jour permettre à un enchérisseur de prouver qu’il peut financer une offre sans révéler l’intégralité de son solde ; et les techniques de calcul confidentiel pourraient permettre à un bureau d’enregistrement ou à une place de marché de vérifier des règles d’éligibilité sans exposer l’identité complète d’un acheteur. Rien de cela n’est déployé aujourd’hui dans la tokenisation de domaine, mais les primitives sous-jacentes sont les mêmes que celles qui sécurisent actuellement des milliards de dollars dans l’infrastructure DeFi et de conservation.

Sources et lectures complémentaires

• Preuves à divulgation nulle — ethereum.org
• Preuves, arguments et divulgation nulle — Justin Thaler
• Rollups ZK — ethereum.org
• Résumé du passage à l’échelle L2BEAT
• Présentation de la technologie Zcash
• Introduction au chiffrement homomorphe — Zama
• Recommandations de sécurité — HomomorphicEncryption.org
• Documentation cofhe de Fhenix
• Calcul multipartite sécurisé — Wikipedia
• Théorèmes de complétude pour le calcul distribué non cryptographique tolérant aux pannes — ACM
• Calcul efficace à sécurité parfaite — TCC 2021
• Calcul multipartite à partir du chiffrement quelque peu homomorphe (SPDZ) — IACR
• Étendre la sécurité de SPDZ par l’équité — PoPETs
• Qu’est-ce que le MPC ? — Fireblocks
• Software Guard Extensions (SGX) — Wikipedia
• Détails techniques de l’attestation Intel SGX
• Technologie Oasis Protocol
• Signatures en anneau — Moneropedia de Monero
• Adresses furtives — Moneropedia de Monero