Hoe de Hiero Node Server werkt en hoe het Hedera-netwerk transacties verwerkt

Als je ook maar even de markt voor gedecentraliseerde netwerken hebt gevolgd, heb je waarschijnlijk gehoord van het Hedera-netwerk. Lange tijd bleef de engine gesloten commerciële code met een specifieke licentie. De situatie veranderde toen het project onder de vlag van de Linux Foundation kwam en de open-source naam Hiero kreeg.

De broncode van de consensus node, geschreven in Java, is beschikbaar in de hiero-consensus-node repository. Dit is de exacte service die gRPC-verzoeken accepteert, transacties door DAG-consensus uitvoert en smart contracts uitvoert.

Wat zit er in de Monorepository

De code is opgesplitst in twee hoofd child modules:

• platform-sdk/ — het lagere niveau van het platform. Het verwerkt netwerkverbindingen tussen nodes, het consensus-algoritme en persistente opslag van de netwerkstatus.
• hedera-node/ — de applicatielaag. Het bevat services voor accounts, tokens, bestanden en EVM-code-uitvoering.

De verdeling is logisch. Het platform voert het zware wiskundige werk van gedistribueerde consensus uit, terwijl de applicatiemodule die consensus omzet in een handige API voor ontwikkelaars.

Services, Protobuf en Solidity

Client-naar-node communicatie is gebouwd op het gRPC-protocol. De volledige specificatie is gedefinieerd in aparte Protobuf-schema's. Via deze protocollen verwerkt de node kerntaken:

• Tokenisatie (HTS). Maakt het uitgeven en overdragen van tokens mogelijk zonder smart contracts te schrijven.
• Consensus logging (HCS). Maakt het vastleggen van timestamps en berichten op een gedistribueerd grootboek mogelijk.
• Smart contracts. Een EVM virtuele machine draait binnen de node, met ondersteuning voor de Solidity-compiler met de pragma solidity <=0.8.9 directive.

Solidity versie-ondersteuning is momenteel beperkt tot release 0.8.9. Voor standaard OpenZeppelin contracts of typische bedrijfslogica is dit voldoende, hoewel je nog geen toegang hebt tot de nieuwste taalfuncties.

Infrastructuur en Codekwaliteit

De repository onthult direct zijn bedrijfsmatige oorsprong. Er is geen van de typische chaos van kleine open-source utilities. De CI/CD-pipelines omvatten dagelijkse performancetests (Single Day Performance Tests) en langlopende endurance tests (Longevity Tests).

Het project is gecertificeerd volgens de OpenSSF Scorecard en CII Best Practices standaarden, en testdekking wordt gevolgd via Codecov.

Aan de andere kant heeft de issues sectie meer dan vijftienhonderd openstaande taken. Dit is normaal voor grote systemen die naar open source zijn gegaan, maar nieuwe ontwikkelaars zullen tijd moeten besteden aan het begrijpen van hoe het project is gestructureerd.

Waar te beginnen met leren

Het project is gebouwd met Gradle. Voor lokaal draaien heb je een recente Java-versie en voldoende RAM nodig.

Als je de architectuurdetails wilt bekijken, is het nuttig om de documentatie te raadplegen:

• De hedera-node/docs/design/ map bevat architectuurdiagrammen en serviceontwerpbeslissingen.
• De documentatie in platform-sdk/docs/ beschrijft de interne structuur van het consensus platform zelf.

Voor wie is dit project nuttig

Voor een typische Web3-ontwikkelaar die alleen een token wil uitgeven of een dApp wil deployen, is het draaien van je eigen node niet nodig. Het is veel eenvoudiger om kant-en-klare SDK's te gebruiken voor je favoriete programmeertaal.

Deze repository is voornamelijk interessant voor engineering teams. Die hun eigen enterprise netwerken ontwerpen op basis van Hashgraph-technologie, asynchroon BFT fault tolerance onderzoeken, of high-load Java-systemen bestuderen. De code bevat goede voorbeelden van geheugenoptimalisatie en het structureren van gRPC-services voor hoge belasting.