How the Hiero Node Server Works and How the Hedera Network Processes Transactions

If you've even briefly followed the decentralized networks market, you've likely heard of the Hedera network. For a long time, its engine remained closed commercial code with a specific license. The situation changed when the project moved under the Linux Foundation umbrella and received the open-source name Hiero.

The consensus node source code, written in Java, is available in the hiero-consensus-node repository. This is the exact service that accepts gRPC requests, runs transactions through DAG consensus, and executes smart contracts.

What's Inside the Monorepository

The code is split into two main child modules:

• platform-sdk/ — the platform's lower level. It handles network connections between nodes, the consensus algorithm, and persistent storage of the network state.
• hedera-node/ — the application layer. It contains services for accounts, tokens, files, and EVM code execution.

The division is logical. The platform handles the heavy mathematical work of distributed consensus, while the application module turns that consensus into a convenient API for developers.

Services, Protobuf, and Solidity

Client-to-node communication is built on the gRPC protocol. The entire specification is defined in separate Protobuf schemas. Through these protocols, the node handles core tasks:

• Tokenization (HTS). Allows issuing and transferring tokens without writing smart contracts.
• Consensus logging (HCS). Enables recording timestamps and messages to a distributed ledger.
• Smart contracts. An EVM virtual machine runs inside the node, supporting the Solidity compiler with the pragma solidity <=0.8.9 directive.

Solidity version support is currently limited to the 0.8.9 release. For standard OpenZeppelin contracts or typical business logic, this is sufficient, although you won't be able to access the latest language features yet.

Infrastructure and Code Quality

The repository immediately reveals its corporate origins. There's none of the typical chaos of small open-source utilities. The CI/CD pipelines include daily performance tests (Single Day Performance Tests) and long-running endurance tests (Longevity Tests).

The project is certified under OpenSSF Scorecard and CII Best Practices standards, and test coverage is tracked through Codecov.

On the other hand, the issues section has over fifteen hundred open tasks. This is normal for large systems that have moved to open source, but new developers will need to spend time understanding how the project is structured.

Where to Start Learning

The project is built with Gradle. For local running, you'll need a recent Java version and sufficient RAM.

If you want to dig into architecture details, it's useful to check the documentation:

• The hedera-node/docs/design/ folder contains architectural diagrams and service design decisions.
• The documentation in platform-sdk/docs/ describes the internal structure of the consensus platform itself.

Who Will Find This Project Useful

For a typical Web3 developer who just needs to issue a token or deploy a dApp, running your own node isn't necessary. It's much simpler to use ready-made SDKs for your preferred programming language.

This repository is primarily interesting for engineering teams. Those designing their own enterprise networks based on Hashgraph technology, researching asynchronous BFT fault tolerance, or studying high-load Java systems. The code contains good examples of memory optimization and structuring gRPC services for high load.