Libra comparé à Ethereum 1.0 et 2.0

Le Libra Coin de Facebook a massivement fait parler de lui, tant sur les réseaux sociaux qu’à travers les grands médias. Il nous a semblé intéressant d’aller voir de plus près ce que Libra a dans le ventre technologiquement en faisant un comparatif de Libra vs Ethereum, au-delà de l’idéologie et des différents partenariats de Libra qui ont déjà été largement discutés.

L’article qui va suivre a été mis au point en s’appuyant sur de nombreuses sources, dont l’article de FX Thoorens – président co fondateur de ARK – ainsi que sur le thread twitter de Diederik Loerakker – chercheur à l’Ethereum Fondation – dans lequel, il compare Ethereum 1.0 et 2.0 au projet Libra d’un point de vue technique.

A first technical impression of Libra, aka "facebook coin", compared against Eth 1 and Eth 2.
tweetstorm:
🧐⬇️#ethereum #libra #eth2

— proto.eth (@protolambda) June 18, 2019

Rappels généraux sur Libra

Libra est la cryptomonnaie développée par Facebook, annoncée pour début 2020 et dont le whitepaper a été dévoilé en début de semaine.

Avant cela, très peu d’informations étaient disponibles. Parmi le peu d’informations, nous savions que Libra reposerait sur 100 nœuds validateurs – à 10 millions de dollars unités – et que ce serait un stable coin, répliquant la valeur d’un panier de monnaies fiduciaires.

Depuis la sortie du whitepaper et des spécifications techniques du projet, nous savons à présent que Libra permettra également l’utilisation de smart contracts, ce qui peut potentiellement en faire un concurrent direct d’Ethereum.

C’est pour cette raison qu’il nous semble intéressant de comparer les deux projets afin d’étudier les avantages et inconvénients techniques entre ces deux technologies. Le comparatif Libra vs Ethereum peut débuter !

Libra n’a pas de blockchain

Le projet Libra a décidément envie de faire la peau dure au blockchain bullshit. Là ou l’on entend à tors et à travers que la révolution n’est pas Bitcoin, mais la Blockchain, Facebook montre son désaccord.

Libra n’a pas de blockchain. Plutôt que d’agglomérer des transactions au sein de blocs, qui sont ensuite chaînés entre eux – comme pour la grande majorité des cryptomonnaies – Libra a fait le choix d’utiliser le concept de Ledger State.

Le Ledger State – ou état comptable – est un système dans lequel, au lieu d’accéder à dernière modification du registre distribué, nous allons accéder à l’état des comptes à jour qui fait foi entre chaque nœud.

Sur ce plan-là, le fonctionnement est relativement similaire à celui d’Ethereum à la différence de la présence d’une blockchain. En effet, Ethereum utilise aussi un système d’état général, et dont la principale différence réside dans l’accessibilité à l’historique des transactions.

La blockchain publique d’Ethereum stocke l’ensemble des transactions ayant eu lieu sur le réseau. Dans le cas de Libra comme il n’y a pas de blockchain publique, l’historique de toutes les transactions n’est de ce fait pas publiquement accessible. Cela reste cependant possible, pour un utilisateur donné, d’accéder à son propre historique en effectuant une requête auprès d’un nœud validateur.

Cette différence dans les choix de conception, démontre des besoins différents pour les deux projets. D’un côté, la blockchain publique d’Ethereum permet d’assurer la confiance des utilisateurs en leur donnant la possibilité de vérifier l’historique des transactions. Cependant, le prix à payer pour cette transparence sera répercuté sur les performances du réseau, car les blocs ont besoin d’être propagés et sauvegardés par l’ensemble des acteurs du réseau (validateurs et nœuds complets).

Le choix qu’a fait Libra démontre la volonté d’obtenir les meilleures performances possible. Comme il n’y a pas de bloc ni d’historique, les performances sont accrues et la quantité de données à stocker est minimale. Cependant, cela mène indéniablement à une réduction de la décentralisation, car, l’ensemble des utilisateurs doivent avoir confiance dans l’état de compte communiqué par les nœuds validateurs.

Dans ce cas, il n’y a pas de bonne ou mauvaise solution. Il y a celle de Libra, qui maximise les performances, mais amène une centralisation et celle d’Ethereum qui préfère la décentralisation au prix d’une « perte » en termes de performances.

Le langage de programmation : Move vs Solidity

Même si Libra n’utilise pas de blocs, la manière dont fonctionnent les transactions est assez similaire à Ethereum. Ces dernières sont écrites en Move un nouveau langage spécialement développé par Facebook pour Libra.

Contrairement à Ethereum où le code Solidity est compilé pour pouvoir être interprété par l’EVM (Ethereum Virtual Machine), le code Move quant à lui est directement exécuté dans la MVM (Move Virtual Machine).

Move permet d’écrire des modules – équivalent des smart contracts – qui sont déployés grâce à une transaction, comme le fait Ethereum 1.0.

Pour ce qui est de la Move virtual machine, qui permet d’exécuter le code des modules, elle est présentée dans le white paper comme adressant les faiblesses de l’EVM. L’EVM y est décrite comme la porte ouverte à de nombreuses erreurs de programmation. Le whitepaper appuie également le point des ERC-20, qui n’héritent pas forcement des protections du langage Solidity.

Ainsi les développeurs Ethereum doivent apporter une attention particulière lors du développement afin de ne pas introduire de bugs permettant la réutilisation, la perte ou la duplication des actifs.

