IMA4 2018/2019 P22

Présentation générale

Dépôt Git

Afin de consulter le travail effectué sur ce projet un dépôt Git est disponible ici. Pour y accéder, vous devez au préalable disposer d'un compte sur la plateforme Git-hub et faire une demande d'accès à l'adresse: ait.mouheb.arezki@gmail.com

Présentation Générale

Introduction

schéma abstrait Blockchain

Blockchain est une technologie de stockage et de transmission d’informations basé sur la cryptographie. Elle peut être vue comme une sorte de base de données distribuée, sécurisée et partagée. Autrement dit, c'est une structure de données qui contient des informations et qui n'est pas détenue par un serveur centralisé mais par toutes les machines connectées au réseau. Ces informations sont groupées en blocs d'une taille définie et chaque bloc est lié à celui qui le précède par un Hash Cryptographique créant ainsi une chaîne. Le véritable attrait de la Blockchain est de créer un registre de données qui est au même temps commun et extrêmement difficile à altérer.

Plusieurs implémentations de la technologie existent et beaucoup d'autres sont en cours de développement. Historiquement, la première et la plus connue reste la Cryptomonnaie Bitcoin qui est une variante spécifique dite publique c'est à dire que tous les utilisateurs ont les mêmes droits d'accès. Le potentiel d'application de la technologie a conduit à l'apparition d'autres variantes plus adaptées aux nouveaux usages.

Blockchain Fédérée

On peut distinguer 2 autres types:

• Privée: propriété d'un individu ou organisation. Un nœud central décide d'octroyer les privilèges d'accès aux autres nœuds
• Fédérée ou Consortium: propriété d'un groupe. Les nœuds fédérateurs se réservent le droit de vérifier les blocs, voire de les créer.

Description du projet

L'idée de ce projet est d'explorer cette technologie par l'implémentation d'une variante fédérée de celle-ci qui sera illustrée par un système d'annonce public. Dans ce système, les membres du réseau peuvent se connecter et ainsi avoir accès aux messages diffusés mais seuls certains membres seront autorisés à émettre/valider une annonce. Les messages publiés seront protégés contre l'altération par les mécanismes de cryptage et de sécurité blockchain.

Objectifs

Ce projet est essentiellement un sujet d'exploration dont les objectifs principaux sont:

• Découvrir la Blockchain et analyser son potentiel technologique et économique.
• Découvrir les systèmes distribués pair à pair.
• Connaître les différents outils et plateformes de développement d'applications distribuées basés sur la Blockchain.
• Acquérir des compétences dans un domaine en pleine expansion.
• Implémenter une application mettant en œuvre cette technologie.

Analyse du projet

Positionnement par rapport à l'existant

La technologie blockchain est très récente et fait l'objet de beaucoup de projets de développement. Parmi ces derniers, certaines applications se rapprochent de l'objectif de ce projet c'est à dire la création d'un système de diffusion de contenu (annonce, messages). Parmi les plus aboutis, nous retrouvons deux projets majeurs.

Analyse du premier concurrent

Civil

La plateforme Civil

Civil est une start-up qui propose un nouveau business modèle pour le journalisme. Ils proposent un système décentralisé de publication basé sur la Blockchain. Leur système permet à la communauté de voter pour élire les Newsrooms (groupes de journalistes représentant des nœuds dans le réseau) qui auront le droit de publier et de vérifier le contenu journalistique. Le droit de vote est acquis en disposant de Consumer Tokens, l'équivalent d'une monnaie client.

Spécificités:

• Plateforme de développement utilisée: Ethereum
• Système de diffusion à monnaie interne..
• Contenu partagé: Articles journalistiques, vidéos, podcasts ...
• Accès: Public.

Analyse du second concurrent

DNN:The Decentralised News Network

La plateforme DNN

DNN "Decentralized News Network est une start-up qui utilise la technologie Blockchain pour la diffusion de l'information de façon vérifiable, transparente et protégée contre la censure en incitant les utilisateurs à contribuer à la validation et la vérification de contenu à travers un processus de revue rémunérant.

Spécificités:

