Mécanismes de validation de transactions

Modèles de communication publications/abonnements

Le système de publications/abonnements (Pub/Sub : Publish/Subscribe) est un service de messagerie asynchrone, simple et puissant pour les communications entre machines. Pub/Sub permet aux consommateurs de données (Subscribers) de s’abonner à des canaux spécifiques, appelés topics auxquels les producteurs de données (Publishers) envoient des données générées en temps réel. Un courtier appelé Broker est responsable de faire correspondre les publications aux sujets et les acheminer aux abonnés. La structure que nous venons de détailler est illustrée dans le schéma de la figure 1.1 ci-dessous. Le modèle de publications/abonnements se caractérise par un support inhérent à la messagerie point à multipoint ce qui le rend utile pour les cas d’utilisation de l’IdO. De plus, il fournit une abstraction qui permet le découplage des producteurs de contenu (éditeurs) et des consommateurs de contenu (abonnés).

XMPP : Extensible Messaging and Presence Protocol Le protocole XMPP est un protocole de messagerie instantanée basé sur une architecture client/serveur. Le protocole permet un échange asynchrone des informations au format XML entre les entités au travers du serveur XMPP. Les entités peuvent créer des nœuds (topics) et publier des données sur ces nœuds. Ainsi, une notification d’évènement est diffusée pour informer toutes les entités qui se sont abonnées aux nœuds par la nouvelle publication. Ce protocole est caractérisé par son adressage des clients avec un identifiant unique (Saint-Andre, 2011).

AMQP : Advanced Message Queuing Protocol Le protocole AMQP est un protocole de transfert binaire qui a été conçu principalement pour les applications d’entreprise et la communication de serveur à serveur (Vinoski, 2006). Il est basé sur le principe de producteur/consommateur qui est équivalent au publisher/subscriber de MQTT. En outre, le protocole AMQP permet l’acheminement d’un nouveau message d’un producteur vers plusieurs sujets selon certains critères du message tels que le contenu, l’entête ou les clés de routage. De ce fait, les différents consommateurs qui se sont abonnés sur divers sujets peuvent recevoir le même message.

Comparaison des protocoles de messagerie On résume dans le tableau 1.1 les principales caractéristiques des protocoles de messagerie basé sur le modèle de communication de publications/abonnements décrits ci-dessous (Sennoun, 2018). Dans notre système Pub/Sub, nous intégrons le protocole MQTT en tant que couche de transport de messages pour le marché des données IdO. Nous considérons adapter nos solutions dans des travaux futurs à d’autres systèmes de communications Pub/Sub.

Discussion du choix de registre distribué

La valeur des chaînes de blocs provient de ses caractéristiques uniques permettant de créer des registres décentralisés, transparents, immuables et traçables. En effet, la chaîne de blocs publique est copiée et partagée sur l’ensemble du réseau ce qui permet à chaque participant d’accéder aux registres complets des transactions ainsi que les codes des contrats intelligents. En outre, cette duplication de données combinée avec le mécanisme de consensus de validation des transactions assure l’immuabilité et le suivi de toutes les opérations effectuées sur le registre. Effectivement, toute donnée ajoutée est permanente, horodatée et difficile à altérer ou supprimer. Dans notre travail, nous tirons parti des contrats intelligents pour mettre en œuvre différentes logiques de monétisation des données de l’IdO et nous nous appuyons sur l’immuabilité des chaînes de blocs pour construire une traçabilité robuste de l’échange de données en temps réel. Ainsi, nous avons choisi de travailler sur la plateforme Ethereum qui bénéficie de toutes les propriétés de la technologie de chaîne de blocs afin de développer notre application décentralisée.

La machine virtuelle d’Ethereum est Turing-complète qui fonctionne sur le réseau Ethereum et qui permet d’exécuter n’importe quel programme quelque soit le langage de programmation. Nous utilisons le langage de programmation Solidity pour développer nos contrats intelligents qui s’exécutent automatiquement sur l’EVM lorsque les conditions spécifiées sont remplies et sans autorité de confiance. De plus, la notion de comptes Ethereum qui est contrôlé par une clé privée et disposant d’un solde d’Ether nous permet d’identifier les utilisateurs de notre système, d’assurer la non-répudiation et de procéder à la monétisation en nous basant sur la cryptomonnaie. Enfin, nous nous concentrons dans notre évaluation sur la consommation de gaz comme indicateur de performance clé pour évaluer notre système et représenter les surcoûts d’exécution de nos contrats intelligents sur la chaîne de blocs. De ce fait, nous comparons nos trois modèles de monétisation et nous démontrerons qu’il existe un compromis entre le coût du gaz et la précision de la monétisation.

Marché de données de l’Internet des Objets

La commercialisation des données IdO est entrain de gagner en popularité durant ces dernières années. Ces marchés de données devraient atteindre 3 billion de dollars d’ici 2030 (Tang, FujiiHwang, Colwill, Arora, Shah, Mendizabal & Callejas, 2018). Plusieurs entreprises telles que BDEX (BDEX) et DAWEX (Dawex), offrent des marchés de données spécialisées qui permettent de vendre et d’acheter des flux de données IdO. Ces flux de données permettent aux entreprises de cibler les consommateurs et d’obtenir des statistiques représentant le comportement des utilisateurs dans le but de découvrir les défauts d’un produit spécifique ou de compléter des produits existants. De nombreuses études ont été menées pour concevoir des marchés de données pour l’Internet des Objets. Les auteurs (Bröring, Schmid, Schindhelm, Khelil, Käbisch, Kramer, Le Phuoc, Mitic, Anicic & Teniente, 2017) proposent un écosystème qui comble le problème d’interoperabilité des environnements IdO pour les fournisseurs des données et utilisent cinq plateformes d’interopérabilité offrant un modèle de marché de données indépendant de la plateforme avec une API commune. Une autre solution proposée par (Mišura & Žagar, 2016) définit un modèle de marché de données où les propriétaires d’appareils enregistrent leurs capteurs avec toutes les informations pertinentes et les consommateurs de données interrogent le système en définissant le besoin et le budget disponible pour se procurer ces données.

