Как устроен узловой сервер Hiero и за счет чего сеть Hedera обрабатывает транзакции

Если вы хотя бы мельком следили за рынком децентрализованных сетей, то наверняка слышали про сеть Hedera. Долгое время её движок оставался закрытым коммерческим кодом со специфической лицензией. Ситуация изменилась, когда проект перешел под крыло Linux Foundation и получил открытое имя Hiero.

В репозитории hiero-consensus-node выложен исходный код узла консенсуса, написанный на Java. Это именно тот сервис, который принимает gRPC-запросы, проводит транзакции через DAG-консенсус и исполняет смарт-контракты.

Что внутри монорепозитория

Код разбит на два основных дочерних модуля:

• platform-sdk/ — нижний уровень платформы. Он отвечает за сетевые связями между узлами, алгоритм консенсуса и персистентное хранение состояния сети.
• hedera-node/ — прикладной уровень. На нем созданы сервисы аккаунтов, токенов, файлов и исполнение кода EVM.

Разделение логичное. Платформа берет на себя суровую математику распределенного согласия, а прикладной модуль превращает это согласие в удобный API для разработчиков.

Сервисы, Protobuf и Solidity

Связь клиентов с узлом строится через gRPC-протокол. Вся спецификация вынесена в отдельные Protobuf-схемы. Через эти протоколы узел обрабатывает базовые задачи:

• Токенизация (HTS). Позволяет выпускать и передавать токены без написания смарт-контрактов.
• Логирование консенсуса (HCS). Дает возможность записывать временные метки и сообщения в распределенный реестр.
• Смарт-контракты. Внутри узла работает виртуальная машина EVM, поддерживающая компилятор Solidity с директивой pragma solidity <=0.8.9.

Поддержка версий Solidity пока ограничена релизом 0.8.9. Для стандартных контрактов OpenZeppelin или привычной бизнес-логики этого вполне хватает, хотя до самых свежих фич языка добраться пока не получится.

Инфраструктура и качество кода

Репозиторий сразу выдает корпоративное происхождение. Здесь нет типичной хаотичности мелких open-source утилит. В CI/CD пайплайнах прописаны суточные тесты производительности (Single Day Performance Tests) и длительные тесты на выносливость (Longevity Tests).

Проект сертифицирован по стандартам OpenSSF Scorecard и CII Best Practices, а тестовое покрытие отслеживается через Codecov.

С другой стороны, в разделе issues висит больше полутора тысяч открытых задач. Это норма для крупных систем, перешедших в открытый доступ, но новому разработчику придётся потратить время, чтобы разобраться в устройстве проекта.

С чего начать изучение

Проект собирается с помощью Gradle. Для локального запуска понадобится свежая Java и достаточное количество оперативной памяти.

Если захочется покопаться в деталях архитектуры, полезно заглянуть в документацию:

• В папке hedera-node/docs/design/ собраны архитектурные схемы и решения по устройству сервисов.
• Документация в platform-sdk/docs/ описывает внутреннее устройство самой платформы консенсуса.

Кому пригодится этот проект

Обычному веб3-разработчику, которому нужно просто выпустить токен или развернуть dApp, поднимать собственный узел не обязательно. Гораздо проще взять готовые SDK для нужного языка программирования.

Этот репозиторий интересен в первую очередь инженерным командам. Тем, кто проектирует собственные корпоративные сети на базе технологии Hashgraph, исследует асинхронную BFT-толерантность к сбоям или изучает высоконагруженные Java-системы. В коде можно найти хорошие примеры оптимизации работы с памятью и структурирования gRPC-сервисов под высокую нагрузку.