Pour pallier à ces différents problèmes, Move se concentre sur 3 points :

• Pas de dynamic dispatch, ce qui veut dire que la logique d’exécution du code n’est pas déterminée pendant l’exécution (dynamique), mais lors de la compilation (static).
• Mutabilité limitée, chaque modification d’une valeur dans un contrat Move se fait par le biais d’une référence. Sans rentrer dans les détails, ceci permet une vérification formelle du bytecode du smart contract assurant qu’il n’y aura pas de comportements imprévus.
• Modularité, l’utilisation des modules assure une abstraction des données. Ceci permet d’assurer que des propriétés déclarées dans un module ne peuvent pas être violées par du code provenant de l’extérieur de ce module.

La conception du langage Move et de sa machine virtuelle est majoritairement orientée vers la sécurité et découle d’une étude approfondie des faiblesses des autres protocoles de l’écosystème. Move semble de ce fait largement surpasser l’EVM d’Ethereum 1.0.

Cependant, Ethereum 2.0 verra arriver eWasm une nouvelle virtual machine utilisant le langage Web Assembly (en plus de Solidity). Le langage a été standardisé de la W3C (World Wide Web Consortium). Comme dans le cas de Libra, le code eWasm est directement interprété par la machine virtuelle, sans avoir à le compiler préalablement.

Alors que la supériorité de Move face à l’EVM semble être une évidence, elle n’est pas aussi claire face à eWasm. Cependant, aucune de ces solutions n’a encore été testée et éprouvée, il est donc pour le moment compliqué de déterminer laquelle des deux solutions est la plus performante et sécuriser.

Pour finir, même si Move venait à être largement adopté par les développeurs, rien n’empêcherait de permettre à eWasm d’Ethereum 2.0 d’interpréter le langage, comme le souligne Diederik Loerakker : 

« Je peux voir Move grandir, obtenir de l’outillage de développement / support. Mais si c’est le cas, nous le porterons simplement sur un environnement d’exécution Eth 2, et laisserons le marché jouer avec. », Diederik Loerakker

L’algorithme de consensus : POW/POS vs LBFT

Nous allons à présent nous intéresser au mode de consensus. Là encore, les choix pour Libra démontrent une longue étude des problématiques liées au consensus.

Dans sa version 1.0 – la version actuelle – Ethereum utilise le POW (Proof Of Work), système dans lequel ce sont des mineurs qui valident les transactions en déployant une large puissance de calcul.

Pour ce qui est d’Ethereum 2.0 – dont la date de sortie approche à grands pas – ce sera le POS (Proof Of Stake) qui sera utilisé. Dans ce système-ci, ce sont des nœuds qui prétendent à la validation d’un bloc, en prouvant la possession d’une quantité de jetons.

Dans le cas de Libra, la cryptomonnaie utilise LibraBFT, un dérivé de l’algorithme HotStuff. Dans LibraBFT, BFT signifie Byzantin Fault Tolerant. Le consensus sur l’état général des comptes est atteint si plus de 2/3 des validateurs ont voté. C’est le même concept que sur Tendermint, la technologie utilisée par Cosmos où la Binance chain.

Dans les deux cas, les choix semblent logiques. Pour Ethereum 2.0, le POS va permettre de rendre la blockchain scalable, tout en apportant une grande décentralisation. Dans ce modèle-là, les performances sont conservées même avec un très grand nombre de validateurs.

Pour ce qui est de Libra, la décentralisation ne semble pas être importante (le terme n’est abordé que 8 fois dans le whitepaper). Les 100 nœuds validateurs, dont MasterCard, VISA ou encore PayPal, ont dû payer la modique somme de 10 millions de dollars pour s’assurer une place, et ce n’est pas le prix de la décentralisation. D’un point de vue technique, l’algorithme de BFT semble être un choix judicieux, car ce dernier présente d’excellentes performances avec peu de validateurs.

Le BFT permet contrairement à Ethereum 1.0 d’assurer la finalité des transactions : il n’y a pas à attendre 12 blocs pour que les transactions soient considérées comme valides. Une fois qu’une transaction est approuvée en BFT, elle est directement valide. Ce sera également le cas pour Ethereum 2.0.

Conclusion : Libra > Ethereum 1.0 ?

D’un point de vue technique Libra surpasse largement Ethereum 1.0 en adressant nombreuses de ses faiblesses. Cependant, dans le cas d’Ethereum 2.0 et Libra, les deux n’ont pas grand-chose à s’envier, chacun répondant technologiquement à ses besoins.

Ethereum 2.0 garde cependant pour le moment une nette avance grâce à son historique et les outils déjà déployés dessus. En plus de cela, le protocole pourrait garder son avance même si le langage Move venait à être largement adopté, en ajoutant le support de Move par eWasm.

Les deux projets – Libra et Eth 2.0 – sont tous les deux au stade de la conception. Les promesses sont grandes des deux côtés, 1 000 transactions par secondes pour Libra et des milliers pour Ethereum 2.0. Cependant, aucune des deux solutions n’a été déployée et testée, rendant les comparatifs de performances réelles impossibles.

Seul l’avenir nous dira si les développeurs migreront sur Libra afin d’y développer des applications décentralisées. Au regard des acteurs impliqués dans la validation des transactions, il a fort à parier que Libra devienne la plateforme vers laquelle les entreprises se tourneront, malgré sa décentralisation plus faible qu’Ethereum.