R3 Corda : Présentation
Les technologies Blockchain & DLT (Distributed Ledger Technology) sont nombreuses. Nous allons ici nous concentrer sur Corda, un DLT développé par le consortium R3.
Genèse du projet
A l’origine de Corda : cinq problématiques des blockchains publiques les rendent inadaptées à l’utilisation en entreprise. Nous allons commencer par détailler ces problématiques.
Manque de confidentialité
Les blockchains classiques telles qu’Ethereum proposent un registre complet distribué entre tous les participants (les ‘nœuds’). Or, pour des raisons de compétition voire de régulation, il est difficilement envisageable de donner accès à toutes à les transactions réalisées par une entreprise à ses concurrents directs.
Risque de non-finalité
R3 considère que le protocole PoW (Proof of Work) utilisé par Bitcoin ne répond pas au besoin de ‘finalité’ requis par les entreprises. En effet, pour entériner une transaction dans le registre, il faut attendre le travail des mineurs, et même si la transaction est ajoutée à un bloc, rien ne permet de s’assurer définitivement qu’un fork n’aura pas lieu.
Pseudonymat des participants
Si l’inscription sur un réseau tel qu’Ethereum est très facile, par exemple en créant son portefeuille via MyEtherWallet, à aucun moment dans le processus il n’est demandé de fournir son identité. Alors, anonymat complet ? Non, pas complètement. A travers des pratiques de crawling on peut assez aisément relier de nombreuses adresses de portefeuilles à des individus précis. On parle de ‘pseudonymat’.
Lorsque l’on parle d’échanges entre des entreprises, il est évident qu’elles doivent savoir à tout moment à qui elles ont affaire. Plutôt que de masquer l’identité des participants, il faut bien au contraire identifier fortement les entités qui traitent sur le réseau.
Faible scalabilité
On recense plusieurs milliards de transactions de type ‘paiement’ dans le monde chaque jour. A l’inverse, Bitcoin ne traite qu’environ 300 000 transactions dans une journée. Pour qu’un système actuel puisse être remplacé par un système blockchain, il faut que ce dernier puisse absorber autant de transactions. Ce critère est d’autant plus important en entreprise que la rapidité de transfert est parfois indispensable (par opposition de la moyenne actuelle de 19 secondes par bloc sur Ethereum).
Faible productivité et lenteur d’intégration
Si les technologies et langages exotiques comme Solidity (pour Ethereum) sont loin de rebuter les startups, il est clair qu’un grand compte (une grande banque, un assureur, etc.) aura plus de mal à accepter l’ajout d’une brique d’un nouveau format dans son système d’information. De plus, il est aujourd’hui plus facile de recruter des développeurs Java que Solidity…
Pénurie des talents et standardisation du SI poussent les entreprises à privilégier des technologies déjà éprouvées plutôt que les nouveautés encore mal maîtrisées voire interdites par les experts de la sécurité.
Historique rapide
C’est sur la base de ces observations communes à plusieurs acteurs financiers que consortium R3 est fondé en 2015 par des grandes banques du monde entier, comme Barclays, Société Générale ou Deutsche Bank. La première version officielle de Corda sort en octobre 2017, avant une version d’entreprise en juillet 2018.
Corda est présentée comme étant une ‘blockchain’ d’entreprise, mais nous aurons l’occasion de revenir sur la notion de ‘blockchain’ dans ce cas précis. R3 part du constat que les solutions comme Ethereum ou Bitcoin ne répondent pas aux besoins spécifiques d’une entreprise.
Deux versions de Corda
Corda se décline en deux versions, chacune dédiée à un usage différent.
Community Edition
Version open-source de Corda, accessible à tous et dont le code source est disponible sur GitHub.
Un très bon moyen de se former aux concepts de base, créer sa première CorDapp (application Corda, par analogie aux ÐApps d’Ethereum — applications décentralisées). Pour cela, la documentation de Corda propose des tutoriels qui permettent assez rapidement de faire fonctionner un réseau Corda, de développer des contrats et faire des transactions.
Enterprise Edition
Version dédiée aux entreprises, accès aux exécutables sur demande.
Cette version entend répondre plus spécifiquement aux besoins des entreprises. C’est ainsi qu’elle permet de coller aux exigences de haute performance et haute disponibilité, propose un support de plusieurs bases de données (Oracle, SQL Server, etc.) et une migration d’un système à l’autre.
Mais surtout, cette version inclut un composant supplémentaire : le firewall. Elément à l’aspect marketing indéniable, surtout en pensant à des contextes très sécurisés comme dans une banque. Composé de deux éléments (bridge & float), il entend garantir la qualité des données en entrée et sortie du SI.
Quelques concepts de base
Un réseau sous contrôle
Un réseau Corda est semi-privé, dans la mesure où chaque nœud doit fournir des éléments permettant de justifier de son identité à un doorman pour rejoindre le réseau. Ce service permet de s’assurer que chaque entité participant au réseau est connue de manière non ambigüe. On parle alors d’un processus de KYC (Know Your Customer), largement répandu dans de nombreuses activités hors blockchain.
Un réseau Corda est donc composé de nœuds et d’un doorman, mais aussi d’un ou plusieurs service(s) de notaire. Un notary est un nœud particulier, chargé de garantir l’unicité des mise à jour du registre.
Une fois validée par le doorman, l’identité d’une entité est attestée par un certificat X.509 délivré par celui-ci, et publiée sur l’ensemble du réseau via un service dit de network map.
Un registre semi-partagé
Contrairement à Ethereum où tous les participants ont accès au registre de toutes les transactions, le registre de Corda n’est pas entièrement partagé. En effet, un nœud n’a accès qu’aux données pertinentes pour son activité. C’est ainsi que sur le schéma ci-dessous, le noeud Alice n’a pas accès aux données partagées entre Bob et Carl alors même qu’il partage certaines informations avec Bob.
De plus, Corda va synchroniser en continu les données partagées par deux nœuds. Ainsi, nous avons l’assurance qu’à tout moment Alice et Bob voient la même chose.
Des ‘états’ propres aux nœuds
Chacun des points de couleurs des schémas ci-dessus représente un fait, un ‘état’. Les states d’un nœud peuvent évoluer dans le temps. Pour réaliser cette évolution, l’état courant est marqué comme ‘historique’ et un nouvel état mis à jour est créé. L’ensemble des états, y compris leurs versions historiques, est stocké dans un vault propre à chaque nœud. Ce coffre-fort ne contient donc que les états relatifs au nœud.
En rentrant un peu plus dans les détails, ce vault est en réalité une base de données classique (par défaut H2 pour la version Community, avec possibilité de passer sur des systèmes plus complets comme Oracle avec la version Enterprise). Nous sommes donc bien loin d’une blockchain puisque la notion même de ‘bloc’ est totalement absente de Corda. C’est notamment cette architecture radicalement différente qui permet d’assurer de meilleures performances de transaction.
Automatisation via des contrats
Si vous avez déjà approché Ethereum, vous avez entendu parler des smart contracts. Ces bouts de code qui n’ont d’intelligent que le nom permettent l’automatisation de certaines tâches lors de transactions avec la blockchain.
Corda n’échappe pas à ce concept, en le nommant plus sobrement ‘contrat’. Les contrats Corda sont rédigés dans des langages exécutables par la JVM (Java Virtual Machine), Java et Kotlin en tête. C’est ainsi qu’un développeur Java ‘classique’ pourra s’approprier un contrat Corda assez facilement, sans apprendre un nouveau langage, uniquement en exploitant l’API fournie par Corda.
L’exécution d’un contrat doit être ‘déterministe’, dans la mesure où l’acceptation d’une transaction par le contrat dépend uniquement du contenu de celle-ci.
Des transactions sous conditions
Nous venons tout juste d’évoquer le terme de ‘transaction’, il est temps de le définir. Une transaction est avant tout un souhait de mettre à jour le registre. Ce souhait ne peut ensuite être entériné dans le registre qu’à trois conditions :
- Elle ne contient pas de ‘double dépense’ (autrement dit elle n’essaye pas de consommer un état déjà consommé)
- Elle respecte les termes du contrat Corda (nature des paramètres d’entrée, etc.)
- Elle a été signée par les parties requises
Des flows pour atteindre le consensus
Entre l’émission du souhait de mettre à jour le registre et sa prise en compte par les nœuds impliqués, il y a donc plusieurs étapes, qui peuvent paraître lourdes et redondantes, là où une blockchain classique se charge entièrement de traiter la transaction émise.
C’est là que la notion de flow entre en jeu. Les flows Corda visent à automatiser le processus de consensus. Fort heureusement, il n’y a pas besoin de développer les mêmes flows de manière répétitive, car Corda fournit par défaut des flows standardisés pour les actions courantes (signature de transaction, vérification d’un ensemble de transactions, etc.).
Validité des transactions en deux volets
Comme nous l’avons vu, pour être intégrée au registre, une transaction doit répondre à des règles précises et inaltérables. Ces règles ont deux pendants :
Validité - Les entités devant signer une transaction vérifient sa validité avant d’apposer leur signature. Pour cela, les inputs et outputs de la transaction doivent répondre aux règles pré-établies, ainsi que toutes les transactions antérieures ayant amené au state que nous essayons de modifier. On peut donc parler de ‘chaînage’ des transactions même si on est loin du fonctionnement d’une blockchain.
Unicité - Une transaction ne doit pas consommer un état qui a déjà été consommé. Par exemple, une entité ne doit pas pouvoir dépenser de l’argent qu’elle a déjà donné à une autre entité. Donc, les inputs de la transaction ne doivent pas avoir été historisés auparavant.
Le cœur de Corda : le nœud
Un nœud Corda est une instance de JVM possédant une identité unique au sein d’un réseau. Il possède deux interfaces avec l’extérieur :
- Une couche réseau pour interagir avec les autres nœuds
- Une interface RPC pour interagir avec son propriétaire
Comme nous l’avons vu, un nœud contient aussi son vault qui contient les states et un service de stockage pour héberger les transactions et leurs éventuelles pièces jointes.
Tel quel, le nœud permet donc des opérations basiques, mais ses fonctionnalités sont évidemment restreintes et doivent être étendues par l’ajout de CorDapps.
L’application distribuée : la CorDapp
Une CorDapp est une application distribuée sur un réseau Corda, à l’image des ÐApps sur un réseau Ethereum. Elles sont constituées de :
- states qui définissent les ‘faits’ manipulés par la CorDapp
- contracts qui définissent les règles de validation de transaction à appliquer
- services qui fournissent des méthodes utilitaires pour interagir avec les composants du nœud
- whitelists qui imposent les données que le nœud peut recevoir.
Contrairement à un réseau Ethereum, la CorDapp ne sera pas propagée dans tous les nœuds du réseau, mais installée de manière optionnelle sur les nœud volontaires. Tant qu’un nœud n’a pas la CorDapp ad hoc pour exécuter un certain flow, il ne pourra pas l’exploiter.
Pour aller plus loin…
Nous avons évoqué de nombreux concepts à la base de Corda et de ses composants, mais il est évident que de nombreux détails pourraient être ajoutés. La documentation officielle de Corda pourra sûrement répondre aux questions plus poussées !
Dans un prochain article, nous évoquerons les limites de Corda, pour garder un regard critique sur cette solution largement employée dans le milieu bancaire notamment.
