Hiero 节点服务器的工作原理及 Hedera 网络如何处理交易

如果你曾短暂关注过去中心化网络市场，你可能听说过 Hedera 网络。长期以来，其引擎一直是带有特定许可的闭源商业代码。直到该项目移至 Linux Foundation 旗下，并获得了 Hiero 这个开源名称，情况才有所改变。

用 Java 编写的共识节点源代码可在 hiero-consensus-node 仓库中获取。这正是接受 gRPC 请求、通过 DAG 共识运行交易并执行智能合约的服务。

单仓库内部结构

代码分为两个主要子模块：

• platform-sdk/ — 平台的底层。它处理节点间的网络连接、共识算法以及网络状态的持久化存储。
• hedera-node/ — 应用层。它包含账户、代币、文件和 EVM 代码执行的服务。

这种划分是合理的。平台处理分布式共识的繁重数学计算工作，而应用模块则将这些共识转化为对开发者友好的 API。

服务、Protobuf 和 Solidity

客户端到节点的通信基于 gRPC 协议构建。整个规范在独立的 Protobuf 模式中定义。通过这些协议，节点处理核心任务：

• 代币化（HTS）。允许发行和转移代币而无需编写智能合约。
• 共识日志（HCS）。支持将时间戳和消息记录到分布式账本。
• 智能合约。节点内部运行 EVM 虚拟机，支持带有 pragma solidity <=0.8.9 指令的 Solidity 编译器。

Solidity 版本支持目前仅限于 0.8.9 版本。对于标准的 OpenZeppelin 合约或典型业务逻辑，这已经足够，尽管你还无法使用最新的语言特性。

基础设施和代码质量

这个仓库立即暴露了其企业背景。没有小型开源工具常见的典型混乱。CI/CD 流水线包括每日性能测试（Single Day Performance Tests）和长期运行的 endurance 测试（Longevity Tests）。

该项目通过了 OpenSSF Scorecard 和 CII Best Practices 标准认证，测试覆盖率通过 Codecov 进行跟踪。

另一方面，issues 部分有超过一千五百个未完成的任务。这对于已转向开源的大型系统来说是正常的，但新开发者需要花时间理解项目的结构。

从哪里开始学习

项目使用 Gradle 构建。在本地运行需要较新的 Java 版本和足够的内存。

如果你想深入了解架构细节，查看文档会很有帮助：

• hedera-node/docs/design/ 文件夹包含架构图和服务设计决策。
• platform-sdk/docs/ 中的文档描述了共识平台本身的内部结构。

谁会发现这个项目有用

对于只需要发行代币或部署 dApp 的典型 Web3 开发者来说，运行自己的节点并非必要。使用现成的 SDK for your preferred programming language 会简单得多。

这个仓库主要对工程团队有吸引力。那些基于 Hashgraph 技术设计自己的企业网络、研究异步 BFT 容错或学习高负载 Java 系统的人。代码包含内存优化和高负载 gRPC 服务结构化的良好示例。