UTXOs vs “Accounts Based” : la différence entre Bitcoin et Ethereum
Dans cet article, nous allons aborder l’une des importantes différences entre Bitcoin (BTC) et Ethereum (ETH). A part la différence Turing-complet et non Turing-complet, il existe une autre divergence entre les deux protocoles : UTXOs (Unspent Transaction Output) et les “accounts”.
[coin-widget id= »bitcoin »]
[coin-widget id= »ethereum »]
Ce sujet est un peu moins souvent abordé dans les articles et pourtant il est tout aussi intéressant. Cela a aussi certaines conséquences sur le fonctionnement des deux systèmes qui sont souvent comparés sans mentionner cet élément majeur.
UTXOs (Unspent Transactions Output)
Nous allons faire un petit rappel sur le fonctionnement de Bitcoin. Il est important de comprendre comment fonctionne une transaction Bitcoin pour comprendre les différences avec Ethereum.
Exemple de transaction :
Input: Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6 Index: 0 scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 Output: Value: 5000000000 scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Une transaction Bitcoin comporte deux champs qui nous intéressent particulièrement : Input et Ouput. Il peut y avoir plusieurs inputs/outputs par transactions. Aujourd’hui, nous allons prendre le cas où nous avons un seul input et un seul output.
Il existe un autre type de transaction dite coinbase transaction. Cette transaction a la particularité de ne pas avoir d’input. Elle est introduite par les mineurs lorsqu’ils trouvent un bloc et est généralement attribuée à leur propre compte. C’est de cette manière que l’on met en circulation les nouveaux bitcoins toutes les 10min. Chaque mineur est autorisé à produire 12.5BTC par bloc (aujourd’hui) via cette transaction.
Output
Output: Value: 5000000000 scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Le champ Ouput permet de préciser le nombre de satoshis que l’on souhaite attacher à celui-ci (sa valeur) et le script définit sous quelle condition cet output peut être utilisé (donc dépensé) comme input dans une autre transaction. Un output peut être assimilé à une ligne qui correspond à une rentrée d’argent dans un livre de comptabilité. Ici, cet ajout est de 500000000 satoshis.
Lorsque l’on fait la somme de tous les outputs qui n’ont pas été encore utilisés – unspent – et dont on sait qu’on est les seuls à pouvoir remplir la condition définie dans le script (cette partie sera plus approfondie dans un autre article dédié aux scripts), on peut en déduire notre balance, la quantité de bitcoins que l’on détient.
Input
Input: Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6 Index: 0 scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
L’input, est un précédent ouput que l’on a pas utilisé et que l’on souhaite utiliser dans notre transaction. Le champ Previous tx nous indique le hash de la transaction ultérieure dans laquelle on a créé notre précédent ouput. Index nous donne sa position dans la transaction.
ScriptSig est la solution à la fameuse condition de dépense. C’est celui-ci que les nœuds vont vérifier et qui doit être validé pour valider un bloc.
Vue globale d’une transaction
Cela peut paraître un peu compliqué à première vue, mais cela fait sens dès lors que l’on imagine plusieurs comptes dans une banque. Une transaction entre deux comptes bancaires consiste à débiter le compte du client A et à créditer de la même somme le compte du client B. Les deux actions doivent être effectuées et validées simultanément pour éviter tout problème de comptabilité.
Comparer Bitcoin au fonctionnement d’une banque peut paraître ironique, mais il y a beaucoup de similarités entre les deux systèmes. Il y a aussi beaucoup de choses à apprendre du système informatique des banques qui a été perfectionné pendant des décennies avec les meilleurs ingénieurs, et de comprendre les obstacles auxquels ils ont été confrontés.
Les comptes Ethereum
Disclaimer : mon expérience sur le projet Ethereum est un peu plus limitée. Il se peut qu’une erreur ou deux se glissent dans mon explication.
Le projet Ethereum, lui, est basé sur une idée d’état général. C’est-à-dire qu’on a un état des comptes à un certain instant, comme si on avait pris une photo. On va ensuite envoyer une transaction qui modifiera cet état vers un nouveau. Dans la transaction, on doit préciser un from et un to qui sont les deux comptes concernés par la transaction (et donc qui modifie l’état des comptes), champs qui sont d’ailleurs absents dans les transactions Bitcoin.
Ce modèle à l’avantage d’être plus facile à appréhender. Les transactions sont aussi plus petites, car on n’a pas besoin de référencer des transactions précédentes. Il y a cependant une conséquence non négligeable à ce modèle, réussir à définir l’ordre des transactions.
Pour Bitcoin si on envoie deux transactions avec deux différents inputs, l’ordre dans lequel ils sont exécutés importe peu. Rappelons, aussi, que ce sont les mineurs qui choisissent quelle transaction va dans quel bloc (en général ce sont les transactions avec les frais les plus élevés).
Dans le cas d’Ethereum, c’est un peu différent. L’ordre des transactions est très important. Peut-être que dans un contrat on veut d’abord appeler Fonction 1 puis Fonction 2 ce qui va nous donner État A, mais changer l’ordre et on va avoir État B. Il faut donc trouver un moyen de forcer l’ordre, pour cela Ethereum utilise un nonce, un nombre qui va être incrémenter à chaque transaction effectuée pour un compte.
Cela veut aussi dire qu’une transaction avec un nonce qui ne suit pas directement celui de la dernière transaction sera refusée par les mineurs. Le nonce permet aussi de se protéger contre une replay attack. Sinon, il serait facile de renvoyer exactement la même transaction encore et encore puisqu’une fois qu’on a la signature de la transaction celle-ci resterait valide pour une transaction identique.
Les transactions Ethereum ont aussi un champ data qui permet de spécifier quelle fonction d’un contrat est appelée. Ce champ est absent lors d’un transfert d’ether vers deux comptes qui ne sont pas des contrats.
Conclusion
Le concept d’état global d’Ethereum nécessite l’utilisation de comptes et un format différent de transaction par rapport aux systèmes UTXOs. Ethereum gagne en espace, les transactions étant plus petites, mais perd en flexibilité. Il est impossible de traiter deux transactions d’un même compte en parallèle. Cela veut aussi dire qu’il faut attendre la confirmation de la première transaction pour ne pas risquer d’envoyer une transaction avec un nonce invalide.
Sources :
Lola D.
"Le Cyberespace est fait de transactions, de relations, et de la pensée elle-même, formant comme une onde stationnaire dans la toile de nos communications. Notre monde est à la fois partout et nulle part, mais il n’est pas où vivent les corps." - John Perry Barlow, Déclaration d’indépendance du Cyberespace, Davos, Suisse, 8 février 1996
