🥇Blockchain : que nous coûte la construction d'un PoC ?

Les yeux ont peur, mais les mains démangent !

Dans les articles précédents, nous avons exploré les technologies sur lesquelles reposent les blockchains (Quel est le coût de construire une blockchain ?) et les cas d'utilisation qui peuvent être réalisés grâce à elles (Qu'est-ce qui nous empêche de construire un cas ?). Il est temps de mettre la main à la pâte ! Pour réaliser des pilotes et des PoC (Proof of Concept), je préfère utiliser le cloud, car ils sont accessibles de n'importe où dans le monde et, souvent, il n'est pas nécessaire de perdre du temps sur une installation ennuyeuse, car il existe des configurations prédéfinies. Alors, faisons quelque chose de simple, par exemple, un réseau pour transférer des pièces entre participants et appelons-le modestement Cittcoin. Pour cela, nous allons utiliser le cloud IBM et la blockchain universelle Hyperledger Fabric. Commençons par comprendre pourquoi Hyperledger Fabric est appelé blockchain universelle.

Hyperledger Fabric — blockchain universelle

En général, un système d'information universel se compose de :

Un ensemble de serveurs et un cœur logiciel exécutant la logique métier ;
Interfaces pour interagir avec le système ;
Outils pour enregistrer, authentifier et autoriser les dispositifs / personnes ;
Une base de données qui stocke les données opérationnelles et archivées :

La version officielle de ce qu'est Hyperledger Fabric peut être consultée sur site, et en résumé, Hyperledger Fabric est une plateforme open source permettant de construire des blockchains privées et d'exécuter des contrats intelligents arbitrés dans des langages de programmation comme JS et Go. Analysons de plus près l'architecture d'Hyperledger Fabric et vérifions que c'est un système universel, où il n'y a que des spécificités sur le stockage et l'enregistrement des données. La spécificité réside dans le fait que les données, comme dans tous les blockchains, sont stockées dans des blocs, qui ne peuvent être ajoutés à la blockchain que si les participants parviennent à un consensus, et une fois enregistrées, les données ne peuvent pas être modifiées ou supprimées furtivement.

Architecture d'Hyperledger Fabric

Le schéma montre l'architecture d'Hyperledger Fabric :

Organisations — les organisations contiennent des pairs, de sorte que la blockchain existe grâce au soutien des organisations. Différentes organisations peuvent faire partie d'un même canal.

Channel — une structure logique qui regroupe des pairs, définissant ainsi la blockchain. Hyperledger Fabric peut traiter simultanément plusieurs blockchains avec différentes logiques métier.

Fournisseur de services d'adhésion (MSP) — c'est une CA (Autorité de certification) pour l'émission d'identités et l'attribution de rôles. Pour créer un nœud, il est nécessaire d'interagir avec le MSP.

Nœuds pairs — vérifient les transactions, stockent la blockchain, exécutent des contrats intelligents et interagissent avec des applications. Les pairs ont une identité (certificat numérique) délivrée par un MSP. Contrairement au réseau Bitcoin ou Ethereum, où tous les nœuds sont égaux, dans Hyperledger Fabric, les nœuds jouent des rôles différents :

Le pair peut être un pair d'approbation (EP) et exécuter des contrats intelligents.
Le pair d'engagement (CP) — sauvegarde uniquement les données dans la blockchain et actualise l'état mondial.
Pair d'ancrage (AP) — si plusieurs organisations participent à la blockchain, les pairs d'ancrage sont utilisés pour établir des liens entre elles. Chaque organisation doit avoir un ou plusieurs pairs d'ancrage. Grâce à l'AP, tout pair d'une organisation peut obtenir des informations sur tous les pairs des autres organisations. Pour synchroniser les informations entre les AP, le protocole de gossip.
Pair leader — si une organisation a plusieurs pairs, seul le pair leader recevra des blocs du service de commande et les distribuera aux autres pairs. Le leader peut être assigné statiquement ou être choisi dynamiquement par les pairs de l'organisation. Pour synchroniser les informations sur les leaders, le protocole de gossip est également utilisé.

