Mise en œuvre de Amazon Managed Blockchain
Introduction
Au chapitre Chaînes de blocs et AWS, vous avez pu découvrir l’architecture d’un réseau de chaînes de blocs créé sur Amazon Managed Blockchain avec Hyperledger Fabric 1.2 ou 1.4. Amazon a annoncé depuis un bon moment le support d’Ethereum, pour offrir plus de choix aux développeurs qui ne souhaitent pas créer ni gérer l’infrastructure sous-jacente à leurs applications de chaînes de blocs. Cependant, au moment de l’écriture de ce livre, pendant l’année 2020, Ethereum se faisait encore attendre. Nous allons donc, dans ce chapitre, nous focaliser exclusivement sur Hyperledger Fabric 1.4. Si certains concepts entre Hyperledger Fabric et Ethereum sont fondamentalement différents, à commencer par l’existence d’un token sur Ethereum, l’ether, qui n’a pas d’équivalent sur Hyperledger Fabric, la philosophie des smarts contracts est identique et il ne sera pas difficile de passer de l’un à l’autre si Ethereum devient disponible.
Vous pouvez vous reporter à la section Service Managed Blockchain et Hyperledger Fabric du chapitre Chaînes de blocs et AWS afin de vous rafraîchir la mémoire sur l’architecture d’un réseau Hyperledger Fabric et sur son implémentation avec Amazon Managed Blockchain. Dans ce chapitre, nous...
Créer un réseau et y accéder
La fondation d’une application de chaînes de blocs construite sur Hyperledger Fabric est le réseau. Ce réseau est le regroupement de plusieurs organisations qui souhaitent exécuter des transactions entre elles. La première étape de la création de notre application est donc la création de ce réseau.
1. Créer un nouveau réseau
La création d’un réseau depuis la console est une opération simple et rapide. Depuis la console Amazon Managed Blockchain, cliquez sur le bouton Créer un réseau.
Il existe deux types de réseaux de chaînes de blocs :
-
Starter, supportant jusqu’à 5 membres, 2 nœuds pairs par membre et 3 canaux, l’instance de chaque nœud pouvant être bc.t3.small ou bc.t3.medium.
-
Standard, supportant jusqu’à 14 membres, 3 nœuds pairs par membre et 8 canaux, l’instance de chaque nœud pouvant être bc.t3, bc.m5 ou bc.c5.
Le débit et la disponibilité du service de commande sont plus importants dans un réseau standard. Les différences entre réseaux starter et standard se ressentent sur les prix. Faire fonctionner un réseau standard revient environ trois fois plus cher qu’un réseau starter.
Un réseau de chaîne de blocs AMB est facturé à l’heure, qu’il soit utilisé ou non. Faites attention à la facture pendant la phase de développement.
Figure 1 - Choix du type de framework et du réseau
Au moment de l’écriture de ce livre, seul Hyperledger Fabric est disponible, c’est la raison pour laquelle nous nous focalisons sur ce framework. Nous choisissons aussi un réseau de type Starter, n’ayant pas besoin pour le moment d’un nombre important de membres.
Figure 2 - Nom du réseau et stratégie de vote
Une fois le Nom et la Description du réseau fournis, il nous faut choisir...
Créer un client et un utilisateur administratif
Un réseau de chaîne de blocs opère en isolation réseau. Cela signifie qu’il faut définir un cloud privé virtuel (VPC, Virtual Private Cloud) afin de pouvoir accéder au registre depuis un client, quel qu’il soit. Dans notre cas, il s’agira dans un premier temps d’un client CLI, puis d’un client SDK.
Tout compte AWS opère dans son propre VPC. C’est ce VPC par défaut que Amazon Managed Blockchain utilise de prime abord. Vous pouvez utiliser ce VPC ou en créer un nouveau pour isoler votre chaîne de blocs et ses applications. C’est le choix que nous faisons ici.
Attelons-nous donc à la création de l’infrastructure du VPC, puis à celle du client Hyperledger Fabric et de l’administrateur.
1. VPC et point de terminaison
La création d’un cloud privé virtuel (VPC) est une opération rapide que l’on peut exécuter depuis la console AWS VPC, en cliquant sur le bouton Créer un VPC.
Figure 10 - Création d’un VPC
Attention, le VPC ainsi créé ne prend en charge ni l’obtention de noms d’hôte DNS ni la résolution DNS, qui sont nécessaires au bon fonctionnement de notre réseau de chaîne de blocs. Il faut donc impérativement l’ajouter.
Pour ce faire, sélectionnez le VPC en question depuis la console AWS et depuis le menu Actions, choisissez Modifier les noms d’hôte DNS. Cochez la case Activer et validez en cliquant sur le bouton Enregistrer les modifications.
Figure 11 - Obtention de noms d’hôte DNS
Faites la même opération depuis le menu Actions, en choisissant cette fois Modifier la résolution DNS.
Figure 12 - Résolution DNS
Le VPC créé et configuré, ajoutez-y un sous-réseau qui servira de fondation de communication. Faites bien attention de sélectionner le VPC que vous venez de créer, ainsi que le bloc d’adresses utilisées.
Figure 13 - Création d’un sous-réseau
L’objectif de ce cloud privé est de filtrer le trafic entrant et sortant. Il convient donc maintenant de créer un groupe de sécurité adéquat qui laissera au minimum entrer une connexion...
Créer et utiliser un canal
Un registre dans Hyperledger Fabric existe dans le contexte d’un canal qui permet aux membres du réseau d’échanger des transactions. Si cette structure est encore floue dans votre esprit, vous pouvez vous reporter au chapitre Chaînes de blocs et AWS, section La structure d’un réseau Hyperledger Fabric, pour vous remémorer les différents composants d’un réseau Hyperledger Fabric.
1. Configurer un canal
Les détails de la configuration d’un canal sont contenus dans un fichier configtx.yaml (les détails de ce fichier sont décrits dans la documentation d’Hyperledger qui, pour la version 1.4, se trouve à l’adresse https://hyperledger-fabric.readthedocs.io/en/release-1.4/configtx.html). Nous allons en faire une copie dans la racine du fichier configtx.yaml fourni avec l’application exemple en remplaçant la chaîne __MEMBERID__ par le numéro du premier membre du réseau trouvé dans ses propriétés. Il a la forme m- G4YODZU2MZFYHMNL3PMOMO47Y4.
cp ~/non-profit-blockchain/ngo-fabric/configtx.yaml ~
sed -i "s|__MEMBERID__|$MSP|g" ~/configtx.yaml
Ce fichier configtx.yaml est une version minimaliste qui ne contient que la configuration nécessaire à notre chaîne à une seule organisation. Il doit ressembler au fichier suivant (une partie des commentaires a été supprimée) :
##########################################################
# Section: Organizations
##########################################################
Organizations:
- &Org1
Name: m-G4YODZU2MZFYHMNL3PMOMO47Y4
# ID to load the MSP definition as
ID: m-G4YODZU2MZFYHMNL3PMOMO47Y4
MSPDir: /opt/home/admin-msp
AnchorPeers:
- Host: ...
Installer et tester les smart contracts (chaincode)
Nous verrons dans le prochain chapitre le développement proprement dit des smarts contracts. Pour le moment, pour en terminer avec l’installation de notre chaîne de blocs, nous allons utiliser le code existant de ces contrats et l’installer sur notre chaîne.
1. Installer et instancier le chaincode
Commencez par copier le code source du chaincode que vous allons utiliser :
cd ~
mkdir -p ./fabric-samples/chaincode/ngo
cp ./non-profit-blockchain/ngo-chaincode/src/* ./fabric-samples
/chaincode/ngo
Le code source est composé d’un fichier Node.js, d’un fichier ngo.js, et d’un fichier JSON de configuration, package.json. Nous les retrouverons au chapitre suivant.
Installez ce chaincode sur votre nœud pair :
docker exec -e "CORE_PEER_TLS_ENABLED=true" -e
"CORE_PEER_TLS_ROOTCERT_FILE=$FICHIERCA" -e
"CORE_PEER_LOCALMSPID=$MSP" -e
"CORE_PEER_MSPCONFIGPATH=$CHEMINMSP" -e
"CORE_PEER_ADDRESS=$NDPAIRPOINTTERM" cli peer chaincode install -n
$NOMCHAINCODE -l node -v $VERSIONCHAINCODE -p $DIRCHAINCODE
Vous obtenez alors le message de réussite suivant :
2021-01-28 16:57:13.533 UTC [chaincodeCmd]
checkChaincodeCmdParams -> INFO 001 Using default escc
2021-01-28 16:57:13.534 UTC [chaincodeCmd]
checkChaincodeCmdParams -> INFO 002 Using default vscc
2021-01-28 16:57:14.321 UTC [chaincodeCmd] install ->...
Gérer membres et invitations
La chaîne de blocs que nous avons créée jusqu’à présent et que nous allons continuer à utiliser ne possède qu’un seul membre, c’est-à-dire, pour l’implémentation d’Amazon Blockchain Service, une seule organisation (dans notre cas, notre ONG). Cependant, pour permettre un suivi des dons, il peut être nécessaire d’inclure une autre organisation, par exemple, une association partenaire. C’est ce à quoi nous allons nous intéresser dans cette partie.
1. Inviter des nouveaux membres
Ajouter un nouveau membre consiste tout d’abord à lui lancer une invitation.
Depuis la fenêtre des propriétés du réseau, ouvrez l’onglet Membres ou Propositions puis cliquez sur le bouton Proposer une invitation.
Figure 32 - Création d’une proposition d’invitation
Vous remarquez qu’il ne s’agit pas ici d’une invitation à rejoindre le réseau à proprement parler, mais d’une proposition d’invitation. Rappelez-vous, lorsque nous avons créé le réseau, nous avons défini les paramètres de la stratégie de vote (voir figure 2). Deux paramètres ont alors été définis :
-
Le seuil d’approbation, par défaut supérieur strictement à 50 %.
-
La durée de validité de la proposition, par défaut de 24 heures, pouvant aller jusqu’à 168 heures.
Pour le moment, notre réseau ne contient qu’un seul membre, celui créé lors de la création du réseau. Il convient donc que nous votions seul pour approuver notre proposition. Cela peut faire sourire de devoir approuver sa propre proposition, mais cela permet de n’avoir qu’une seule procédure en place, quel que soit le nombre de membres.
Il vous faut donc approuver la proposition d’invitation. Sélectionnez cette dernière, choisissez le membre votant (un compte AWS peut disposer de plusieurs membres, d’où le choix du membre votant), et cliquez sur Oui ou Non.
Figure 33 - Procédure de vote de la proposition
Figure 34 - Confirmation de la prise en compte du vote
Une fois la proposition approuvée, son statut est mis à jour...
Sécurité
La sécurité fait partie intégrante de toute chaîne de blocs, vous l’avez compris. Un des avantages de déployer un tel réseau avec Amazon Web Services est de pouvoir s’appuyer sur l’ensemble des paramètres et services de sécurité disponibles par défaut.
1. Sécuriser l’accès
Quand on pense sécurité d’accès, on pense à éviter les tentatives d’intrusions. C’est l’objectif de la création d’un cloud privé virtuel et de son point d’accès. Mais même le filtrage le plus fin peut être vaincu. Il faut alors vérifier l’identité de celui ou celle qui a pénétré le réseau et cherche à accéder à ses ressources. D’où la nécessité de sécuriser le périmètre et l’accès aux ressources qui s’y trouvent.
a. Cloud privé virtuel
Un des moyens et une bonne pratique pour limiter le risque d’intrusion sur un réseau est de l’isoler logiquement du reste du monde. C’est la raison d’être du cloud privé virtuel dans lequel nous plaçons le réseau. C’est une condition obligatoire des réseaux de chaînes de blocs Hyperledger Fabric créés avec Amazon Managed Blockchain.
Avec la création d’un VPC, vient celle du point de terminaison, le point d’entrée obligatoire vers le réseau. Un sous-réseau et un groupe...