Mise en place d’une blockchain classique

a) Mise en place du modèle d’IdO

Le modèle présenté précédemment propose d’évaluer la contribution de chaque passerelle, en charge de collecter les données provenant de leurs objets (capteur/actionneur), de les traiter si besoin, pour ensuite les propager sur le reste du réseau et/ou les utiliser pour créer des services. Lorsqu’il est question d’évaluer une donnée, plusieurs aspects peuvent être pris en compte, comme sa taille, sa précision, sa viabilité ou encore la valeur ajoutée qu’elle apporte dans l’écosystème. Toutefois, une première approche pour évaluer la contribution des passerelles, consiste à certifier de manière unanime, décentralisée et sécurisée, la quantité de données qu’elles produisent et partagent sur le réseau. En fonction de cette dernière, les passerelles peuvent accéder à différents types de ressources, services ou données. Bien que cette vision semble à première vue limitée, elle offre néanmoins une excellente preuve de concept permettant de valider ce type de modèle pour l’IdO, à savoir la monétisation de la donnée. Les différents aspects évoqués plus haut entreront progressivement en compte, afin de perfectionner le modèle.

b) Modèle de transactions de la blockchain

Avant tout, il convient de préciser que cette section traite uniquement les transactions en lien avec la blockchain et non celles de l’application IdO en elle-même (e.g. transmission de données capteurs).

Deux modèles de transactions sont utilisés dans les blockchains actuelles : les UTXO et les comptes/soldes (Account/Balance model) [128] comme Bitcoin [114] et Ethereum [117] respectivement. Les UTXO constituent un historique complet de transactions, les unes liées aux autres, offrant une traçabilité remarquable (e.g. Alice transfère à Bob, qui transfère à Carole, etc.). Toutefois, dans un contexte d’IdO, chaque donnée transmise n’est pas forcément dépendante de la précédente. Par exemple, la valeur de température d’une pièce ne dépend pas de sa valeur précédente. De plus, ce modèle requiert une conservation totale et définitive de toutes les anciennes transactions, pour s’assurer de la validité des suivantes. Étant donné l’intensité des communications attendues dans le contexte de l’IdO mais aussi l’espace de stockage limité des passerelles, l’approche UTXO ne semble pas adaptée. À l’inverse, un modèle de compte, contenant le solde actuel d’une entité, est plus flexible quant à la suppression d’anciennes transactions. En effet, bien que l’historique complet assure l’inviolabilité du solde, le lien entre les précédentes valeurs du compte est moindre que précédemment. Il peut donc être plus facilement envisagé de supprimer une partie de l’historique permettant ainsi une diminution de l’espace de stockage requis.

c) Génération de blocs et consensus, 1ère _approche

En accord avec le modèle d’IdO choisi, une passerelle est récompensée en fonction de la quantité de données qu’elle produit/partage. Cela doit faire l’objet d’un consensus, afin que l’ensemble de l’écosystème ait la même vision. Comme dans le scénario des transferts d’argent d’Alice (cf. 3.2.2.c), effectuer cette procédure pour chaque transaction de donnée n’est pas envisageable, pour des raisons d’efficacité. Une solution simple à mettre en œuvre consiste à déterminer un seuil de quantité au bout duquel la génération d’un bloc sera déclenchée, ainsi que le consensus. Toutefois, en raison du nombre important de transferts de données dans un écosystème d’IdO, mais aussi de la latence du réseau, chaque passerelle ne reçoit pas toutes les informations en même temps ni dans le même ordre. Pour limiter ce phénomène, une légère modification à la solution proposée s’impose. Le seuil ne s’applique pas sur l’ensemble des données, toutes confondues, mais sur chaque groupe émetteur – type de données. Par exemple, pour un seuil fixé à 10, si les passerelles A et B publient respectivement 10 et 4 valeurs de température, seules celles de A seront prises en compte dans le prochain bloc. Celles de B seront traitées dans le suivant, si le seuil est atteint. Ce système exige donc de stocker toutes les transactions. Cependant, il convient de signaler que ce stockage est d’une part que temporaire (attente de confirmation du bloc), et potentiellement déjà présent pour le fonctionnement de l’application IdO embarquée.

À partir du modèle de ses transactions, un bloc contient les mises à jour des comptes des passerelles, sur lesquels un consensus doit être atteint. La transparence étant de rigueur dans une blockchain, chaque bloc doit contenir la justification pour toute nouvelle valeur des comptes (e.g.

justifier que « A a bien publié 10 valeurs de température »). De plus, les passerelles ne publient pas uniquement un seul type de données (e.g. température, pression, etc.), et il se peut que plusieurs d’entre elles atteignent le seuil simultanément. Encore une fois, à cause de la latence certaines entités du réseau peuvent être en décalage par rapport à d’autres. C’est pourquoi il est primordial d’indiquer précisément quels jeux de données sont pris en compte. Une méthode efficace consiste à appliquer une fonction de hachage (e.g. SHA-256 [225]) sur ces données, associées à l’identifiant de l’émetteur (A), et à la date de publication de chacune d’elles. Cela assure l’intégrité des informations, tout en constituant une preuve. La Figure 3-20 illustre la composition d’un bloc.