Actifs — entités ayant de la valeur, stockées dans la blockchain. Plus précisément, ce sont des données clé-valeur au format JSON. Ce sont ces données qui sont enregistrées dans la blockchain «Blockchain». Elles ont une histoire, qui est conservée dans la blockchain, et un état actuel qui est stocké dans la base de données «World state». Les structures de données sont remplies aléatoirement selon les exigences commerciales. Il n'y a pas de champs obligatoires, la seule recommandation est que les actifs doivent avoir un propriétaire et représenter de la valeur.

Grand livre — composé de la blockchain «Blockchain» et de la base de données «World state», dans laquelle l'état actuel des actifs est stocké. L'état mondial utilise LevelDB ou CouchDB.

Contrat intelligent — la logique commerciale du système est implémentée à l'aide de contrats intelligents. Dans Hyperledger Fabric, les contrats intelligents sont appelés chaincode. Avec le chaincode, les actifs et les transactions qui leur sont associées sont définis. En termes techniques, les contrats intelligents sont des modules logiciels réalisés dans les langages de programmation JS ou Go.

Politique d'approbation — pour chaque chaincode, il est possible de définir des politiques concernant le nombre et les membres dont les confirmations sont nécessaires pour une transaction. Si aucune politique n'est définie, la règle par défaut est : "la transaction doit être approuvée par tout membre (member) de n'importe quelle organisation dans le canal". Exemples de politiques :

La transaction doit être approuvée par n'importe quel administrateur de l'organisation ;
Doit être approuvée par tout membre ou client de l'organisation ;
Doit être approuvée par tout peer de l'organisation.

Service de commande — emballe les transactions dans des blocs et les envoie aux peers dans le channel. Garantit la livraison des messages à tous les peers du réseau. Pour les systèmes industriels, on utilise le courtier de messages Kafka, pour le développement et les tests. Solo.

CallFlow

L'application interagit avec Hyperledger Fabric en utilisant les SDK Go, Node.js ou Java ;
Le client crée une transaction tx et l'envoie aux endorsing peers ;
Le peer vérifie la signature du client, exécute la transaction et renvoie la signature d'endossement au client. Le chaincode n'est exécuté que sur l'endorsing peer, et le résultat de son exécution est diffusé à tous les peers. Ce mécanisme de fonctionnement est appelé — consensus PBFT (Practical Byzantine Fault Tolerant). Il se distingue de la BFT classique en ce sens que le message est diffusé et qu'une confirmation est attendue non pas de tous les participants, mais seulement d'un ensemble spécifique ;
Après que le client a reçu un nombre de réponses correspondant à la politique d'endossement, il envoie la transaction au service de commande ;
Le service de commande forme un bloc et l'envoie à tous les committing peers. Le service de commande assure l'enregistrement séquentiel des blocs, ce qui exclut ce qu'on appelle le fork du ledger (voir la section « Forks »);
Les peers reçoivent le bloc, vérifient de nouveau la politique d'endossement, enregistrent le bloc dans la blockchain et modifient l'état dans la base de données « World state ».

C'est-à-dire qu'il y a une séparation des rôles entre les nœuds. Cela assure l'évolutivité et la sécurité de la blockchain :

Les smart contracts (chaincode) sont exécutés par les endorsing peers. Cela assure la confidentialité des smart contracts, car ils ne sont pas stockés par tous les participants, mais seulement sur les endorsing peers.
Le service de commande doit fonctionner rapidement. Cela est assuré par le fait que le service de commande ne fait que former un bloc et l'envoyer à un ensemble fixe de leader peers.
Les committing peers stockent simplement la blockchain — ils peuvent être nombreux et ne nécessitent pas une grande puissance et un fonctionnement instantané.

Pour plus de détails sur les solutions architecturales d'Hyperledger Fabric et pourquoi il fonctionne ainsi, vous pouvez consulter ici : Origines de l'architecture ou ici : Hyperledger Fabric : un système d'exploitation distribué pour blockchains autorisées.

Ainsi, Hyperledger Fabric est vraiment un système polyvalent, qui permet de :

