Ties.network un « LinkedIn » basé sur Ethereum


by

Ties.network et TiesDB

Dans le flux continu des projets blockchain et des différentes ICO qui sont lancées chaque mois sur des bases plus ou moins solides, Ties.network  a attiré mon attention en début d’année. Moins par l’objet du projet : la création d’un linkedIn distribué en tant que plateforme commerciales et business anonyme, mais bien par le défi technique sous-jacent. Alexander Neymark et Dmitry Kochin entendent en effet créer une base de données transactionnelle distribuée. En mars dernier je faisais un point sur les système de stockage distribués et dans mon article j’avais fait l’impasse sur les bases de données relationnelles décentralisées et notamment BigchainDB. Ties.network me permet aujourd’hui de compléter ce panorama.

Porté initialement sous le nom d’Übermensch le projet a été renommé Ties.network. Cette plateforme collaborative anonyme vise comme LinkedIn à mettre en relation des proils professionnels de manière anonyme ou pas mais va au-delà en étant également une plateforme de paiement et d’échange de crypto-monnaies qui permet d’abonder une budget projet pour payer les participants ou comme base d’investissement d’un groupe d’associés. Ties.network s’appuiera sur Ethereum pour totue la partie blockchain et ledger mais le projet avait besoin de disposer d’une base de données fiable, distribuée garantissant l’anonymat promis par par le réseau : TiesDB. Dans cet article je vous présente les bases de compréhension sur l’enjeu des bases de données distribuées vis-à-vis de la problématique de décentralisation.

Logo Ties.network

BDD distribuées et Ties.network

Principes théoriques

Tout d’abord revenons sur le théorème CAP et les propriétés ACID d’une base de données. Comme beaucoup d’ingénieur de ma génération j’ai toujours utilisé des bases de données classiques (SQL Server, Oracle, MySQL, PostgreSQL, etc.). Dans les années 2000, j’ai suivi la montée des bases de données objet et les problèmes de scalabilité, de load-balancing sans creuser vraiment la question. Puis est venue l’ère du NoSQL avec des projets comme MongoDB, Cassandra, Neo4j . Ce n’est qu’en attrapant le virus de la blockchain et avec les problématiques  de stockage de données distribuées afférentes que je me suis vraiment replonger dans le sujet.

Les Systèmes de Gestion de Base de Données Relationnelles (SGBDR) classiques ont été conçue pour garantir qu’une transaction informatique s’effectue de manière fiable. Pour rester dans notre univers Blockchain, l’idée et que le débit et le crédit de deux comptes impliqués dans une transaction bancaire vont s’effectuer en une seule transaction informatique quel que soit le nombre d’opérations intermédiaires impliquées. Dans le cas contraire le SGBDR revient à l’état antérieur (Rollback). Cette fiabilité se traduit par le respect des propriétés suivantes :

  • Atomicity : la transaction n’est pas sécable, elle s’exécute entièrement ou pas du tout et ce même en cas de défaillance physique du système (ex. panne matérielle)
  • Consistency : l’état du système avant et après la transaction doit être valide au sens des règles informatiques définies pour le système,
  • Isolation : les transactions doivent s’effectuer de manière totalement indépendante sans aucune adhérence entre elles. En somme si 3 transactions sont exécutées sur le système T1, T2 et T3 qu’elles s’effectuent de manière simultané ou dans n’importe quel ordre l’état final de la BDD sera le même.
  • Durability : une fois confirmée(validée pour écriture sur le disque dur) la transaction est enregistrée même en cas de panne système. En effet le temps d’exécution en mémoire vive versus le temps d’écriture sur le disque dur ne doit pas entraîner l’incohérence du système même en cas de coupure du courant.

Ces propriétés peuvent être assurer par les configuration matérielles sur un système unique (serveur de BDD) mais l’explosion de la quantité de données et la nécessité d’y accéder de manière décentralisée par un grand nombre d’utilisateurs a imposé la mise en place de systèmes distribués alternatifs. Dans un système distribué l’objectif est d’assurer la répartition des données et des traitements sur plusieurs configuration matérielles (et/ou logicielles) différentes. Ceci de manière à assurer que l’ajout d’une ressource au système (nœud) augmente de manière linéaire la capacité globale de celui-ci. On parle de scalabilité ou mise à l’échelle horizontale.

