Cybermonnaies, les technologies de consensus

Set of cryptocurrencies on dollar bills by Marco Verch (CC BY 2.0) — Marco Verch, CC-BY

Quels sont les systèmes dont la performance actuelle, mesurée en transactions par jour, est supérieure voire très supérieure à celle de Bitcoin ?

Par Gérard Dréan.

Dans un article précédent, nous avons vu que, dans un contexte de demande stagnante, le système Bitcoin a atteint sa limite pratique de capacité imposée par les technologies qu’il utilise. Toute augmentation éventuelle de la demande de paiements en cybermonnaie ne pourra être satisfaite que par des systèmes alternatifs, dont il existe des centaines mais dont seulement une petite dizaine est réellement utilisée de façon opérationnelle, et à un niveau bien inférieur à celui de Bitcoin bien que leur capacité soit nettement supérieure.

Nous avons aussi vu que le Lightning Network, en cours de déploiement sous forme d’une extension pouvant s’ajouter à Bitcoin et aux systèmes qui en dérivent, propose d’étendre l’utilisation de transactions libellées en bitcoins en les acceptant sans les soumettre aux validations nécessaires à leur inscription dans la chaîne de blocs, donc sans leur conférer la même autorité, mais en permettant de faire appel aux mécanismes du système sous-jacent pour valider l’état courant des comptes concernés. Sa portée pratique est très controversée. Quels que soient ses mérites techniques, on peut penser que pour ses cas d’usage, les utilisateurs potentiels lui préféreront des systèmes plus éprouvés.

Les autres systèmes

Or il existe d’autres systèmes dont la performance actuelle, mesurée en transactions par jour, est supérieure voire très supérieure à celle de Bitcoin : Ethereum entre 500K et 600K transactions par jour, Ripple 350K à 500K, Steem probablement autour de 1 million, TRON 2 à 3 millions, EOS 5 à 8 millions1. Ces systèmes peuvent-ils indiquer des pistes de solution aux problèmes de capacité de Bitcoin ? En quoi éclairent-ils l’avenir des systèmes de registre distribué ?

Ces cinq systèmes ont des vocations différentes. Ethereum (2014), Steem (2016) et EOS (2018) sont des plateformes de développement et d’exécution d’applications distribuées (les Dapps). Leurs monnaies sont destinées aux règlements internes entre les utilisateurs des services du système et les fournisseurs de ces mêmes services. Ripple (2012) est spécialisé dans les règlements Interbancaires. TRON (2017) est une application d’échange d’informations au service de l’industrie du divertissement, mais aussi une plateforme spécialisée. Aucun n’entre dans la catégorie des systèmes de paiement généralistes à laquelle appartient Bitcoin.

Ces cinq systèmes utilisent tous la technologie de la chaîne de blocs pour sécuriser leur registre partagé. Pour la construction des blocs et le consensus, Ethereum est le seul qui utilise la preuve de travail, mais prévoit de passer à une variante de la preuve d’enjeu (voir ci-après) en 2019 ; Ripple utilise une méthode originale appelée « consensus byzantin »2 ; EOS, TRON et Steem utilisent des variantes de la preuve d’enjeu, qui semble être actuellement la voie la plus explorée.

Rappel : la preuve de travail

La méthode de la preuve de travail (PoW pour Proof of work) consiste à donner périodiquement le départ d’une course à la construction d’un bloc, ouverte à tous mais rendue artificiellement difficile, et à retenir le premier bloc valide arrivé en rémunérant son auteur. Pour espérer être ce gagnant, il faut investir lourdement en matériel et en électricité, ce qui a pour conséquence une concentration de cette activité sur une vingtaine de participants, appuyés sur de gigantesques coopératives de serveurs. 95 % des blocs sont construits par moins d’une dizaine de coopératives, dont les propriétaires monopolisent le pouvoir de retenir ou d’exclure des transactions et acquièrent ainsi celui de contrôler voire perturber le fonctionnement du système.

La taille des blocs, et donc le nombre de transactions par bloc, est bornée afin de limiter les effets d’une attaque par déni de service3. Un intervalle de temps est imposé entre la construction de deux blocs pour limiter le risque de conflit entre blocs et de scission de la chaîne4. La combinaison de ces deux paramètres détermine un nombre maximum de transactions par unité de temps et un délai de confirmation des transactions, une transaction incluse dans un bloc ne pouvant être considérée comme définitive que si ce bloc est confirmé par plusieurs successeurs.

Les alternatives actuelles à Bitcoin, par exemple Litecoin, Dogecoin, Dash, Bitcoin cash ou Monero, se différencient principalement par les valeurs de ces deux paramètres, qui traduisent des arbitrages différents entre performances et sécurité de fonctionnement, toute amélioration de la sécurité se payant en complexité et en performances.

