La Blockchain est-elle le futur du big data et du machine learning ?

This article is also available in english.

La popularité de la blockchain ayant explosée récemment par l’effet de mode des ICO’s, on en mange à toutes les sauces. Malheureusement elles ne sont pas toutes du meilleure goût. Prenons conscience de la puissance de cette technologie et de tout ce qu’on pourrait construire d’utile avec elle avant que le trading de crypto ne la tue.

Pour les non initiés (de moins en moins nombreux), rappel sur les concepts de blockchain et smart contract :

  • Blockchain : le principe de base est simple. Un premier block de donnée est utilisé pour initialiser la chaîne. Ce block est diffusé sur un réseau de nœuds (des serveurs) qui s’occupent d’écrire des données dans la chaîne. Chaque block suivant contient le hash (une référence) du block précédent, ainsi que d’autres données (n’importe quoi, tant que ça respecte la taille maximale d’un block). Les serveurs de lecture/écriture sont souvent appelés des mineurs (du fait du consensus d’écriture utilisé dans la majorité des chaines, le Proof Of Work). Ils sont la plupart du temps rémunérés pour leur travail, c’est à dire la résolution d’un algorithmes qui prouve que la transaction est validé sur le réseau.
  • Smart contracts : les smart contracts sont une évolution du système précédent. Chaque transaction est associée à une portion de programme qui se déclenche en général lors de l’écriture de la donnée. Ce code peut réaliser différentes choses, c’est relativement ouvert. Par exemple on peut vérifier la cohérence de l’écriture par rapport à d’autres blocks ou appeler une api. En général, on vérifie surtout que l’échange a bien été réalisé pour lancer un paiement.

Ci-dessous quelques schémas qui résument assez bien ces principes :

Peut de projets exploitent réellement l’essence même de la blockchain : une base de donnée décentralisée, historisée par nature, inaltérable. Plus possible de modifier des registres pour les corrompre.

Décentralisée, il n’y a plus besoin de s’occuper de réplication, de sauvegarde. Tous les nœuds font vivre la chaîne. Tout le monde accède facilement à la donnée, tout le monde peut y contribuer.

Les smart contracts et les différentes technologies de blockchain facilitent la mise en place de process de validation de lecture et d’écriture plus complexes, avec potentiellement des triggers événementiels pour prévenir lors de l’ajout d’une donnée.

Un suivi des données grâce à la suite de blocks se crée naturellement, ce qui facilite le suivi d’un produit ou d’un incident par exemple. On peut même au sein d’un block en référencer un autre qui ne serait pas le précédent, mais qui aurait un lien métier afin de tisser un maillage plus complexe.

Ci-dessous un exemple de la décentralisation des banques avec une blockchain. La banque centrale y est absente, elle n’est plus nécessaire.

Historiquement les entreprises étaient frileuses de diffuser leur données publiques. Aujourd’hui avec l’avènement du machine learning, l’open data est le nouvel objectif dans de nombreux secteurs, notamment dans le public avec les transports et la santé. Tout cela poussé par des initiatives comme celles de M Macron.

Mais que d’efforts et de dépenses pour en arriver là ! Toutes les sociétés s’acharnent à extraire leurs données historiques dans des portails open data custom, avec le développement de nouvelles api coûteuses, qu’il faut maintenir, documenter,… À l’échelle mondiale, c’est un travail de titan, qui coûte des fortunes, et qui ne fait que complexifier les échanges et la récupération de données.

Pourquoi ne pas utiliser une blockchain pour diffuser ces données ? Un cas d’usage souvent cité est celui de la santé. La diffusion dans une blockchain de ces données aurait beaucoup d’avantages :

  • Suivi d’un patient entre différents établissements, dans le monde entier
  • Uniformisation des formats de données médicales
  • Historique des maladies d’une personne
  • Un dossier médical inaltérable
  • Accès pour la famille au suivi d’un proche

Les possibilités sont presque infinies, et il est évident qu’à grande échelle une telle organisation ne pourra exister sans décentralisation : le nombre d’acteurs en jeux rend cette mise en place impossible.

Et si le monde entier écrivait dans des blockchain ? Tous les objets IOT ? Si tous les pays fournissaient des nœuds pour un réseau gigantesque ? On aurait alors accès à un énorme Data lake mondial !

Megalo et utopique vous dites ? Soyons honnête : aujourd’hui toutes les grandes puissances ont des services d’espionnage qui récoltent toutes les données qui circulent sur internet. Le Pentagone bénéficie même de l’aide de Google pour traiter ses vidéos de drones. Entre ça, les hackings quotidiens de serveurs, les récents scandales Facebook et Cambridge Analytica et j’en passe, l’utopie c’est de croire que nos données peuvent encore être protégées. Ce temps est révolue. A moins que vous ne viviez dans une grotte sans smartphone ni internet, vous existez ou existerez sur internet que vous le vouliez ou non.

Pourquoi alors ne pas proposer la majeure partie des données librement ? Bien entendu, elles seraient anonymisées. Les données sont comme du minerai aujourd’hui pour le machine learning, tout le monde en cherche pour trouver de nouveaux cas d’usage. Si une part importante de ces données devenait publiques, il y aurait beaucoup moins de tentatives d’en récolter illégalement. Même anonymisées, ces données auraient une valeur énorme, surtout si elles étaient formatées au sein d’une même blockchain et disponibles mondialement.

