Pièces et comptes : deux modèles de représentation

Aujourd'hui je voudrais aborder un point un peu technique qui forme la base de l'architecture des blockchains que l'on connaît. Chacun sait que les protocoles Bitcoin et Ethereum permettent d'échanger une unité de compte (le bitcoin et l'éther, respectivement). Cependant, ces unités de comptes ne sont pas représentées de la même manière selon le protocole dans lequel elles évoluent : Bitcoin va utiliser un modèle, et Ethereum un autre. Ces deux modèles, qui ont depuis été repris par beaucoup d'autres protocoles crypto-économiques, sont :

  • Le modèle de représentation par des pièces de cryptomonnaie (aussi appelées UTXO pour Unspent Transaction Output). Ce modèle est contre-intuitif car les adresses n'existent pas au niveau protocolaire : chaque pièce est verrouillée par un script propre. Il est notamment utilisé par Bitcoin, Bitcoin Cash, Litecoin, Dash et Monero.
  • Le modèle de représentation par des comptes, où une adresse possède un solde qui est mis à jour par les transactions. Ce modèle est beaucoup plus intutif et est principalement utilisé par les plateformes de contrats autonomes comme Ethereum, EOS ou Tezos.

Nous allons regarder de plus près comment ces deux modèles fonctionnent, avant d'en faire la comparaison.

 

Le modèle des pièces ou des UTXO

Le modèle de représentation basé sur les pièces est quelque peu contre-intuitif et peut dérouter au premier abord. Il s'agit du système utilisé par Bitcoin depuis sa conception, ainsi que par d'autres protocoles comme Bitcoin Cash, Litecoin, Dash ou Monero. Ce système utilise des pièces de cryptomonnaie. On peut faire l'analogie avec la monnaie fiduciaire : en Europe, il existe des pièces de 50 centimes ou de 2 euros pour payer en liquide ; dans Bitcoin, c'est pareil, à la différence que le montant de la pièce peut être arbitraire. Un utilisateur pourra ainsi détenir une pièce de 25 bitcoins et une pièce de 1,66886523 bitcoin par exemple.

Ces pièces de cryptomonnaies sont créées par les transactions présentes dans la chaîne de blocs. En effet, dans Bitcoin, chaque pièce en circulation correspond à une sortie transactionnelle non dépensée ou UTXO (de l'anglais Unspent Transaction Output) : une pièce n'existe que parce qu'elle est le résultat d'une transaction et qu'elle n'est dépensée par aucune autre transaction.

Les transactions peuvent être constituées de plusieurs entrées et de plusieurs sorties. Sauf dans le cas de la transaction de récompense (coinbase transaction), elles dépensent des pièces existantes pour en créer de nouvelles. Les anciennes pièces sont les entrées de la transaction, et les nouvelles les sorties.

Par exemple, disons qu'Alice veuille envoyer 5 bitcoins à Bob (oui ça fait beaucoup d'argent). Elle dispose pour cela de 7 bitcoins répartis en deux pièces : un pièce de 3 bitcoins qu'elle a reçue de Yoann, et une pièce de 4 bitcoins a reçue de Zoé. Pour envoyer les bitcoins, elle va construire pour elle une transaction dépensant ces pièces de cryptomonnaies (les entrées) pour créer une nouvelle pièce de 5 bitcoins sous le contrôle de Bob (première sortie). Cependant, puisque le montant envoyé à Bob ne correspond pas tout à fait à ce qui a été débloqué, Alice va créer une nouvelle pièce de 1,9999 bitcoin pour « se rendre la monnaie » (seconde sortie). Le montant restant (0,0001 bitcoin) sert à payer les frais versés aux mineurs qu'ils récupéreront dans la transaction de récompense.

 

Transaction Bitcoin à deux entrées et deux sorties

 

Bien sûr tout le monde ne peut pas dépenser les pièces à sa guise : celles-ci sont verrouillées par des scripts imposant que certaines conditions soient satisfaites pour que la transaction soit valide (scripts qui sont aussi appelés « contrats autonomes » ou « smart contracts »). Pour le commun des mortels comme Alice ci-dessus, le standard généralement utilisé est le type Pay-to-Public-Key-Hash, abrégé en P2PKH, qui consiste à verrouiller l'UTXO à l'aide de l'empreinte de la clé publique du destinataire, empreinte obtenue par l'intermédiaire des fonctions de hachage SHA-256 et RIPEMD-160. Pour dépenser cet UTXO, le propriétaire devra produire une signature avec sa clé privée et fournir la clé publique correspondante.

Dans ce cas, l'adresse (par exemple 1DzxhUphLFq8FZPGbFgLF8Ssz3hMX9EuMp) correspond à l'empreinte de la clé publique, à laquelle on rajoute une information pour indiquer qu'on utilise le standard P2PKH (le 1 au début de l'adresse). Pour plus de détails sur les clés et les adresses, vous pouvez lire mon article sur le sujet.

Le solde d'une adresse sera alors la somme des montants de toutes les pièces verrouillées par le script correspondant. Ce solde n'est donc pas inscrit directement sur la chaîne et est reconstitué par les portefeuilles et par les autres services.

Chaque nœud entretient une base de données regroupant l'ensemble des UTXO (UTXO set) qu'il conserve en mémoire flash. Cela lui permet d'être considérablement plus efficace pour vérifier la validité d'une transaction, et de pouvoir fonctionner en « mode élagué » sans conserver la totalité de la chaîne de blocs sur son disque dur. L'ensemble des UTXO équivaut à l'état du système présent dans Ethereum.

Cette architecture a pour mérite de favoriser la mise en lots des transactions (batching) qui, par le regroupement de plusieurs paiements en un seul, permet de réduire les frais payés. Cette mise en lots est notamment utilisée par les plateformes d'échange pour regrouper les retraits de ses utilisateurs. Le modèle facilite également le mélange des pièces, ou CoinJoin.

 

Le modèle des comptes

Le modèle de représentation basé sur les comptes est le plus intuitif des deux mais son implémentation n'en est pas moins compliquée. Il s'agit d'un modèle introduit par Ethereum lors de sa création, et qui a été repris depuis par toutes les plateformes d'applications décentralisées comme EOS, Cardano ou Tezos, et pour cause : ce modèle facilite grandement l'implémentation des contrats autonomes.

Comme son nom l'indique, ce modèle se base sur des comptes (accounts). Généralement, un compte est caractérisé par les éléments suivants :

  • Une adresse publique, par exemple 0xE87BD234546C55Ca73112a551eCd30184106a502 ;
  • Un solde de cryptomonnaie ;
  • Un compteur, appelé « nonce » dans Ethereum, qui indique le nombre de transactions réalisées ;
  • Du code de programmation (seulement pour les contrats) ;
  • Des données stockées (seulement pour les contrats).

