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.

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.

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. À 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.

On recense plusieurs milliards de transactions de type ‘paiement’ dans le monde chaque jour. À 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).

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é.

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.

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. Élé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.

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 mises à 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.

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 nœud 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.

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.

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.

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 :

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.).

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.

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 :

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.

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 :

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œuds 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.