La preuve d’enjeu et ses variantes

Après la preuve de travail, la preuve d’enjeu (« proof of stake ») est la méthode de consensus la plus utilisée et la plus étudiée. Son principe est de désigner a priori un validateur pour construire chaque bloc, au lieu d’en lancer plusieurs et de sélectionner un gagnant a posteriori.

Elle ne nécessite pas de calculs lourds et élimine donc le problème de gaspillage d’énergie. Le délai entre blocs peut être très court (3 secondes pour Steem, une demi-seconde pour EOS), ce qui augmente la capacité et accélère le traitement, mais peut entraîner l’apparition de branches alternatives. Ces systèmes doivent donc comporter des dispositions visant à résoudre ce problème, par exemple en quantifiant en continu le niveau de confiance qu’on peut accorder à chaque validateur et donc le niveau de validité des blocs.

En réduisant le délai entre blocs, le système de preuve d’enjeu peut augmenter la capacité de plusieurs ordres de grandeur et réduire le délai de confirmation à quelques secondes. De plus, il ouvre la possibilité de traitement parallèle des transactions (« sharding »), qui consiste à confier la construction de la chaîne à des groupes de validateurs distincts travaillant simultanément sur des parties différentes, ce qui pourra permettre une capacité quasi-infinie proportionnelle au nombre de nœuds du réseau.

Par rapport à la preuve de travail, la validation par preuve d’enjeu est une idée récente. Les problèmes nouveaux qu’elle soulève font l’objet de nombreux débats théoriques, notamment quant aux risques de sécurité associés. Il en existe plusieurs variantes, chacune étant supportée par une analyse théorique des scénarios d’attaque et des parades à y opposer, mais aucune n’a encore été vraiment validée en régime d’utilisation intensive.

Tous les participants peuvent se proposer comme validateurs, généralement en déposant une caution qui sera rémunérée si ce validateur contribue effectivement au bon fonctionnement en produisant des blocs valides. Dans certains systèmes, elle sera perdue (totalement ou en partie) s’il se comporte de façon irresponsable ou malhonnête.

Périodiquement, un validateur tiré au hasard parmi les candidats est autorisé à construire un bloc et à le soumettre au réseau. La probabilité pour chaque candidat d’être choisi est proportionnelle à une certaine grandeur prise comme indicateur de son intérêt au bon fonctionnement du système, qui est le plus communément son dépôt de garantie mais peut aussi tenir compte de son avoir total, de son ancienneté, de son activité passée, etc. L’algorithme de sélection doit empêcher la concentration des validateurs, neutraliser de possibles coalitions malveillantes, et éliminer les fraudeurs dans la mesure du possible.

Une variante particulièrement prometteuse est la preuve d’enjeu déléguée (DPoS pour Distributed Proof of Stake), utilisée notamment par EOS et Steem. La validation se fait à deux niveaux. Tous les participants au réseau peuvent voter pour élire des validateurs, avec un poids proportionnel à leur avoir. Puis, au début de chaque cycle, les validateurs qui arrivent en tête des votes (21 pour EOS et Steem) sont autorisés à construire un ou plusieurs blocs, dans un ordre aléatoire. Le vote ayant lieu en continu, la liste des validateurs autorisés et l’ordre de leur intervention peuvent changer à chaque cycle.

La preuve de travail déléguée est également utilisée dans certains systèmes encore en cours de développement, mais considérés comme porteurs d’avenir comme en témoigne leur capitalisation (11e rang pour Cardano, 22e rang pour Tezos), ainsi que par exemple WAX et Bitshares. Elle est également utilisée dans un tout nouveau concurrent de Bitcoin appelé Bitcoin Lightning (sans rapport avec l’extension Lightning mentionnée plus haut).

Les transactions et le « consensus byzantin »

Le consensus byzantin utilisé par Ripple inverse l’ordre des opérations. Les validateurs commencent par rechercher un accord sur une liste de transactions que tous jugent valides, puis chacun construit le bloc formé par ces transactions et l’ajoute à son exemplaire de la chaîne. Puisque aucune difficulté artificielle ne vient ralentir la cadence de construction des blocs, un nouveau bloc est produit toutes les 3 à 4 secondes, ce qui correspond à une capacité potentielle de plus de 200 fois Bitcoin. Mais au niveau actuel d’utilisation, chaque bloc ne contient que quelques dizaines de transactions, ce qui ramène l’utilisation réelle à un niveau voisin de Bitcoin.

