← Derniers articles
💻 computer science

The Consensus Number of Untraceable Cryptocurrencies

Cet article analyse les coûts de synchronisation de l'impossibilité de traçabilité de l'expéditeur dans les cryptomonnaies en formalisant deux conceptions — des objets de transfert d'actifs intraçables linéaires (LUAT) et à état constant (CUAT) — et en déterminant que si le LUAT parvient à un nombre de consensus faible de 2 au prix d'un stockage croissant, le CUAT offre un état constant mais incorpore des nombres de consensus non bornés ou quadratiques et manque d'absence de famine selon la force de la garantie d'impossibilité de traçabilité.

Auteurs originaux : Christian Cachin, David Lehnherr, Juan Villacis, François-Xavier Wicht

Publié 2026-07-24
📖 7 min de lecture🧠 Analyse approfondie

Auteurs originaux : Christian Cachin, David Lehnherr, Juan Villacis, François-Xavier Wicht

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Grand Casse Numérique : Se Cacher à la Vue de Tous

Imaginez que vous soyez dans une pièce bondée où tout le monde chuchote des secrets. Dans le monde numérique des crypto-monnaies, cette pièce est le « registre », un immense carnet public qui enregistre qui a envoyé de l'argent à qui. Habituellement, ce carnet est comme une paroi de verre : vous pouvez voir exactement qui a payé qui, même si vous ne connaissez pas leurs vrais noms. Mais que se passerait-il si vous vouliez effectuer un paiement sans que personne ne sache quelle personne de la foule a réellement remis l'argent ? C'est là tout le défi de l'« intraçabilité de l'expéditeur ».

Pour résoudre cela, les cryptographes utilisent une astuce appelée « ensemble de masquage » (masking set). Imaginez que vous soyez celui qui paie, mais que vous vous teniez dans un groupe de dix amis. Vous tenez tous des enveloppes d'apparence identique. Pour un observateur extérieur, il semble que n'importe lequel des dix amis ait pu payer, mais il ne peut pas dire lequel. Le document que nous explorons plonge dans les mécanismes de ces groupes. Il pose une question très spécifique, presque philosophique : si nous voulons cacher l'expéditeur à l'intérieur d'un groupe, cet acte de dissimulation modifie-t-il le fonctionnement du groupe ? Plus précisément, cela rend-il plus difficile pour le groupe de s'accorder sur ce qui se passe ensuite ? Les auteurs étudient le « nombre de consensus », une façon sophistiquée de mesurer la coordination nécessaire pour accomplir des tâches. Voyez cela comme un « compteur de bouchons » : un chiffre bas signifie que les voitures peuvent se croiser facilement ; un chiffre élevé signifie qu'elles doivent s'arrêter, attendre et se disputer pour savoir qui passe en premier.

Les deux façons de se cacher : Le « Tout Garder » contre le « Tout Échanger »

Le document compare deux stratégies différentes pour gérer ces groupes d'amis (ensembles de masquage) afin de cacher l'expéditeur. Appelons-les la Stratégie Linéaire et la Stratégie Constante.