• Plateforme de développement utilisée: Ethereum.
• Système de diffusion à monnaie interne: Ether.
• Contenu partagé: Articles journalistiques, podcasts ...
• Accès: Public.

Synthèse

Les concurrents analysés proposent des fonctionnalités très avancées de partage contenu et sont implémentés sur une plateforme (Ethereum) destinée à une architecture à accès public. Ce choix a ses avantages mais aussi des contraintes liées à l'utilisation obligatoire d'une monnaie locale incitant à la vérification des publications. Il faut savoir aussi que dans ce modèle toutes les diffusions sont publiques et donc consultables par toute personne ayant internet. Cette architecture utilise des protocoles de consensus pour résoudre les conflits qui sont efficaces mais impliquent des coûts calculatoires important. Enfin, le déploiement sur la plateforme Ethereum est orienté B2C et implique l'usage de la cryptomonnaie Ether.

A terme ce projet doit aboutir sur une architecture fédérée de validation avec des nœuds diffuseurs prédéfinis, sans avoir à utiliser de cryptomonnaie, exploitant des ressources libres pour le développement telles que Hyperledger de la Linux foundation qui sont plus flexibles tout en tirant profit des avantages d'une application décentralisée et sécurisée blockchain.

Scénario d'usage du concept

concept du projet

AGRI est un producteur agricole qui produit toutes sortes de fruits. Il les revend à BioF00d une entreprise qui crée à partir de ça plusieurs variétés de produits tels que des compotes, des confitures, des jus etc... qui sont ensuite acheminés par des camions vers des distributeurs partout en France puis vers les différents revendeurs. Les autorités sanitaires impose la traçabilité de toutes les denrées alimentaires pour connaître leurs origines et s'assurer que les normes sont respectées de la production au consommateur final. Les différents acteurs ont rencontré plusieurs problèmes avec les autorités car il y avait des incohérences dans les données que chaque entreprise gardait à différents points de passage. Aussi, ils ne cessent de se renvoyer la faute quant aux dégradations subit par les produits lors du transport. C'est là qu'ils entendent parler d'une startup "IoTchain" qui a développé un système très intéressant qui pourrait résoudre leur problème de traçabilité.

Le système est composé de deux parties:

• Un dispositif IoT qui mesure des données telles que la position, l’humidité, la température et bien d'autres grandeurs et les transmet sous forme de messages à un réseau Fédérateur pour les archiver dans une blockchain.
• Un réseau Fédérateur qui vérifie que seuls ces client IoT certifié (les dispositifs) peuvent écrire des données dans cette blockchain et offre aux autres clients l’opportunité de consulter seulement les données à travers une application web par exemple.

Avec ce système le consortium AGRI, BioF00d, Les entreprises de transport, les distributeurs, les revendeurs, les autorités sanitaires et même les clients peuvent avoir accès à ces informations et garantir l'intégrité de la donnée et une transparence totale sans qu'une entité ne les altère.

Réponse à la question difficile

Qu'est-ce qui fait la sécurité de la Blockchain?

Fonction de hashage

Liaison entre blocs

Dans le domaine de l'informatique l'usage des fonctions de hachage cryptographiques telles que SHA256 est assez fréquent. Ce sont des fonctions qui, à une donnée de taille arbitraire, associent une image de taille fixe (digest ou hash). La propriété essentielle de ces fonctions est le fait qu'elles sont pratiquement impossibles à inverser. En d'autre termes, à partir d'un hash il s'avère très difficile de retrouver la donnée qui l'a produit. D'une autre part un petit changement dans la donnée d'entrée engendre un hash totalement différent.

Lorsque l'on insère un nouveau bloc dans une blockchain, on le relie au reste de la chaîne en y ajoutant un champ contenant le digest du bloc précédent. D'après ce qu'on a vu dans le paragraphe précédent, si l'on modifie un bloc (n), son digest ne sera plus le même donc le bloc suivant (n+1) n'aura plus un lien valide il faudra de ce fait le recalculer. En recalculant le lien dans le (n+1) nous changeons maintenant son contenu. Du coup, le bloc (n+2) n'aura plus un lien valide ...etc jusqu'au dernier bloc de la chaîne.

Ceci n'est pas suffisant pour garantir une sécurité car dans ce sens le calcul des Hash reste toujours faisable. C'est alors qu'intervient une autre composante importante qu'on appelle "protocole de consensus". Différents types de protocoles existent selon le type de système que l'on souhaite mettre en place.

Les protocoles de consensus

Nous n'allons pas détailler ici tous les protocoles existant mais nous allons nous intéresser à deux exemples bien précis. La preuve de travail PoW pour sa popularité étant donné son usage dans le réseau bitcoin et Practical Byzantine Fault Tolerance de par son usage dans le framework Hyperledger sur lequel nous allons baser notre travail.

1- Proof of work : (PoW)

Preuve de travail

C'est un protocole basé sur l'asymétrie du coût de calcul : le travail doit être difficilement réalisable, mais facilement vérifiable. Une implémentation de ce protocole peut être d'ajouter un champs dans le bloc "nonce" qui serait juste un chiffre dont le rôle est de faire varier le hash du bloc construit précédemment. D'une autre part on spécifie un critère pour le protocole par exemple :"Le hash après le calcul de la preuve de travail doit commencer par six '0' successifs." Comme les fonctions de hashage ne sont pas réversibles, la seule façon d y arriver est de calculer le Hash du bloc pour chaque valeur du "nonce" jusqu'à ce que le critère soit satisfait. Cette tache est très demandeuse en terme de puissance de calcul. Un fois que le critère est satisfait le bloc est validé par le protocol qui calcule le hash du bloc et le compare à la preuve de travail. S'il correspond, le bloc est ajouté à la chaîne. Pour comprendre le niveau de sécurité de cette solution, essayons de voir ce qu'il faut faire pour réussir à la contourner. Supposons qu'un nœud malveillant décide de modifier un bloc (n) pour quelque raison que ce soit. En faisant cela, il devra refaire la preuve de travail pour le bloc (n) puis recalculer le champ "Prev hash" dans le (n+1) puis sa preuve de travail et ainsi de suite pour le (n+2),(n+3)...etc ce qui s'avère être une tâche vorace en terme de puissance de calcul. Même s'il y arrive, il doit continuer à valider les nouveaux blocs (calculer la preuve de travail) pour maintenir la chaîne altérée qu'il vient de créer car le protocole est fait de telle sorte à considérer la chaîne la plus longue comme étant la chaîne de référence. Ceci donc nous amène à considérer les limites de cette solution:

• Si une entité malveillante possède 51% de la puissance de calcul du réseau elle pourra donc imposer sa version de la chaîne ce qui implique que le réseau doit être suffisamment grand pour que ça ne soit pas pratiquement possible qu'une entité puisse s'accaparer autant de puissance.
• Cet algorithme de consensus est vorace en énergie.

Conclusion: cet algorithme initial de consensus est certes très intéressant d'un point de vue sécurité sous resserve de certaines conditions mais ne correspond pas à tout type d'application.

2- Practical Byzantine Fault Tolerence : (PBFT)

PBFT

"Byzantine Fault Tolerance" est l’habilité d'un système distribué basé sur le consensus à avoir assez d’éléments pour prendre une décision malgré la présence de nœuds malicieux ou défectueux en son sein. La problématique des généraux byzantins est à l'origine de cette réflexion mais le concept a été appliqué à beaucoup de systèmes critiques tels que les avions, les centrales nucléaires et les systèmes distribués modernes.

L'approche pratique (practical) prend en compte certaines suppositions:

• L’indépendance des nœuds en termes d'infection.
• La présence de messages altérés dans le système.

Dans ce système de validation, on tolère un nombre bien définit de nœuds malicieux (m) qui doit être inférieur au tiers du nombre de nœuds dans le réseau dans une fenêtre de vulnérabilité donnée (original paper). Dans ce cas, plus le réseau est grand, plus il devient sécurisé.

Dans ce système, les nœuds sont organisés de façon séquentielle avec un nœud Leader. Ils doivent communiquer entre eux de façon à décider du comportement du système en utilisant le principe de la majorité. A titre d'exemple, la validation, ou pas, d'un message.

La communication entre ces nœuds a deux buts:

• Prouver que le message est bien venu d'un nœud spécifique
• S'assurer que le message n'a pas été modifié durant la transmission.

Déroulement de l'algorithme:

• Un nœud envoie une requête au nœud Leader.
• Le Leader reçoit la requête puis la diffuse aux autres nœud réplica.
• Ces nœuds diffusent à leurs tours leurs réponses à la requête de façon à ce que chaque nœud sache ce que les autres ont répondu.
• Resultat:
  • Si m+1 nœuds optent pour une même décision on est sûr qu'au moins un nœud "honnête" a répondu. Ainsi, la décision est Valide.
  • Si unanimité le système est sein autrement le/les intrus est/sont détecté(s).

Le nœud Leader, est constamment vérifié. On s'assure de ça transparence grâce à la signature électronique de la requête. De plus, il est systématiquement remplacé par un autre nœud de façon séquentielle en cas d'inactivité constatée.

Les limites:

• L'algorithme suppose que le traitement des nœuds est déterministe. Pour la même requête les nœuds seins doivent donner le même résultat.

Framework Hyperledger-Fabric

Services Fabric

Hyperledger Fabric est une plate-forme DLT (Distributed Ledger Technology) open source conçue pour être utilisée dans des contextes d'entreprise. Un point clé de Hyperledger est le fait qu'elle a été créée sous la Linux Foundation, qui a elle-même une longue et fructueuse expérience de projets open source sous une gouvernance ouverte. Sa communauté de développeurs compte désormais plus de 35 organisations telles que IBM ou J.P Morgan et près de 200 développeurs depuis son lancement. Pour plus d'information consultez le site de la communauté ici.

Préparation du projet

Cahier des charges

• Prototype 0:
  • Réalisation d'un premier système de diffusion d'annonce libre d’accès et sans protocole de consensus sur Hyperledger Fabric.
  • Réalisation d'un API Rest sur javaScript simple pour interagir avec le système (GET,POST).
  • Implémenter et déployer des clients simples visualisant les messages (Exemple: Page web).