La difficulté est ici de concevoir un protocole de consensus qui garantit que les validateurs convergeront vers un accord, même si certains se comportent de façon frauduleuse ou hostile, et qui détecte et sanctionne les validateurs frauduleux, malveillants ou paresseux. Un autre problème est le volume des communications, qui augmente très rapidement avec le nombre des validateurs. Ripple évite largement ces problèmes en obligeant les validateurs à être préalablement agréés par la société Ripple. C’est ce qu’on appelle un réseau « permissioned ». Chaque participant choisit dans la liste des validateurs agréés ses propres validateurs « de confiance », et peut proposer de nouveaux validateurs.

Ces choix illustrent une autre antinomie fondamentale, cette fois entre performances et fiabilité du registre, qui repose à la fois sur l’ouverture et la décentralisation du processus de validation, matérialisée par le nombre et la diversité des validateurs, et sur la capacité du réseau à atteindre un consensus malgré cette ouverture. Comme la sécurité, la fiabilité se paye en complexité et en performances.

Une variante récente (Stellar) généralise cette technique dans le cadre d’un système ouvert. Tous les nœuds peuvent faire acte de candidature au rôle de validateur en déposant une caution, selon un processus analogue à celui de la preuve d’enjeu. Chaque nœud désigne alors parmi ces candidats un ensemble de validateurs en qui il a confiance pour valider ses propres écritures. D’autres variantes du consensus byzantin sont utilisées dans les systèmes NEO, Zilliqa, Hyperledger Fabric et CORDA, quatre plateformes de développement.

Les graphes orientés acycliques (DAG)

Ce panorama technologique ne serait pas complet sans la mention de quelques nouvelles technologies de validation qui ne sont encore utilisées que de façon expérimentale, mais sont jugées suffisamment prometteuses pour que les monnaies associées figurent en bonne place dans le classement par capitalisation.

Leur point commun est de remplacer la chaîne unidimensionnelle, formée de blocs contenant plusieurs transactions, et dont chacun valide son unique prédécesseur, par un graphe à deux dimensions où les unités validées peuvent être les transactions individuelles, et en demandant à chaque unité de valider plusieurs de ses prédécesseurs. La validation d’une unité reste concrétisée par l’inclusion d’une empreinte cryptographique de chacune des unités qu’elle valide (ses « parents »). Avec ces relations de parenté, les unités forment un graphe orienté acyclique (en anglais DAG pour Directed Acyclic Graph) communément appelé tangle (fouillis ou enchevêtrement). Modifier une unité existante oblige à modifier toutes les unités qui la valident directement ou indirectement, ce qui est d’autant plus difficile que l’unité modifiée a un grand nombre d’unités « descendantes » directement ou indirectement, et peut même devenir plus difficile que modifier une chaîne de blocs si ces descendants sont très nombreux.

Dans IOTA (13e rang), destiné aux paiements entre objets connectés, donc a priori très nombreux et de faible montant, l’unité de validation est la transaction. Tout nœud qui soumet une nouvelle transaction doit valider deux transactions antérieures. L‘opération de validation est ainsi intégrée à la soumission de nouvelles transactions ; il n’y a plus de validateurs spécialisés (les « mineurs » de Bitcoin), puisque tous les nœuds participent à la validation. Il n’y a pas non plus besoin de création monétaire ni de commissions de transaction, puisque le prix à payer par les utilisateurs pour que leurs propres transactions soient prises en compte est constitué par leur participation à la validation des autres transactions. Enfin, la capacité de validation croît automatiquement en même temps que la charge, et donc la capacité est pratiquement illimitée. Sur les mêmes principes, Byteball (2017) promet d’offrir une plateforme générale où les unités de mémorisation peuvent avoir un contenu quelconque.

Dans Nano (41e rang), il existe une chaîne par compte. Les transferts sont décomposés en transactions élémentaires (par exemple débit du compte émetteur et crédit du compte récepteur), qui ne sont validées que par le titulaire du compte concerné ou un représentant désigné par lui. Les conflits sont résolus par un système de vote.

Dans une variante plus générale, le protocole HashGraph, chaque nœud complet a sa propre chaîne de blocs, ce qui est une forme de fragmentation du registre permettant le traitement en parallèle par tous les nœuds. Le projet actuel est limité à un réseau fermé, ce qui fait disparaître beaucoup de problèmes de mise en œuvre qui se représenteront pour un réseau ouvert.

