Blockchain de consortium, Corda ou Fabric ? (2/2)

le 20/07/2018 par Loup Theron

Après avoir comparé Hyperledger Fabric et Corda dans un premier article sur leurs composants, leur état “****stateful ou stateless ?”, la confidentialité et le consensus, nous allons maintenant nous intéresser dans ce deuxième et dernier article au cycle transactionnel, l'interopérabilité, et enfin la haute disponibilité de ces plateformes pour pouvoir conclure sur leurs potentiels.

Cycle transactionnel

Fabric

Concrètement, envoyer une transaction dans Fabric se fait en 8 étapes :

Dans les blockchain stateful telles qu’Ethereum, le cycle de vie d’une transaction se fait, de manière simplifiée, en deux temps : ordre puis exécution/validation. En effet, les transactions sont inscrites dans un bloc selon un certain ordre puis sont exécutées et validées par tous les noeuds du réseau.

Dans Fabric, le cycle de vie d’une transaction se fait en 3 temps : exécution (étape 2), ordre (étape 7) puis validation (étape 8).

Détaillons notre schéma : un Client (SDK) soumet aux 3 Endorsing Peers une proposition de transaction ; ils vont simuler cette transaction (possiblement en parallèle) puis renvoyer leur approbation avec leur signature.

Après avoir reçu toutes les approbations nécessaires (appelées endorsements), le client les regroupe puis soumet la transaction définitive à l’Orderer. Celui-ci va alors regrouper dans un bloc les transactions reçues, selon l’ordre de réception, et les délivrer à tous les noeuds du channel****.

Enfin, tous les pairs du channel vont valider les transactions : ils vérifient les endorsements et s’assurent que les états lus dans les chaincodes lors de la validation des Endorsing Peer soient cohérents avec leur états internes. Cette dernière étape ne permet pas à deux transactions séquentielles dans un bloc de modifier le même état, car l’état lu par la 2ème transaction sera dépendant de l’écriture de la 1ère transaction.

On constate qu’il n’y a pas de déterminisme (l’exécution d’un code donne toujours le même résultat) assuré dans l’exécution du chaincode. En effet, ni Golang, ni Node.js ni la JVM ne sont déterministes : ils peuvent faire appel à l’I/O (une base de données qui stocke les états), utiliser des nombre flottants (qui dépendent du hardware), créer un timestamp, etc...

Il faut donc éviter toute opération non-déterministe ou la proposition de transaction ne sera pas approuvée.

Corda

Le concept de Flow permet dans Corda de directement écrire le cycle de vie d’une transaction et sa finalité : on peut alors comprendre le workflow d’une transaction en lisant le Flow.

https://docs.corda.net/key-concepts-flows.html

Le schéma ci-dessus définit un Flow, il comprend toutes les étapes de finalisation d’une transaction : la création de la transaction, sa signature, la vérification de celle-ci par l’autre organisation (par le biais du smart-contract) qui à son tour la signe et la renvoie.

On constate que ce framework de Flow offre donc plus de liberté que Fabric dans la mise en place des cas d’usage : il est possible d’implémenter un cycle de vie à la Fabric mais l’inverse n’est pas possible.

Ce Flow pourtant assez simple peut se complexifier lorsque plusieurs organisations prennent part à une transaction, en somme quand le workflow est plus ardu. Corda fournit donc une infrastructure de test complète pour simuler un réseau comprenant les services utilisés et les organisations qui prennent part au Flow.

Les tests unitaires sur les smart-contracts et les tests sur les Flow permettent au développeur de suivre les principes du TDD (Test Driven Development), comme expliqué dans cet article.

Il est possible d’avoir de la concurrence entre plusieurs Flow car ceux-ci sont sérialisés sur disque lorsqu’une organisation attend la réponse d’une autre sur une même transaction.

Interopérabilité

Est-il possible à plusieurs smart-contract ou même à plusieurs réseaux de “parler ensemble” ?

Fabric

Le noeud d’une organisation peut invoquer des chaincodes de différents channels mais également de plusieurs Orderers : deux réseaux peuvent donc potentiellement se connecter.

Néanmoins, on remarque que le transfert d’un asset d’un channel à un autre requiert l’aide d’une tierce partie de confiance, car les channels ne sont pas directement interopérables.

Il semble d’ailleurs qu’une communication inter-channels n’a encore jamais été mise en place.

Corda

On trouve deux types de réseaux dans Corda:

Compatibility zone : Elle permet l'interopérabilité entre plusieurs pairs Corda en définissant des standards techniques. Il faut demander l’accès à une autorité de certification pour entrer dans cette zone. Chaque zone contient des paramètres réseaux tels que la version minimum de Corda, les Notary disponibles, la taille maximale de message, etc.
Business Network : C’est une représentation logique, dans laquelle plusieurs participants s’échangent des actifs ou des informations. Il définit la gouvernance et les règles d’opération de ce réseau en s’articulant autour d’un besoin métier. Plus de détails ici.

Dans une même compatibility zone, un asset peut être transféré à travers plusieurs business networks de façon atomique. La mise en évidence de ces deux types de réseau révèle un souci d'interopérabilité. Même s’il ne faut pas oublier qu’une organisation doit accorder un degré de confiance aux Notary, cette interopérabilité par design est un critère en faveur de Corda.

Haute disponibilité

Si la haute-disponibilité n’est pas un besoin des DLT publiques, car l’information est répliquée, elle l’est pour les DLT à destination des entreprises et leur transfert point-à-point. Rappelons que ces systèmes peuvent transférer de la valeur.

Nous allons mettre en lumière leur capacité à avoir une haute disponibilité de façon macro, sans parler de l’implémentation ni de la qualité de service attendue.

Fabric

Pour rappel, chaque noeud Fabric reçoit toutes les nouvelles transactions d’un channel.

Pour assurer une haute disponibilité, une solution simple est la mise en place d’un cluster de peers qui représentent une même organisation, en utilisant les endorsement policies****.

Par exemple, pour deux peers, il faut donc mettre en place la validation des transactions par les endorsers d’un même chaincode de la sorte :

(Party1.peer1 OR Party1.peer2) AND (Party2.peer1 OR Party2.peer2)

De cette façon, nous avons une configuration actif-actif en utilisant deux noeuds distincts directement insérés dans le réseau, car seulement la validation d’un des deux noeuds est valide. Le deuxième noeud recevra la transaction dans la mesure où il fait partie du réseau.

Corda

Une haute disponibilité Actif-Passif semble être facilement réalisable, explicitons l’architecture de Corda.

Corda stocke toutes ses transactions et états dans une base de données relationnelle. AMQP est utilisé comme protocole d’échange : Corda embarque donc un broker MQ Artemis qui stocke sa file de messages sur le système de fichier. Il est donc possible de mettre en place cette architecture assez rapidement dans une infrastructure Cloud, comme le présente le schéma ci-dessous :

https://medium.com/corda/high-availability-for-r3-corda-nodes-bbdc6d92a156

Dans cette architecture Actif-Passif, il y a un seul noeud actif. En cas de panne de celui-ci, les nouvelles connexions seront redirigées vers un second noeud. Ce second noeud récupère le système de fichier et se connecte à la même base de données. Cependant, les écritures effectuées durant la panne du 1er noeud peuvent être perdues car le broker MQ, qui est embarqué (Artemis), ne peut pas encore être découplé du noeud.

Une architecture Actif-Actif semble néanmoins plus compliquée car la consistance à terme ne nous convient pas ; nous manipulons ici des données critiques. Cela requiert donc une base de données en écriture multi-master avec une cohérence forte ou l’utilisation par exemple de Google Spanner (qui permet une forte cohérence même en haute disponibilité).

Conclusion

Au sein d’un même réseau, Corda permet une gestion fine de la confidentialité mais également l’interopérabilité entre plusieurs applications métiers.

Il semble plus à même de partager des assets et comporte les fonctionnalités nécessaires à un échange sécurisé de données entre organisations, tout en s’intégrant assez bien au système d’informations.

Fabric, de son côté, est utile pour le partage d’informations au sein d’un consortium, mais son architecture rend le partage d’assets inter-consortium plus compliqué à mettre en place et ne permet pas de gestion de la confidentialité au niveau transactionnel, frein inhérent à l’approche orientée exécution de la plateforme.

Sources :