Actuellement il existe un réel problème pour un tel système mondial, c’est le coût d’un tel système. Comme très bien expliqué dans cet article, injecter de grandes quantités de données dans une blockchain publique de type ethereum coute une fortune, du fait du prix des transactions à régler, et du stockage infini de la donnée :

Estimation par IPDP

Utiliser une blockchain comme HyperLedger résout une partie du problème, de part la méthode de consensus utilisée PBFT, qui permet de ne pas avoir de fees à payer pour écrire dans la chaine. Les noeuds écrivent dans la chaine grâce à un système basé sur la rumeur, qui évite de plus d’avoir des calculs serveurs inutiles.

Reste le problème du stockage : au fil du temps, la chaine grossit de plus en plus, nécessitant des machines pour les noeuds capables de gérer cet historique. Le risque pour le réseau est de ne plus avoir que quelques noeuds avec cette capacité, les autres noeuds ne disposant que d’une partie de la chaine pour valider des transaction récentes. On retomberait alors dans un système certes décentralisé, mais pas distribué.

Heureusement, différentes techniques sont en cours de développement ou existent déjà pour pallier à ce type de problème :

  • State Tree Pruning : cette technique consiste à ne conserver que les derniers blocks utiles au fonctionnement du réseau dans les noeuds. Si les blocks sont inutilisés ou trop vieux, on ne les conserve pas dans l’historique des noeuds classiques. Seules certains master nodes conservent cet historique.
  • Sharding : le principe du sharding est de découper l’historique en plusieurs sous ensembles. Cela permet d’avoir des noeuds dédiés à ces ensembles, qui nécessitent donc moins d’espace de stockage. Il existe toujours des masters nodes, mais leur fonction est de vérifier la cohésion de l’ensemble, et non plus de gérer toutes les transactions et leur contenu.
  • Channels : sur le système HyperLedger, les channels permettent de séparer les transactions par thème dès leur création. Les noeuds n’ont donc pas besoin de gérer tous les channels, seulement ceux auxquels ils sont abonnés. Cela réduit d’office la taille de la chaine à gérer.

On ne va pas faire l’autruche, il existe bien des problématiques fortes liées à ce type de réseau mondialement ouvert. Mais il s’agit plus de réglementer des usages que de limiter les données. Un exemple évident serait les dérives possibles dans les métiers des assurances ou des banques.

Entraîner des systèmes pour détecter si un individu sera en capacité de rembourser un emprunt en fonction de son état de santé par exemple serait totalement immoral. Malheureusement ce type de pratique existe déjà, et ce n’est pas un verrouillage des données qui pourra l’en empêcher : seul une réglementation stricte et une transparence totale des organismes permettra d’éviter ces dérives.

Le business, ce n’est pas que la data, c’est aussi le service. Et aujourd’hui proposer un service de qualité qui contienne de façon unifiée les informations, c’est ce qu’attendent les utilisateurs. Pourquoi se limiter à afficher les moyens de transport de sa société de bus quand on peut y ajouter le transport public et les concurrents ? Si votre app est la meilleure, elle sera utilisée, c’est là que vos clients seront. Penser que parce que vous avez le contrôle de vos données vous donne le monopole de son business est une erreur. Cela ne fera qu’inciter les scrappers à polluer le traffic de votre site avec des robots.

Citymapper propose maintenant son propre service de bus. A la base Citymapper n’a pas de données propre, ce n’est qu’un aggrégteur et fournisseur de trajets. Un nouveau business s’est créé chez eux.

Google, agrège toutes les données de transports dans Maps pour y attirer des utilisateurs. Au final, le produit est Maps qui est un produit complet, grâce au travail de Google sur les données.

C’est le sujet qui fâche en ce moment, notemment avec les règlementations GDPR qui arrivent à grand pas, le scandale Facebook Cambridge Analytica et consorts. Certes les données des utilisateurs devront être anonymisées. Mais elles resteront une source de donnée très intéressante à croiser avec d’autres données business.

Un autre cas d’utilisation pour le grand publique pourrait être la validation d’informations de type ‘rumeur’. Les nœuds de la blockchain permettent de valider une transaction via différents algorithmes. On pourrait imaginer la création d’une donnée propagée et validée par plusieurs utilisateurs.

Prenons l’exemple d’un train en retard. Un utilisateur demande à inscrire cette donnée dans la chaîne. Tant que 5 utilisateurs ne confirment pas la donnée, elle n’est pas validée. Cette donnée pourrait être croisée avec celles de l’information voyageur du transporteur officiel par exemple.

Image associée

Hashgraph, basé sur le protocole Practical Fault Tolerance Byzantine, pourrait être une technologie intéressante pour ce type de use case :

Imaginez une IA branchée sur ce Gigantesque data lake où tous les objets et événements pourraient voir un lien. On pourrait lui apprendre à relier des blocks d’informations sans lien de prime abord, et d’y découvrir des corrélations cachées. Et qui sait peut-être prédire l’avenir ? On y verrait sûrement apparaître des patterns d’effet papillon, où un incident isolé déclenche plusieurs actions à plus grande échelle.

Fullstack software engineer @Oui.sncf. I love discovering new technologies. Tech is as important as his usage.

Fullstack software engineer @Oui.sncf. I love discovering new technologies. Tech is as important as his usage.