Blockchain de consortium, Corda ou Fabric ? (1/2)
Nous allons, dans une suite de deux articles, comparer deux registres distribués (distributed ledger) open-source à destination des entreprises, à savoir Fabric, incubé dans le projet Hyperledger, et Corda, développé en grande partie par l’entreprise R3.
Ces articles ont pour but de donner des éléments de comparaison comme leurs composants, leur état “****stateful ou stateless ?”, la confidentialité, le consensus, le cycle transactionnel, l'interopérabilité, et enfin la haute disponibilité de ces plateformes, afin de pouvoir choisir la plateforme qui correspond le mieux au cas d’usage posé.
Pour un rappel sur l’utilisation des DLT à destination des entreprises versus les DLT publiques, nous vous conseillons de d’abord lire : Distributed Ledgers & Blockchain… Où en est-on ?
Le développement de Fabric a débuté en 2015, sous le nom de Open Blockchain (OBC). C’est IBM et Digital Asset Holdings qui sont à l’origine de son développement. Son nom est ensuite devenu “Fabric” lorsqu’il fut incubé par Hyperledger, un projet de la Fondation Linux qui regroupe différents registres distribués et utilitaires (explorateur blockchain, projets d’interopérabilité et d’identité...).
Fabric se veut être le nom éponyme d’une fabrique à blockchain, qui ne se focalise pas sur un secteur métier.
Corda, pour sa part, a été développé par l’entreprise R3, qui l’a mis par la suite en open-source le 30 Novembre 2016. R3 fait également partie d’Hyperledger, et participe à différents groupes de travail. Si les licences open-source de Fabric et Corda sont les mêmes, R3 a choisi de ne pas soumettre Corda à Hyperledger pour des questions de gouvernance et de dépôt de marque.
Corda a été pensé par et pour les institutions financières, mais la plateforme se veut agnostique et propose un framework pour construire n’importe quel cas d’usage.
Ces deux plateformes ont tenté de recueillir le plus de retours à la fois sur les besoins de l’industrie et sur ceux de la finance, afin d’affiner leur spécification.
Comparons maintenant dans ce 1er article leurs composants, leur état “****stateful ou stateless ?”, la confidentialité et le consensus.
Composants
Commençons par détailler leur composants, nous utiliserons les termes ci-dessous dans la suite de l’article.
Les deux plateformes utilisent une architecture à clés publiques pour la gestion des identités.
Fabric
On dénombre plusieurs types de noeuds et services dans un réseau Fabric :
- Client : Rattaché au noeud d’une organisation, il utilise un SDK en Node.js ou Java permettant d’envoyer des transactions (nous y reviendrons plus tard) et de recevoir de nouveaux blocs par le biais de son noeud rattaché.
- Peer : C’est le noeud d’une organisation, il en existe deux types :
- Committing Peer : Ils reçoivent les blocs contenant les transactions de la part de l’Orderer et maintiennent les états associés aux chaincodes.
- Endorsing Peer : Ils valident les propositions des transactions qu’ils reçoivent, et renvoient un endorsement. Ils ont toutes les fonctionnalités des Committing Peers.
- Orderer : Aussi appelé Ordering Service, c’est le service qui regroupe les transactions validées et les broadcast à l’ensemble des noeuds d’un même réseau blockchain (appelé channel). Supportant plusieurs channels, il regroupe les transactions en batch, dans des blocs.
Corda
Voici les composants d’un réseau Corda :
- Corda Node : C’est le noeud d’une organisation, il peut porter plusieurs Cordapp, qui sont les applications métier incorporant les smart-contract et Flow de Corda.
- Network Map : Il permet aux différentes organisations du réseau de se découvrir. Implémenté comme un service HTTP, il peut être situé derrière un CDN et est mis en cache par chacun des noeuds du réseau.
- Notary : C’est le service qui permet le consensus sur la double dépense dans le réseau
- Non-Validating : Il permet d’assurer la non double-dépense d’un asset dans un même réseau Corda et doit signer ces transactions de dépense. Il vérifie simplement qu’un état n’a pas déjà été consommé ; il respecte donc la confidentialité de la transaction en question. C’est le notaire le plus souvent utilisé.
- Validating : Il vérifie si les vérifications du smart-contract référencé dans la transaction sont corrects. Il ne respecte pas la confidentialité dans les transactions s’il n’est pas utilisé avec des enclaves de type SGX (en cours d’implémentation).
Stateful ou stateless ?
Fabric
Fabric est une plateforme d’exécution : elle permet l’exécution de smart-contract, appelé chaincode. Ces chaincodes peuvent être écrits en Golang, Node.js ou encore en Java, et interagissent avec une base de données, qui est soit de type clé/valeur (LevelDB), soit orientée document (CouchDB), au choix.
On note donc qu’à la manière d’Ethereum, Fabric est stateful : en plus de contenir l’historique des transactions contenues dans des blocs (la blockchain est un registre de logs), elle sauvegarde des états internes dans une base de données accessible depuis le chaincode****.
Il est possible de tester les chaincodes implémentés en mockant les interface sous-jacentes, voir exemple en Node.js.
Corda
Corda part du principe que la plupart des échanges métiers sont majoritairement des transferts d’****assets et suit par conséquent la logique UTXO (Unspent Transaction Outputs), que l’on retrouve dans Bitcoin. Selon cette logique, un utilisateur ne possède pas de compte en tant que tel (assimilable à un compte en banque) mais conserve toutes les transactions qu’il a précédemment reçues pour pouvoir à son tour les consommer et créer une nouvelle transaction. Par conséquent, comme Bitcoin, Corda ne contient pas d’état interne "riche" mais seulement les transactions reçues ; on peut donc dire qu'il est stateful dans une moindre mesure que Fabric.
Ici, le mot “état” désigne n’importe quel actif ou donnée structurée (du Cash, un reçu de livraison, un message structuré, etc.) que l’on insère dans une transaction.
https://docs.corda.net/key-concepts-consensus.html
Dans l’exemple ci-dessus, Charlie créé un état Cash qu’il transfère à Dan par le moyen d’une transaction. Si Dan souhaite utiliser son Cash, il va simplement consommer l’état qu’il a reçu et en créer un nouveau pour Alice en échange d’un instrument financier Bond (une obligation). Enfin, Alice consomme son état Cash reçu pour l’envoyer à Bob.
Le terme smart-contract introduit dans Corda est différent de celui de Fabric. Un smart-contract a pour but de vérifier, à l’aide d’une Java Virtual Machine dont les fonctionnalités non-déterministes sont retirées, que les passages entre les entrées et les sorties d’une transaction sont conformes. Dans le schéma ci-dessus, les verbes ISSUE, PAY et SEND, inclus dans les transactions, appellent des smart-contracts. Le verbe PAY, par exemple, vérifie que l’état consommé a bien été signé par celui qui le possédait avant de le transférer.
Nous observons ici qu’il est possible pour Bob de voir les différents états qui aboutissent à celui qu’il reçoit : il peut donc connaître toutes les transactions effectuées avant lui par les parties, ce qui peut potentiellement aboutir à un manque de confidentialité. Afin de remédier à cela, Bob et son(ses) partenaire(s) peuvent se mettre d’accord pour créer une identité temporaire à une transaction. Dans ce cas, Bob ne peut pas connaître les vraies identités des parties ayant échangé l’état avant lui.
Confidentialité
Fabric
À l’origine, Fabric formait un unique réseau global où tous les pairs recevaient l’ensemble des transactions_._ Puis le concept de channel est apparu en version 1 pour permettre à différents réseaux de garder de la confidentialité. Un channel est une blockchain à part entière, dans laquelle plusieurs organisations vont définir les critères de validation des transactions.
Ainsi, plusieurs organisations voulant travailler ensemble vont rejoindre un même channel qui peut contenir un ou plusieurs chaincodes.
Dans le schéma ci-dessus, les données échangées par les parties A & B dans le chaincode B ne sont pas visibles par la partie C car elle ne fait pas partie du channel 1.
De plus, même si la partie A n’a pas connaissance du chaincode C, elle reçoit toutes les transactions qui ciblent ce dernier car il se situe dans le même channel.
En plus de cloisonner le partage de la donnée inter-channels, il est possible d’envoyer des données privées à certaines organisations à l’intérieur même d’un channel (par le biais d’un chaincode). Ces données ne passent alors pas par l’Orderer mais sont envoyées en pair à pair. Pour ce faire, il faut définir une Collection, définissant les organisations qui vont recevoir ces données. Cependant, cette fonctionnalité, disponible en version 1.2 de Fabric, n’est pas encore sortie.
Dans Fabric, le partage se fait donc au niveau d’un channel****, avec la possibilité d’envoyer certaines données privées.
Corda
Rappelons ici que Corda a été construit pour le monde de la finance, qui a des besoins forts de confidentialité. Son design initial reste inchangé : une transaction est uniquement partagée avec les organisations y participant.
Dans cet exemple, chaque cercle représente le contenu des base de données des différentes parties, avec les états qu’ils contiennent.
Party A a partagé le Fact #1 avec Party C et Party B, c’est-à-dire qu’ils voient exactement le même état partagé, qui est par ailleurs signé. Dans le même sens, le Fact #2 que partage Party C avec Party A n’est pas visible par Party B.
Ainsi, dans Corda, le partage des états se fait directement au niveau transactionnel et permet donc une gestion de la confidentialité pour chaque état.
Consensus
Le consensus de ces deux plateformes s'acquièrent par la validation des transactions seulement par certaines organisations prédéfinies (qui s’exprime simplement par “nous sommes d’accord”), car les organisations sont authentifiées.
Pour rappel, dans les blockchain publiques, le consensus doit être possible sans connaissance des identités du réseau, c’est d’ailleurs ce qui le rend beaucoup plus compliqué.
Alors que dans Fabric il y a consensus sur toutes les transactions d’un chaincode****, dans Corda, celui-ci se fait sur la base d’une transaction unitaire et entre ses participants.
Fabric
Les règles de validation des transactions sont définies dans chaque chaincode, avec l’endorsement policy.
Dans l’exemple de transaction vu dans le chapitre “cycle transactionnel”, l’endorsement policy requiert la signature de 3 endorsing peers, mais il est également possible de mettre en place des polices plus complexes du type :
(Alice OR Bob) AND (any two of: Charlie, Dave, Eve, Frank, George)
L’Orderer, qui reçoit et broadcast les transactions d’un channel est un élément central de Fabric. Il a deux spécificités : il faut lui faire confiance (il peut censurer les transactions qu’il reçoit) et assurer sa disponibilité (il peut bloquer les transactions s’il tombe en panne).
Il est possible de lui conférer une haute disponibilité en le composant en cluster Kafka.
Néanmoins, cette solution ne tolère pas la faute byzantine, il est donc prévu de faire fonctionner ce service avec un consensus Byzantine Fault Tolerant (ici, SBFT est utilisé). Ce consensus est toujours en cours d’implémentation et permettra donc de n’accorder presque aucune confiance à cet Orderer, qui sera vu comme un composant logique mais implémenté par plusieurs organisations.
Si Kafka comme SBFT assurent une haute disponibilité, Kafka a plus de débit mais requiert plus de confiance.
On note que dans les deux cas l’Orderer voit le contenu des transactions qu’il reçoit, il n’y a donc pas de confidentialité.
Corda
Le consensus de Corda se fait d’une part sur la validation de la transaction par le signataire et d’autre part sur son unicité.
La validation de la transaction est assurée par ses participants : ils doivent signer la transaction et faire passer les vérifications du smart-contract. Il faut également vérifier que toutes les transactions qui ont conduit à la transaction reçue soient validées : par exemple, si nous recevons du Cash, nous voulons vérifier qu’il a bien été émis par une banque centrale lors de la première transaction.
La validation de son unicité est faite avec l’aide du Notary : c’est lui qui va assurer la finalité d’une transaction. Il va par exemple nous certifier que le Cash que nous recevons n’a pas été envoyé en même temps à une autre organisation. Dans cette tentative de fraude, une des deux organisations réceptrices ne pourra pas l’utiliser, car cet état sera déjà consommé.
Les notaires n’ont pas besoin de voir le contenu des transactions, on garde donc la confidentialité voulue.
Il est possible pour un même réseau Corda d’avoir plusieurs Notary.
Il est également possible comme avec Fabric d’abstraire un Notary en cluster, avec un consensus de type RAFT ou avec un consensus tolérant à la faute byzantine (ici, BFT SMaRt).
Ces deux consensus sont fonctionnels dans Corda.
A suivre…
Nous étudierons dans le second article le cycle transactionnel, l'interopérabilité, et enfin la haute disponibilité de ces plateformes pour pouvoir conclure sur leurs potentiels.