La Stratégie Linéaire (LUAT) : La liste d'invités en croissance perpétuelle
Imaginez une fête où, chaque fois que quelqu'un paie, il ne se contente pas de se cacher dans un groupe ; il laisse aussi une note permanente sur le mur disant : « Quelqu'un de ce groupe a payé ! ». La fête ne supprime jamais ces notes. La liste des « payeurs potentiels » (l'ensemble d'autorisation ou allow-set) continue de croître, et la liste des « personnes ayant déjà payé » (l'ensemble de refus ou deny-set) croît également.

  • La Bonne Nouvelle : Cette méthode est étonnamment décontractée. Même si la liste devient énorme, le « compteur de bouchons » reste très bas. Les auteurs prouvent que peu importe la taille du groupe d'amis, le système n'a besoin de se coordonner que pour 2 personnes à la fois. C'est comme une piste de danse où tout le monde peut bouger librement ; même si vous bousculez quelqu'un, vous n'avez pas besoin d'arrêter toute la fête pour savoir qui a bougé en premier.
  • Le Bémol : Le mur de la fête se couvre de post-it pour toujours. L'espace de stockage nécessaire pour se souvenir de chaque personne qui aurait pu payer croît linéairement avec chaque transaction. C'est comme essayer de se souvenir de chaque personne qui a franchi une porte, même si elle est partie il y a des années.

La Stratégie Constante (CUAT) : La re-randomisation magique
Maintenant, imaginez une fête différente. Quand quelqu'un paie, il ne se contente pas de laisser une note. Au lieu de cela, l'ensemble du groupe d'amis change instantanément de vêtements, de noms et d'identités. L'ancien groupe disparaît, et un tout nouveau groupe apparaît. Cela permet de garder le nombre total de personnes dans la pièce constant, de sorte que le « mur » ne devienne jamais encombré. C'est la méthode utilisée par des systèmes comme Quisquis.

  • Le Bémol : C'est là que les choses deviennent chaotiques. Parce que l'ensemble du groupe change, si deux personnes essaient de payer en même temps et que leurs groupes se chevauchent (même d'une seule personne), elles entrent en collision. Elles ne peuvent pas toutes deux réussir.
  • Le Résultat : Le « compteur de bouchons » explose. Les auteurs ont découvert que la coordination nécessaire ici croît de manière quadratique avec la taille du groupe. Si votre groupe compte 10 personnes, la coordination nécessaire est d'environ 100. Si vous avez 100 personnes, vous avez besoin d'une coordination pour 10 000 ! C'est comme un jeu de chaises musicales où, si deux groupes partagent ne serait-ce qu'une seule chaise, tout le jeu doit s'arrêter et recommencer pour déterminer qui s'assoit où.

Le compromis entre Vie privée et Progrès

La découverte majeure de ce document est un compromis strict. Vous pouvez avoir de la confidentialité, mais vous devez la payer dans l'une de ces deux monnaies : le Stockage ou la Synchronisation.

  1. Payer en Stockage (Stratégie Linéaire) : Vous gardez l'historique pour toujours. Le système reste rapide et facile à coordonner (nombre de consensus de 2), mais votre disque dur se remplit.
  2. Payer en Synchronisation (Stratégie Constante) : Vous gardez l'historique petit et propre. Mais pour ce faire, vous forcez le système à se coordonner massivement. Plus vous essayez de vous cacher parmi des gens, plus il est difficile pour tout le monde de s'accorder sur l'ordre des événements.

Les auteurs ont également étudié un mode de « super-vie privée » appelé Intraçabilité Forte (Strong Untraceability). C'est comme si un détective surveillait l'ensemble de l'historique de la fête, et pas seulement un instant donné. Ils ont remarqué que si vous voulez cacher l'expéditeur parfaitement sur un long historique, les groupes d'amis doivent être disposés selon un motif mathématique très spécifique (comme une grille parfaite ou un plan projectif). Si vous ne les disposez pas parfaitement, le détective peut deviner qui a payé en voyant qui apparaît dans trop de groupes. Lorsque vous imposez cet arrangement parfait, le « compteur de bouchons » atteint un plafond spécifique et élevé basé sur la taille du groupe.

Le problème de la famine : Le programmeur malveillant

Enfin, le document aborde un côté sombre de la Stratégie Constante : la Famine (Starvation).
Imaginez un brute à la fête (un « ordonnanceur adverse » ou adversarial scheduler) qui contrôle la musique. Dans la Stratégie Linéaire, si vous êtes prêt à payer, vous pouvez toujours finir par payer, même si le brute essaie de vous arrêter. Mais dans la Stratégie Constante, parce que le groupe entier change, le brute peut appuyer sur le bouton « reset » sur votre groupe spécifique de façon répétée.
Les auteurs ont prouvé que dans la Stratégie Constante, un brute peut faire en sorte qu'une personne paie éternellement tout en faisant attendre une autre personne indéfiniment, même si cette dernière a de l'argent et est prête à payer. La personne qui attend essaie sans cesse, mais chaque fois qu'elle tente de le faire, le brute réinitialise le groupe juste avant qu'elle ne puisse terminer. C'est un « déni de service » qu'il est mathématiquement impossible d'empêcher si le système est conçu pour maintenir l'état réduit.

L'essentiel

Ce document ne se contente pas de dire « l'un est meilleur que l'autre ». Il cartographie le coût exact de vos choix.

  • Si vous voulez un système qui ne manque jamais d'espace et qui est équitable pour tout le monde, vous devez accepter que la liste des transactions passées croisse éternellement (Linéaire).
  • Si vous voulez un système qui reste petit et ordonné, vous devez accepter qu'il deviendra incroyablement lent et complexe à coordonner à mesure que vous ajoutez des personnes, et qu'il pourrait permettre à un brute de priver certains utilisateurs de leurs droits (Constante).

Les auteurs ont prouvé ces limites avec une certitude mathématique. Ils ont montré que vous ne pouvez pas avoir le meilleur des deux mondes : vous ne pouvez pas avoir un historique petit et ordonné et un système rapide, équitable et facile à coordonner en même temps. L'univers des crypto-monnaies exige un prix pour la vie privée, et ce document vous dit exactement quel prix vous devez payer.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →