Wie der Hiero Node Server funktioniert und wie das Hedera-Netzwerk Transaktionen verarbeitet

Wenn Sie den Markt für dezentrale Netzwerke auch nur kurz verfolgt haben, haben Sie wahrscheinlich vom Hedera-Netzwerk gehört. Lange Zeit blieb seine Engine Closed-Source-Commercial-Code mit einer spezifischen Lizenz. Die Situation änderte sich, als das Projekt unter das Dach der Linux Foundation kam und den Open-Source-Namen Hiero erhielt.

Der in Java geschriebene Konsens-Node-Quellcode ist im hiero-consensus-node Repository verfügbar. Dies ist der genaue Dienst, der gRPC-Anfragen annimmt, Transaktionen durch den DAG-Konsens ausführt und Smart Contracts ausführt.

Was sich im Monorepository befindet

Der Code ist in zwei Haupt-Untermodule aufgeteilt:

• platform-sdk/ — die untere Ebene der Plattform. Sie verwaltet Netzwerkverbindungen zwischen Nodes, den Konsensalgorithmus und die persistente Speicherung des Netzwerkzustands.
• hedera-node/ — die Anwendungsschicht. Sie enthält Dienste für Konten, Token, Dateien und die Ausführung von EVM-Code.

Die Aufteilung ist logisch. Die Plattform übernimmt die mathematisch aufwendige Arbeit des verteilten Konsenses, während das Anwendungsmodul diesen Konsens in eine benutzerfreundliche API für Entwickler umwandelt.

Dienste, Protobuf und Solidity

Die Kommunikation zwischen Client und Node basiert auf dem gRPC-Protokoll. Die gesamte Spezifikation ist in separaten Protobuf-Schemas definiert. Über diese Protokolle verarbeitet der Node zentrale Aufgaben:

• Tokenisierung (HTS). Ermöglicht das Ausgeben und Übertragen von Token ohne das Schreiben von Smart Contracts.
• Konsens-Logging (HCS). Ermöglicht das Aufzeichnen von Zeitstempeln und Nachrichten in einem verteilten Ledger.
• Smart Contracts. Eine EVM-Virtual Machine läuft innerhalb des Nodes und unterstützt den Solidity-Compiler mit der pragma solidity <=0.8.9 Direktive.

Die Solidity-Versionsunterstützung ist derzeit auf die Version 0.8.9 beschränkt. Für Standard-OpenZeppelin-Verträge oder typische Geschäftslogik ist dies ausreichend, auch wenn Sie noch nicht auf die neuesten Sprachfunktionen zugreifen können.

Infrastruktur und Codequalität

Das Repository zeigt sofort seine Unternehmensherkunft. Es gibt keine der typischen Unordnung kleiner Open-Source-Utilities. Die CI/CD-Pipelines umfassen tägliche Performance-Tests (Single Day Performance Tests) und langlebige Ausdauertests (Longevity Tests).

Das Projekt ist nach den Standards von OpenSSF Scorecard und CII Best Practices zertifiziert, und die Testabdeckung wird über Codecov verfolgt.

Andererseits hat der Issues-Bereich über fünfzehnhundert offene Aufgaben. Dies ist normal für große Systeme, die auf Open Source umgestiegen sind, aber neue Entwickler müssen Zeit darauf verwenden, zu verstehen, wie das Projekt strukturiert ist.

Wo man mit dem Lernen beginnt

Das Projekt ist mit Gradle aufgebaut. Für die lokale Ausführung benötigen Sie eine aktuelle Java-Version und ausreichend RAM.

Wenn Sie sich in die Architekturdetails vertiefen möchten, ist es hilfreich, die Dokumentation zu konsultieren:

• Der hedera-node/docs/design/ Ordner enthält Architekturdiagramme und Servicedesign-Entscheidungen.
• Die Dokumentation in platform-sdk/docs/ beschreibt die interne Struktur der Konsensplattform selbst.

Wem dieses Projekt nützlich sein wird

Für einen typischen Web3-Entwickler, der nur einen Token ausgeben oder eine dApp bereitstellen muss, ist das Betreiben eines eigenen Nodes nicht notwendig. Es ist viel einfacher, vorgefertigte SDKs für Ihre bevorzugte Programmiersprache zu verwenden.

Dieses Repository ist in erster Linie für Engineering-Teams interessant. Für diejenigen, die eigene Enterprise-Netzwerke basierend auf der Hashgraph-Technologie entwerfen, asynchrone BFT-Fehler­toleranz erforschen oder hochbelastete Java-Systeme untersuchen. Der Code enthält gute Beispiele für Speicheroptimierung und die Strukturierung von gRPC-Diensten für hohe Last.