Presentation de Hyperledger Besu

Hyperledger est une plateforme de developpement de blockchain maintenue par la fondation Linux.
Elle contient tout un panel d'outils permettant aux entreprises de par exemple développer des applications décentralisées ( Dapp ) ou de faire
des smart contracts.

Un de leurs outils nommé Besu a été introduit en 2019 et est le premier outil permettant d'interagir avec la blockchain Ethereum.

Schema de la Hyperledger greenhouse

Client Ethereum Besu

Besu est un client Ethereum, c'est-à-dire qu'il implémente les fonctions de base de la blockchain Ethereum ( réseau P2P, copie locale de la blockchain, diffuser une transaction sur le réseau ) et permet également d'interagir avec celle-ci via des APIs.

Le client Besu étant écrit en Java possède un code robuste et peut fonctionner sur des réseaux privés Ethereum ou sur la mainnet ( réseau publique ). Il permet l'utilisation de plusieurs types d'algorithmes de consensus tels que Proof of authority avec QBFT, IBFT 2.0 et Clique, Proof of work avec Ethash ou Proof of stake.

Caractéristiques du client

Le client Besu est écrit en Java et développé sous la licence Apache 2.0. Il possède de nombreuses caractéristiques qui font de lui un client robuste :

• The Ethereum Virtual Machine (EVM): l'EVM est une technologie d'Ethereum qui permet la création et l'execution de smart contract.
• La communication P2P : Besu tire parti des protocoles devP2P et RLPx afin de faciliter la communication entre les clients Ethereum ( système de découverte des autres clients )
• Stockage : Besu utilise ce que l'on appelle une "forest of tries", c'est une façon de stocker les données dans les différents noeuds en les organisant en arbre dont les feuilles sont les données les plus récentes sur la blockchain.
• Permission : Besu introduit un système de permissioning pour désigner quel noeud ou quel compte a le droit d'interagir avec le réseau Ethereum.
• APIs : Besu propose des APIs pour interagir avec le client. Dans les protocoles surpportés il y a notamment JSON-RPC et GraphQL.
• Monitoring : Une solition de monitoring est disponible par le client, utilisant Prometheus et Block Explorer, elle permet aux utilisateurs de surveiller les performances des noeuds.

Schéma donné par Besu pour les réseaux privés

Algorithmes de consensus

Besu supporte plusieurs algorithmes de consensus, ces algorithmes sont utilisés en fonction du type de réseau Ethereum ( private ou public )

Réseaux privés :

Proof of authority ( PoA ) :

IBFT 2.0 :

IBTF est un protocole de consensus PoA qui garantit les propriétés suivantes :

• La finalité immédiate d'un block : Aucune concurrence de block n'est permise, seulement 1 block est accepté pour une longueur de chaîne donnée. Cela évite le risque qu'une transaction ne soit pas effectuée.
• Temps réduit entre les blocks : Les efforts à fournir pour la construction d'un block sont beaucoup moins importants que la PoW, ce qui augmente l'efficacité de la chaîne et réduit le temps de validation d'un block.
• Une intégrité forte des données et une résistance aux défaillances : IBTF utilise un groupe de validateurs pour assurer l'intégrité des blocks proposés dans la blockchain. Pour qu'un block soit inséré dans la chaîne, une majorité de ces validateurs ( plus de 2/3 ) doit signer la validité du block ce qui rends difficile les attaques. Le chef des validateurs change régulièrement ce qui évite un contrôle à long terme sur la blockchain.
• Flexible : Le groupe de validateurs peut être changé en temps réels ce qui assure de la fiabilité des noeuds de ce groupe.

Mechanisme d'IBTF :

IBTF utilise un groupe de validateurs qui opère sur la blockchain Ethereum afin de valider les différents blocks.

Un noeud est d'abord choisi dans ce groupe de validateurs comme étant celui qui propose de construire le block. Ce noeud va alors construire le block en se basant sur le dernier de la blockchain et va ensuite le proposer au groupe de validateurs. Si plus de 2/3 des validateurs du groupe valident le block, alors il est ajouté à la chaîne.

