Blockchain : les détails techniques du projet d’IBM et d’A.P. Møller-Mærsk

Hyperledger dans le Cloud (et bientôt sur site)

Il restait à savoir, concrètement, si toutes ces entités allait héberger un nœud chez elles. D’autant plus qu’Hyperledger – la blockchain portée par IBM et la Linux Fondation, entre autre - n’est pas connue pour être la plus simple à déployer.

« Actuellement, tous les nœuds sont sur IBM Cloud », nous précise Aaron Lieber, Program Director, Offering Management de la division Blockchain Trade Solutions chez IBM.

Sur le papier, l’idée est bonne car elle permet de s’affranchir de la complexité de la mise en œuvre d’un nœud sur site, en local, par ses propres moyens. Mais dans l’esprit, recentraliser l’architecture sous-jacente d’une couche censée être distribuée pose question.

« Ce n’est pas la simple distribution géographique qui compte – entendons par là le fait d’avoir des nœuds blockchain fonctionnant sur plusieurs serveurs distants - mais l'indépendance des entités qui les gèrent », soulignait Damien Lecan de SQLI.

IBM semble avoir pris ce point en compte, en tout cas partiellement. « Nous travaillons en vue d'offrir la possibilité d'exécuter un réseau hybride où chaque propriétaire de nœuds (NDR : chaque participant) a le choix de gérer son propre nœud ou de le faire tourner sur le Cloud d'IBM. Dans les deux cas, le propriétaire a le contrôle administratif complet du nœud ».

L’option de faire tourner ce nœud sur un cloud tiers reste possible (Microsoft propose par exemple Hyperledger sur Azure) mais ne bénéficiera a priori pas du même accompagnement qu’IBM propose dans son PaaS.

En revanche, il y a fort à parier que pour les déploiements sur site, Mærsk et IBM proposeront des nœuds « clefs en main », pré-déployés - dans des appliances par exemple - qu’il ne restera « plus qu’à » configurer.

Un enregistrement des sources des informations…

L’autre question initialement sans réponse concernait la nature des informations qui seront stockées dans cette blockchain. Par définition, un registre n’est pas fait pour stocker de grandes quantités de textes – comme la documentation administrative d’un conteneur. Un registre est fait pour lister des transactions.

« Actuellement, nous n'utilisons la blockchain que pour la gestion des documents commerciaux et des flux de processus associés ("Paperless Trade"). Nous travaillons également à l'intégration des événements du transport », nous précise Aaron Lieber. « De façon générale, notre intention est de permettre à tous les membres du réseau d'expédition d'écrire dans le registre et d'être transparents avec les autres au sujet de la personne qui a écrit l'information et du moment où elle l'a écrite. »

Quant à la vérification des données, IBM ne prévoit pas de coder un smart contract complexe pour automatiser les consensus ni de faire appel à des oracles pour en valider la véracité via des capteurs, des portails RFID ou des balises GPS.

« Nous prévoyons de laisser les participants du réseau porter leurs propres jugements de valeur sur les sources d’information », confirme le porte-parole. « Par exemple, si un terminal maritime et une compagnie maritime écrivent tous les deux un événement dans le registre indiquant qu'un conteneur particulier a été déchargé d'un navire, les deux événements seront consignés dans le registre ainsi que des renseignements sur leurs auteurs. Notre but n'est pas de porter des jugements de valeur sur les sources de données, mais plutôt de fournir un enregistrement partagé et immuable sur qui affirme avoir fait quoi, et quand ».

… mais pas de la documentation

Les documents administratifs, eux, restent en dehors de la blockchain. Ils y sont en revanche « rattachés » via leur hash qui lui, est, stocké dans la blockchain (sur le même modèle que l’offre de Docapost).

« L'accès au document, stocké hors blockchain, se fait par le biais d'APIs. Lorsqu'un document est récupéré, le hash est vérifiée et comparée à celui stockée dans la blockchain », complète Aaron Lieber.

L'objectif d’un tel montage est « d'améliorer les performances » et de « réduire l'empreinte de la blockchain ».

L’option fait sens. Ceci étant, la contrepartie de cette solution est qu’elle rajoute de la complexité et qu’il faut stocker le(s) document(s) à un endroit sécurisé, identifié et ne pas les faire bouger ailleurs pour une raison ou une autre. Sauf à utiliser une autre API et à modifier la blockchain, ce qui aboutit à un paradoxe.

IBM et Mærsk dans le même bateau (pour un voyage au long cours)

Au final, on rappellera que le succès d’un projet entre co-opétiteurs réside - aussi -dans la capacité à mettre tout le monde autour d’une table et à prendre une décision commune alors que jusque-là les participants n’avaient pas souhaité – ou eu l’idée - de le faire.

Le poids de Mærsk dans l’écosystème du transport maritime est donc un atout majeur pour IBM dans son évangélisation de la blockchain dans le secteur.

L’étape suivante sera de convaincre les acteurs – TOUS les acteurs – que Hyperledger est la bonne blockchain. Il n’est en effet pas possible de déployer des nœuds sous des blockchains différentes (un nœud sous Hyperledger, un autre sous Ethereum par exemple). Cette uniformité nécessaire, et imposée, est en soit un autre obstacle majeur à l’aboutissement de tout projet de ce type.

Bref, avec leur blockchain, IBM et Mærsk ont embarqué pour un projet au long cours.