Nous avons vu dans un article précédent la présentation des grands principes de Corda, le DLT (Distributed Ledger Technology) développé par le consortium R3. Utilisé en très grande majorité par des banques, Corda semble répondre à de nombreux besoins non assouvis par les blockchains publiques. Nous allons désormais tâcher d’explorer les limites de Corda.
À question directe … réponse directe : non. Corda n’est pas une blockchain.
Ok, mais, pourquoi ? Tout simplement parce que le registre Corda n’est pas stocké sous forme de blocs, donc pas de chaîne de blocs possible.
Mais alors, si ce n’est pas une blockchain, ce n’est pas intéressant ? C’est beaucoup plus compliqué que ça…
Certes, ces deux dernières années, le mot ‘blockchain’ fait le buzz, y compris dans les médias généralistes, notamment suite à l’envol de la valeur de certaines crypto-monnaies. Pour autant, pour l’immense majorité des entreprises et tout particulièrement des banques, tout ce qui touche aux crypto-monnaies est bien loin de leurs intérêts premiers, et on parle plus volontiers de DLT (Distributed Ledger Technologies). Les DLT forment un ensemble de technologies qui englobent les blockchains, bien plus large que simplement Bitcoin ou Ethereum.
Pour autant, la communication autour de Corda, principalement par le consortium R3, a entretenu un certain flou sur la question depuis les origines. Et ce flou perdure ! Lorsque l’on se rend sur le site officiel de Corda, la baseline du logo est claire :
Pour autant, la polémique ne date pas d’hier, puisque déjà en 2017 R3 publiait un article sur son blog pour expliquer que le problème est plus de l’ordre de la sémantique que de l’architecture. Il semblerait donc que le terme de ‘blockchain’ soit ici utilisé comme un raccourci pour ‘DLT’, avec une composante marketing indéniable. #buzzword
Comme nous l’avons vu dans l’article de présentation, pour rejoindre un réseau Corda il faut fournir son identité à un doorman qui autorise l’accès et fournit les certificats nécessaires. Ce doorman peut révoquer une identité (dans le cas du retrait d’un participant au sein d’un consortium par exemple). Mais ne serait-ce pas là une porte ouverte à la censure ?
Tout dépend de qui gère ce service central. R3 a récemment annoncé la création de la “Corda Network Foundation”, une entité à but non lucratif en charge de gérer le réseau mondial Corda. Donc une seule entité va être chargée de gérer un réseau soi-disant décentralisé… Heureusement, l’aspect non lucratif garantit une certaine résilience à la corruption par exemple.
Pour autant, si l’on craint une certaine centralisation du ‘pouvoir’, il est toujours possible de créer son propre réseau privé, avec sa propre gouvernance et ses propres règles. Donc inutile de paniquer, la solution existe.
Il existe deux versions de Corda : la version Community, totalement open-source et dont le code est disponible sur GitHub, et une version Enterprise, pour laquelle il faut faire une demande à R3 pour obtenir les exécutables.
Il s’agit là d’une différence majeure : on récupère des exécutables et non pas du code source. Même en considérant que la majorité du code de “Corda core” est similaire dans les deux versions, la brique “firewall”, argument principal justifiant la valeur de la version Enterprise, est totalement opaque. Difficile de savoir comment est assurée la sécurité via ce firewall…
Actuellement, les nœuds de type ‘notaire’ d’un réseau Corda proposent deux modes : *validating *et non-validating. Lorsqu’ils sont non-validating, ils ne procèdent qu’à une seule vérification : la double dépense. En revanche, en mode validating, le notaire va inspecter le contenu de la transaction pour le valider, selon le protocole de consensus choisi (RAFT ou BFT disponibles).
Toutefois, sur le réseau d’UAT fourni par R3, seul le mode non-validating est actuellement disponible, ce qui diminue l’intérêt des notaires. Cela s’explique par des besoins de performances qui ne semblent donc pas encore au rendez-vous avec le mode de fonctionnement cible.
À noter que les notaires jouent tout de même un rôle intéressant en étant des témoins supplémentaires des transactions, notamment en permettant d’horodater de manière univoque celles-ci.
Corda étant vendue comme une solution tournée vers les entreprises, tout laisse à penser que son intégration a été prévue pour s’imbriquer sans souci dans le SI des grandes banques qui constituent le consortium R3. Malheureusement, la réalité n’est pas aussi rose…
Alors évidemment, la notion même de peer-to-peer est antinomique de ce que font les banques. Par exemple, pour convaincre les équipes de sécurité d’accepter de nouveaux flux considérés comme ‘exotiques’ dans leur SI, il est nécessaire de travailler de concert dès le lancement des initiatives Corda.
Une fois les validations obtenues via les équipes d’architecture technique et de sécurité, encore faut-il s’attaquer à la réalisation technique. Malheureusement, la documentation de Corda Enterprise (légèrement différente de celle de Corda open-source) n’est pas parfaitement auto-porteuse. De nombreux allers-retours sont nécessaires avec les équipes de support et de déploiement de R3.
Par exemple, si un flux n’est pas documenté par R3, l’impact temporel sur un déploiement peut être assez conséquent : toutes les étapes de documentation, de validation et de mise en pratique sont parfois longues.
Pour autant, Corda reste une solution très tournée vers le monde des entreprises sécurisées. Évoquons notamment Hyperledger Fabric qui utilise des flux gRPC (Remote Procedure Call, développé initialement par Google), alors qu’il n’y a actuellement pas de WAF (Web Application Firewall, chargé de protéger le serveur applicatif) en mesure d’analyser ces flux qui contiennent de surcroit de nombreuses failles CVE identifiées. Idem par rapport à Quorum qui ne comporte pas de brique firewall, donc avec tout le traitement dans la même zone réseau.
En guise de conclusion, précisons tout de même que le but n’était pas de critiquer unilatéralement cette solution, mais bien d’examiner des axes d’amélioration ou des contradictions dans la communication officielle.
Si Corda est une solution DLT encore jeune et prometteuse, elle n’en a pas moins de nombreux challenges à relever. Améliorer son intégration aux SI existants, avoir une documentation à jour, clarifier sa nature (blockchain vs. DLT) … les pistes sont nombreuses !
De plus, pourquoi ne pas aller un cran plus loin et imaginer une solution interopérable avec d’autres DLT, pour devenir une brique incontournable d’un système décentralisé ? Si les blockchains actuelles ne sont pas interopérables, Corda aurait tout à y gagner, pour se démarquer plus fermement sur un marché (déjà) concurrentiel.
La documentation a été pointée comme lacunaire, toutefois il faut noter un effort certain de transparence avec la page “Tradeoffs” qui liste les points sur lesquels des concessions ont été faites. Parmi ces concessions, on relèvera un point : R3 encourage à doubler les contrats en code par des contrats sur papier. Un comble pour une solution censée désintermédier les échanges de ses participants ! En opposant “Code is law” et “Existing legal systems”, R3 trahit en fait une réalité : les entreprises et les réglementations en vigueur ne sont pas encore prêtes à reposer uniquement sur du code.
Si le produit n’est pas fini, avec une roadmap encore floue, il n’en est pas moins en constante (r)évolution, réagissant aux demandes de ses clients, grâce à une équipe de développeurs très investis, réactifs et heureux d’échanger avec les utilisateurs finaux.
Au-delà des difficultés initiales, Corda devrait réussir à repousser ses limites et s’assurer un avenir plus radieux dans le monde bouillonnant des blockchains et DLT !
Cet article fait partie d’une série sur Corda, commencée par R3 Corda : Présentation.
Cet article a initialement été publié sur Medium.