Figure 3-20 - Composition d’un bloc

L’empreinte du bloc est générée à l’aide du PoW [114], algorithme de consensus de Bitcoin, mais ici avec une faible difficulté dans le but de dissuader la publication de blocs frauduleux, comme le font Nano [119] et IOTA [118]. Pour rappel, cela consiste à calculer l’empreinte du bloc, en fonction de ses informations et d’un nombre aléatoire, de sorte que cette dernière respecte un format particulier. Par exemple, elle doit débuter par un certain nombre de 0. Cette opération a un coup en termes de puissance de calcul et d’énergie, qu’il convient de dimensionner pour être suffisamment important pour dissuader un comportement malveillant, sans être pénalisant pour le reste du système. Une fois l’empreinte calculée, le bloc est inscrit dans la blockchain locale de la passerelle et transmis sur le réseau.

d) Consensus, 2ème _approche

Bien qu’une première approche basée sur le PoW léger soit intéressante, elle apporte son lot d’inconvénients, à savoir son manque de finalité. En effet, en raison des imperfections du réseau, plusieurs blocs créés en même temps, faisant donc référence au même prédécesseur (i.e. « hash précédent »), peuvent arriver dans un ordre différent aux passerelles, causant l’apparition de forks qu’il convient de résoudre (cf. 3.2.5.h)). Naïvement, il serait tentant d’augmenter le temps de génération d’un bloc, de sorte à réduire la probabilité que plusieurs d’entre eux soient publiés en même temps. Toutefois, cela implique une augmentation de la latence et donc une perte de réactivité du système. Une autre approche consisterait à synchroniser parfaitement chaque entité du réseau.

Malheureusement, cela s’avère être impossible, notamment sur vaste réseau tel que l’IdO [254]. En conséquence, comme dans Bitcoin [114] et Ethereum [117], la présence de forks engendre une latence de confirmation sur l’acceptation et sur l’ordre définitif des blocs, non appropriée à un contexte d’IdO. De plus, le caractère sécurisé du PoW réside dans la difficulté de génération des blocs, ce qui, aux vues des ressources limitées des passerelles, ne peut être très complexe. De ce fait, un autre algorithme de consensus doit être envisagé. Pour remédier à ces problématiques, un système de votes à la majorité permettrait, comme évoqué dans la section 3.2.5.h), de valider immédiatement un bloc. De plus, la sécurité serait cette fois liée à la taille du réseau, et donc au nombre de participants. En effet, plus il y a de votants, plus le seuil permettant d’atteindre la majorité est grand, rendant plus difficile sa manipulation, et augmentant la confiance dans le réseau. D’autre part, cela constitue un nouveau critère de motivation d’évolution de l’écosystème.

La première étape de cette nouvelle approche reste la même que précédemment : les passerelles créent un bloc contenant l’empreinte du précédent, les mises à jour de comptes, les justificatifs, et la solution du PoW (cf. Figure 3-20), avant d’être transmis sur le réseau. En revanche ici, le bloc fait l’objet d’un vote explicite, avant d’être ajouté à la blockchain. Il ne peut être accepté que lorsque la majorité des passerelles (e.g. 2/3 du réseau), donne leur accord, en publiant des blocs identiques. Le premier bloc valide et atteignant la majorité prend alors place dans la blockchain, de manière unanime et définitive. De plus, la liste de toutes les passerelles ayant voté un bloc est inscrite dans celui-ci, en guise de preuve de majorité. La nouvelle composition est illustrée par la Figure 3-21. Enfin, l’empreinte définitive du bloc est calculée, en prenant en compte toutes ses informations.

Figure 3-21 - Nouvelle composition d’un bloc

Lorsqu’il est question de majorité, cela sous-entend d’être en mesure d’estimer le nombre de participants présents dans le système. Grâce à son modèle de compte, l’estimation s’avère triviale, car il suffit de parcourir la blockchain et de procéder à un comptage. Une possibilité serait d’ajouter le nombre de participants total dans chaque nouveau bloc, ce qui permettrait plus facilement de retrouver le seuil de majorité. Toutefois, cela exigerait une utilisation supplémentaire de l’espace de stockage, dont l’impact augmenterait avec la taille de la blockchain.

Cette seconde approche a le mérite d’assurer la validation unanime et immédiate de chaque mise à jour de compte, résolvant a priori le problème de forks. En revanche, tel qu’il l’est décrit, ce protocole comporte quelques inconvénients. Tout d’abord, en raison de la latence de propagation sur le réseau, la liste des passerelles formant une majorité peut être différente. Par exemple, dans un système constitué de 6 participants (nommés de A à F), une majorité peut être représentée par les votes de A B, C et D ou bien par C, D, E et F. Plusieurs listes sont alors possibles, résultant sur différentes empreintes de bloc, menant à nouveau à l’apparition de forks, bien que moins fréquente par rapport à précédemment. Autre point important, intrinsèque à un système de majorité : tant qu’un bloc ne récolte pas suffisamment de votes, il n’est pas ajouté à la blockchain. Dès lors, cela signifie que le système peut rester bloqué indéfiniment si aucune procédure n’est prévue. Il convient donc de prendre en considération ces éléments afin d’élaborer un algorithme de consensus adapté et efficace.