Messari｜Couche de confidentialité : Comprendre le fonctionnement interne du calcul confidentiel décentralisé
TechFlow SélectionTechFlow Sélection
Messari｜Couche de confidentialité : Comprendre le fonctionnement interne du calcul confidentiel décentralisé
Le calcul confidentiel décentralisé (DeCC) représente un changement fondamental dans la manière de traiter les données sensibles dans les systèmes décentralisés.
Dédié à des analyses Web3 approfondiesAuteurs : Mohamed Allam, Drexel Bakker
Traduction : AI.bluue
Idées clés
-
DeCC introduit la capacité de protéger la confidentialité des données sur une blockchain publique intrinsèquement transparente, permettant le calcul privé et l'état privé sans sacrifier la décentralisation.
-
DeCC garantit la sécurité des données pendant leur utilisation en permettant des calculs cryptés sans exposer les données en clair, résolvant ainsi une vulnérabilité clé présente dans les systèmes traditionnels et les systèmes blockchain.
-
En combinant des outils cryptographiques (tels que ZKP, MPC, GC, FHE) avec des environnements d'exécution fiables (TEE) prouvables, DeCC assure une confidentialité sans confiance, chaque technologie offrant différents compromis entre performance et niveau de confiance, pouvant être combinés pour des garanties renforcées.
-
Plus d'un milliard de dollars ont déjà été investis dans des projets DeCC, reflétant la croissance du secteur, avec des équipes concentrées sur l'intégration pratique et les infrastructures orientées développeur.
Introduction : Évolution du calcul et de la sécurité des données
La technologie blockchain a introduit un nouveau paradigme de décentralisation et de transparence, mais elle comporte aussi des compromis. Lors de la première vague de confidentialité dans la cryptosphère, souvent appelée « confidentialité 1.0 », des outils tels que les mixeurs, les rouleurs ou les transactions privées (par exemple Zcash, Monero et Beam.mw) ont fourni un certain niveau d'anonymat aux transferts financiers des utilisateurs. Ces solutions étaient spécialisées, principalement limitées à masquer l'identité de l'émetteur et du destinataire, et étaient déconnectées de l'infrastructure applicative plus large.
Une deuxième vague est en train de se former. La confidentialité ne se limite plus à cacher les transactions, mais s'étend désormais au calcul complet. Ce changement marque l'émergence du calcul confidentiel décentralisé (DeCC), également connu sous le nom de « confidentialité 2.0 ». DeCC introduit le calcul privé comme caractéristique fondamentale des systèmes décentralisés, permettant aux données d'être traitées en toute sécurité sans divulguer les entrées sous-jacentes à d'autres utilisateurs ou au réseau.
Contrairement aux environnements typiques de contrats intelligents où toutes les modifications d'état et toutes les entrées sont visibles publiquement, DeCC conserve les données chiffrées tout au long du processus de calcul, révélant uniquement ce qui est nécessaire pour vérifier la validité et l'authenticité. Cela permet aux applications de maintenir un état privé par-dessus l'infrastructure blockchain publique. Par exemple, grâce au calcul multipartite (MPC), un groupe d'hôpitaux peut analyser leurs jeux de données combinés sans qu'aucune institution voie les données brutes des patients des autres institutions. Là où auparavant la transparence limitait ce que les blockchains pouvaient supporter, la confidentialité ouvre désormais une nouvelle catégorie d'applications nécessitant la protection des données sensibles.
DeCC est rendu possible par un ensemble de technologies conçues spécifiquement pour le traitement sécurisé des données. Ces technologies incluent les preuves à divulgation nulle de connaissance (ZKP), le calcul multipartite (MPC), les circuits chiffrés (GC) et le chiffrement homomorphe complètement homomorphe (FHE), toutes reposant sur la cryptographie pour imposer la confidentialité et la correction. Les environnements d'exécution fiables (TEE) complètent ces outils en fournissant une isolation matérielle pour une exécution hors chaîne sécurisée. Ensemble, ces technologies constituent la base de la pile technique DeCC.
Les applications potentielles sont très vastes : systèmes de finance décentralisée (DeFi) gardant les stratégies de trading confidentielles, plateformes de santé publique extrayant des informations à partir de données privées, ou modèles d'intelligence artificielle entraînés sur des ensembles de données distribués sans exposer les entrées sous-jacentes. Tous exigent que le calcul protégé par la confidentialité soit intégré directement dans la couche infrastructurelle des systèmes blockchain.
Ce rapport explore l'état actuel de DeCC et ses implications plus larges. Nous comparons d'abord la manière dont les données sont traitées dans les systèmes traditionnels et dans les cadres DeCC, et pourquoi la simple transparence n'est pas suffisante pour de nombreuses applications décentralisées. Ensuite, nous examinons les technologies fondamentales soutenant DeCC, leurs différences, et comment elles peuvent être combinées afin d'équilibrer les compromis liés aux performances, à la confiance et à la flexibilité. Enfin, nous dressons un panorama de l'écosystème, en mettant en lumière les capitaux injectés, les équipes construisant en production, et ce que cette dynamique signifie pour l'avenir du calcul décentralisé.
Traitement des données traditionnel vs Calcul Confidentiel Décentralisé (DeCC)
Pour comprendre la nécessité de DeCC, il est utile d’examiner comment les données sont traitées dans les environnements informatiques classiques et où se trouvent les points faibles. Dans les architectures informatiques classiques, les données existent généralement sous trois formes : au repos (stockées sur disque ou dans une base de données), en transit (se déplaçant via un réseau) et en cours d'utilisation (traitées en mémoire ou sur le processeur). Grâce à des décennies de progrès en matière de sécurité, l'industrie du calcul confidentiel dispose de solutions fiables pour deux de ces états.
-
Données au repos : Chiffrées à l’aide de techniques telles que le chiffrement au niveau du disque ou de la base de données (ex. AES). Couramment utilisé dans les systèmes d’entreprise, les appareils mobiles et le stockage cloud.
-
Données en transit : Protégées par des protocoles de transmission sécurisés tels que TLS/SSL. Assure que les données restent chiffrées lorsqu’elles circulent entre systèmes ou à travers un réseau.
-
Données en cours d’utilisation : Traditionnellement, les données chiffrées reçues depuis le stockage ou le réseau sont déchiffrées avant traitement. Cela signifie que la charge de travail fonctionne sur des données en clair, laissant les données en cours d’utilisation non protégées et exposées à des menaces potentielles. DeCC vise à combler cette faille en permettant des calculs sans divulguer les données sous-jacentes.
Bien que les deux premiers états soient bien protégés, assurer la sécurité des données en cours d'utilisation reste un défi. Que ce soit un serveur bancaire calculant des paiements d’intérêts ou une plateforme cloud exécutant un modèle d’apprentissage automatique, les données doivent généralement être déchiffrées en mémoire. À cet instant, elles deviennent vulnérables : un administrateur malveillant, un logiciel malveillant ou un système d’exploitation compromis pourrait espionner, voire modifier, des données sensibles. Les systèmes traditionnels atténuent cela par des contrôles d’accès et des infrastructures isolées, mais fondamentalement, il existe une période où le « joujou le plus précieux » se trouve en clair à l’intérieur de la machine.
Considérons maintenant les projets basés sur la blockchain. Ils poussent la transparence encore plus loin : les données ne sont pas seulement susceptibles d’être déchiffrées sur un seul serveur, mais sont souvent copiées en texte clair sur des milliers de nœuds à travers le monde. Des blockchains publiques comme Ethereum ou Bitcoin diffusent intentionnellement toutes les données transactionnelles pour atteindre un consensus. Si vos données ne sont que des informations financières publiques (ou pseudonymes), cela convient. Mais si vous souhaitez utiliser la blockchain pour tout cas d’usage impliquant des informations sensibles ou personnelles, cela devient totalement inacceptable. Par exemple, dans Bitcoin, le montant et les adresses de chaque transaction sont visibles de tous — excellent pour l’auditabilité, mauvais pour la confidentialité. Pour les plateformes de contrats intelligents, toute donnée que vous insérez dans un contrat (votre âge, votre séquence ADN, les informations de la chaîne d’approvisionnement de votre entreprise) est rendue publique à tous les participants du réseau. Aucune banque ne souhaite que toutes ses transactions soient publiques, aucun hôpital ne peut mettre les dossiers médicaux des patients sur un grand livre public, et aucune société de jeux ne veut révéler l’état secret des joueurs.
Cycle de vie des données et leurs vulnérabilités
Dans le cycle de vie traditionnel du traitement des données, un utilisateur envoie généralement ses données à un serveur, qui les déchiffre, les traite, puis stocke le résultat (éventuellement chiffré sur disque) et renvoie une réponse (chiffrée via TLS). Le point de vulnérabilité est évident : pendant l'utilisation, le serveur détient les données originales. Si vous faites confiance au serveur et à sa sécurité, tout va bien — mais l’histoire montre que les serveurs peuvent être piratés ou que des employés internes peuvent abuser de leurs droits d’accès. Les entreprises gèrent cela par des pratiques de sécurité strictes, mais elles restent prudentes quant à remettre des données extrêmement sensibles à des tiers.
À l’inverse, dans l’approche DeCC, l’objectif est qu’à aucun moment une entité unique ne puisse voir les données sensibles en clair, même pendant le traitement. Les données peuvent être divisées entre plusieurs nœuds, traitées à l’intérieur d’un « enveloppe » cryptée, ou manipulées via des preuves cryptographiques sans jamais les afficher. Ainsi, tout le cycle de vie, de l’entrée à la sortie, peut rester confidentiel. Par exemple, au lieu d’envoyer les données brutes à un serveur, un utilisateur peut envoyer une version chiffrée ou des parts secrètes de celles-ci à un réseau de nœuds. Ces nœuds effectuent des calculs de façon à ce qu’aucun d’eux ne puisse apprendre les données sous-jacentes, et l’utilisateur obtient un résultat chiffré que seul lui (ou une partie autorisée) peut déchiffrer.
Pourquoi la transparence ne suffit pas dans la cryptosphère
Bien que les blockchains publiques résolvent le problème de la confiance (nous n’avons plus besoin de faire confiance à un opérateur central ; les règles sont transparentes et appliquées par consensus), elles le font au prix de la confidentialité. Le slogan est : « Ne mettez rien sur la chaîne que vous ne souhaiteriez pas rendre public. » Pour de simples transferts de cryptomonnaies, cela peut convenir dans certains cas ; pour des applications complexes, cela peut devenir problématique. Comme l’a dit l’équipe de Penumbra (qui construit une chaîne DeFi privée), dans la DeFi actuelle, « lorsque les utilisateurs interagissent sur la chaîne, la fuite d’information devient une fuite de valeur », conduisant au front-running et à d’autres vulnérabilités. Si nous voulons que les échanges décentralisés, les marchés de prêt ou les enchères fonctionnent équitablement, les données des participants (offres, positions, stratégies) doivent généralement être cachées ; sinon, des tiers peuvent exploiter ces connaissances en temps réel. La transparence rend publics les mouvements de chaque utilisateur, contrairement au fonctionnement des marchés traditionnels — et pour de bonnes raisons.
En outre, de nombreux cas d’usage pertinents en dehors de la finance impliquent des données personnelles ou réglementées qui ne peuvent légalement pas être rendues publiques. Prenons l’identité décentralisée ou le score de crédit — un utilisateur pourrait vouloir prouver certaines propriétés à son sujet (« j’ai plus de 18 ans » ou « mon score de crédit est de 700 ») sans révéler son identité complète ou son historique financier. Dans un modèle entièrement transparent, c’est impossible ; toute preuve que vous placez sur la chaîne expose les données. Les technologies DeCC comme les preuves à divulgation nulle (ZKP) sont précisément conçues pour résoudre ce problème, permettant une divulgation sélective (prouver X sans révéler Y). Un autre exemple : une entreprise pourrait vouloir utiliser la blockchain pour suivre sa chaîne d’approvisionnement, sans que ses concurrents puissent voir ses journaux d’inventaire bruts ou ses données de ventes. DeCC peut soumettre des données chiffrées sur la chaîne et partager les informations déchiffrées uniquement avec des partenaires autorisés, ou utiliser des preuves ZK pour prouver le respect de certaines normes sans révéler ses secrets commerciaux.
Comment DeCC permet le calcul confidentiel sans confiance
Résoudre les limites de la transparence dans les systèmes décentralisés nécessite une infrastructure capable de préserver la confidentialité pendant le calcul actif. Le calcul confidentiel décentralisé fournit une telle infrastructure en introduisant un ensemble de méthodes cryptographiques et matérielles conçues pour protéger les données tout au long de leur cycle de vie. Ces technologies visent à garantir que les entrées sensibles ne soient pas divulguées même pendant le traitement, éliminant ainsi le besoin de faire confiance à un opérateur ou à un intermédiaire unique.
La pile technique DeCC comprend les preuves à divulgation nulle (ZKP), qui permettent à une partie de prouver qu’un calcul a été correctement exécuté sans révéler les entrées ; le calcul multipartite (MPC), qui permet à plusieurs parties de calculer conjointement une fonction sans exposer leurs données respectives ; les circuits chiffrés (GC) et le chiffrement homomorphe complètement homomorphe (FHE), qui permettent d’effectuer des calculs directement sur des données chiffrées ; ainsi que les environnements d’exécution fiables (TEE), qui offrent une isolation matérielle pour une exécution sécurisée. Chacune de ces technologies possède des caractéristiques opérationnelles, des modèles de confiance et des profils de performance distincts. En pratique, elles sont souvent intégrées pour répondre aux différentes contraintes de sécurité, d’évolutivité et de déploiement des applications. Les sections suivantes décrivent les bases techniques de chacune et comment elles permettent un calcul privé sans confiance dans les réseaux décentralisés.
1. Preuves à divulgation nulle (ZKP)
Les preuves à divulgation nulle (ZKP) comptent parmi les innovations cryptographiques les plus influentes appliquées aux systèmes blockchain. Un ZKP permet à une partie (le prouveur) de convaincre une autre partie (le vérificateur) qu’une affirmation donnée est vraie, sans révéler aucune information supplémentaire au-delà de la validité de cette affirmation elle-même. Autrement dit, cela permet à quelqu’un de prouver qu’il connaît quelque chose — comme un mot de passe, une clé privée ou la solution à un problème — sans divulguer la connaissance elle-même.
Prenons l’exemple du puzzle « où est Waldo ? ». Supposons que quelqu’un affirme avoir trouvé Waldo sur une image bondée, mais ne veuille pas révéler sa position exacte. Au lieu de partager l’image complète, ils prennent une photo rapprochée du visage de Waldo, accompagnée d’un horodatage, agrandie au point que le reste de l’image n’apparaisse pas. Le vérificateur peut confirmer que Waldo a été trouvé, sans savoir où il se trouve dans l’image. L’affirmation est prouvée correcte, sans révéler d’information supplémentaire.
Plus formellement, une preuve à divulgation nulle permet au prouveur de démontrer qu’un énoncé spécifique est vrai (par exemple, « je connais une clé dont le hachage correspond à cette valeur publique » ou « cette transaction est valide selon les règles du protocole »), sans divulguer les entrées ou la logique interne du calcul. Le vérificateur est convaincu, mais n’obtient aucune autre information. L’un des exemples les plus anciens et les plus répandus dans la blockchain est zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge). Zcash utilise zk-SNARKs pour permettre aux utilisateurs de prouver qu’ils possèdent une clé privée et qu’ils effectuent une transaction valide, sans révéler l’adresse de l’émetteur, celle du destinataire ni le montant. Le réseau voit seulement une courte preuve cryptographique attestant que la transaction est légale.
Comment les ZKP permettent-ils le calcul confidentiel ? Dans un environnement DeCC, les ZKP brillent lorsque vous souhaitez prouver qu’un calcul a été correctement effectué sur des données cachées. Le prouveur peut effectuer le calcul en privé, puis publier une preuve, plutôt que de demander à tout le monde de refaire le calcul (comme dans la validation blockchain traditionnelle). Les autres peuvent utiliser cette petite preuve pour vérifier que le résultat est correct, sans voir les données sous-jacentes. Cela protège la confidentialité et améliore considérablement l’évolutivité (car vérifier une preuve concise est beaucoup plus rapide que de refaire tout le calcul). Des projets comme Aleo construisent une plateforme complète autour de cette idée : les utilisateurs exécutent des programmes hors ligne sur leurs données privées et génèrent une preuve ; le réseau vérifie la preuve et accepte la transaction. Le réseau ne connaît ni les données ni ce qui s’est passé précisément, mais il sait que quoi qu’il en soit, cela suit les règles du contrat intelligent. Cela crée efficacement des contrats intelligents privés, impossibles sur la machine virtuelle publique d’Ethereum sans ZKP. Une autre application émergente concerne les zk-rollups pour la confidentialité : ils regroupent non seulement les transactions pour l’évolutivité, mais utilisent aussi des ZK pour cacher les détails de chaque transaction (contrairement aux rollups classiques, dont les données sont généralement toujours publiques).
Les ZK-proofs sont puissants car leur sécurité repose purement sur des mathématiques, dépendant généralement de l’honnêteté des participants à une « cérémonie » (un protocole cryptographique multipartite produisant des informations secrètes/aléatoires) lors de la phase d’initialisation. Si les hypothèses cryptographiques tiennent (par exemple, certains problèmes restent difficiles à résoudre), la preuve ne peut être falsifiée ni utilisée pour affirmer une fausse déclaration. Par conception, elle ne divulgue aucune information supplémentaire. Cela signifie que vous n’avez pas besoin de faire confiance au prouveur ; la preuve passe ou elle ne passe pas.
Limites : Le compromis historique concerne la performance et la complexité. Générer une preuve ZK peut être très coûteux en calcul (plusieurs ordres de grandeur plus élevé que le calcul normal). Dans les constructions initiales, même prouver des affirmations simples pouvait prendre plusieurs minutes ou plus, et la cryptographie était complexe et nécessitait des configurations spéciales (cérémonie de configuration fiable) — bien que des systèmes plus récents comme STARKs évitent certains de ces problèmes. Il existe aussi des limites fonctionnelles : la plupart des schémas ZK impliquent un prouveur unique prouvant quelque chose à de nombreux vérificateurs. Ils ne résolvent pas l’état partagé privé (données privées « appartenant à » ou combinées par plusieurs utilisateurs, comme dans les enchères ou les AMM). Autrement dit, un ZK peut prouver qu’un utilisateur a correctement calculé Y à partir de mon secret X, mais il ne permet pas à deux personnes de calculer conjointement une fonction de leurs deux secrets. Pour résoudre ce problème, les solutions basées sur ZK utilisent souvent d’autres technologies comme MPC, GC et FHE. De plus, les ZKPs purs supposent généralement que le prouveur connaît réellement ou possède les données prouvées.
Il y a aussi la question de la taille : les premiers zk-SNARKs produisaient des preuves très courtes (quelques centaines d’octets), mais certaines nouvelles preuves à divulgation nulle (notamment celles sans configuration fiable, comme bulletproofs ou STARKs) peuvent être plus grandes (des dizaines de Ko) et plus lentes à vérifier. Toutefois, l’innovation continue (Halo, Plonk, etc.) améliore rapidement l’efficacité. Ethereum et d’autres acteurs investissent massivement dans les ZK comme solution d’évolutivité et de confidentialité.
2. Calcul multipartite (MPC)
Les preuves ZK permettent à une partie de prouver quelque chose concernant ses propres données privées, tandis que le calcul multipartite sécurisé (principalement désignant les techniques basées sur le partage de secret - SS) résout un autre défi lié mais différent : comment calculer réellement quelque chose de manière collaborative sans divulguer les entrées. Dans un protocole MPC, plusieurs parties indépendantes (ou nœuds) calculent conjointement une fonction de toutes leurs entrées, de sorte que chaque participant n’apprenne que le résultat, sans rien connaître des entrées des autres. Les bases du MPC basé sur le partage de secret ont été posées par Ivan Damgard de la Partsia Blockchain Foundation et ses co-auteurs dans des articles des années 1980. Depuis, diverses techniques ont été développées.
Un exemple simple : un groupe d’entreprises souhaite calculer le salaire moyen sectoriel pour un poste donné, mais aucune ne veut révéler ses données internes. Avec MPC, chaque entreprise entre ses données dans un calcul conjoint. Le protocole garantit qu’aucune entreprise ne voit les données brutes des autres participants, mais tous reçoivent la moyenne finale. Le calcul est exécuté via un protocole cryptographique à travers le groupe, éliminant le besoin d’un organisme central. Dans ce cadre, le processus lui-même agit comme un intermédiaire de confiance.
Comment fonctionne MPC ? L’entrée de chaque participant est mathématiquement divisée en plusieurs parts (shares) et distribuée à tous les participants. Par exemple, si mon secret est 42, je peux générer des nombres aléatoires dont la somme fait 42, et donner une part à chaque participant (chaque part semblant aléatoire). Aucune part individuelle ne révèle d’information, mais ensemble elles contiennent l’information. Ensuite, les participants effectuent des calculs sur ces parts, s’échangeant des messages, jusqu’à obtenir des parts du résultat, qui peuvent être combinées pour révéler le résultat final. Pendant tout le processus, personne ne voit les entrées originales ; ils ne voient que des données codées ou brouillées.
Pourquoi MPC est-il important ? Parce qu’il est essentiellement décentralisé, il ne dépend pas d’une seule boîte sécurisée (comme un TEE) ni d’un seul prouveur (comme dans le ZK). Il élimine le besoin de faire confiance à une seule partie. Une définition courante le décrit ainsi : lorsque le calcul est distribué entre les participants, aucune partie n’est dépendante pour protéger la confidentialité ou garantir la correction. Cela en fait un pilier des technologies de protection de la vie privée. Si vous avez 10 nœuds effectuant un calcul MPC, généralement, il faut qu’une grande partie d’entre eux collaborent ou soient compromises pour révéler le secret. Cela correspond bien au modèle de confiance décentralisé de la blockchain.
Les défis de MPC : la confidentialité n’est pas gratuite. Les protocoles MPC engendrent généralement des frais généraux, principalement en communication. Pour calculer ensemble, les parties doivent échanger plusieurs tours de messages cryptés. Le nombre de tours de communication (messages aller-retour successifs) et les besoins en bande passante augmentent avec la complexité de la fonction et le nombre de participants. À mesure que davantage de parties participent, assurer l’efficacité du calcul devient délicat. Il y a aussi la question des participants honnêtes contre malveillants. Les protocoles MPC de base supposent que les participants suivent le protocole (curieux mais non déviants). Des protocoles plus robustes peuvent gérer des comportements malveillants (qui pourraient envoyer de fausses informations pour tenter de violer la confidentialité ou la correction), mais cela ajoute plus de frais pour détecter et atténuer la tricherie. Curieusement, la blockchain peut aider en fournissant un cadre pour punir les comportements incorrects. Par exemple, si un nœud dévie du protocole, des mécanismes de mise en jeu et de pénalités peuvent être utilisés, ce qui rend MPC et blockchain complémentaires.
En termes de performance, des progrès significatifs ont été réalisés. Des techniques de prétraitement peuvent effectuer les calculs cryptographiques lourds avant que les entrées réelles ne soient connues. Par exemple, générer des données aléatoires pertinentes (appelées triplets de Beaver) peut servir ultérieurement à accélérer les opérations de multiplication. Ainsi, lorsque le calcul doit être effectué sur de véritables entrées (phase en ligne), il peut être beaucoup plus rapide. Certains cadres MPC modernes peuvent calculer des fonctions assez complexes entre quelques participants en quelques secondes ou moins. Il existe aussi des recherches sur l’extension de MPC à de nombreux participants en organisant les nœuds en réseau ou comités.
MPC est particulièrement important pour des applications telles que les dApps privées multi-utilisateurs (enchères avec offres confidentielles exécutées via MPC), l’apprentissage automatique protégé par la confidentialité (plusieurs entités entraînant conjointement un modèle sans partager leurs données — un domaine actif appelé apprentissage fédéré avec MPC) et la gestion de secrets distribués (comme les exemples de clés seuil). Un exemple concret dans la cryptosphère est Partisia Blockchain, qui intègre MPC dans son cœur pour permettre la confidentialité de niveau entreprise sur une blockchain publique. Partisia utilise un réseau de nœuds MPC pour traiter la logique des contrats intelligents privés, puis publie sur la chaîne des engagements ou des résultats chiffrés.
3. Circuits chiffrés (GC)
Les circuits chiffrés sont un concept fondamental de la cryptographie moderne et l'une des premières solutions proposées pour effectuer des calculs sur des données chiffrées. Outre le support du calcul crypté, les méthodes GC sont utilisées dans divers protocoles de protection de la vie privée, notamment les preuves à divulgation nulle et les jetons anonymes/inliens.
Qu'est-ce qu'un circuit ? Un circuit est un modèle de calcul universel pouvant représenter n'importe quelle fonction, de l'arithmétique simple aux réseaux neuronaux complexes. Bien que ce terme soit généralement associé au matériel, les circuits sont largement utilisés dans diverses technologies DeCC, notamment ZK, MPC, GC et FHE. Un circuit comprend des lignes d'entrée, des portes intermédiaires et des lignes de sortie. Lorsque des valeurs (booléennes ou arithmétiques) sont fournies aux lignes d'entrée, les portes traitent ces valeurs et produisent la sortie correspondante. La disposition des portes définit la fonction calculée. Les fonctions ou programmes sont convertis en représentation de circuit à l'aide de compilateurs VHDL ou de compilateurs cryptographiques spécifiques au domaine.
Qu'est-ce qu'un circuit chiffré ? Un circuit standard divulgue toutes les données pendant son exécution : les valeurs sur les lignes d'entrée et de sortie, ainsi que les sorties des portes intermédiaires, sont en clair. En revanche, un circuit chiffré crypte tous ces composants. Les entrées, sorties et valeurs intermédiaires sont transformées en valeurs cryptées (texte chiffré), et les portes sont appelées portes chiffrées. L'algorithme de circuit chiffré est conçu de telle sorte que l'évaluation du circuit ne révèle aucune information sur les valeurs en clair d'origine. Le processus de conversion d'une valeur en clair en texte chiffré, puis son décodage, est appelé encodage et décodage.
Comment les GC résolvent-ils le problème du calcul sur données chiffrées ? Les circuits chiffrés ont été proposés par Andrew Yao en 1982 comme la première solution universelle pour calculer sur des données chiffrées. Son exemple initial, appelé le problème des millionnaires, impliquait un groupe voulant savoir qui était le plus riche sans révéler leurs richesses respectives. Avec un circuit chiffré, chaque participant chiffre son entrée (sa richesse) et partage la version chiffrée avec les autres. Ensuite, le groupe évalue progressivement le circuit conçu pour calculer le maximum, en utilisant des portes chiffrées. Le résultat final (par exemple, l'identité du plus riche) est déchiffré, mais personne ne connaît les entrées exactes des autres participants. Bien que cet exemple utilise une simple fonction de maximum, la même méthode peut s'appliquer à des tâches plus complexes, notamment l'analyse statistique et l'inférence de réseaux neuronaux.
Les avancées récentes dirigées par Soda Labs ont appliqué la technologie des circuits chiffrés à des environnements décentralisés. Ces progrès se concentrent principalement sur trois domaines clés : la décentralisation, la composable et l'auditable publique. Dans un cadre décentralisé, le calcul est divisé entre deux groupes indépendants : les obfuscateurs (responsables de la génération et de la distribution du circuit chiffré) et les évaluateurs (responsables de l'exécution du circuit chiffré). Les obfuscateurs fournissent le circuit au réseau d'évaluateurs, qui exécutent ces circuits à la demande selon la logique du contrat intelligent.
Cette séparation permet la composable, c'est-à-dire la construction de calculs complexes à partir d'opérations atomiques plus petites. Soda Labs y parvient en générant un flux continu de circuits chiffrés correspondant aux instructions de bas niveau d'une machine virtuelle (par exemple, pour EVM). Ces blocs constitutifs peuvent être assemblés dynamiquement au moment de l'exécution pour accomplir des tâches plus complexes.
Pour l'auditable publique, Soda Labs propose un mécanisme permettant à des tiers (qu'ils participent ou non au calcul) de vérifier que le résultat a été correctement calculé. Cette vérification peut être effectuée sans exposer les données sous-jacentes, ajoutant ainsi une confiance et une transparence supplémentaires.
L'importance des GC pour DeCC : les circuits chiffrés offrent un calcul à faible latence et haut débit sur des entrées chiffrées. Comme démontré sur le réseau principal de COTI, les implémentations initiales prennent en charge environ 50 à 80 transactions ERC20 confidentielles par seconde (ctps), avec des versions futures promettant un débit plus élevé. Les protocoles GC reposent sur des standards cryptographiques largement adoptés (comme AES) et des bibliothèques comme OpenSSL, largement utilisées dans les domaines de la santé, de la finance et du gouvernement. AES offre également des variantes résistantes aux ordinateurs quantiques, prenant en charge la compatibilité future avec les exigences de sécurité post-quantique.
Les systèmes basés sur GC sont compatibles avec les environnements clients et ne nécessitent ni matériel spécialisé ni GPU, contrairement à certains déploiements TEE ou FHE. Cela réduit les coûts d'infrastructure et permet un déploiement sur une gamme plus large de dispositifs, y compris ceux à faible capacité.
Les défis des GC : la limitation principale des circuits chiffrés est la surcharge de communication. Les implémentations actuelles nécessitent d'envoyer environ 1 Mo de données aux évaluateurs pour chaque transaction ERC20 confidentielle. Cependant, ces données peuvent être préchargées longtemps avant l'exécution, donc elles n'introduisent pas de latence pendant l'utilisation en temps réel. L'amélioration continue de la disponibilité de la bande passante, y compris les tendances décrites par la loi de Nielsen (prédisant un doublement de la bande passante tous les 21 mois), ainsi que la recherche active sur la compression des circuits chiffrés, contribuent à réduire cette surcharge.
4. Chiffrement homomorphe complètement homomorphe (FHE)
Le chiffrement homomorphe complètement homomorphe (FHE) est souvent considéré comme une forme de magie cryptographique. Il permet d'effectuer des calculs arbitraires sur des données tout en conservant leur état chiffré, puis de déchiffrer le résultat pour obtenir la bonne réponse, comme si le calcul avait été effectué en clair. Autrement dit, avec FHE, vous pouvez externaliser le calcul sur vos données privées vers un serveur non fiable, qui opère uniquement sur le texte chiffré, et produit quand même un texte chiffré que vous pouvez déchiffrer pour obtenir la bonne réponse, le tout sans que le serveur ne voie vos données ou le résultat en clair.
Pendant longtemps, le FHE était purement théorique. Ce concept était connu depuis les années 1970, mais ce n'est qu'en 2009 qu'un schéma pratique a été découvert. Depuis, des progrès constants ont été réalisés pour réduire le coût computationnel du FHE. Malgré cela, il reste très intensif en calcul. Les opérations sur des données chiffrées peuvent être des milliers ou des millions de fois plus lentes que sur des données en clair. Mais des opérations autrefois d'une lenteur astronomique sont désormais simplement assez lentes, et les optimisations ainsi que les accélérateurs FHE spécialisés améliorent rapidement la situation.
Pourquoi le FHE est-il révolutionnaire pour la confidentialité ? Avec FHE, vous pouvez faire exécuter des calculs par un serveur unique ou un nœud blockchain, tant que le chiffrement reste solide, ce nœud n'apprend rien. C'est une forme très pure de calcul confidentiel : les données restent chiffrées partout. Pour la décentralisation, vous pouvez aussi faire en sorte que plusieurs nœuds exécutent chacun un calcul FHE pour assurer la redondance ou le consensus, mais aucun d'eux n'a accès à l'information secrète. Ils manipulent tous uniquement des textes chiffrés.
Dans le contexte blockchain, le FHE ouvre la possibilité de transactions et de contrats intelligents entièrement chiffrés. Imaginez un réseau similaire à Ethereum où vous envoyez des transactions chiffrées aux mineurs, qui exécutent la logique du contrat intelligent sur les données chiffrées et incluent un résultat chiffré dans la chaîne. Vous ou une partie autorisée pouvez déchiffrer le résultat plus tard. Pour les autres, ce n'est qu'un tas de charabia illisible, mais ils pourraient avoir une preuve que le calcul était valide. C'est là que le mélange de FHE et de ZK pourrait intervenir, prouvant que la transaction chiffrée suit les règles. C'est essentiellement ce que vise le projet Fhenix : une couche 2 compatible EVM dont tous les calculs prennent nativement en charge le FHE.
Applications pratiques activées par FHE : au-delà de la blockchain, le FHE est déjà attrayant pour le cloud computing. Par exemple, vous pouvez envoyer une requête chiffrée à une base de données dans le cloud et recevoir une réponse chiffrée, que seul vous pouvez déchiffrer. Dans le contexte blockchain, un scénario intéressant concerne l'apprentissage automatique protégé par la confidentialité. Le FHE permet à un réseau décentralisé d'exécuter l'inférence d'un modèle d'IA sur des données chiffrées fournies par les utilisateurs, de sorte que le réseau n'apprenne ni l'entrée ni le résultat, et que seul vous sachiez après déchiffrement. Un autre cas d'usage concerne le secteur public ou la collaboration sur des données de santé. Différents hôpitaux peuvent utiliser une clé commune ou un système de clé fédérale pour chiffrer leurs données patient, un réseau de nœuds peut calculer des statistiques agrégées sur les données chiffrées de tous les hôpitaux, et livrer le résultat aux chercheurs pour déchiffrement. Cela ressemble à ce que peut faire le MPC, mais le FHE pourrait y parvenir avec une architecture plus simple, nécessitant uniquement un cloud non fiable ou un réseau de mineurs manipulant des chiffres, au prix d'opérations plus coûteuses en calcul.
Les défis du FHE : le plus grand défi est la performance. Malgré les progrès, le FHE est généralement encore mille à un million de fois plus lent que les opérations en clair, selon le calcul et le schéma. Cela signifie qu'il n'est actuellement adapté qu'à des tâches limitées, comme des fonctions simples ou le traitement par lots d'un grand nombre d'opérations en une seule fois dans certains schémas, mais pas encore une technologie que vous pouvez utiliser pour exécuter une machine virtuelle complexe effectuant des millions d'étapes, du moins sans support matériel puissant. Il y a aussi le problème de la taille du texte chiffré. Les opérations FHE ont tendance à faire exploser la taille des données. Certaines optimisations, comme le bootstrap (bootstrapping), qui rafraîchit le texte chiffré dont le bruit commence à s'accumuler pendant les opérations, sont nécessaires pour des calculs de longueur arbitraire et ajoutent des frais généraux. Cependant, de nombreuses applications n'ont pas besoin d'une profondeur complètement arbitraire. Elles peuvent utiliser un HE hiérarchisé (leveled HE), qui exécute un nombre fixe de multiplications avant le déchiffrement, et peut éviter le bootstrap.
Pour la blockchain, intégrer le FHE est complexe. Si chaque nœud doit exécuter une opération FHE pour chaque transaction, cela pourrait être très lent avec la technologie actuelle. C'est pourquoi des projets comme Fhenix commencent par une L2 ou une sidechain, où un coordinateur puissant ou un sous-ensemble de nœuds peut effectuer les calculs FHE lourds, et la L2 regroupe les résultats. Avec le temps, à mesure que le FHE devient plus efficace, ou que des ASIC ou GPU spécialisés FHE apparaissent, il pourrait être adopté plus largement. Il convient de noter que certaines entreprises et cercles académiques étudient activement le matériel pour accélérer le FHE, reconnaissant son importance pour l'avenir de la confidentialité des données dans les cas d'usage Web2 et Web3.
Combiner le FHE avec d'autres technologies : souvent, le FHE peut être combiné avec le MPC ou le ZK pour compenser ses faiblesses. Par exemple, plusieurs parties peuvent détenir des parts de la clé FHE, de sorte qu'aucune partie unique ne puisse déchiffrer seule, créant ainsi effectivement un schéma FHE seuil. Cela combine MPC et FHE pour éviter un point de défaillance unique au déchiffrement. Ou alors, on peut utiliser une preuve à divulgation nulle pour prouver qu'une transaction FHE chiffrée est bien formatée sans la déchiffrer, afin que les nœuds blockchain puissent déterminer sa validité avant traitement. C'est ce que certains appellent le modèle hybride ZK-FHE. En réalité, une approche DeCC composable pourrait consister à utiliser le FHE pour le gros œuvre du traitement des données, car c'est l'une des rares méthodes capables de calculer tout en restant constamment chiffré, et à utiliser des preuves ZK pour garantir que le calcul n'a rien fait d'illégitime, ou permettre à d'autres de vérifier le résultat sans les voir.
5. Environnements d'exécution fiables (TEE)
Les environnements d'exécution fiables (TEE) sont un composant fondamental du calcul confidentiel décentralisé. Un TEE est une zone sécurisée à l'intérieur d'un processeur qui isole le code et les données du reste du système, garantissant que leur contenu est protégé même si le système d'exploitation est compromis. Le TEE assure la confidentialité et l'intégrité pendant le calcul, avec un minimum de surcoût en performance. Cela en fait l'une des technologies les plus pratiques disponibles pour un calcul général sécurisé.
On peut y penser ainsi : un TEE est comme lire un document confidentiel dans une pièce verrouillée à laquelle personne d'autre ne peut entrer ou regarder à l'intérieur. Vous êtes libre d'examiner et de traiter le document, mais une fois que vous quittez la pièce, vous emportez le résultat et laissez tout le reste verrouillé derrière vous. Les gens à l'extérieur ne verront jamais directement le document, seulement le résultat final que vous choisissez de révéler.
Les TEE modernes ont fait des progrès remarquables. Intel TDX et AMD SEV prennent en charge l'exécution sécurisée de machines virtuelles entières, et les GPU haute performance d'NVIDIA (y compris H100 et H200) disposent désormais de fonctionnalités TEE. Ces mises à jour rendent possible l'exécution d'applications arbitraires dans des environnements confidentiels, y compris des modèles d'apprentissage automatique, des services backend et des logiciels orientés utilisateur. Par exemple, Intel TDX combiné à NVIDIA H100 peut exécuter l'inférence sur des modèles de plus de 70 milliards de paramètres avec peu de perte de performance. Contrairement aux méthodes cryptographiques nécessitant des outils personnalisés ou des environnements restreints, les TEE modernes peuvent exécuter des applications conteneurisées sans modification. Cela permet aux développeurs d'écrire des applications en Python, Node.js ou d'autres langages standards tout en préservant la confidentialité des données.
Un exemple typique est Secret Network, la première blockchain à implémenter des contrats intelligents généraux avec état privé en exploitant les TEE (spécifiquement Intel SGX). Chaque nœud Secret exécute le runtime d'exécution des contrats intelligents à l'intérieur d'un enclave (zone sécurisée). Les transactions envoyées aux contrats intelligents sont chiffrées, de sorte que seul l'enclave peut les déchiffrer, exécuter le contrat intelligent et produire une sortie chiffrée. Le réseau utilise la preuve à distance (remote attestation) pour s'assurer que les nœuds exécutent le véritable SGX et le code d'enclave approuvé. Ainsi, les contrats intelligents sur Secret Network peuvent traiter des données privées, comme des entrées chiffrées, que même les opérateurs de nœuds ne peuvent pas lire. Seul l'enclave peut le faire, et il ne libère que ce qu'il doit libérer, généralement un hachage ou un résultat chiffré. Phala Network et Marlin utilisent un modèle similaire mais différent. Leur architecture repose sur des nœuds de travail pilotés par TEE, qui exécutent des calculs hors chaîne sécurisés et retournent des résultats vérifiés à la blockchain. Ce dispositif permet à Phala de protéger la confidentialité des données et l'intégrité de l'ex
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Messari