Réaliser une logique commerciale arbitraire en utilisant le mécanisme des smart contracts ;
Enregistrer et récupérer des données depuis une base de données blockchain au format JSON;
Fournir et vérifier l'accès à l'API en utilisant une autorité de certification.

Maintenant que nous avons un peu compris la spécificité d'Hyperledger Fabric, faisons enfin quelque chose d'utile!

Déploiement de la blockchain

Définition du problème

La tâche consiste à implémenter un réseau Citcoin avec les fonctionnalités suivantes : créer un compte, obtenir un solde, approvisionner un compte, transférer des pièces d'un compte à un autre. Dessinons un modèle d'objet que nous allons ensuite implémenter dans un contrat intelligent. Ainsi, nous aurons des comptes qui s'identifient par des noms (name) et contiennent un solde (balance), ainsi qu'une liste de comptes. Les comptes et la liste de comptes sont des actifs en termes d'Hyperledger Fabric. Par conséquent, ils ont une histoire et un état actuel. Je vais essayer de le dessiner visuellement :

Les figures supérieures représentent l'état actuel, qui est stocké dans la base « World state ». En dessous, les figures montrent l'historique qui est conservé dans la blockchain. L'état actuel des actifs est modifié par des transactions. Un actif ne peut être modifié que dans son intégralité, donc à la suite d'une transaction, un nouvel objet est créé et la valeur actuelle de l'actif est envoyée dans l'historique.

Cloud IBM

Créons un compte dans le cloud IBM. Pour utiliser la plateforme blockchain, il faut la mettre à niveau vers Pay-As-You-Go. Ce processus peut prendre du temps, car IBM demande des informations supplémentaires et les vérifie manuellement. En positif, je peux dire qu'IBM a de bons matériaux d'apprentissage, permettant de déployer Hyperledger Fabric dans leur cloud. J'ai apprécié le cycle suivant d'articles et d'exemples :

Voici quelques captures d'écran de la plateforme Blockchain d'IBM. Ce n'est pas un guide sur la création d'une blockchain, mais simplement une démonstration de l'ampleur de la tâche. Alors, pour nos besoins, créons une Organisation :

Nous y créons des nœuds : Orderer CA, Org1 CA, Orderer Peer :

Créons des utilisateurs :

Créons un Canal et appelons-le citcoin :

En substance, un Canal est une blockchain, donc il commence avec le bloc zéro (Genesis block) :

Écrivons un Smart Contract

/*
 * Citcoin smart-contract v1.5 for Hyperledger Fabric
 * (c) Alexey Sushkov, 2019
 */
 
'use strict';
 
const { Contract } = require('fabric-contract-api');
const maxAccounts = 5;
 
class CitcoinEvents extends Contract {
 