Cependant, ces travaux se sont concentrés à élaborer des solutions de stockage de données où la gestion des données ainsi que l’échange ne se font pas en temps réel. Un exemple de marché de données IdO en temps réel est suggéré par I3 (Krishnamachari, Power, Kim & Shahabi, 2018) définissant un site Web unique qui récupère les informations sur tous les vendeurs et leurs produits et les affiche aux acheteurs selon les besoins. Les auteurs utilisent un courtier de publications/abonnements qui autorise des acheteurs à accéder aux données en fonction de leurs paiements. Les flux de données sont mesurés à des fins de facturation et désactivés automatiquement à la fin de la période de paiement. Les propriétaires de données peuvent décider à qui et quand partager leurs données. Cependant, ces marchés de données présentent un point d’échec central et un goulot d’étranglement des interactions qui suscitent un besoin de confiance important entre le serveur, les vendeurs et les consommateurs. Ainsi, plusieurs recherches focalisent à proposer des alternatifs pour avoir des marchés de données décentralisés en utilisant la technologie de registres distribués.

Datapace (Draskovic & Saleh, 2017) est une solution décentralisée de marché de données basées sur le registre distribué privé Hyperledger Fabric. L’application s’appuie sur les contrats intelligents pour définir les conditions dans lesquelles les données doivent être transférées. L’utilisation de ce registre garantit l’intégrité des données échangées. Dans (Özyilmaz et al., 2018), les auteurs proposent IDMoB, une architecture décentralisée et distribuée de marché de données pour l’IdO. Ils utilisent Ethereum, la plateforme de contrat intelligent publique des chaînes de blocs, combinée avec le système de stockage décentralisé “Swarm” pour fournir un système de collaboration incitateur entre les fournisseurs de données IdO et les fournisseurs de solutions d’intelligence artificielle et d’apprentissage intelligent. Contrairement aux travaux ci-dessus, notre solution est intégrée à un système de publications/abonnements afin de fournir des flux de données en temps réel pertinents pour les consommateurs intéressés, tout en surveillant en permanence les flux d’informations à des fins de monétisation.

Table des matières

INTRODUCTION
CHAPITRE 1 NOTIONS DE BASE
1.1 Modèles de communication publications/abonnements
1.1.1 MQTT : Message Queuing Telemetry Transport
1.1.2 XMPP : Extensible Messaging and Presence Protocol
1.1.3 AMQP : Advanced Message Queuing Protocol
1.1.4 Comparaison des protocoles de messagerie
1.2 Technologie des registres distribués
1.2.1 Chaînes de blocs
1.2.1.1 Mécanismes de validation de transactions
1.2.1.2 Exemples de chaînes de blocs
1.2.2 Autres registres distribués
1.2.3 Comparaison des registres distribués
1.2.4 Discussion du choix de registre distribué
1.3 Les Filtres de Bloom
1.3.1 Opérations sur le Filtre de Bloom
1.3.2 Taux de faux positifs et fonctions de hachage
1.4 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Marché de données de l’Internet des Objets
2.2 Modèles de monétisation des données
2.3 Traçabilité à l’aide de contrats intelligents
2.4 Systèmes de publications et d’abonnements
2.5 Conclusion
CHAPITRE 3 ARCHITECTURE ET SOLUTIONS PROPOSÉES
3.1 Architecture du système
3.2 Processus d’enregistrement
3.3 Schéma de monétisation
3.4 Modèles de traçabilité proposés
3.4.1 Trace-MAX : Traçabilité maximale
3.4.1.1 Protocole d’échange de données
3.4.1.2 Processus de vérification des données
3.4.1.3 Protocole de monétisation des données
3.4.2 Trace-MIN : Traçabilité minimale
3.4.2.1 Protocole d’échange de données
3.4.2.2 Processus de vérification des données
3.4.2.3 Protocole de monétisation des données
3.4.3 Trace-BF : Traçabilité basée sur le filtre de Bloom
3.4.3.1 Protocole d’échange de données
3.4.3.2 Processus de vérification des données
3.4.3.3 Protocole de monétisation des données
3.5 Comparaison et discussion
3.6 Conclusion
CHAPITRE 4 ÉVALUATION ET DISCUSSION DES RÉSULTATS
4.1 Environnement de travail
4.1.1 Environnement d’échange de données
4.1.2 Environnement de chaînes de blocs
4.2 Évaluation du Coût global d’exécution
4.2.1 Scénario 1 : Effet de la fréquence de publication
4.2.2 Scénario 2 : Impacte du nombre d’abonnés
4.2.3 Scénario 3 : Influence du nombre d’éditeurs
4.3 Évaluation des coûts de la vérification
4.3.1 Scénario 1 : Effet de la fréquence de publication
4.3.2 Scénario 2 : Impacte du nombre d’abonnés
4.3.3 Scénario 3 : Influence du nombre d’éditeurs
4.4 Discussion des résultats obtenus
CHAPITRE 5 EXPÉRIENCE PERSONNELLE
CONCLUSION ET RECOMMANDATIONS
ANNEXE I ARTICLE PUBLIÉ DANS UNE CONFÉRENCE
ANNEXE II CONTRATS INTELLIGENTS
RÉFÉRENCES

 

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

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