Les étapes sont les suivantes pour un validateur :

• En attente d'une proposition de block : Le groupe de validateurs est en attente du block que va proposer le noeud choisi comme étant le constructeur du block actuel.
• Preparation : le validateur reçoit un block proposé par le noeud contructeur, il va notifier en P2P les autres validateurs et va se mettre en attente de leur réponse pour l'acceptation du block.
• Prêt à être inséré : Le block à été accepté par le validateur qui va attendre que les autres validateurs soit en position prêt à l'insertion, à ce moment le block est figé et ne peut pas être remplacé par un autre temps qu'une réponse positive ou négative à son insertion ne soit donnée.
• Insertion ou time out : Si au moins 2/3 du groupe de validateurs est en état prêt, alors le block est inséré, sinon il y a un timeout et le block n'est pas accepté.
• Tour de vote : A la fin du processus, que le block ait été inséré ou non, un nouveau vote est lancé par le groupe pour désigné le prochain constructeur du block.

Clique :

Clique est un autre algorithme de consensus Proof of authority ressemblant fortement à IBFT mais avec des variantes sur ses caractéristiques, les différences sont dans le tableau ci-dessous :

Tableau de consensys.net comparant clique à IBFT 2.0

Proof of work ( PoW ) :

Ethash :

L'algorithme Etash s'appuie sur les fondements d'un autre algorithme; Dagger-Hashimoto qui est un mix entre dagger développé par Vitalik Buterin et Hashimoto développé par Thaddeus Dryja. Ces algorithmes introduisent un modèle assez complexe pour être exécuté sur des ASIC en toute sécurité. Cependant ces deux algorithmes avaient des défauts qui ont conduit à la création d'Ethash.

L'algorithme Dagger-Hashimoto permet la création d'un DAG ( Directed Acyclic Graph ) qui est un fichier contenant une structure de données dont l'algrotihme Ethash a besoin pour fonctionner.

Les étapes d'Etash sont les suivantes :

• Une valeur "seed" peut être calculée via l'entête du block précédent concaténée avec un nombre aléatoire de 32 bits.
• Cela produit une structure de 128 bits appelée "mix".
• Cette structure est utilisée pour determinée quelles sont les données à extraire du DAG.
• Une fois les données extraites, On les fusionne avec notre "mix" pour créer le nouveau mix qui va nous servir à répeter cette étape.
• Une fois l'étape répétée 64 fois, on récupère la valeur pour la passer dans une fonction de digest qui va générer une séquence de 32 bits.
• On compare cette valeur avec la valeur target, si notre valeur est plus petite alors le block est résolu sinon on recommence les étapes avec un nouveau nombre aléatoire.

Réseaux publiques :

Proof of stake ( PoS ) :

L'algorithme Proof of stake est un consensus qui permet une réduction significative de l'énergie utilisée par une blockchain. Ce consensus est beaucoup moins coûteux que d'autre comme le PoW.

L'algorithme fonctionne avec des validateurs qui sont désignés de façon aléatoire. Pour avoir une chance de devenir validateur, il faut être en possession d'au moins 32 Ethereum et mettre sur son noeud un client d'execution, un client de consensus et un client de validation. Besu permet de remplir ces conditions sur son noeud.

Sources

• Site officiel de Besu : https://besu.hyperledger.org/en/stable/
• Explication forest of tries : https://consensys.net/blog/news/bonsai-tries-a-big-update-for-small-state-storage-in-hyperledger-besu/
• Explication IBFT 2.0 : https://consensys.net/blog/news/another-day-another-consensus-algorithm-why-ibft-2-0/
• Comparaison avec Clique : https://consensys.net/blog/quorum/hyperledger-besu-understanding-proof-of-authority-via-clique-and-ibft-2-0-private-networks-part-1/
• Ethash explication : https://academy.bit2me.com/en/what-is-the-algorithm-of-ethash-mining/
• Proof of stake explication : https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/