    async instantiate(ctx) {
        console.info('instantiate');
        let emptyList = [];
        await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(emptyList)));
    }
    // Get all accounts
    async GetAccounts(ctx) {
        // Get account list:
        let accounts = '{}'
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            accounts = JSON.parse(accountsData.toString());
        } else {
            throw new Error('accounts not found');
        }
        return accountsData.toString()
    }
     // add a account object to the blockchain state identifited by their name
    async AddAccount(ctx, name, balance) {
        // this is account data:
        let account = {
            name: name,
            balance: Number(balance),       
            type: 'account',
        };
        // create account:
        await ctx.stub.putState(name, Buffer.from(JSON.stringify(account)));
 
        // Add account to list:
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            let accounts = JSON.parse(accountsData.toString());
            if (accounts.length < maxAccounts)
            {
                accounts.push(name);
                await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(accounts)));
            } else {
                throw new Error('Max accounts number reached');
            }
        } else {
            throw new Error('accounts not found');
        }
        // return  object
        return JSON.stringify(account);
    }
    // Sends money from Account to Account
    async SendFrom(ctx, fromAccount, toAccount, value) {
        // get Account from
        let fromData = await ctx.stub.getState(fromAccount);
        let from;
        if (fromData) {
            from = JSON.parse(fromData.toString());
            if (from.type !== 'account') {
                throw new Error('wrong from type');
            }   
        } else {
            throw new Error('Accout from not found');
        }
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balances
        if ((from.balance - Number(value)) >= 0 ) {
            from.balance -= Number(value);
            to.balance += Number(value);
        } else {
            throw new Error('From Account: not enought balance');          
        }
 
        await ctx.stub.putState(from.name, Buffer.from(JSON.stringify(from)));
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "SendFrom",
            from: from.name,
            to: to.name,
            balanceFrom: from.balance,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('SendFrom', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
 
    // get the state from key
    async GetState(ctx, key) {
        let data = await ctx.stub.getState(key);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
    // GetBalance   
    async GetBalance(ctx, accountName) {
        let data = await ctx.stub.getState(accountName);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
     
    // Refill own balance
    async RefillBalance(ctx, toAccount, value) {
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balance
        to.balance += Number(value);
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "RefillBalance",
            to: to.name,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('RefillBalance', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
}
module.exports = CitcoinEvents;

Intuitivement, tout devrait être clair ici :

Il existe plusieurs fonctions (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance) qui seront appelées par le programme de démonstration à l'aide de l'API Hyperledger Fabric.
Les fonctions SendFrom et RefillBalance génèrent des événements (Event) que recevra le programme de démonstration.
La fonction instantiate est appelée une fois lors de l'instanciation d'un smart contract. En réalité, elle est appelée plusieurs fois lors de chaque changement de version du smart contract. Par conséquent, initialiser la liste avec un tableau vide est une mauvaise idée, car lors du changement de version, nous perdrons la liste actuelle. Mais pas de souci, je suis simplement en train d'apprendre).
Les comptes et la liste des comptes (accounts) sont des structures de données JSON. Le JS est utilisé pour manipuler les données.
La valeur actuelle de l'asset peut être obtenue en appelant la fonction getState, et mise à jour avec putState.
Lors de la création d'un compte, la fonction AddAccount est appelée, où une comparaison avec le nombre maximum de comptes dans la blockchain (maxAccounts = 5) est effectuée. Et ici, il y a une erreur (vous l'avez remarqué ?), qui entraîne une croissance infinie du nombre de comptes. De telles erreurs doivent être évitées)

Nous continuons en chargeant le smart contract dans le channel et en l'instanciant :

Nous regardons la transaction d'installation du Smart Contract :

Nous consultons les détails de notre Channel :

En conséquence, nous obtenons le schéma suivant du réseau blockchain dans le cloud IBM. Le schéma présente également un programme démo, exécuté dans le cloud Amazon sur un serveur virtuel (nous en parlerons plus en détail dans la section suivante) :

Création d'une interface graphique pour les appels à l'API Hyperledger Fabric

Hyperledger Fabric dispose d'une API qui peut être utilisée pour :

Créer un channel ;
Connecter un peer au channel ;
Installer et instancier des smart contracts dans le channel ;
Appeler des transactions ;
Demander des informations dans la blockchain.

Développement d'application

Dans notre programme démo, nous utiliserons l'API uniquement pour appeler des transactions et demander des informations, car nous avons déjà réalisé les autres étapes en utilisant la plateforme blockchain IBM. Nous écrivons l'interface graphique en utilisant la pile technologique standard : Express.js + Vue.js + Node.js. On pourrait écrire un article séparé sur la façon de commencer à créer des applications web modernes. Ici, je laisse un lien vers une série de conférences que j'ai le plus appréciées : Full Stack Web App using Vue.js & Express.js. En conséquence, cela a donné une application client-serveur avec une interface graphique familière dans le style Material Design de Google. L'API REST entre le client et le serveur se compose de plusieurs appels :

HyperledgerDemo/v1/init — initialiser la blockchain ;
HyperledgerDemo/v1/accounts/list — obtenir la liste de tous les comptes ;
HyperledgerDemo/v1/account?name=Bob&balance=100 — créer le compte Bob ;
HyperledgerDemo/v1/info?account=Bob — obtenir des informations sur le compte Bob ;
HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — transférer deux pièces de Bob à Alice ;
HyperledgerDemo/v1/disconnect — fermer la connexion avec la blockchain.

J'ai mis la description de l'API avec des exemples sur le site «Postman» — un programme bien connu pour tester les API HTTP.

L'application de démonstration est hébergée sur Amazon Cloud.

J'ai téléchargé l'application sur Amazon, car IBM n'a toujours pas réussi à mettre à jour mon compte et à me permettre de créer des serveurs virtuels. En prime, j'ai ajouté le domaine : www.citcoin.info. Je garderai le serveur allumé un peu, puis je l'éteindrai, car les frais de location s'accumulent et les pièces de citcoin ne sont pas encore cotées sur les échanges.) Dans cet article, je mets des captures d'écran de la démonstration pour illustrer la logique de fonctionnement. L'application de démonstration peut :

Initialiser la blockchain ;
Créer un compte (mais actuellement, il n'est pas possible de créer un nouveau compte, car le nombre maximal de comptes mentionné dans le contrat intelligent a été atteint) ;
Obtenir la liste des comptes ;
Transférer des pièces de citcoin entre Alice, Bob et Alex ;
Recevoir des événements (mais pour l'instant, il n'est pas possible d'afficher des événements, donc pour simplifier l'interface, il est indiqué que les événements ne sont pas pris en charge) ;
Enregistrer les actions.

D'abord, nous initialisons la blockchain :

Ensuite, nous créons notre propre compte, sans lésiner sur le solde :

Nous obtenons la liste de tous les comptes disponibles :

Nous choisissons l'expéditeur et le destinataire, et nous obtenons leurs soldes. Si l'expéditeur et le destinataire sont la même personne, son solde sera approvisionné :

Dans le log, nous suivons l'exécution des transactions :

Voilà, c'est tout pour l'application de démonstration. Ensuite, nous pouvons consulter notre transaction dans la blockchain :

Et la liste générale des transactions :

Nous avons réussi à terminer la mise en œuvre de la PoC pour la création du réseau Citcoin. Que faut-il encore faire pour que Citcoin devienne un réseau complet pour le transfert de pièces ? Pas grand-chose :

Lors de la création du compte, mettre en place la génération d'une clé privée/publique. La clé privée doit être conservée par l'utilisateur du compte, la clé publique dans la blockchain.
Effectuer un transfert de pièces, où l'identification de l'utilisateur est faite non pas par le nom, mais par la clé publique.
Chiffrer les transactions envoyées par l'utilisateur au serveur à l'aide de sa clé privée.

Conclusion

Nous avons implémenté le réseau Citcoin avec les fonctionnalités suivantes : ajouter un compte, obtenir un solde, approvisionner son compte, transférer des pièces d'un compte à un autre. Alors, quel a été le coût de la construction de la PoC ?

Il faut étudier la blockchain en général et Hyperledger Fabric en particulier ;
Apprendre à utiliser les clouds d'IBM ou d'Amazon ;
Apprendre le langage de programmation JS et un framework web.
Si certaines données doivent être stockées en dehors de la blockchain, dans une base de données distincte, apprenez à vous intégrer, par exemple, avec PostgreSQL ;
Et enfin, bien que ce soit le dernier de la liste, il n'est pas moins important — sans connaissances en Linux, on ne fait pas grand-chose dans le monde moderne !)

Bien sûr, ce n'est pas de la science fusée, mais il va falloir fournir un effort !

Sources sur GitHub

J'ai mis les sources sur GitHub. Description succincte du dépôt :
Répertoire «serveur» — serveur Node.js
Répertoire «client» — client Node.js
Répertoire «blockchain» (les valeurs des paramètres et les clés, bien sûr, ne fonctionnent pas et sont fournies uniquement à titre d'exemple) :

contract — code source du contrat intelligent
wallet — clés de l'utilisateur pour utiliser l'API Hyperledger Fabric.
*.cds — versions compilées des contrats intelligents
*.json fichiers — exemples de fichiers de configuration pour utiliser l'API Hyperledger Fabric

Ce n'est que le début !

Source : habr.com

Blockchain : que nous coûte-t-il de construire un PoC ?