Pour décrire les contraintes et les possibilités d’un tel système on se réfère au théorème CAP. Postulé par Eric Brewer en 2000, le théorème CAP  pour  :

  • Consistency (cohérence ou Consistance des données) : tous les nœuds du système voient exactement les mêmes données au même moment
  • Availability (disponibilité) : toute requète reçoit une réponse, la perte de nœuds du réseau ne l’affecte pas, les données restent accessibles
  • Partition tolerance (tolérance au partitionnement ou morcellement) : seule la coupure complète du réseau peut le faire tomber, il peut-être diviser en sous-réseaux dont chacun peut fonctionner de manière autonome,

prédit que seules deux de ces trois propriétés peuvent être garanties sur un réseau de BDD distribué à un instant T.

Les SGBDR classiques afin de respecter les propriétés ACID sont des système AC (Availibility/Consistency) au sens du théorème CAP et de fait en général un site web par exemple va s’appuyer sur un serveur de BDD principal (il peut éventuellement être redondé mais du point de vue écriture il y a un seul point d’entrée). La répartition de l’écriture des données sur ces système (Partition) entraîne en général un effondrement des performances. Les bases des NoSQL répondent à ce problème de performance au prix de concession sur le modèle relationnel.

Les bases NoSQL

Que les habitués du SQL se rasssure NoSQL ne veut pas obligatoirement dire abandon du langage de requête le plus utilisé mais plutôt Not Only SQL et concrètement ce qui est abandonné c’est le modèle relationnel plus que langage de requête. Néanmoins des langages alternatifs existent car l’univers des BDD NoSQL n’est pas homogène. On distingue 4 types de BDD NoSQL qui répondent à des besoins différents et que je ne ferais que citer :

  • type colonne : ex. Cassandra, Hbase,
  • type document : ex. MongoDB, RavenDB
  • type Clé/valeur ex. Redis, Voldemort
  • type graphe : ex. Neo4j, OrientDB
  • type Objet : ex. Versant, VelocityDB

Pour une liste plus complète vous pouvez vous référer au site nosql-database.org
Du point de vue CAP les BDD NoSQL sont de type AP (Availability/Partition tolérance) ou CP (Consistency /Partition tolerance). Les GAFA sont à l’origine de nombre des architectures NoSQL qui sont particulièrement adaptées aux problématiques de Bigdata pour lesquelles ils sont en première ligne.
Parmi les bases NoSQL qui ont le vent en poupe en ce moment je citerais MongoDB, Cassandra ou encore RethinkDB (BigchainDB s’appuie dessus) Les bases NoSQL de ce type sont également disponible chez Amazon et Google en mode cloud avec respectivement les solutions DynamoDB et Datastore.
Ce qu’il faut retenir c’est la différence entre le fait que ces BDD sont un modèle distribué (physiquement décentralisé) mais pas décentralisé au niveau de la gouvernance. Dis autrement les solutions que nous venons de citer se réfèrent à une distribution physique de nodes qui se font confiance et sont opérés par une seule instance centrale. Nous sommes donc encore loin du modèle décentralisé de la blockchain

logos mongoDB et RethinkDB

BDD distribuées et Blockchain

