>_ DevTrendsit

Lingua

Home

Linguaggi

Sezioni

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embedded Sicurezza
Java

Come Funziona il Server Nodo Hiero e Come la Rete Hedera Elabora le Transazioni

Se hai anche solo brevemente seguito il mercato delle reti decentralizzate, probabilmente hai sentito parlare della rete Hedera. Per molto tempo, il suo motore è rimasto codice commerciale chiuso con una licenza specifica. La situazione è cambiata quando il progetto è passato sotto l'egida della Linux Foundation e ha ricevuto il nome open-source Hiero.

Il codice sorgente del nodo di consenso, scritto in Java, è disponibile nel repository hiero-consensus-node. Questo è esattamente il servizio che accetta richieste gRPC, esegue le transazioni attraverso il consenso DAG ed esegue gli smart contract.

Cosa c'è all'interno del Monorepository

Il codice è suddiviso in due moduli figlio principali:

  • platform-sdk/ — il livello inferiore della piattaforma. Gestisce le connessioni di rete tra i nodi, l'algoritmo di consenso e la memorizzazione persistente dello stato della rete.
  • hedera-node/ — il livello applicativo. Contiene i servizi per account, token, file e l'esecuzione del codice EVM.

La divisione è logica. La piattaforma gestisce il pesante lavoro matematico del consenso distribuito, mentre il modulo applicativo trasforma quel consenso in un'API comoda per gli sviluppatori.

Servizi, Protobuf e Solidity

La comunicazione client-nodo è basata sul protocollo gRPC. L'intera specifica è definita in schemi Protobuf separati. Attraverso questi protocolli, il nodo gestisce le attività principali:

  • Tokenizzazione (HTS). Consente di emettere e trasferire token senza scrivere smart contract.
  • Logging di consenso (HCS). Consente di registrare timestamp e messaggi su un ledger distribuito.
  • Smart contract. Una macchina virtuale EVM viene eseguita all'interno del nodo, supportando il compilatore Solidity con la direttiva pragma solidity <=0.8.9.

Il supporto per la versione di Solidity è attualmente limitato alla release 0.8.9. Per contratti OpenZeppelin standard o logiche di business tipiche, questo è sufficiente, anche se non potrai accedere alle ultime funzionalità del linguaggio.

Infrastruttura e Qualità del Codice

Il repository rivela immediatamente le sue origini aziendali. Non c'è il tipico caos dei piccoli progetti open-source. Le pipeline CI/CD includono test di prestazioni giornalieri (Single Day Performance Tests) e test di durata a lunga esecuzione (Longevity Tests).

Il progetto è certificato secondo gli standard OpenSSF Scorecard e CII Best Practices, e la copertura dei test viene tracciata attraverso Codecov.

D'altra parte, la sezione issues ha oltre millecinquecento attività aperte. Questo è normale per sistemi di grandi dimensioni che sono passati all'open source, ma i nuovi sviluppatori dovranno dedicare tempo a comprendere la struttura del progetto.

Dove Iniziare lo Studio

Il progetto è costruito con Gradle. Per l'esecuzione locale, avrai bisogno di una versione recente di Java e di RAM sufficiente.

Se vuoi approfondire i dettagli dell'architettura, è utile consultare la documentazione:

  • La cartella hedera-node/docs/design/ contiene diagrammi architetturali e decisioni di design dei servizi.
  • La documentazione in platform-sdk/docs/ descrive la struttura interna della piattaforma di consenso stessa.

A Chi Sarà Utile Questo Progetto

Per un tipico sviluppatore Web3 che ha solo bisogno di emettere un token o distribuire una dApp, non è necessario eseguire un proprio nodo. È molto più semplice usare SDK già pronti per il linguaggio di programmazione preferito.

Questo repository è interessante principalmente per i team di ingegneria. Coloro che progettano le proprie reti aziendali basate sulla tecnologia Hashgraph, che ricercano la tolleranza ai guasti BFT asincrona, o che studiano sistemi Java ad alto carico. Il codice contiene buoni esempi di ottimizzazione della memoria e di strutturazione dei servizi gRPC per carichi elevati.

Progetti correlati