Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Blockchain avec AWS
  3. Mise en œuvre de Amazon Managed Blockchain
Extrait - Blockchain avec AWS Développez votre chaîne de blocs avec les services web d'Amazon
Extraits du livre
Blockchain avec AWS Développez votre chaîne de blocs avec les services web d'Amazon Revenir à la page d'achat du livre

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.

images/04EXP001.png

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.

images/04EXP002.png

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.

images/04EXP010.png

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.

images/04EXP011.png

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.

images/04EXP012.png

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.

images/04EXP013.png

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.

images/04EXP032.png

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.

images/04EXP034.png

Figure 33 - Procédure de vote de la proposition

images/04EXP035.png

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...