TiesDB et Ties.network se placent dans une perspective de blockchain publique où les différents nodes ne se font pas nécessairement confiance. A ce jour le projet phare qui se situe dans la même perspective est BigchainDB. En quoi les deux projets se distinguent-ils et avant cela à quels besoins répondent-ils ?
Tout d’abord revenons très rapidement sur le stockage distribué du point de vue blockchain :

  • la blockchain elle-même qui est un un système de stockage d’information mais ne répond à aucune des fonctionnalités pratique demandé à un SGBD  traditionnel ou noSQL tout en répondant parfaitement à un objectif distribué et décentralisé par nature. Très concrètement, hors de question de stocker de gros volumes de données, pas de langage de requête performant, pas de performance en lecture/écriture etc ,
  • les systèmes de stockage de données distribuées associés aux blockchains. A savoir Storj, Swarm ou IPFS. Notamment IPFS qui est utilisé comme base de stockage pour des application blockchain comme Akasha. La principale différence est qu’IPFS n’est PAS une base de données mais un système de fichier et que donc l’information n’est pas structurée (pas de tables). Par contre on peut stocker de gros fichier dessus. De plus IPFS n’est pas associé directement à une blockchain. Swarm pallie à cette inconvénient mais reste un système de fichier.
  • les bases de données décentralisées qui proposent les attributs d’une base noSQL distribuée mais également décentralisée selon les même mécanismes que propose la blockchain. Ce sont donc des BDD de type AP au détriment de la cohérence car la limite des systèmes est la durée de propagation des mises à jour entre les nodes.

A ce jour bigchainDB est la seule solution viable répondant à la définition de base de données décentralisée. Cependant, selon l’équipe de TiesDB, BigchainDB  ne répond que partiellement à cette définition. Pour eux BigchainDB en l’état est plutôt une base de donnée « blockchainée » privée. D’où la proposition de TiesDB de venir combler ce vide en offrant une base de données totalement décentralisée et publique dont les nœuds sont indépendants et collaborent pour fournir un consensus de données. Comme pour une blockchain un mécanisme d’incentive est mis en place pour garantir l’intégrité du stockage dans le temps et la qualité de la recherche d’information. L’idée est de pouvoir construire des applications sur TiesDB comme on le fait aujourd’hui avec des bases de données NoSQL classiques sans le biais de centralisation. Quels sont les arguments de TiesDB par arapport à BigchainDB ? En fait TiesDB va tout simplement plus loin en terme de BDD distribuée publique :

  • TiesDB permet à n’importe quel utilisateur de créer sa propre structure de données (ses propres tables) et d’y accéder par son identifiant. BigchainDB,  quant à elle, contraint la structure de données à l’ensemble d’un cluster. Techniquement en effet BigchainDB peut-être vue comme une blockchain qui s’appuie sur une BDD distribuée (RethinkDB et MongoDB en cours) les deux sont corrélés mais distincts. De ce fait le cluster de réplique RethinkDB ou MongoDb partage la même structure de donnée
  • TiesDB est complètement décentralisée et n’importe qui peut participer et créer un node qui est une base de données par lui-même, a contrario il y a un biais de centralisation dans BigchainDB du fait que chaque node est connecté au même cluster de données privé. En effet imaginons que nous ayons plusieurs serveurs répliques et qu’un des serveurs soit compromis et lance une commande d’effacement de table (Drop table), cette commande sera répliquée sur l’ensemble du cluster. Celui-ci doit donc être privé (ergo centralisé) pour garantir la sécurité.

Il y a un débat  sur ce biais de centralisation dans BigchainDB et le projet promet d’y répondre à terme mais TieDB intègre cette notion dans son concept même d’où son intérêt. Pour résumer voici comment Ties.network compare TiesDB à BigchainDB :

comparatif TiesDB BigchainDB

En attendant que les promesses de TiesDB soient tenues, j’aimerais terminer cet article en insistant sur l’intérêt que représente une BDD distribuée et décentralisée. Là où la blockchain offre un environnement d’exécution non censurable et non contrôlable, TiesDB promet l’équivalent en base de données en mariant le meilleur de la BDD et de la décentralisation blockchain. Au delà de l’application Ties.network qui permet une implémentation réelle de TiesDB le cœur et l’intérêt du projet reste essentiellement la réussite du développement de cette BDD qui viendra s’ajouter à la stack du Wb3.0 décentralisé.

Nous verrons comment réagi la communauté lors de l’ICO du 21/09/2017 ce sera un bon indice de la crédibilité et du potentiel du projet qui sur le papier suscite déjà un très large intérêt.

 

Share

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.