En même temps que ces techniques sont susceptibles de résoudre un certain nombre de problèmes, elles en soulèvent de nouveaux au moins aussi sérieux. Comment s’assurer que toutes les écritures seront soumises à validation et que les auteurs de nouvelles écritures ne se contenteront pas de faire référence à des écritures déjà validées ? Qui croire en cas de désaccord ? Par quel protocole de consensus le système peut-il considérer qu’une écriture est définitivement validée ? Le processus critique à cet égard est l’algorithme de sélection des « parents » de chaque nouvelle écriture. Un autre problème majeur est la taille du tangle, surtout pour un système comme IOTA qui est destiné aux échanges entre objets connectés.

Enfin, ces systèmes ne fonctionnent correctement que s’il y a un grand nombre de transactions, sinon le graphe reste unidimensionnel et se réduit à une chaîne linéaire, et la validation est entre les mains d’un petit nombre. Comment alors amorcer le système d’une façon qui inspire la confiance des utilisateurs potentiels, alors que cette confiance repose justement sur le nombre des utilisateurs ?

Le tableau général

Au bout de 10 ans d’existence, l’ancêtre Bitcoin est arrivé à saturation, et ses nombreux clones et concurrents tardent à prendre le relais dans un contexte de stagnation de la demande. Mais pour la fonction de paiement qui est à l’origine de tous ces systèmes, la capacité disponible de la demi-douzaine de systèmes déjà éprouvés en conditions opérationnelles est largement suffisante pour absorber toute croissance réaliste de la demande pour plusieurs années.

En même temps, les technologies qui ont été inventées à cette occasion ont trouvé d’autres domaines d’utilisation : la chaîne de blocs pour l’enregistrement définitif d’autres natures d’informations, le paiement interne pour des applications où le paiement est une fonction secondaire comme les jeux, les paris ou les échanges de services divers. Cette classe d’applications ne peut que croître et prospérer, mais chaque domaine est un cas particulier soumis à sa propre logique.

Pour faire face à cette diversité, des plateformes de développement et d’exécution d’applications spécifiques sont proposées. Et de nouvelles technologies sont apparues et continuent à apparaître en réponse à tous les problèmes rencontrés.

Vu de Sirius, nous avons d’un côté une gigantesque réserve de technologies continuellement alimentée par une recherche foisonnante largement motivée par la simple curiosité intellectuelle et l’intérêt académique, et de l’autre une demande plus ou moins prudente selon l’application et ses enjeux, qui se traduit par des rythmes d’adoption très diversifiés : quasi-instantané pour des applications « frivoles » où l’enjeu est très faible, très lent quand l’enjeu est lourd et les risques de fraude omniprésents, comme dans les applications financières qui étaient l’objectif initial.

On peut donc s’attendre à ce que les technologies émergentes soient d’abord mises en œuvre et partiellement validées par les applications les moins critiques, mais dont le caractère frivole ne doit pas détourner l’observateur car elles peuvent être pionnières en matière de technologies. Suivront les plateformes, qui ne prendront vraiment leur plein essor qu’avec la preuve d’enjeu déléguée et pourront bénéficier de l’expérience des applications qu’elles supportent ; et enfin les systèmes de paiement purs et durs pour lesquels un lent cheminement est nécessaire depuis le prototype jusqu’à à la validation concrète et l’établissement de la confiance du public, mais pour lesquels il existe déjà une réserve de capacité suffisante pour absorber toute croissance raisonnable pendant plusieurs années.

On peut donc se hasarder aux pronostics suivants : en utilisation réelle, les systèmes de règlement généralistes continueront longtemps à utiliser la demi-douzaine de systèmes actuellement opérationnels et la preuve de travail, avant de se tourner très progressivement vers des technologies de graphes orientés acycliques, en sautant pour l’essentiel l’étape de la preuve d’enjeu. Au contraire, les plateformes décolleront avec la preuve d’enjeu (probablement dans sa variante distribuée), par rapport à laquelle il n’est pas certain que les technologies DAG apportent des avantages substantiels pour la majorité des cas d’usage.

  1. Ordres de grandeur janvier 2019, source https://coinmetrics.io/charts. Le site https://blocktivity.info/ ajoute WAX, Bitshares et Telos, non confirmés par d’autres sources.
  2. Par allusion au fameux problème dit « des généraux byzantins » qui doivent se mettre d’accord par messagers interposés pour coordonner une attaque, chacun pouvant être soupçonné de trahir.
  3. Une attaque par déni de service consiste à inonder le système de transactions de faible montant afin de paralyser son fonctionnement.
  4. Une scission se produit quand des populations d’utilisateurs adoptent des versions différentes de la chaîne de blocs, par exemple quand des blocs différents arrivent aux nœuds du réseau dans un ordre différent à intervalles très rapprochés.
Vous souhaitez nous signaler une erreur ? Contactez la rédaction.