Comment fonctionne le serveur de nœud Hiero et comment le réseau Hedera traite les transactions

Si vous avez même brièvement suivi le marché des réseaux décentralisés, vous avez probablement entendu parler du réseau Hedera. Pendant longtemps, son moteur est resté un code commercial fermé sous licence spécifique. La situation a changé lorsque le projet est passé sous l'ombrelle de la Linux Foundation et a reçu le nom open-source Hiero.

Le code source du nœud de consensus, écrit en Java, est disponible dans le dépôt hiero-consensus-node. C'est ce service exact qui accepte les requêtes gRPC, exécute les transactions via le consensus DAG et exécute les smart contracts.

Ce qu'il y a à l'intérieur du monodépôt

Le code est divisé en deux modules enfants principaux :

• platform-sdk/ — le niveau inférieur de la plateforme. Il gère les connexions réseau entre les nœuds, l'algorithme de consensus et le stockage persistant de l'état du réseau.
• hedera-node/ — la couche application. Elle contient les services pour les comptes, les jetons, les fichiers et l'exécution du code EVM.

La division est logique. La plateforme gère le lourd travail mathématique du consensus distribué, tandis que le module application transforme ce consensus en une API pratique pour les développeurs.

Services, Protobuf et Solidity

La communication client-à-nœud est construite sur le protocole gRPC. Toute la spécification est définie dans des schémas Protobuf séparés. À travers ces protocoles, le nœud gère les tâches principales :

• Tokenisation (HTS). Permet d'émettre et de transférer des jetons sans écrire de smart contracts.
• Journalisation de consensus (HCS). Permet d'enregistrer des horodatages et des messages dans un registre distribué.
• Smart contracts. Une machine virtuelle EVM s'exécute à l'intérieur du nœud, supportant le compilateur Solidity avec la directive pragma solidity <=0.8.9.

Le support de la version Solidity est actuellement limité à la version 0.8.9. Pour les contrats OpenZeppelin standard ou la logique métier typique, cela suffit, bien que vous ne puissiez pas encore accéder aux dernières fonctionnalités du langage.

Infrastructure et qualité du code

Le dépôt révèle immédiatement ses origines d'entreprise. Il n'y a aucun du désordre typique des petits utilitaires open source. Les pipelines CI/CD incluent des tests de performance quotidiens (Single Day Performance Tests) et des tests d'endurance de longue durée (Longevity Tests).

Le projet est certifié selon les normes OpenSSF Scorecard et CII Best Practices, et la couverture des tests est suivie via Codecov.

D'un autre côté, la section des issues contient plus de quinze cents tâches ouvertes. C'est normal pour les grands systèmes qui sont passés en open source, mais les nouveaux développeurs devront passer du temps à comprendre la structure du projet.

Par où commencer l'apprentissage

Le projet est construit avec Gradle. Pour une exécution locale, vous aurez besoin d'une version récente de Java et d'une RAM suffisante.

Si vous voulez approfondir les détails de l'architecture, il est utile de consulter la documentation :

• Le dossier hedera-node/docs/design/ contient des diagrammes architecturaux et les décisions de conception des services.
• La documentation dans platform-sdk/docs/ décrit la structure interne de la plateforme de consensus elle-même.

À qui ce projet sera utile

Pour un développeur Web3 typique qui a juste besoin d'émettre un jeton ou de déployer une dApp, exécuter son propre nœud n'est pas nécessaire. Il est beaucoup plus simple d'utiliser des SDK prêts à l'emploi pour votre langage de programmation préféré.

Ce dépôt est principalement intéressant pour les équipes d'ingénierie. Celles qui conçoivent leurs propres réseaux d'entreprise basés sur la technologie Hashgraph, qui recherchent la tolérance aux pannes BFT asynchrone, ou qui étudient les systèmes Java à haute charge. Le code contient de bons exemples d'optimisation de la mémoire et de structuration des services gRPC pour une charge élevée.