Considérations
Autres possibilités de déploiement
La solution type a été conçue pour se déployer et s’exécuter sur une seule machine virtuelle. Quelques points importants doivent être envisagés sur les plans de la performance, de la mise à l’échelle et de la disponibilité de l’application.
Performance
Les transactions effectuées sur le réseau de la solution type sont des transactions HLF ordinaires qui traversent une série d’opérations exécutées par les différents nœuds du réseau (client, pair, ordonnanceur). Il faut bien comprendre que ces opérations sont des tâches informatiques (p. ex., calcul de code haché) qui alourdissent la charge de travail de l’unité centrale (UC). Accroître la puissance de cette dernière devrait accélérer les calculs et le débit quand la charge de travail devient trop lourde.
Mise à l’échelle
On peut agrandir le réseau horizontalement en y ajoutant d’autres pairs pour traiter les demandes de clients supplémentaires (à savoir, lire les données sur les transactions). Des UC à cœurs multiples accélèreront le débit des transactions. L’ajustement du réseau est une démarche constante, car le réseau DLT devrait prendre ou perdre de l’ampleur avec le temps (quand de nouveaux participants s’y ajoutent ou d’autres le quittent). Pour les réseaux de production, utiliser plusieurs MV amènera le réseau à un stade permettant le traitement d’un volume supérieur de transactions. La solution type n’intègre pas le principe de mise à l’échelle et se limite à une machine virtuelle.
Disponibilité
La disponibilité d’un réseau dépend du nombre de nœuds et de leur répartition entre différentes infrastructures (fournisseurs de services d’infonuagique et centres de données). En général, un réseau HLF de type produit avec des participants de l’étranger fonctionnera sur plusieurs centres de données et fournisseurs de services d’infonuagique disséminés dans le monde. La sauvegarde régulière des pairs/ordonnanceurs et de leurs magasins CouchDB (si on utilise ce système de gestion de base de données) permettra la restauration des pairs advenant une défaillance matérielle. La solution type ne comprend aucune stratégie de sauvegarde de sécurité automatique.
Technologies de rechange
HLF n’est qu’une technologie de chaîne de blocs fondée sur un registre décentralisé (DLT) parmi d’autres pouvant servir à créer un réseau privé avec permissions. Il existe aussi des réseaux à chaînes de blocs utilisant des jetons, entièrement publics, ouverts et sans permissions. Ces réseaux traitent toutefois les transactions avec lenteur, ils ne protègent pas vraiment les données personnelles et soutiennent mal les modèles avec permissions, autant de capacités qu’on juge indispensables à maintes applications d’entreprise pour lesquelles la confidentialité et le contrôle des données ainsi que des transactions doivent être préservés grâce à des permissions.
Habituellement, les réseaux publics à chaînes de blocs sont commandés par un grand nombre de pairs répartis et décentralisés. N’importe qui peut exploiter ces pairs, souvent hébergés dans des fermes ou parcs situés ici et là sur le globe. Certains de ces réseaux n’ont d’autre but qu’enregistrer les transactions qui déplacent des jetons d’un compte ou d’une adresse à l’autre dans le registre (c’est notamment le cas du réseau Bitcoin). D’autres soutiennent des transactions plus complexes régies par des contrats intelligents qui permettent aux développeurs de consigner des données dans le registre public. Ces réseaux se prêtent à de nombreuses utilisations comme la modélisation et l’échange d’actifs au moyen de jetons non fongibles (NFT). Ethereum figure parmi les réseaux publics les plus utilisés et les plus reconnus acceptant les contrats intelligents.
La plupart des réseaux DLT privés s’appuient sur des technologies éprouvées de chaînes de blocs comme Corda, HLF, Quorum, Hyperledger Sawtooth, etc., ayant chacune leurs forces et leurs faiblesses, selon l’usage qu’on en fait. Il existe aussi des projets de source ouverte que soutiennent des communautés de développeurs et d’entreprises. HLF fait partie des applications les plus populaires, car cette plateforme est assez ouverte et générique pour prendre en charge et résoudre les problèmes de diverses industries (chaînes d’approvisionnement, soins de santé, finances, etc.).
Sécurité
On accède au réseau HLF provisionné par ses nœuds, sur différents ports susceptibles d’être exposés à l’extérieur de la MV qui utilise un groupe de sécurité approprié. Les pairs et les ordonnanceurs sont reliés entre eux par leurs ports Docker internes, dont les canaux de communication sont encryptés au niveau de la couche TLS. Les artefacts de l’infrastructure à clé publique (PKI) sont stockés dans le répertoire de fichiers local de la MV. Pour les stocker ailleurs, on pourrait recourir à une boîte noire transactionnelle ou à un autre système de gestion de la PKI (Vault, par exemple).
Les applications Web fournies recourent à un système de gestion des identités qui ne compte qu’un utilisateur, déterminé à l’avance, la solution type n’ayant surtout pour objectif que d’illustrer les capacités d’Hyperledger Fabric employées par un client, où La gestion des utilisateurs est intégrée à la gestion des identités en fonction des besoins du projet.
Remarque : L’intégration d’un système de gestion de la PKI ou de l’identité des applications Web déborde du sujet de la présente solution type.
Évolution
Les réseaux HLF sont commandés par ordonnancement des nœuds de services et des nœuds de pairs. Le réseau permet aux participants d’ajouter au réseau autant de pairs que nécessaire pour atteindre la meilleure disponibilité et expansion horizontale possibles. Les pairs peuvent être hébergés sur différents nuages ou dans différentes régions afin d’en permettre le déploiement dans des nuages hybrides et une meilleure répartition. Le service d’ordonnancement de HLF peut aussi répartir les nœuds (ordonnanceurs) entre diverses infrastructures, où chaque canal devra maintenir un nombre d’ordonnanceurs gérable de manière obtenir une grappe RAFT stable (beaucoup d’autres projets comme Kubernetes recourent au protocole de consensus RAFT). Les participants hébergent et gèrent les nœuds du réseau et chacun héberge ses pairs sur une infrastructure qui autorise une importante mise à l’échelle horizontale ou verticale.
Disponibilité
Les nœuds HLF peuvent être hébergés chez différents fournisseurs d’infonuagique ou dans diverses régions. Habituellement, plus les nœuds seront répartis et plus le réseau sera disponible. Chaque participant pourrait exploiter plusieurs nœuds afin de réduire les risques de panne pour une sorte de transactions donnée. Certaines transactions, par exemple, pourraient exiger d’être sanctionnées par un sous-groupe de participants, afin que d’autres pairs, inaccessibles ou peu fiables, ne puissent les affecter.
Ce Propulseur propose une solution pouvant accueillir les nœuds d’un réseau sur une seule MV, une bonne option pour bâtir et développer une application qu’on désire valider. Pour les réseaux et les applications de production, on s’attend, ce qui est fortement préconisé, à ce que les nœuds soient hébergés sur plusieurs infrastructures dans diverses régions, chez un ou plusieurs services d’infonuagique.
API
Les nœuds d’Hyperledger Fabric (ordonnanceurs et pairs) et les autorités de certification Hyperledger procurent des API de gestion et d’exploitation (vérification de l’état, gestion des journaux, déploiement/évocation du code d’enchaînement, communication entre nœuds, enregistrement des identités, adhésion, etc.). Ces interfaces reposent sur le cadriciel gRPC. Dans la plupart des cas, on recommande de sécuriser ces API sur la couche TLS. Les liens ci-dessous mènent aux instructions techniques sur la façon d’activer la couche TLS sur différents nœuds :
Remarque : Sur une plateforme à permissions ultra sécurisée, on pourra recourir à un protocole TLS commun afin de sécuriser davantage les protocoles de communication à chaque niveau et ne laisser traverser le serveur TLS commun que les clients dont le certificat a été validé.
Coût
Le coût d’exploitation d’un réseau HLF dépend de l’infrastructure retenue pour accommoder les contraintes non fonctionnelles du réseau (disponibilité, performance, sécurité, etc.).
Les réseaux de production pourraient nécessiter plusieurs nœuds, situés à divers endroits (ou centres de données), de manière à garantir une disponibilité adéquate. On pourra recourir à des boîtes noires transactionnelles (BNT) pour stocker les artefacts de l’infrastructure à clé publique (PKI) comme les certificats et les clés privées.
Le réseau Hyperledger Fabric de Senofi n’utilise qu’une MV et quelques pairs et ordonnanceurs. Les artefacts sont conservés dans le répertoire de fichiers local de la MV. À titre de comparaison, AWS et Azure facturent 45 $ par mois pour une instance de 4 Go à double cœur, minimum requis pour exécuter la solution type.
Calculer les services et les infrastructures dont on a besoin permettra d’établir le coût exact de la solution.
N’importe quel réseau de production évoluera avec le temps, car des nœuds et des participants s’y ajouteront ou en seront retranchés. En conséquence, son coût d’exploitation variera à la hausse ou à la baisse.
Licence d’exploitation
Les composants de la solution Hyperledger Fabric proposée par Senofi sont tous visés par une licence de source ouverte. Pour en apprendre davantage à ce sujet, on consultera les dépôts du code source.
