Facebook Libra, qu’y a-t-il sous le capot ?

Après la publication le 18 Juin 2019 du whitepaper du projet de cryptomonnaie de facebook, il me semble important de regarder ce qu’il y a sous le capot. Mes sources principales sont le whitepaper https://libra.org/fr-FR/white-paper/, le code source https://github.com/libra/libra et la documentation technique https://developers.libra.org

Le whitepaper technique est co-écrit par une vingtaine d’auteurs dont un Français, Mathieu Baudet, que je ne connaissais pas. https://www.linkedin.com/in/mathieu-baudet-a526b09/

Êtes-vous prêt ? C’est parti !

Facebook Libra n’utilise PAS la blockchain

There is no concept of a block of transactions in the ledger history (Technical Whitepaper)

Contrairement à toutes attentes, la cryptomonnaie de facebook n’utilise pas la blockchain. Même si le mot blockchain est utilisé partout, il n’y a pas de blocs dans la représentation de données, donc pas de blockchain. Le seul endroit ou il y a un bloc évoqué, c’est pour transmettre les transactions, mais les blocs ne sont pas chainés. Cela tord le coup notamment à une phrase souvent entendue: “la vraie technologie, c’est la blockchain”. Force est de constater que facebook n’est pas du même avis. Que trouve-t-on alors pour remplacer la blockchain comme modèle de données ?

En fait, Libra utilise le concept d’état comptable, ou « Ledger State », pour identifier l’état des transactions entre chaque noeud. Plutôt que d’envoyer la dernière page de votre livre comptable, avec le numéro de page, vous allez plutôt échanger l’état de tous les comptes à jour, en calculer le hash et ce hash sera l’élément discriminant pour savoir si vous êtes à la page avec les autres noeuds.

La principale conséquence est que pour synchroniser votre noeud, vous ne devez plus télécharger tout l’historique, seul l’état comptable le plus récent et le plus partagé au sein du réseau fait foi. Un des problèmes est, donc, que vous n’êtes plus dans la position de vérifier l’historique. L’accord, ou consensus, que vous constatez sur le réseau fait foi. Il n’y a donc pas de décentralisation à proprement parler.

L’autre conséquence, et qui est probablement la raison de l’adoption de ce système, c’est sa rapidité. Sans besoin de télécharger l’historique ni de systématiquement échanger des blocks, le hash des derniers états est suffisant pour se mettre d’accord.

Pour pouvoir arriver à se mettre d’accord, le Technical Whitepaper explique que l’execution des transactions est faite de façon déterministe, de façon que l’ordre d’exécution soit toujours le même, quel que soit le noeud. Il n’y a pas plus de détails sur l’algorithme et je dois avouer que cela me laisse perplexe.

Qu’est ce qu’un compte pour Libra ? C’est un identifiant, c’est-à-dire une adresse qui est le hash de la clef publique, et une série de valeurs associées, notamment et on l’imagine volontiers le solde du compte. Il est, d’ailleurs, manifestement possible de changer la clef publique pour signer une transaction sur un compte, sans en changer l’adresse, mais le mécanisme n’est pas indiqué. On imagine une transaction spécifique pour mettre à jour la clef de signature.

Programmez vos transactions avec MOVE

Mais parlons des transactions. Une transaction Libra est, en réalité, un script écrit dans un nouveau langage: move.

Pour être plus précis, le script écrit dans ce langage est compilé dans une transaction pour être ensuite exécuté sur Libra, un peu comme Solidity le fait pour Ethereum.

Mais le script est bien plus important dans le monde Libra. En effet, c’est au niveau de la transaction que l’on déclare la création d’un compte — instruction create_account -, et que l’on demande une ressource spécifique, en gros un espace de stockage — resources dans le monde Libra — ou un appel de fonction — module.

Enfin un élément intéressant est l’instruction event. Il semble qu’il s’agisse d’un élément permettant de déclencher le comportement d’un noeud, par exemple pour notifier l’utilisateur que le paiement a bien été validé.

On peut consulter l’historique des transactions

Contrairement aux cryptomonnaies basées sur la blockchain, l’historique des transactions n’est pas utile pour valider de nouvelles transactions sur Libra. Il peut, cependant, être utile pour les utilisateurs de conserver cet historique. Un mécanisme — authenticated data structure — est donc décrit comme un immense arbre de Merkle. Cette structure a pour but de donner une preuve que l’information donnée par le noeud correspond bien à l’état du réseau, soit le hash du dernier état comptable.

Dit autrement, si je veux avoir l’état de mon compte, je peux faire une requête sur un noeud. Mais comment être certain que les données renvoyées sont vraies ? Avec cette structure, vous pourrez vous-mêmes vérifier les informations de l’arbre de Merkle, depuis le début de Libra jusqu’à l’état récent du réseau. L’arbre de Merkle est un mécanisme permettant de le faire d’une façon rapide, même si la taille de l’historique augmente.

Evitez de stocker vos preuves dans Libra

Manifestement, le technical whitepaper est peu loquace sur la façon de contrôler l’espace utilisé par un compte, surtout s’il on considère que la base se monte à 2 milliards d’utilisateurs. Une piste évoquée est l’éviction de compte. La réservation d’espace expire avec le temps, et ce temps sera proportionnel au prix que vous allez mettre. Il n’y a donc pas d’immutabilité dans ce domaine. Mon conseil : évitez donc de stocker vos preuves dans Libra !

Et le consensus ?

Nous voilà au point sensible: Libra n’a pas de proof of work — un système qui serait trop gourmand en énergie, donc inenvisageable selon le Technical Whitepaper. Il n’y a pas, ou pas encore, de proof of stake.

Introducing… LibraBFT. BFT pour Byzantin Fault Tolerant, le « graal » de toute cryptomonnaie. Petite introduction sur le BFT, donc.

Pour mettre d’accord des personnes qui n’ont pas un chef pour leur matraquer la vérité, on se met dans la peau d’un de ces acteurs, et on essaye de savoir comment par l’observation des autres acteurs on parvient à connaître la vérité. Evidemment, vous n’avez aucune possibilité de savoir si un acteur vous ment ou non. Les acteurs peuvent avoir intérêt à vous mentir si ils y gagnent par ailleurs — en pillant des comptes par exemple, ou en étant corrompus. Vous êtes, par conséquent, réduit à faire des statistiques. Je passe les détails de cette science, mais il faut avoir en tête deux résultats importants:

• PBFT ou Practical Byzantin Fault Tolerant, qui est un algorithme qui permet de prouver que la vérité que l’on arrive à trouver en observant les autres acteurs est fiable si plus de 2/3 des acteurs ne mentent pas.
• Bitcoin est le premier algorithme qui a aligné l’intérêt des acteurs à dire la vérité avec leur intérêt personnel, qui est de gagner de l’argent.

Chez Libra, on cite explicitement Casper, l’algorithme d’Ethereum qui était développé par Vitalik Buterin pour la prochaine version du consensus, et Tendermint, le consensus développé par la cryptomonnaie Cosmos.

LibraBFT dérive d’un autre algorithme, appelé HotStuff, qui permet d’obtenir un consensus si plus des deux tiers des acteurs sont vertueux, via un système de vote.

En pratique, l’ensemble des validateurs de Libra, soit MasterCard, Visa, Iliad, Coinbase, etc., vont voter avec leur machine pour se mettre d’accord régulièrement sur l’état comptable de Libra. Lorsque deux tiers des votes sont reçus, l’état est validé, et on peut passer à la validation des nouvelles transactions.

Pourquoi un consensus spécifique ? Manifestement, l’objectif de Libra est d’être un système qui peut « avaler » 1000 transactions par seconde, sur un système comprenant jusqu’à 500–1000 validateurs. Il faut donc optimiser cette partie, et l’équipe de Libra ne semble pas convaincue par les alternatives existantes.

A noter: la topologie envisagée est ultra-connectée, chaque validateur étant connecté à tous les autres. Pour 100 noeuds, cela fait 100*99/2 = 5000 connections environ. Pour 1000 validateurs, c’est 500 000 connections.

L’objectif étant de passer à termes, 5 ans après le lancement de Libra, vers un consensus ouvert, il est explicitement précisé que le consensus sera basé sur le PoS, sans plus de précision. DPoS pourrait aussi bien aller puisqu’il retient la notion de vote par les validateurs.

Que vous faudra-t-il pour faire tourner Libra ?

Il vous faudra, d’abord, être adoubé dans le club des multimillionaires validateurs. Le mécanisme d’authentification concernant la cryptomonnaie Libra n’est pas mentionné, mais on imagine un compte spécial ouvert par la libre association des multimillionaires basés en Suisse, qui permet de créer une transaction spéciale avec un scrip MOVE, qui authentifie grâce à une ressource réservée — et pour un temps limité — le statut de validateur.

Ensuite, il vous faudra vous payer un serveur qui selon le whitepaper nécessite 40 Mbps de bande passante internet, 16GB de disque SSD et un CPU intel classique. A la portée de toutes les bourses !

Le Wallet Colibra

Le whitepaper ne mentionne pas colibra, le logiciel portefeuille édité par facebook (via une société éponyme 100% détenues par facebook et dirigée par David Marcus). C’est le produit phare pour les utilisateurs de facebook lorsqu’il s’échangeront de la monnaie. Hors à ce stade il reste plusieurs inconnues :

• La libra-monnaie est-elle la monnaie de base de ce projet ou est-ce une ressource particulière qui est réservée (penser un smartconctract de type ERC20 dans le monde Ethereum)
• Si c’est un ‘smart-contract’ la maîtrise du KYC/AML est plus simple. Reste le jeton sous-jacent. Sera-t-il listé lui aussi sur les exchanges. Est-il préminé pour les validateurs en échange des 10 millions de dollars, transformant l’opération en ICO ou en STO ?

Où en est le projet ?

Après ce descriptif, que peut-on dire de l’état du projet ?

• la documentation contient beaucoup d’incertitudes qui demandent à être levées avant de pouvoir simplement fonctionner : utilise-t-on du gas pour réserver une resources ? Comment les validateurs sont définis dans le système ? Certaines resources expireront-elles, au bout de combien de temps ?
• Des trous dans le consensus : Comment les valideurs sont choisis ? est-ce une distribution de clefs publiques ? Faut-il hardforker le réseau si un validateur se fait hacker sa clef privée ?
• Développement encore à l’état de concept : les primitives cryptographiques sont implémentés, mais il manque encore la liste des instructions MOVE utilisables pour les transactions, qui apparement devrait être que validées au compte goutte pour des raisons de sécurités

Conclusion:

• pas de blockchain, mais une chaine d’état comptable
• des innovations sur la couche consensus et modèle de données
• Encore à l’état de PoC
• Des questions demeures sur le ou les jetons en circulations