Ces chercheurs français et la blockchain
Qui a dit que la recherche française n’était pas aussi impliquée dans la technologie des protocoles distribués que les E.-U ? Il faut reconnaître que leur communication reste très discrète, mais cela ne veut pas dire que nos cerveaux français ne carburent pas à trouver de nouvelles solutions aux problématiques actuelles liées à cette technologie.
Lors d’une invitation à l’École Polytechnique à Palaiseau, j’ai pu faire la rencontre de brillants chercheurs dans le domaine de la blockchain venant de différents centres de recherche tel que l’INRIA, Polytechnique, CNRS ou encore le CEA. Cela a été un très agréable et instructif moment d’autant plus que nos chercheurs restent très accessibles et ouverts à la conversation.
C’est donc suite aux présentations, mais aussi au fil de discussions que j’ai pu découvrir 3 projets que j’aimerais partager à travers ce billet.
Un premier sujet de recherche, qui est maintenant plutôt bien avancé, est le projet « Red Billy Blockchain » ou encore appelé « RBBC ». Ce projet présenté et porté par Vincent Gramoli, a pour vocation de créer une nouvelle blockchain avec un consensus particulièrement intéressant.
Un second projet, présenté par François Bobot, est un outil s’appelant Why3 permettant aux développeurs Solidity de procéder à des vérifications prédictives sur les smart-contracts pour Ethereum.
Enfin un troisième projet, réalisé par l’équipe de OCamlPro, qui est Liquidity. Un langage permettant de créer des smart-contracts sur la nouvelle blockchain qui est en train d’émerger : Tezos.
RedBelly : Une blockchain survitaminée
Les problèmes de sécurité possibles sur une blockchain tournent beaucoup autour de la possibilité d’un fork. C’est pourquoi la technologie RBBC (RedBelly Blockchain) propose de créer une blockchain sans capacité d’effectuer un fork.
RBBC sera composé d’un système distribué composé de N participants identifiés dans le bloc genesis. Les nodes communiqueront par l’intermédiaire de TCP + SSL où les certificats seront enregistrés dans les blocs.
Comme expliqué, les participants sont clairement identifiés et si des personnes extérieures (clients) à ces participants veulent agir sur la blockchain, ils devront passer alors par eux. Ces clients auront la capacité de lire la blockchain, mais aussi envoyer des transactions qui seront commit par les participants dans des blocs décidés. Les nodes ayant le rôle de participant sera régulièrement changé.
Une transaction fera l’objet d’une validation si plus d’un tiers des participants ont approuvé la transaction. De plus, RBBC se veut être partiellement synchronisée (comment ?)
Bien évidemment, cette blockchain sera « Byzantin Fault Tolerant » en utilisant le consensus DBFT (« D » pour democratic). Contrairement au BFT qui se tient de respecter ces 3 règles :
- Agreement : Il ne peut y avoir 2 process valides qui décident différemment
- Termination : Chaque process valide décide
- Validity : Si tous process valides proposent la même valeur, alors aucune autre valeur ne peut être décidée.
Le DBFT, lui, élimine le point « Validity » considérant que si le point « Agreement » et « Termination » sont corrects alors « Validity » le sera aussi.
(L’explication en détail de DBFT sera présentée dans un autre billet.)
Après un certain nombre de benchmarks et calculs théorique, il s’est avéré que RedBelly était le plus efficace avec des blocs de 10.000 transactions de 350 bytes chacune. Avec 260 participants, les benchmarks ont démontré un taux de transaction par seconde de l’ordre de 660.000.
Lorsque l’on constate que Visa est à 120.000 transactions secondes, nous comprenons donc l’enjeu de cette blockchain qui pourrait permettre faire des transactions crossborder sans le moindre essoufflement contrairement à Ethereum ou Bitcoin qui sont encore très loin de pouvoir proposer cette solution… ou du moins tant que Lightning Network et Raiden/Plasma n’ont pas été mis en place. Sans même cela toute la problématique de fees résiderait toujours.
RBBC en résumé:
- 660.000 transactions/secondes avec un bloc toutes les 4 secondes
- 260 participants au consensus (avec un nombre de clients illimités)
- Avec un nouvel algorithme de consensus byzantin sans leader
- Avec une reconfiguration régulière des participants
Why3 : La fin des smart-contracts mal conçus ?
Le smart-contract est un microcode qui est inséré dans la blockchain. Ce smart-contract, lors de son développement, va embarquer des conditions qui vont permettre de valider automatiquement si le ou les actifs en question doivent être transmis. Il s’agit là de règles de gestion ou encore nous pourrions les assimiler à des clauses, tout comme dans un contrat classique. Ce smart-contract étant sur la blockchain est sans altération. Lors de son exécution si toutes les conditions sont respectées le process s’exécutera sans quoi aucun actif ne transitera.
On comprend donc que le smart-contract donne une tout autre dimension à la blockchain et pourrait permettre à des entreprises de développer de nouveaux business models en s’y appuyant dessus. Actuellement, la blockchain de référence avec des smart-contracts s’appelle Ethereum. Le langage utilisé pour coder des smart-contracts est Solidity.
Solidity présente un défaut majeur malgré toutes les opportunités qu’il offre : il n’est pas capable de faire de preuves formelles sur son code. C’est-à-dire que la sémantique du code peut provoquer des comportements inattendus qui pourrait être à titre d’illustration :
uint8 a; a = 0; a=a-1;
Quelle valeur devrions-nous trouver ? 0 étant donné qu’il s’agit de nombres non signés, n’est-ce pas ?
Eh bien non, avec Solidity le résultat retourné sera 255…
Il sera compréhensible pour tous que dans le cadre d’un accord commercial fait par le biais d’un smart-contract, si le développeur n’a pas anticipé ce genre de comportement, les conséquences puissent être graves. Rappelez-vous de TheDAO, il s’agissait d’une problématique du même genre…
C’est sur ces problématiques que Why3 peut intervenir en assistant le développeur dans sa revue de code.
Why3 est un outil qui utilise le langage WhyML qui va récupérer toute une batterie externe de « provers » qui vont chacun contenir des règles mathématiques. WhyML va être utilisé en tant qu’intermédiaire entre les « provers » et le langage Solidity qui sera mis en input.
Lorsque Why3 sera exécuté, toutes les incohérences mathématiques seront mises en surbrillance. Si Why3 avait été utilisé sur le développement de TheDAO le bug aurait été immédiatement identifié.
Actuellement Why3 ne couvre pas encore tous les théorèmes mathématiques, mais un grand nombre existe déjà.
Liquidity : Vers un langage adapté pour les entreprises sur Tezos
Avant de parler de Liquidity, je voudrais rappeler qui est l’équipe derrière cette technologie et ce qu’elle a pu faire dans le passé. OCamlPro, est une entreprise avec un degré d’expertise avancée sur le langage OCaml. Cela s’explique par la simple et bonne raison que le langage Ocaml a été inventé dans les laboratoires de l’INRIA d’où provient Fabrice Le Fessant, fondateur de cette entreprise. Actuellement OCamlPro compte 13 employés, dont Fabrice. Cette fine équipe est composée exclusivement d’ingénieurs chercheurs.
Vous aurez bien évidemment compris que le langage OCaml est une évolution du Caml, langage bien connu des étudiants en informatique. Le Caml (et OCaml par conséquent) a les propriétés d’être fortement typé et conçu pour la sécurité et la fiabilité des applications.
Il est important de savoir que Tezos est actuellement développé en OCaml (il faudra même noter que l’équipe de Fabrice y est pour beaucoup dans l’avancement de Tezos) et que le langage des smart-contracts utilisés est le Michelson… lui-même basé sur le OCaml.
L’inconvénient du langage Michelson est son manque d’abstraction par rapport au jeu d’instructions du processeur de la machine. C’est-à-dire que moins nous avons d’abstraction plus nous nous rapprochons d’un langage proche de l’assembleur et donc peu lisible par l’humain.
C’est pourquoi Liquidity a été créé : Fournir aux développeurs un langage gardant toutes les propriétés de sécurité et fiabilité, mais aussi et surtout la capacité d’effectuer des preuves formelles sur les smart-contracts qui seront développés. En d’autres termes, Liquidity est un langage de niveau bien plus élevé que celui de Michelson.
Actuellement Liquidity n’est pas encore dans sa version finale, mais il est possible de le tester soit en le téléchargeant sur github soit directement l’expérimenter via un « IDE » web que propose OCamlPro sur le site liquidity-lang.org.
Voyez ci-dessous la différence entre du Liquidity et du Michelson… Pour un niveau de performance/sécurité identique :
Comme on peut le voir au-dessus le smart-contract devient spontanément bien plus lisible et donc démontre la nécessite d’un tel langage sur Tezos : cela simplifie le travail des développeurs. Effectivement Michelson ressemble peu aux langages les plus utilisés en entreprise et pour cette raison la courbe d’apprentissage et d’adoption que ça soit pour un débutant ou un expert sera bien moins difficile sur Liquidity.
Remerciement
J’aimerai remercier Vincent Danos sans qui cette rencontre n’aurait jamais pu se faire.