• Prototype 1:
  • Ajouter les mesures de sécurité et de vérification pour réserver le droit de diffusion aux Administrateurs et gérer l'accès au système.
    • Un administrateur: peut lire et écrire.
    • Un client : peut lire seulement
  • Implémentation de clients qui devront interagir avec les messages diffusés (Exemples: Dispositif embarqué, Système d'alarme ...etc).

Choix techniques : matériel et logiciel

Logiciel

Les spécificités du projet et l'étude initiale ont conduit au choix du framework Hyperledger pour la réalisation du prototype. Les outils de développement disponibles sur ce framework sont open-source et supportés par la Linux Foundation. Cette plateforme offre aussi un choix assez varié pour les langages de développement. Dans notre cas et affin de s'assurer d'un bonne compatibilité ainsi que pour bénéficier d'une documentation assez riche, nous optons pour une implémentation sur "node.js" en "javaScript".

Matériel

Le projet est essentiellement software donc le matériel requis initialement est:

• Une Raspberry Pi 3 avec Wifi inclus (ou Pi 2 avec le Dongle Wifi)
• Cable serie/USB
• Cable Ethernet RJ45

Réalisation du Projet

Prise en main

Hyperledger composer

Hyperledger Composer - hyperledger.org

Ce framework propose une base intéressante pour la création d'applications blockchain. On distingue deux types d'outils distincts:

• Composer Playground: "terrain de jeu" c'est un outil graphique qui se présente sous forme d'une application web qui procure un environnement isolé de déploiement et de test pour des applications basiques à des fins d'apprentissage.
• Composer Developer Tools: une suite d'outils plus complète pour créer des applications plus poussées à des fin de production. Cette suite comprend:
  • Hyperledger composer: ligne de commande pour créer et gérer les instances de la blockchain.
  • Composer-rest-server: Un générateur d'API rest qui permet de créer à partir d'un modèle, qui sera expliqué plus bas, un API Rest squelette permettant d’interagir avec le réseau une fois déployé.

Quelques concepts importants

Modèle HL

Hyperledger propose permet de modéliser les entités, la logique et les interactions au sein du domaine d'un réseau (Business Network). Cette modélisation se fait sous une structure bien définie comportant essentiellement:

Un fichier de modélisation (.cto)
HL propose un langage orienté objet permettant de définir:

• Un namespace : en français "espace de noms" définissant une notion de portée des objets qui seront déclarés dans ce fichier.
• Des définitions de ressources :
  • Assets: une notion de Biens tangibles ou pas ou d'objets ayant une valeur quelconque.
  • Participants: c'est les acteurs du réseau. Ils peuvent être des Individus ou des entités.
  • Transactions: c'est un mécanisme qui permet aux acteurs du réseau d’interagir avec ces ressources.
  • Events: Des événements peuvent être lancés lors de l’exécution de transaction pour prévenir un système externe (une application par exemple) que des changements importants ont été fait sur le registre partagé.

Structure d'un modèle de réseau HL - hyperledger.org

Fonctions de traitement des Transactions (.js)
Ces fonctions en JavaScript sont invoquées automatiquement à l'execution avec un système d'annotation pour implémenter la logique des transactions définies dans le modèle.

Un fichier de contrôle d’accès (.acl)
Ce fichier contient les règles d'accès et définit les actions autorisées ou non-autorisées sur le réseau en définissant le comportement de chacun de ses éléments.

Un fichier de requêtes (.qry)
Ce fichier comporte les requêtes dont la syntaxe se rapproche du SQL qui sont utilisées pour retourner des données sur l'état du réseau (les ressources, les transactions, ...). Ainsi, nous pouvons extraire de la données de la blockchain.

Développer des applications basées sur la technologie Blockchain utilisant Hyperleger introduit d'autres notions de niveau supérieur:

La sauvegarde de l'état
Toutes les transactions effectuées sur le réseau sont sauvegardé dans le registre distribué. L'état des "Biens" (Assets) et des Participants sont sauvegardés dans la base de donnée d'état de la blockchain. Les deux sont répartis sur tous les nœuds du réseau avec un mécanisme de consensus qui s'assure que tout les nœuds ont les mêmes données.

Business Network Card

Les identités
Sur HL une identité est représentée par un certificat et et un clé cryptographique privée. Ces identités sont utilisées pour pouvoir effectuer des transactions sur le réseau. Une identité doit systématiquement être liée à un acteur du réseau (Participant). Pour une identité on peut créer un carte (Business Network card), qui, une fois liée à un acteur, lui permet d'agir sur le réseau en qualité de l'acteur en question.

Les Profils de connexion
Les profils de connexion sont utilisés dans Hyperledger composer pour spécifier comment se connecter à un environnement d'exécution. Plusieurs options sont disponibles pour chaque type d'environnement que nous verront plus bas. A titre d'exemple le profile de connexion sur l'environnement Hyperledger Fabric contient les adresses TCP/IP et les ports des nœuds du réseau et leurs certificats cryptographiques. Ces Profils font partie des "Business Network Cards", évoquées plus haut, dont le rôle est de gèrer les accès au réseau de registres distribués.

Business Network cards
Un carte naît de la combinaison d'une identité, d'un profil de connexion et des informations supplémentaires concernant le réseau auquel on souhaite se connecter. Ces cartes simplifient seulement le mécanisme de connexion au réseau en regroupant les informations nécessaires en un point.

Architecture Générale HL Composer

Architecture Générale de Composer - hyperledger.org

Hyperledger Composer est construit autour des éléments suivants:

• Un Environnement d’exécution
• Des profils de connexion
• Un SDK JavaScript
• Une interface ligne de commande
• Un Serveur REST
• Une interface logicielle (LoopBack Connector)
• Une Interface Web (Playground)
• Un générateur de code (Yeoman)

Environnement d’exécution
Composer supporte actuellement plusieurs environnements d’exécution qui diffèrent selon l'emplacement de sauvegarde des données d'état du réseau:

• Hyperledger Fabric: l'état est sauvegardé sur les registres distribués.
• Web: l’exécution se fait dans une page web, c'est ce qui est utilisé par Playground. L'état est sauvegardé sur l'espace mémoire local du Navigateur.
• Embarqué: l’exécution se fait à l'interieur d'un processus Node.js c'est utilisé principalement pour faire des tests unitaires. L'état est sauvegardé en mémoire sous forme de paires nom:valeur.

SDK JavaScript
Cette SDK est composé d'un groupe d'API Node.js permettant de créer des applications pour intéragir avec un réseau déployé. Ces APIs peuvent être séparés en deux catégories de modules npm:

• composer-client: API utilisé pour soumettre des transactions au réseau et effectuer les opérations d’interaction de base (CRUD) sur les ressources (Assets, Participants...) échangés ou traquées par le réseau.
• composer-admin: API utilisé pour faire de la gestion administrative des réseaux déployés autorisant des opérations comme install, start et upgrade.

Interface en ligne de commande
Permet aux développeurs et aux administrateurs de déployer et de gérer les réseaux.

Serveur REST
Cette outils permet de générer automatiquement un API Rest suivant la spécification "API (Swagger)" à partir d'une conception modélisée du réseau. En cours d’exécution, il implémente la logique derrière les opérations (CRUD) sur les ressources.

LoopBack Connector
Par défaut cette interface logicielle est utilisé par le serveur REST mais peut être utilisée directement pour créer des API REST très avancés qui ne sont pas nécessaires dans le projet traité.

Yeoman Code Generators
Cet outil est utilisé pour créer des squelettes de projets:

• Angular
• Node.js
• Squelettes des réseaux de nœuds (business networks)

HL Fabric

//A remplir de mes notes

Installation

Installation des prérequis:

• Git
• Node.js
• Docker
• Python
• Npm
• Docker-composer

L'installation peut se faire automatiquement (Ubuntu) en utilisant:

curl -O https://hyperledger.github.io/composer/latest/prereqs-ubuntu.sh

Installation de HL: La ligne de commande Hyperledger

npm i -g composer-cli

Composer-rest-server

npm i -g composer-rest-server

Yeoman generator

npm i -g generator-hyperledger-composer

Yeoman

npm i -g yo

Playground

npm i -g composer-playground

Installation de Fabric:

mkdir fabric-dev-servers

cd fabric-dev-servers  

curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.tar.gz

tar -xvf fabric-dev-servers.tar.gz

./downloadFabric.sh

Lancez Fabric en utilisant le script fourni:

./startFabric.sh

ou manuellement:

#utilisé à l’intérieur de docker-compose.yml
export HOST=localhost

export DIR=$(pwd)/fabric-scripts/hlfv<version_de_fabric>

export DOCKER_FILE="${DIR}"/composer/docker-compose.yml

#Arrêt des containnaires s'ils existent
docker-compose -f "${DOCKER_FILE}" down

docker-compose -f "${DOCKER_FILE}" up -d

Vérification:

#afficher les conteneurs
docker ps

#visualiser les logs des conteneurs pour vérifier qu'ils ont démarré sans erreurs  
docker logs <conteneur>

Dans un répertoire fabric-tools nous allons mettre des programmes utilitaires que nous allons réutiliser plus tard:

• configtxgen,
• configtxlator,
• cryptogen,
• discover,
• idemixgen
• orderer,
• peer,
• fabric-ca-client

pour ce faire, faut récupérer le script à cette adresse et l’exécuter comme suit (-s -d pour ne pas télécharger du contenu superflu pour le moment):

curl https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh > bootstrap.sh 
./bootstrap.sh -s -d

Réalisation - Prototype 0

Configuration Du Réseau

Le test ayant été fait sur mon PC certains chemins son propre à cette implémentation.

export PROJECT_PATH=/media/arezki/STORE/Blockchain
export DIR=$PROJECT_PATH/fabric-dev-servers/fabric-scripts/hlfv12
export DOCKER_FILE=$DIR/composer/docker-compose.yml
export FABRIC_START_TIMEOUT=10
export OUTPUT_CONFIG=arezki@p22-config.yaml
export CFG_PATH=$DIR/composer

GENESIS_BLK=newGenesis.block
CHANNEL=newChannel.tx

cd $DIR
./startFabric.sh

#Vider le cache des network cards
  rm -rf ~/.composer

#Generer les certificats cryptographiques pour la configuration par default
  cd $CFG_PATH
  cryptogen generate --config=crypto-config.yaml --output OUTPUT_CONFIG

#Initialisation Blockchain
  cd $CFG_PATH
  FABRIC_CFG_PATH=. configtxgen -profile ComposerOrdererGenesis -outputBlock $GENESIS_BLK

#Creation du tunnel par défaut
  FABRIC_CFG_PATH=. configtxgen -profile ComposerChannel -channelID composerchannel -outputCreateChannelTx $CHANNEL

#Creating PeerAdmin card
  cd $DIR
  ./createPeerAdminCard.sh

Modélisation

Modèle du prototype 0

Modélisation Prototype0 CODE SOURCE

L'objectif de cette première approche est de réaliser un système de Broadcast simple et fonctionnel regroupant des entités de type User qui sont les acteurs du réseau qui peuvent via une transaction Broadcast créer une instance de type Message qui sera signée par l'identité de son émetteur. Le prototype implémente aussi:

• Une vérification d'identité : à travers un concept de signature (mot de passe) un utilisateur ne peut signer un message que de son nom et seulement si il est existant dans le système.
• Seul un Admin peut créer des User.
• Aucune entité ne peut créer de message à travers autre chose que la transaction de broadcast.
• Un User peut mettre à jour ces informations.
• Un utilisateur ne peut pas accéder au informations complètes d'un autre User ni d'un Admin.
• Toutes les entités peuvent lire les messages diffusés.
• On ne peut pas éditer un message diffusé.
• Des requêtes simples pour lister les messages (les plus récents en premier, pour un utilisateur spécifique ...).

Test sur Playground

VIDEO

Playground offre un moyen de déployer une modèle de réseau très rapidement sur un Navigateur et nous permet de ce fait de tester le bon fonctionnement des fonctionnalités de façon générale. Ici, un modèle équivalent du réseau p22_network est repris sur Playground. Pour ne pas prolonger la taille de l'enregistrement, seul la fonction principale de broadcast est démontrée. Les autres, ont été faites devant les tuteurs.

Déploiement

Git test deploy commit
Pour déployer un modèle il est nécessaire de générer une archive (.bna) à partir du répertoire de développement.

cd <repertoire>
composer archive create --sourceType dir --sourceName .

Pour automatiser la manœuvre de déploiement et de test, j'ai préparé quelques scripts shell qui reprennent les étapes importantes du processus:

• mylauncher.sh : permet de:
  • préparer et initialiser notre réseau.
  • deployer notre modèle.
  • créer un utilisateur admin par défaut et se connecter avec ses identifiants.
  • pinger le réseau
  • générer un API-REST

#---------Launching fabric cluster for P22 IMA4 Prototype0..."
  ./startFabric.sh

#---------clean network cards
  rm -rf ~/.composer
  cd $CFG_PATH
  cryptogen generate --config=crypto-config.yaml --output OUTPUT_CONFIG  

#---------Initializing blockchain..."
  cd $CFG_PATH
  FABRIC_CFG_PATH=. configtxgen -profile ComposerOrdererGenesis -outputBlock $GENESIS_BLK
 
#---------Creating channel..."
  FABRIC_CFG_PATH=. configtxgen -profile ComposerChannel -channelID composerchannel -outputCreateChannelTx $CHANNEL
 
#---------Creating PeerAdmin card
  cd $DIR
  ./createPeerAdminCard.sh

#---------Deploying business Network Archive..."
  composer network install --card PeerAdmin@hlfv1 --archiveFile $PROJECT_PATH/p22_network/p22_network@0.0.1.bna 

#---------Starting network with PeerAdmin card
  composer network start --card PeerAdmin@hlfv1 --networkName p22_network --networkVersion 0.0.1 --networkAdmin admin --networkAdminEnrollSecret adminpw

#---------Importing network card..."
  composer card import --file ./admin@p22_network.card

#---------Pinging the network..."
  composer network ping --card admin@p22_network

#---------Generating rest API..."
  composer-rest-server -c admin@p22_network -n never -u true -d n -w true

Résultat Prototype 0

VIDEO

Sur une machine virtuelle nous faisons le déploiement de notre réseau avec nos scripts. Nous créons donc un réseau avec:

• Un Validateur (Orderer)
• Une Autorité de certification (CA)
• Un Nœud (peer0)

pour ce faire nous lançon leurs centenaires respectifs avec cette configuration reprise dans le docker-compose.yml. Comme chaque entité du réseau doit avoir un certificat et un clé privée, nous utilisons les outils fournis pour les générer automatiquement (fabric-tools/bin/cryptogen...). La génération est automatisée grâce au modèle définit par crypto-config.yml. Suite à cela, il faut initialiser notre blockchain en créant manuellement le premier block GenesisBlock en utilisant configtxgen. Maintenant, il est nécessaire de créer un tunnel entre notre nœud et le validateur leur permettant de communiquer. Comme nous l'avons expliqué plus haut, pour interagir avec le réseau, il faut impérativement disposer d'une Business Network Card que nous créons moyennant les scripts fournis. Le script crée un utilisateur Admin par défaut qui a les privilèges Administrateurs. Nous nous connectons avec cette identité pour pouvoir installer notre modèle de réseau .bna puis nous le démarrons. Nous testons si le réseau a bien démarré et nous lançons la génération de l'API-REST sans les mesures de sécurité (sans login et en http clair pour le moment) sur le port 3000 de la VM. La seconde partie nous ne faisons qu’interagir avec le réseau en créant des utilisateurs (notez qu'ici nous utilisons l'API-REST en étant admin à défaut de login. De ce fait nous pouvons créer des USERs). Des requêtes HTTP sont envoyées avec curl sur le l'API pour aussi réaliser des "broadcasts" de messages. Le système implémente vraisemblablement toutes les fonctionnalités attendues.

Réalisation - Prototype 1

Dimensionnement de la topologie du réseau

Lors de la réalisation du prototype 0, une phase importante n'a pas été explicité relevant de la configuration du réseau lui-même car un modèle par défaut a été utilisé. Le but ayant été d'aboutir à un prototype qui permet d'appréhender les différentes étapes sans se perdre au premier passage dans les détails qui risqueraient d’obscurcir la vue d'ensemble. En revanche cette étape est expliquée ici en détails.

Après entretien avec mes tuteurs il m'a été conseillé de réaliser un réseau pour un cas de figure particulier avec un scénario d'usage orienté "métiers". Le scénario est le suivant: Imaginons que les différents ministères d'un état souhaitent mettre en place un réseau en utilisant la technologie dont il est question ici. Ces ministères coopèrent ensemble et s'échangent des messages en obéissant à des protocoles donnés pour informer mutuellement ou enclencher des procédures.

Pour faire court, réaliser une topologie semblable au prototype 0 ( UN ordonnanceur + Un noeud ) est insensée car on perdrait l'avantage d'un système distribué en centralisant mais aussi les performances seront catastrophiques sans parler de l’aspect sécurité qui n'est géré par nous qu'au niveau applicatif.

Ceci dit, il est maintenant nécessaire d'expliciter comment une transaction se déroule sur un réseau Hyperledger-Fabric pour comprendre comment dimensionner notre réseau.

Génération des certificats cryptographiques et des clés privées

//TODO

Création du tunnel

//TODO

Configuration des conteneurs

//TODO

Automatisation du déploiement du réseau

//TODO

Automatisation de l'installation et du l’instanciation du chaincode

//TODO

Test bout à bout du réseau

//TODO

Développement de la logique applicative

//TODO

Tests de fonctionnement

//TODO

Développement de l'interface client

//TODO

Test Finaux

//TODO

Aspect performance

//TODO

Propositions d'amélioration

//TODO

Conclusion Générale

//TODO

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Wiki	8			4	4	0	0	0	0	0	0	0
Analyse du projet	12
Préparation de l'environnement de développement		3			0	0	0	0	0	0	0	0
Prise en main des outils		4	8	0	0	0	0	0	0	0	0	0
Réalisation du prototype 0				3	4	4	0	0	0	0	0	0

Ainsi que d'innombrables week-ends :)
Modification de IMA4 2018_2019 P22 (section) — Wiki de Projets IMA

Documents Rendus

Références

https://media.readthedocs.org/pdf/hyperledger-fabric/release-1.4/hyperledger-fabric.pdf