Il existe deux types de comptes : les comptes simples et les contrats. Les comptes simples, appelés EOA dans Ethereum pour Externally Owned Accounts, servent généralement à initier des transactions, soit pour réaliser un paiement (qui est un type d'opération en lui-même), soit pour interagir avec un contrat. Les contrats sont eux des programmes existant par eux-mêmes sur la plateforme et réagissent selon les appels effectués par les utilisateurs ou par d'autres contrats.

La cartographie des comptes est appelé l'état du système. Cet état est modifié par les transactions. Par exemple, si Alice veut envoyer 5 éthers à Bob, elle construira et signera une transaction qui retirera 5 éthers de son solde (sans compter les frais payés au validateurs) et ajoutera 5 éthers à Bob.

Ce modèle de représentation est donc beaucoup plus intuitif que celui des pièces-UTXO. Pour trouver son solde total, un portefeuille n'aura qu'à questionner l'état du système sur le compte concerné : pas besoin de reconstituer le montant à partir des UTXO. Les clients légers en particulier bénéficient grandement de cette caractéristique : un nœud du réseau aura plus de mal à tromper un portefeuille léger que dans le modèle des pièces où il peut volontairement oublier de mentionner l'existence d'une pièce.

Néanmoins, ce modèle souffre d'une contrainte majeure : chaque compte doit entretenir un compteur ou nonce qui correspond au nombre de transactions confirmées qu'il a émises. Ce compteur est présent dans toutes les transactions qu'il va envoyer : sa première transaction sera marquée du numéro 0, la deuxième du numéro 1, etc. Ce compteur sert essentiellement à deux choses :

  • D'abord avoir un ordre des transactions : sans compteur, les nœuds du réseau pourraient exécuter les actions dans le désordre, ce qui, dans le cadre d'un ordinateur mondial décentralisé, peut s'avérer problématique.
  • Mais surtout éviter le rejeu des transactions : sans compteur, si Alice possédait 15 éthers et qu'elle envoyait une transactions de 5 éthers à Bob, rien n'empêcherait Bob de diffuser cette transaction deux fois de plus pour récupérer les 10 éthers restants.

 

Comparaison des deux modèles

Il existe donc deux modèles de base pour représenter l'unité de compte : soit par des pièces (ou UTXO), soit par la biais d'un solde présent sur un compte. Chacun des deux modèles a ses caractéristiques propres ce qui fait qu'ils ont chacun leurs avantages et leurs inconvénients.

Le premier point de divergence est la scalabilité. Tout d'abord le stockage est différent. Dans Bitcoin, les UTXO doivent tous porter le script de verrouillage correspondant à l'adresse du destinataire, ce qui alourdit les choses par rapport à un modèle de comptes, où seuls les montants vont être stockés. Cet effet est augmenté si une adresse reçoit de multiples paiements. De plus, grâce à cette caractéristique, les paiements simples dans Ethereum prennent en moyenne deux fois moins de place que dans Bitcoin (un peu plus de 100 octets ou lieu de 226 octets).

Cependant, cela est à mitiger avec le fait que le modèle des pièces facilite la parallélisation des transactions (pas de compteur) et qu'il semble être bien plus compatible avec beaucoup de méthodes de passage à l'échelle comme le partitionnement (sharding).

La seconde différence se trouve au niveau de la confidentialité des transactions : en effet, le modèle des pièces est plus secret que le modèle des comptes. Comme on l'a dit dans la première partie, le fait qu'une transaction possède plusieurs entrées et plusieurs sorties est une caractéristique présente par défaut dans le modèle des pièces. Cela permet de mettre en place des techniques d'anonymisation comme le fait d'utiliser une nouvelle adresse à chaque transaction, ou le mélange des pièces (CoinJoin).

Dans le modèle des comptes, cette caractéristique n'est pas forcément naturelle. Ethereum par exemple ne permet pas nativement d'effectuer des transactions complexes (plusieurs entrées ou plusieurs sorties) sans passer par l'intermédiaire d'un contrat autonome, comme pour procéder à une mise en lots par exemple. La conséquence est que, par facilité, les portefeuilles ont généralement une adresse unique pour recevoir des fonds ce qui altère la confidentialité des utilisateurs. Il est de même pour le mélange des fonds qui doit également se faire par le biais d'un contrat.

Pour continuer avec ce sujet, les deux modèles n'offrent pas le même niveau de fongibilité, cette dernière étant le fait de ne pas pouvoir distinguer une unité d'une autre. Avec les modèle des UTXO, les services gouvernementaux peuvent marquer les pièces « sales » et les rendre illégales, ce qui réduit le niveau de fongibilité de la monnaie. Heureusement, les techniques de confidentialité mentionnées ci-dessus permettent d'améliorer la situation en compliquant considérablement le suivi des pièces sur la chaîne. Le modèle des comptes, lui, assure une fongibilité techniquement parfaite puisque les soldes sont simplement mis à jour, bien qu'il soit sans doute possible de marquer les fonds d'une manière ou d'une autre.

Le troisième et dernier point de différence est la simplicité. En dépit de la difficulté posée par l'implémentation du compteur, le modèle des comptes est, par son côté intuitif, un bien meilleur modèle en terme de facilité de compréhension et d'interaction pour le développeur. En particulier, la programmation de contrats autonomes est beaucoup plus facile à mettre en place sur Ethereum que sur Bitcoin, ne serait-ce que pour accéder au solde présent à une adresse.

 

Ainsi les deux modèles ont leurs forces et leurs faiblesses. Ces caractéristiques font qu'un modèle va être privilégié à un autre selon le type d'usage visé par le protocole. D'un côté, le modèle des pièces va être préféré par les protocoles fondés principalement sur l'échange de valeur entre individus (c'est-à-dire la monnaie), car plus confidentiel. De l'autre côté, les protocoles étant tournés vers l'exécution de contrats autonomes vont préférer opter pour un modèle basé sur des comptes, bien plus accessible pour l'implémentation de ce genre d'application.

Notez que cette distinction n'est pas forcément respectée et beaucoup de nouveaux protocoles utilisent un modèle hybride pour exploiter au maximum les avantages des deux modèles. C'est le cas de Cardano, dont la première couche (Cardano Settlement Layer) est basée sur des UTXO, et de Qtum avec son Account Abstraction Layer (AAL).


Sources

Andreas M. Antonopoulos, Mastering Bitcoin: Programming the Open Blockchain, chapitre 6.
Andreas M. Antonopoulos, Mastering Ethereum: Building Smart Contracts and DApps, chapitre 6.
Dmitry Mishunin, UTXO and Account Model Comparison v.2, 22 octobre 2018.
Offchain.fr, UTXO ou Account - Comprendre l'architecture des Blockchains, 25 mars 2019.

Je suis fasciné par les cryptomonnaies et par l'impact qu'elles pourraient avoir sur nos vies. De formation scientifique, je m'attache à décrire leur fonctionnement technique de la façon la plus fidèle possible.

2 Responses

  • Merci pour cet article, intéressant et très clair, et merci aussi pour la qualité de votre français et votre souci de (bien) traduire un maximum de termes techniques, là où la plupart des articles des sites crypto français se contentent paresseusement de reprendre tel quel le lexique anglais…
    (J’essaie aussi de maintenir un niveau correct de langue dans mes traductions 😉 : https://dashfrance.com/articles-de-fond/ )

    Répondre
    • Ludovic Lars

      Bonjour, merci du compliment !

      En effet, je trouve qu’on utilise bien trop les termes anglais et j’essaie donc de les traduire au maximum (quand c’est possible).

      Répondre

Répondre à D.F. Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *