Soutenance mémoire
Implémentation du « proof-of-concept »
Proof-of-Work (PoW)
Ce mécanisme est historiquement le plus connu et le plus utilisé au sein des blockchains actuelles. En effet, il a été introduit avec l’avènement du « Bitcoin » et est aujourd’hui largement représenté au sein des cryptomonnaies en tant que processus de validation des blocs. Le principe caché derrière le « PoW » est relativement simple. Chaque participant du système souhaitant participer au processus de validation d’un bloc doit résoudre un problème mathématique. Le problème est formulé de telle sorte à ce que la solution soit complexe à trouver (besoin d’une puissance de calcul conséquente, et donc énergivore) et néanmoins facilement vérifiable par les autres participants (Natoli et al., 2019). Le premier participant ayant trouvé la solution la transmet au système. Le restant des participants doivent ensuite vérifier et valider la solution afin que le bloc soit ajouté à la chaîne. Le vainqueur est donc considéré comme le créateur du bloc et reçoit une contrepartie financière pour sa preuve de travail (Andoni et al., 2019).
La méthode de fonctionnement du « PoW » présente l’avantage d’être complètement « décentralisée » et donc d’offrir l’opportunité à tous les participants du réseau d’être sélectionné pour le processus de validation du bloc. Cela induit que ce « consensus » est particulièrement pertinent dans le cadre d’une blockchain « publique ». En matière de « sécurité », le mécanisme est néanmoins soumis à quelques limites qui doivent être prises en considération. En effet, le calcul de solution et la vérification de cette dernière reposent sur les membres ayant la plus grande puissance de calcul au sein du réseau. De ce fait, si un participant parvenait à obtenir une puissance de calcul cumulée dépassant 51 % de la puissance de calcul totale du réseau, il aurait théoriquement le pouvoir sur l’ensemble du réseau. Si ce scénario semble pratiquement impossible au sein de vastes réseaux (ex. : Bitcoin, Ethereum), il est néanmoins envisageable si le nombre de participants venait à être plus restreint (Garg, 2020). La sécurité est donc accrue plus la taille du réseau est importante. D’un point de vue « évolutivité », le constat est radicalement opposé à celui de la sécurité. La puissance de calcul, et donc l’énergie nécessaire, à la résolution du problème mathématique lors de la validation d’un bloc est proportionnellement liée à la taille de la chaîne et au nombre de participants. Par conséquent, plus la chaîne est grande et plus le temps nécessaire à la résolution du problème est important (ex. : la validation d’un bloc au sein de la blockchain « Bitcoin » nécessite aujourd’hui environ huit minutes (Blockchain.com, 2020b)).
Proof-of-Stake (PoS)
Il existe à ce jour de nombreuses implémentations de ce mécanisme (ex. : « Proof-of-Lock », « Proof-ofDeposit », « Proof-of-Activity », « Delegated Proof-of-Stake », « Proof-of-Burn », etc.). Afin de simplifier la compréhension de ces concepts, nous allons rester focalisés sur l’implémentation de base qu’est « Proof-ofStake ». Ce mécanisme a directement été pensé pour combler les faiblesses identifiées au sein du consensus « PoW ». En effet, le caractère extrêmement énergivore et le temps de traitement nécessaire à la validation des transactions au sein d’un système « PoW » ont contribué à la naissance d’alternatives moins coûteuses en temps et en ressources. « PoS » tente de solutionner ces deux problématiques par l’introduction d’un nouveau mode de sélection des participants à la validation d’un bloc : la preuve d’enjeu. Le mécanisme remplace le principe de résolution de problèmes complexes (qui nécessitait beaucoup de puissance de calcul et de temps) par un principe de dépôt de « valeur », apporté par le participant souhaitant être sélectionné pour la validation du bloc. Concrètement, plus le participant dépose un montant important de « valeur » (généralement utilisés dans le milieu des cryptomonnaies, nous pouvons traduire « valeur » par « montant » de la devise implémentée au sein de la blockchain), plus son vote aura d’influence lors de la validation d’un bloc. Si le participant se montre être « honnête », il gardera sa mise en sa possession. Dans le cas où un comportement frauduleux est détecté, il perdra instantanément le montant qu’il a misé (Natoli et al., 2019).
Le processus mis en avant par « PoS » est extrêmement intéressant en tant qu’alternative au consensus « PoW ». En effet, il garde les avantages apportés par « PoW », notamment en matière de « décentralisation » en permettant à tous les « noeuds » du système de participer au processus de validation d’un bloc. Il apporte également, contrairement à son prédécesseur, un mécanisme moins énergivore et considérablement plus rapide. Cet état de fait contribue à faire de « PoS » un mécanisme nettement plus « évolutif » que « PoW ».
Cependant, le système de « mise » ou de dépôt de « valeur » proposé dans ce mécanisme suscite également quelques problèmes du point de vue de la « sécurité ». Théoriquement, si un ou plusieurs participants arrivaient à détenir plus de 51 % de la valeur totale de la chaîne, le poids de son vote surpasserait l’ensemble des autres participants. Un certain nombre d’attaques connues ont également vu le jour concernant ce « consensus » (Martinez, 2018). Il est important de toute fois préciser que certaines sous-implémentations du « PoS » tendent à corriger ces problèmes en instaurant des mécanismes de punitions ou en introduisant une notion de sélection « aléatoire » à chaque nouvelle validation (Andoni et al., 2019).
Practical Byzantine Fault Tolerance (PBFT)
En informatique, le problème de la tolérance aux pannes (ou aux nœuds défaillants, dans le cadre de la blockchain) dans un système « distribué » et « décentralisé » est généralement illustré par le théorème intitulé « Byzantine Generals Problem » (Lamport et al., 1982). Cette problématique vise à identifier le moyen de faire passer un message au sein d’un réseau distribué, tout en étant conscient que les membres de ce réseau puissent être inatteignables ou malveillants. Le but étant qu’une fois le message passé, les membres ayant autorité sur le réseau puissent prendre la bonne décision, malgré un nombre potentiel d’informations malveillantes reçues (Natoli et al., 2019). Ce concept a inspiré un grand nombre d’algorithmes connus dans le monde informatique, et a également fait l’objet d’un certain nombre d’implémentations en tant que mécanisme de « consensus » au sein des blockchains modernes. Le « PBFT » est un mécanisme de « consensus » qui repose sur ce principe. La particularité de ce mécanisme, contrairement au « PoW » et au « PoS » est que les nœuds ayant autorité pour la validation des blocs (les « généraux ») sont connus à l’avance. Ils sont directement définis au sein de la configuration de la blockchain elle-même. De ce fait, il est important de noter que ce type de « consensus » est particulièrement adapté aux blockchains « privées » et n’est donc pas réellement viable dans une implémentation « publique ». En matière de « sécurité », le « PBFT » accepte un taux de défaillance (ou des nœuds malveillants) inférieur ou égal à un tiers (≤ 33.3 %) des nœuds (Bach et al., 2018). Si le degré de sécurité semble être nettement inférieur à « PoW » et « PoS » de prime abord, il est important de prendre en compte que nous sommes dans un environnement « privé » et « connu ». Par conséquent, le nombre et l’identité des nœuds participants à la validation des blocs peuvent être maîtrisés, contrairement aux environnements « publics ». En matière d’ « évolutivité », le « PBFT » ne semble pas réagir aussi bien que ses prédécesseurs. Induit par le nombre de messages qui transitent entre les nœuds, le temps nécessaire au traitement et à la diffusion des messages augmente de manière exponentielle (des problèmes de performances peuvent être constatés à partir de 20 nœuds (Galas, 2018)). Cependant, tout comme pour les aspects sécuritaires, il est important de comprendre que le nombre de nœuds sera drastiquement plus faible dans un environnement « privé » par rapport à un environnement « public ». Un utilisateur du système n’est pas nécessairement compté comme un « noeud » au sein d’une blockchain « privée ». Le nombre de nœuds (ou de « replicas » de la chaîne) est défini dans la configuration de la blockchain. Finalement, nous pouvons d’ores et déjà statuer que ce type de « consensus » n’influe pas positivement sur la « décentralisation » du système. Les nœuds dépositaires du processus de validations étant connus et sélectionnées en amont de la création de la blockchain, le recours à une ou plusieurs autorités de contrôles centrales est par définition incontournable.
Proof-of-Authority (PoA)
Dans un contexte similaire à celui du « PBFT », le mécanisme de consensus « PoA » préconise l’utilisation d’une liste d’autorités (nœuds) connues à l’avance et ayant le droit de participer au processus de validation d’un bloc.
L’ensemble des autorités, défini lors de la configuration de la « blockchain », forment un comité étant le seul garant de la validation des blocs et du « consensus » de la blockchain. À chaque nouveau processus de validation, un membre du comité est sélectionné en tant que « leader » et propose un bloc au restant des membres. Si les membres valident le bloc, il est ajouté à la chaîne. Toute fois, si le bloc est considéré comme étant invalide, le « leader » peut être expulsé du comité et le bloc est donc rejeté. Le principal objectif de cette approche était de créer un mécanisme capable de réduire drastiquement le gaspillage énergétique des consensus tels que « PoW » et était initialement prévu pour des environnements de tests (Natoli et al., 2019).
Néanmoins, ce type de consensus tant à gagner en popularité, notamment dans le secteur énergétique, lorsque le système nécessite que l’intégrité et la sécurité des données soient préservées à tout prix (Andoni et al., 2019). En matière de « sécurité », le « PoA » est capable de tolérer un pourcentage de nœuds malveillants supérieur au « PBFT » (< 51 % des nœuds ayant autorité). Toutefois, il est important d’observer en détail les systèmes d’information particularités de chaque implémentation du « PoA » (ex. : « Aura », « Clique ») afin d’assurer que la position de « leader » ne permet pas d’effectuer des validations de blocs malveillantes, au détriment du comité. En termes d’« évolutivité » et de performances, le « PoA » outrepasse les problèmes rencontrés par le « PBFT » grâce au concept de sélection d’un « leader » lors de la validation d’un bloc. Cependant, comme nous l’avons mentionné précédemment, ce gain en performance peut-être parfois obtenu au détriment de l’intégrité des données (Angelis et al., 2017). Concernant les aspects liés à la « décentralisation », le « PoA » se situe dans la même catégorie que le « PBFT » en proposant un mécanisme de « consensus » centralisé pouvant néanmoins, au contraire de « PBFT », être envisagé au sein d’une architecture de blockchain « publique ».
Proof-of-Elapsed-time (PoET)
Ce consensus fait partie d’une nouvelle génération de mécanismes, régulièrement nommé en tant que : « Trusted Execution Environments (TEE) ». La particularité de cette famille de consensus réside dans la méthode avec laquelle elle tente de garantir la « confiance » accordée aux nœuds du système « blockchain ».
Les « TEEs », et par transitivité le « PoET » utilisent des algorithmes de sélection aléatoires, basés sur les composants « matériels » de chaque nœud. En effet, ce système est capable de remplacer les preuves de travail (« PoW ») ou les preuves d’enjeux (« PoS ») analysés précédemment, par un processus de sélection basé sur un facteur « aléatoire ». Dans le contexte du « PoET », la blockchain est en capacité d’invoqué une fonction de génération de données aléatoire, directement intégrée au sein du matériel (le processeur de la machine) de chaque nœud du système. Le résultat envoyé par cette fonction permettra au mécanisme « PoET » de déterminer le nœud sélectionné pour la validation du bloc (il se base notamment sur le temps le plus faible, écoulé entre l’initialisation de la fonction et l’obtention de la réponse) (Natoli et al., 2019). Cette technologie
est aujourd’hui intégrée et développée par les plus grands fabricants de matériel informatique tels que Intel (Intel Corporation, 2020), AMD (Advanced Micro Devices, Inc, 2020) ou IBM (IBM Corporation, 2020).
La « sécurité » est indéniablement le point fort de cette technologie. Si des attaques restent néanmoins possibles, il apparaît clair que le risque de fraude est fortement réduit et plus complexe qu’au sein du reste des « consensus » analysés (Natoli et al., 2019). En matière d’« évolutivité », le « PoET » semble également être très efficace en se reposant sur des technologies directement embarquées dans le matériel des nœuds du système.
Le processus de sélection est ainsi largement plus rapide et moins énergivore que les problèmes à résoudre au sein du mécanisme « PoW ». Néanmoins, si la technologie semble prometteuse en matière de « sécurité » et « évolutivité », elle est intimement liée à la confiance attribuée aux différents constructeurs qui fournissent le matériel agrée. Si le système et le mécanisme de « consensus » et totalement « décentralisé » d’un point de vue architectural, il semble au contraire être « centralisé » sur les plans « logique » et « politique ». Nous ne pouvons par conséquent pas écarter d’éventuelles situations de monopoles ou d’implémentations « frauduleuses », étant dépendantes de l’intégrité et de l’honnêteté des fabricants (Andoni et al., 2019). Synthèse Sur la base de notre analyse, nous pouvons à présent dresser un comparatif des différents mécanismes étudiés sur le plan des trois axes identifiés en introduction de cette partie. Nous allons noter les consensus sur une échelle de 1 à 3 pour chaque axe d’analyse identifié (1 étant « non-couvert » et 3 « couvert »).
Nous pouvons constater que les mécanismes « PoS », « PoA » et « PBFT » semblent être les plus adaptés à notre cas d’utilisation. Néanmoins, si l’on prend en compte le caractère « privé » de notre implémentation, il semblerait que le consensus « PoS » ne soit pas adapté à ce genre d’implémentations. De ce fait, nous privilégierons les mécanismes « PBFT » et « PoA » lors de la sélection de la technologie « Blockchain ».
D Smart contracts
Le « smart contract » (contrat intelligent) fait partie des critères indispensables à la sélection d’une technologie « blockchain » adéquate avec nos besoins. Son implémentation au sein d’un système « blockchain » offre un panel de fonctionnalités qui peut être vital au bon fonctionnement de l’écosystème que l’on souhaite mettre en place. Nous pouvons le définir de la manière suivante : « Un contrat intelligent est une portion de code informatique qui s’exécute au sein de la blockchain pour faciliter, exécuter et faire respecter les termes d’un accord. L’objectif principal d’un contrat intelligent est d’exécuter automatiquement les termes d’un accord une fois les conditions spécifiées remplies. (Alharby & Moorsel, 2017) »
Nous pouvons percevoir le « smart contract » comme un « contrat » numérique, qui lie deux ou plusieurs membres d’un même réseau « blockchain » en exécutant une ou plusieurs opérations. Il est généralement déclenché lors de la soumission d’une transaction au sein de la « blockchain ». Nous pouvons comparer le « smart contract » au système de « procédures stockées » existant au sein des bases de données traditionnelles. La logique « métier » et les opérations déclenchées lors de l’exécution d’un « smart contract » dépendent complètement du contexte de la « blockchain ». En effet, si cette fonctionnalité est très souvent associée au processus d’échange de cryptomonnaie, elle peut également être complètement dissociée de ce type d’opérations.
|
Table des matière
1 Introduction
1.1 Avant-propos
1.2 Contexte
1.3 Objectifs
2 Méthodologie
3 Revue de la littérature
3.1 Introduction à la « Blockchain »
3.1.1 Historique
3.1.2 Concepts fondamentaux
3.1.3 Apports et limites de la technologie
A Avantages et apports
B Inconvénients et limites
3.2 La « Blockchain » dans le contexte de la mobilité électrique
3.2.1 Exemples existants
A Energy Web Foundation
B SwissPower – EWB
4 Analyses et développement
4.1 Architecture et objectifs du projet
4.2 Choix de la technologie « Blockchain »
4.2.1 Mise en place des critères de sélection pertinents
A Architecture et permissions
B Nature et stockage des données
C Mécanismes de « consensus »
D Smart contracts
4.2.2 Technologies retenues
A Synthèse et classification des plateformes
4.3 Implémentation du « proof-of-concept »
4.3.1 Présentation du système
A Authentification
B Accueil
C Liste des ressources
D Détails d’une ressource
E Ajout d’une ressource
4.3.2 Résultats obtenus et difficultés rencontrées
5 Synthèses et conclusion
5.1 La « Blockchain » dans le système implémenté
5.2 Potentiel de la technologie dans le secteur énergétiques
5.3 Conclusions
6 Références
Télécharger le rapport complet
