Définition et propriétés de la Blockchain

Télécharger le fichier pdf d’un mémoire de fin d’études

Analyse et spécification des besoins

Il sera question ici de faire une capture des besoins de notre système. Cette phase a pour principaux objectifs de définir :
– Le contexte général dans lequel le projet va être réalisé.
– Les acteurs humains ou non qui vont interagir avec le système.
– Les fonctionnalités attendues du système.
– Le fonctionnement dynamique de chaque fonctionnalité.
Pour y parvenir, nous allons en premier lieu analyser rapidement les besoins que notre application devra satisfaire. Cela constituera un aperçu général des besoins et nous amènera, en second lieu, à définir chaque besoin. Nous parlerons dès lors de fonctionnalités. Nous utiliserons des diagrammes UML (diagrammes de cas d’utilisation, diagrammes de séquence) pour exprimer les besoins de manière complète.

Étude et analyse des besoins

Avant de parler du fonctionnement proprement dit du système, il est nécessaire de définir dans un premier temps les fonctionnalités qui seront implémentées au sein dudit système. Ainsi donc, cette étape décrit ce que nous attendons de notre application. Ultérieurement, ces fonctionnalités seront modélisées avec le langage de modélisation UML par la présentation des cas d’utilisation. Nous identifions en second lieu les acteurs de notre système.

Besoins fonctionnels

Nous pouvons dire que notre application doit être capable de fournir les fonctionnalités listées ci-après et que nous avons regroupées en modules :
– Module inventaire :
o affichez les titres fonciers ( actifs ). o affichez les baux ( actifs ).
o Afficher les différents profils utilisateurs ( participants )
– Module contrôle d’accès :
o Proposer différents niveaux d’accès selon le profil de l’utilisateur.
– Module Logs :
o Afficher toutes les activités du système.

Besoins non fonctionnels

Il s’agit de définir un ensemble de critères essentiels pour le bon fonctionnement de notre système. Ils définissent les exigences auxquelles doit répondre ce dernier et le comportement souhaité. Notre système doit aux utilisateurs les fonctionnalités suivantes :
– Sécurité : l’authentification est nécessaire pour que l’utilisateur puisse utiliser l’application. Il faut aussi tenir compte des droits d’accès et permissions pour protéger les données, surtout lorsqu’il s’agit de l’exécution des transactions, qui doivent être faites dans un contexte très sécurisé ;
– Ergonomie : Les différentes fonctionnalités du système doivent être compréhensibles et facile à manipuler par l’utilisateur. L’application doit offrir une meilleure expérience utilisateur ;
– Modularité et extensibilité : le système doit tenir en compte la possibilité de son extension par l’ajout de nouvelles fonctionnalités ;
– Maintenabilité : diminuer l’effort nécessaire pour localiser et corriger un défaut dans l’application. Il faut donc structurer et organiser convenablement le code source.

Besoins optionnels

Il est question ici d’enrichir le système de fonctionnalités qui pourraient répondre aux besoins des utilisateurs sans toutefois tendre vers le superflu. Les besoins qui s’imposent dans ce domaine sont principalement la possibilité, lors de l’ajout d’un participant ou d’une transaction, de pouvoir importer un fichier ( Excel, PDF ) et d’enregistrer directement les informations qu’il contient dans notre Blockchain. On peut ajouter aussi un système de notifications pour plus d’ ergonomie.
Nous venons d’exposer l’ensemble des besoins auxquels doit répondre notre système.
La sous-section suivante nous permettra de présenter les acteurs de notre système.

Identification des acteurs

C’est l’étape qui consiste à faire un recensement sur les différents acteurs qui vont interagir avec le système. Définissons au préalable certains termes qui seront importants pour la suite :
– Acteur : Constitue une entité physique capable d’interagir avec le système. Notons juste que cette entité peut être humaine ou matérielle ;
– Système : C’est l’entité à concevoir, dans notre cas il s’agit de l’application en elle-même.
En définitive, nous aurons trois (03) acteurs principaux et deux (02) niveaux d’utilisation.
1- L’administrateur : En plus de toutes les tâches citées plus haut, l’administrateur assure la maintenance du système. Il a de surcroît la possibilité de consulter tout l’historique du système. Utilisateur de niveau 2.
2- L’utilisateur : personne qui achète un terrain ou enregistre son titre foncier, Utilisateur de niveau 1.
3- Inspecteur foncier : personne qui confirmer et initier le transfert. Utilisateur de niveau 1.
Nous résumons cette description dans la figure 1 que nous nommerons diagramme de contexte statique de notre système. Le diagramme de contexte statique délimite le domaine d’étude. Nous avons vu dans cette section un aperçu général des acteurs de notre système. Cet aperçu nous a permis de proposer un diagramme de contexte statique. Il est donc temps de passer à une présentation spécifique de chaque besoin, de manière à faire une description détaillée de chaque fonctionnalité. C’est ce qui fera l’objet de la partie suivante.

Conception de la solution

Après avoir identifié les rôles des acteurs et défini les fonctionnalités du système, passons maintenant à la phase de conception. Dans ce chapitre nous allons présenter l’architecture de notre solution et les outils avec lesquels nous nous proposons de la réaliser.
La phase d’analyse et de spécification des besoins nous a amené à des conclusions particulières. Ainsi, la solution proposée devra :
– Intégrer une protection de la confidentialité des transactions ;
– Proposer un système permissionné ;
– Assurer l’identification de tous les participants ;
– Mettre à disposition des utilisateurs des performances élevées en termes de débits de transactions.
Nous nous proposons de concevoir et réaliser un système de sécurisation du cadastre qui implémentera trois modules : un module inventaire, un module de contrôle d’accès et un module logs. Fort de cela, nous avons choisi d’utiliser Hyperledger Fabric. C’est une implémentation de la technologie Blockchain basée sur le projet Hyperledger et fondée par la communauté Linux.
Dans la suite, nous faisons un petit focus sur la technologie blockchain en général, avant de présenter notre architecture pour finir avec les outils utilises.

Généralités sur la blockchain

Cette section va nous permettre de définir des concepts nécessaires à la compréhension complète de la technologie blockchain.

Définition de la blockchain :

Afin de définir de manière complète et exhaustive la blockchain, prenons ces définitions:
« Voici plusieurs définitions qui, crescendo, devraient permettre de mieux comprendre ce qu’est la blockchain:
– Généraliste : une blockchain est une technologie pour une nouvelle génération d’applications transactionnelles qui, grâce à un mécanisme de consensus collectif couplé avec l’utilisation d’un grand livre de compte public, décentralisé et partagé, établit la confiance, la responsabilité et la transparence tout en rationalisant les processus d’affaires.
– Technique : une blockchain est une nouvelle technologie de base de données s’appuyant et tirant pleinement profit d’Internet, du protocole libre, de la puissance de calcul et de la cryptographie. Cette base de données transactionnelle et distribuée est comparable à un grand livre comptable (registre ou ledger) dans lequel chaque nouvelle transaction est écrite à la suite des autres, sans avoir la possibilité de modifier ou d’effacer les précédentes. Ce registre est actif, chronologique, distribué, vérifiable et protégé contre la falsification par un système de confiance repartie (consensus) entre les membres ou participants (nœuds). »
De ces réflexions de Leloup, on remarque que certains termes reviennent assez souvent: registre distribué, stockage, décentralisé, transaction, confiance, sécurité. Ces termes sont essentiels et constituent dans leur ensemble le socle sur lequel repose la technologie blockchain. En effet, pour faire une synthèse des définitions proposées plus haut, on peut décrire la blockchain comme une technologie pair-à-pair, permettant de partager des registres dans lequel sont stockées des informations traçables et sécurisées par un mécanisme de cryptographie, et décentralisée (comme les pairs ne sont liés que par un consensus défini au départ (confiance)).
Pour progresser dans la compréhension de la technologie blockchain, il est important de connaitre ses propriétés.

Propriétés de la blockchain :

– Décentralisation : La propriété première et majeure de la blockchain est la décentralisation de la confiance. Il n’y a pas de teneur de registre, de tiers de confiance, d’intermédiaire. D’ailleurs même s’il existait, il serait inutile car les registres sont infalsifiables, tout élément qu’on y inscrit devient de facto immuable. Chaque bloc contient l’empreinte du bloc précèdent, d’où̀ l’appellation de chaines de blocs. De surcroit, l’intégralité de la blockchain est copiée sur l’ensemble du réseau.
– Horodatage : Aussi, la blockchain a une propriété non négligeable : l’horodatage. Elle atteste de façon indéniable du moment exact où̀ a été effectuée une transaction. Ainsi, chaque nouvelle entrée ne peut donc être ni falsifiée ni antidatée.
– Consensus: Ultimement, la pierre angulaire des différentes technologies blockchain est le processus de validation. En effet, c’est ce processus qui nous permet de garantir l’horodatage et l’immutabilité des registres. De manière fonctionnelle, tout le processus de validation découle d’un consensus atteint par l’ensemble des validateurs de la blockchain avant validation de chaque nouveau bloc.
– Résilience : Enfin, la dernière et non moins importante propriété d’une technologie blockchain est la résilience d’un tel système. En effet, l’inaltérabilité et la transparence que nous assure la blockchain font que tout le monde peut créer un nouveau, à partir du moment où un consensus est atteint. Cependant, cela nécessiterait qu’utilisateurs et validateurs acceptent de rejoindre ce nouveau système, ce qui n’est pas évident. A noter que ce système est lui aussi susceptible à une éventuelle subdivision, ce qui diminue drastiquement la probabilité qu’une telle chose arrive.

Les types de consensus :

Pour avoir un ordre défini des transactions et ainsi avoir un registre cohérent, les nœuds du réseau doivent tomber d’accord sur un algorithme qui définira la manière de valider et d’ordonner les transactions. Parmi ces algorithmes, on peut citer :
– Proof-of-work (Preuve de Travail) : Des algorithmes de hachage ou des puzzles mathématiques doivent être exécutés pour valider les transactions. Utilisée par Bitcoin et Ethereum.
– Proof-of-stake (Preuve d’enjeu) : Pour prétendre valider une transaction, le nœud doit posséder une certaine quantité de crypto-monnaie. Ethereum compte migrer vers ce consensus.
– Proof-of-use (Preuve d’utilisation) : Plus le nœud est actif dans le réseau, plus son droit de valider les transactions augmentent.
– Proof-of-possession (Preuve de possession) : Plus longtemps l’utilisateur détient la crypto-monnaie, plus il a droit de validation.

Bitcoin et Ethereum

Bitcoin

Présentation :
En Octobre 2008, un internaute anonyme, caché derrière le pseudonyme de Satoshi Nakamoto, propose le lancement d’une nouvelle monnaie numérique dans un papier scientifique intitulé « Bitcoin : A Peer-to-Peer Électronique Cash System ». Bitcoin est né. Par sa nature, cette monnaie est appelée à créer une véritable révolution dans le monde de la finance. Avant d’aller plus loin, il est important d’éclaircir un point : quand on parle de Bitcoin, on fait référence soit à la crypto-monnaie, soit au protocole sous-jacent qui est à l’origine de la génération de cette crypto-monnaie.
Bitcoin est la première blockchain existante. Plus exactement, elle est l’application à l’origine de l’avènement de la blockchain. L’engouement qu’elle a suscité à sa création est justifié par une prouesse historique : c’est la première technologie qui est arrivée à empêcher la double dépense sans un organe central de contrôle.
Nous connaissons tous les artefacts numériques et la facilité avec laquelle ils peuvent être copies. Cette facilité crée des problèmes évidents lorsqu’on envisage d’utiliser de tels objets pour représenter des actifs comme l’argent. Ainsi, Qu’est-ce qui empêcherait quelqu’un de faire des copies et de dépenser le même argent deux fois ? Traditionnellement, cette question est résolue en faisant appel à un tiers pour tenir le grand livre en toute confiance. Les banques, les sociétés émettrices de cartes de paiement et les services de paiement en sont des exemples. Ils tiennent tous des registres numériques pour régler le problème de la double dépense.
Par conséquent, il n’est généralement pas possible pour deux parties d’échanger de la valeur en ligne sans impliquer également un tiers de confiance dans le processus de règlement. C’est-à-dire que cela n’était pas possible avant que Bitcoin démontre une nouvelle méthode pour résoudre le problème de la double dépense.
Plus précisément, Bitcoin résout le problème en remplaçant le tiers de confiance par un réseau de gardiens et mainteneurs du grand registre. Ils ont chacun une réplique du grand livre et ils s’en servent pour observer les changements proposés et parvenir à un consensus sur les nouveaux états du grand livre. Nous les appellerons des nœuds. Personne ne peut apporter une quelconque modification au grand livre sans avoir d’abord obtenu le consensus du réseau. C’est comme si chaque transaction est observée par une grande foule de témoins qui forment un consensus sur tout ce qui s’est produit et qui interdisent même les évènements qui ne devraient pas se produire. Les évènements qui ne devraient pas se produire comprennent les dépenses de fonds inexistants et les doubles dépenses.
Fonctionnement :
Imaginons que l’on veuille conserver et surveiller les modifications apportées à un fichier, par exemple un fichier journal. De plus, imaginons que l’on veuille vérifier un historique ininterrompu de tous les changements jamais apportés au fichier. Comment pourrait-on procéder ?
Une solution bien connue utilise des fonctions de hachage cryptographique. Présentons brièvement le concept :
La fonction de hachage cryptographique idéale a cinq propriétés principales :
– Elle est déterministe, de sorte que le même message aboutit toujours au même hachage.
– Il est rapide de calculer la valeur de hachage pour n’importe quel message donné.
– Il est impossible de générer un message à partir de sa valeur de hachage, sauf en essayant tous les messages possibles.
– Une petite modification d’un message devrait modifier la valeur de hachage de telle sorte que la nouvelle valeur de hachage ne semble pas corrélée avec l’ancienne valeur de hachage.
– Il est impossible de trouver deux messages différents avec la même valeur de hachage.
Notons que :
– Il existe différents algorithmes de hachage qui aboutissent tous à des résultats ayant les propriétés décrites ci-dessus ;
– Chaque algorithme de hachage produit systématiquement des hachis de la même taille, quelle que soit la taille de l’entrée ;
– Un hachage peut être utilisé pour prouver qu’une entrée correspond exactement à l’original, mais l’original ne peut pas être reconstruit à partir d’un hachage ;
Passons désormais à une démonstration :
– D’abord, commençons avec la première version d’un fichier et enregistrons un hachage du contenu du fichier ;
– Ensuite, supposons que nous n’ajouterons de nouvelles entrées qu’à la fin du fichier;
– Faisons enfin une règle stipulant qu’en plus du nouveau contenu, le hachage précèdent sera également une entrée pour le hachage suivant.
En résumé, la règle se présentera comme suit:
Hash (NouveauFichier) = hash (NouveauContenu + hash(FichierPrécédent) )
De ce fait, à chaque tentative de modification du fichier, on peut d’abord vérifier si le fichier précèdent est correct, et en fin de compte apporter les changements subséquents avec exactitude. Ce processus se répète pour toutes les versions ultérieures. Toute version du contenu du fichier fait partie d’une chaine ininterrompue de changements depuis le début du fichier. Tout écart par rapport au système, par exemple un hachage ne se calculant pas comme prévu, prouve une rupture dans l’historique et est donc invalide.
Il serait intéressant de noter que, puisque le hachage de la dernière version valide est une entrée à la fonction de hachage de la version suivante, il n’est pas possible de générer une nouvelle version valide sans connaitre la version qui la précède. Ce processus force les modifications à être ajoutées à une version valide précédente. Bitcoin fonctionne de la même manière. Les blocs de transactions sont ajoutés en utilisant les hash des blocs précédents comme entrées dans les hash des blocs suivants. Tout participant peut rapidement vérifier une chaine ininterrompue de blocs (dans l’ordre correct).
Les blocs de transactions sont des unités logiques qui regroupent un ensemble de transactions dans un ordre spécifique. L’ordonnancement des transactions est étonnamment difficile dans un système en chaîne de blocs en raison des objectifs et des contraintes de conception. En tant que réseau distribué, tout le monde a un peu d’autorité. Par exemple, tous les nœuds peuvent générer des transactions et ensuite annoncer cette information à d’autres nœuds. N’importe qui peut, théoriquement, écouter les propositions de transaction et organiser un bloc valide contenant une opinion sur l’ordre correct des évènements. En raison de la physique et de la latence du réseau, tous les membres du réseau apprendront les propositions de transaction dans un ordre légèrement diffèrent. Comment déterminer l’ordre correct des transactions ?
Même si nous supposons que tous les membres du réseau ont de bonnes intentions et participent honnêtement, ils arriveront surement à des opinions quelque peu différentes sur l’ordre correct des transactions et il n’y a pas de façon évidente de régler la question. L’ordre des transactions doit être résolu parce que le traitement des transactions non conformes produit des différences non triviales dans les résultats. Sans accord sur l’ordre des transactions, il ne peut y avoir d’accord sur les résultats.
Bitcoin utilise un processus appelé Proof-of-Work qui peut être considéré(de façon simpliste) comme une loterie. Les bitcoins sont générés lorsque les ordinateurs de ce réseau résolvent des problèmes difficiles de cryptographie, une procédure connue sous le nom de « minage » de Bitcoin. Le mécanisme du système Bitcoin a été mis en place de telle sorte qu’il devient progressivement plus difficile de « miner » les Bitcoins au fil du temps, et le nombre total qui ne peut jamais être extrait est limité à environ 21 millions. Il n’y a donc aucun moyen pour une banque centrale d’émettre un flot de nouveaux Bitcoins et de dévaloriser ceux qui sont déjà en circulation ». Le premier nœud (ou mineur) qui réussit à résoudre le problème mathématique gagne les bitcoins génères et le privilège de faire autorité pour un bloc de transactions. Le ticket de loterie gagnant, appelé nonce, est utilisé comme une autre entrée pour la fonction de hachage. Ceci est facilement vérifiable par les autres participants. L’avis du gagnant de la loterie sur l’ordre des transactions dans le bloc devient le résultat officiel de facto du réseau.
Dans le cas où ce qui précède n’est pas clair : un bloc valide est un ensemble de transactions bien ordonné, contient le hash du bloc précèdent, et contient un « ticket de loterie gagnant » (nonce). Les autres participants reconnaissent cette combinaison improbable (improbable en raison du billet de loterie gagnant) et acceptent le bloc comme une opinion correcte de facto sur l’ordre des transactions. Ce processus règle l’ordre des transactions, même si des nœuds bien intentionnés parviennent indépendamment à des opinions légèrement différentes sur la question.
En définitive, retenons que Bitcoin est la première blockchain et utilise comme algorithme de validation des blocs le Proof of Work. Elle sert principalement de monnaie pour des grosses transactions du fait de ses frais de transactions élevées ainsi que d’actif d’investissement grâce à la montée prodigieuse de sa valeur. Elle ne peut cependant pas être utilisée facilement pour autre chose qu’un moyen de paiement.

Ethereum

Présentation :
Ethereum est une technologie Blockchain créée par Vitalik Buterin. A travers Ethereum, Buterin se propose de concevoir une application qui utilise de manière plus complète les propriétés de la Blockchain, plus généraliste qu’une simple application de transfert d’argent. C’est la raison pour laquelle, Ethereum est souvent appelée la Bitcoin 2.0.
Dans sa forme la plus simple, Ethereum est une plate-forme logicielle ouverte basée sur la technologie de la chaîne de blocs qui permet aux développeurs de construire et de déployer des applications décentralisées. Une application décentralisée ou Dapp sert un but particulier à ses utilisateurs. Bitcoin, par exemple, est un Dapp qui fournit à ses utilisateurs un Programmeur russo-canadien, né le 31 Janvier 1994 à Kolomna (Moscou). Il publie le livre blanc de Ethereum en Novembre 2013. Système de paiement électronique de pair à pair qui permet les paiements Bitcoin en ligne. Parce que les applications décentralisées sont composées de codes qui s’exécutent sur un réseau à chaîne de blocs, elles ne sont pas contrôlées par un individu ou une entité centrale.
Comme Bitcoin, Ethereum est une blockchain publique . Bien qu’il y ait quelques différences techniques significatives entre les deux, la distinction la plus importante à noter est que Bitcoin et Ethereum diffèrent substantiellement en termes d’objectif et de capacité. Bitcoin offre une application particulière de la technologie de la chaîne de blocs, un système de paiement électronique de pair à pair qui permet des paiements en ligne, tandis qu’Ethereum se concentre sur l’exécution du code de programmation de toute application décentralisée, appelé « smart contract » ou contrat intelligent.
Les contrats intelligents sont simplement des programmes informatiques qui exécutent des actions prédéfinies lorsque certaines conditions du système sont remplies. C’est une expression utilisée pour décrire un code informatique qui peut faciliter l’échange d’argent, de contenu, de biens, d’actions ou de tout ce qui a de la valeur. Lorsqu’il est exécuté sur la blockchain, un contrat intelligent devient comme un programme informatique autonome qui s’exécute automatiquement lorsque des conditions spécifiques sont remplies. Parce que les contrats intelligents s’exécutent sur la blockchain, ils fonctionnent exactement comme programmés sans aucune possibilité de censure, de temps d’arrêt, de fraude ou d’interférence de tiers.
Dans la chaîne de blocs d’Ethereum, au lieu d’extraire du bitcoin, les mineurs travaillent pour gagner de l’Ether, un type de jeton cryptographique qui alimente le réseau. Au-delà d’une crypto-monnaie négociable, Ether est également utilisé par les développeurs d’applications pour payer les frais de transaction et les services sur le réseau Ethereum.

Fonctionnement :
Pour valider les transactions, les mineurs d’Ethereum utilisent aussi l’algorithme du Proof of work. Ils sont rétribués en gaz, qui est sous-unité de la crypto-monnaie Ether. L’innovation centrale d’Ethereum, la Machine Virtuelle Ethereum (Ethereum Virtual Machine ou EVM) est un logiciel complet de Turing qui fonctionne sur le réseau Ethereum. Il permet à n’importe qui d’exécuter un contrat intelligent avec suffisamment de temps et de mémoire.
La machine virtuelle d’Ethereum rend le processus de création d’applications blockchain beaucoup plus facile et efficace. Au lieu de devoir construire une blockchain entièrement originale pour chaque nouvelle application, Ethereum permet le développement de milliers d’applications différentes sur une seule plate-forme.
Parce que les applications décentralisées s’exécutent sur la blockchain, elles bénéficient de toutes ses propriétés :
– Immutabilité : Un tiers ne peut apporter aucune modification aux données ;
– Incorruptibilité et inviolabilité : Les applications sont basées sur un réseau formé autour du principe du consensus, rendant la censure impossible ;
– Sécurisé: Sans point central de défaillance et sécurisé par un mécanisme de cryptographie, les applications sont bien protégées contre les attaques de piratage et les activités frauduleuses ;
– Zéro temps d’arrêt : Les applications ne s’arrêtent jamais et ne peuvent jamais être éteintes.

Autres applications de la blockchain :

Ripple :
C’est le nom d’un réseau de paiement et du protocole utilisé. Développé et publié en 2012 par une société du même nom, afin de permettre des « transactions financières mondiales sécurisées, instantanées et quasiment gratuites », il est construit sur des principes similaires à ceux de la blockchain Bitcoin, donc parfois considéré comme une crypto-monnaie. Mais le code est privé, donc invérifiable par des tiers. De nombreuses banques l’utilisent comme base de leur propre infrastructure de règlement.
Litecoin :
C’est une blockchain tirée de Bitcoin. Ce type de crypto-monnaie est appelé alt-coin. Comme Bitcoin, il utilise l’algorithme de Proof of work pour valider et ordonner les transactions, mais de difficulté différente. Conséquemment, les blocs sont validés plus rapidement, et leur taille est plus importante.
Lisk:
Lisk est une blockchain créée en 2016 similaire à Ethereum. Il permet de faciliter le développement et l’hébergement des Dapps. Lisk est une plateforme entièrement conçue avec Node.js et les applications décentralisées qui y sont déployées sont écrites en Javascript.

Classification des blockchains :

Selon la manière de gérer le consensus au sein du réseau et le type d’accès au registre distribué, nous distinguons 3 types de blockhains : les blockchains publiques, les blockchains hybrides (consortium) et les blockchains privées. Nous spécifierons les particularités de chacune d’elles dans la sous-section qui suit.

Blockchain publique

C’est le type de Blockchain considérée par les puristes comme le seul qui mérite le nom de blockchain. Ici, tout le monde peut participer sans restriction. Tout le monde peut télécharger le code et l’exécuter sur son propre appareil, valider les transactions dans le réseau, et ainsi participer au processus de consensus pour décider quel bloc ajouter à la chaîne. N’importe qui peut proposer une transaction et espérer qu’elle soit ajoutée à la blockchain si elle est considérée comme valide. Enfin, tout le monde peut lire les transactions dans les explorateurs publics. Les transactions sont transparentes, mais anonymes ou à la limite pseudonymes.
Les blockchains comme Bitcoin ou Ethereum sont des blockchains publiques.

Blockchain hybride

Une blockchain hybride est aussi appelée blockchain fédérée ou consortium. Elles sont sous la direction d’un groupe. Contrairement aux blockchains publiques, les transactions ne peuvent pas être validées par n’importe qui. Les transactions dans un consortium sont plus rapides, et leur confidentialité est assurée. Les consortiums sont utilisés le plus souvent dans le secteur bancaire. Le processus du consensus est contrôlé par des nœuds présélectionnés. On peut imaginer par exemple un ensemble de quinze (15) sociétés financières, chacune représentant un nœud, parmi lesquels dix (10) doivent signer un bloc pour que celui-ci soit considéré comme valide. Le droit de lire les transactions peut être public, ou limité qu’aux participants.

Blockchain privée

Ici, les permissions d’écriture sont réservées à une organisation centralisée. Les permissions de lecture quant à elles sont publiques ou restreintes aux participants.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION GENERALE
Chapitre I. Présentation générale
I.1. Contexte
I.2. Problématique
I.3. Objectifs
Chapitre II. Méthode de travail
II.1. Généralité
II.2. Caractéristiques de notre projet
II.3. Présentation de UML
Chapitre III. Analyse et spécification des besoins
III.1. Étude et analyse des besoins
III.1.1. Besoins fonctionnels
III.1.2. Besoins non fonctionnels
III.1.3. Besoins optionnels
III.1.4. Identification des acteurs
III.2. Spécification des besoins
III.2.1. Vision globale du comportement fonctionnel du système
III.2.2. Description des fonctionnalités
III.2.2.1. Description de la fonctionnalité « s’identifier »
III.2.2.2. Description de la fonctionnalité « consulter logs »
III.2.2.3. Description de la fonctionnalité « Gérer Titre Foncier »
III.2.2.4. Description de la fonctionnalité « Gérer Transfert Titre Foncier »
III.2.2.5. Description de la fonctionnalité « Gérer Contrats de bail»
III.2.2.6. Description de la fonctionnalité « Avoir Un Bail »
III.2.2.7. Description de la fonctionnalité « Transformer un Bail en titre foncier »
III.2.2.8. Description de la fonctionnalité « Acheter Titre Foncier »
Chapitre IV. Conception de la solution
IV.1. Généralités sur la blockchain
IV.1.1. Définition de la blockchain
IV.1.2. Propriétés de la blockchain
IV.1.3. Les types de consensus
IV.1.4. Bitcoin et Ethereum
IV.1.4.1. Bitcoin
IV.1.4.2. Ethereum
IV.1.5. Autres applications de la blockchain
IV.1.6. Classification des blockchains
IV.1.6.1. Blockchain publique
IV.1.6.2. Blockchain hybride
IV.1.6.3. Blockchain privée
IV.1.6.4. Comparaison
IV.2. Architecture de la solution proposée
IV.2.1. Architecture fonctionnelle
IV.2.2. Architecture logicielle
IV.3. Présentation des outils
IV.3.1. Hyperledger Fabric
IV.3.1.1. Les origines de Fabric : le projet Hyperledger
IV.3.1.2. Les caractéristiques de Hyperledger Fabric
IV.3.1.3. Le fonctionnement de Hyperledger Fabric
IV.3.2. Hyperledger Composer
IV.3.2.1. Présentation de Hyperledger Composer
IV.3.2.2. Présentation des concepts-clés:
IV.3.3. Angular
IV.3.4. Docker
IV.3.5. Yeoman
IV.3.6. Rôles des outils dans l’architecture logicielle
Chapitre V. Réalisation de la solution
V.1. Mise en place du réseau d’entreprise
V.1.1. Composer-Playground
V.1.2. Modélisation du réseau d’entreprise
V.1.3. Test du réseau d’entreprise
V.2. Déploiement du réseau d’entreprise sur Hyperledger Fabric
V.2.1. Lancement de Fabric
V.2.2. Déploiement de l’archive sur les pairs
V.2.3. Démarrage du serveur REST
V.3. Présentation de l’application web Angular
V.3.1. Environnement matériel
V.3.2. Présentation du résultat
CONCLUSION GENERALE
ANNEXE
REFERENCES BIBLIOLOGIQUES

Télécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

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