根据各客户端团队维护的硬件建议 EIP-7870，2026 年的以太坊全节点需要 4 核 CPU、32 GB 内存、4 TB NVMe SSD 和 50/15 Mbps 的网络连接。验证节点应配备 8 个核心、64 GB 内存，且 CPU 的 PassMark 单线程得分在 3,500 左右。使用 Reth、Erigon 或 Geth 基于路径的归档模式时，归档节点约需 2 至 2.5 TB；采用传统的基于哈希的模式，则需要超过 12 TB。
简要结论
| 角色 | CPU | 单线程（PassMark） | 内存 | 存储 | 带宽（下行 / 上行） |
|---|---|---|---|---|---|
| 最低配置（ethereum.org） | 2+ 核 | — | 16 GB，建议 32 GB | 2 TB NVMe，预计到 2027 年将不够用 | 25+ Mbps |
| 全节点（EIP-7870） | 4 核 / 8 线程 | 约 1,000 | 32 GB | 4 TB NVMe | 50 / 15 Mbps |
| 验证节点（EIP-7870 中的“证明者”） | 8 核 / 16 线程 | 约 3,500 | 64 GB | 4 TB NVMe | 50 / 25 Mbps |
| 本地区块构建者（EIP-7870） | 8 核 / 16 线程 | 约 3,500 | 64 GB | 4 TB NVMe | 100 / 50 Mbps |
EIP-7870 是一份信息类的“持续更新”文档，于 2025 年 1 月创建，由客户端开发者保持更新；ethereum.org 的节点运行指南（最近更新于 2026 年 8 月）沿用了其中的数据。这些数据描述的是能从容跟上链的节点，而不是技术上勉强能完成同步的最低配置机器。
磁盘空间：各客户端分别需要多少
一个节点要运行两个程序：执行客户端，负责保存状态和历史数据；共识客户端，负责跟踪信标链。磁盘占用几乎全部来自执行客户端。Ethereum.org 列出的主网数据量如下：
| 执行客户端 | Snap 同步全节点 | 完整归档 |
|---|---|---|
| Besu | 800 GB+ | 12 TB+ |
| Erigon | 不支持 snap 同步；完全修剪后约 2 TB | 2.5 TB+ |
| Geth | 500 GB+ | 基于哈希：12 TB+；基于路径：约 2 TB |
| Nethermind | 500 GB+ | 12 TB+ |
| Reth | 不支持 snap 同步；完全修剪后约 1.2 TB | 2.2 TB+ |
共识客户端的信标链数据还需另加约 200 GB。此外还要为数据增长留出余量：Geth 文档指出，在默认缓存设置下，snap 同步的节点在执行修剪之前每周增长约 14 GB。正因如此，尽管新部署的全节点占用远低于 2 TB，EIP-7870 仍要求 4 TB。
历史数据过期可节省 300 至 500 GB。自 2025 年 7 月起，所有主流客户端都可以删除合并（The Merge）之前的区块体和收据，这些数据对共识已不再重要。在 Geth（v1.16.0 及更高版本）中，新节点可用 --history.chain postmerge 启动，已有节点则先停止再运行 geth prune-history；Nethermind 从 v1.32.2 起对新节点默认启用该功能，Besu、Erigon 和 Reth 也有各自的参数，详见以太坊基金会的公告。
SSD 的类型与容量同样重要。Ethereum.org 不建议使用无 DRAM 缓存的硬盘和 QLC 硬盘：节点会持续进行大量小块随机读写，廉价的消费级 SSD 在持续负载下会降速，可能让节点永远落后于链。请使用带 DRAM 的 TLC NVMe 硬盘，运行中的数据库绝不要放在机械硬盘上。
归档节点：2 TB 还是 20 TB
归档节点保存所有历史状态，因此可以回答诸如“在区块 15,000,000 时这个余额是多少”之类的问题。区块浏览器、索引器、数据分析和部分 RPC 服务需要归档节点；钱包和验证节点则不需要。
- Geth 基于路径的归档（v1.16.0 及更高版本）：保存完整历史的主网归档约 2 TB，如果同时保存完整的扁平状态（flat state）则约 6.5 TB，同步约需两周。使用
--syncmode full --gcmode archive --history.state=0启用。通过eth_getProof获取历史默克尔证明需要 v1.17 以及--history.trienode选项。 - Erigon 和 Reth 在设计上就以紧凑归档为目标：据 ethereum.org，二者分别需要 2.5 TB+ 和 2.2 TB+。
- 基于哈希的归档（Geth 的传统模式、Besu、Nethermind）：超过 12 TB；Geth 文档还提醒，其基于哈希的数据库可能超过 20 TB，从创世区块开始同步需要数月。
大容量、高速的 NVMe 阵列以及充足的缓存内存，都能让归档节点明显受益。Geth 还允许用 --datadir.ancient 将状态历史移到更便宜、更慢的设备上。
CPU：单线程性能至关重要
区块处理基本是串行的，因此一个快核心比许多慢核心更重要。EIP-7870 以 PassMark 单线程得分目标来体现这一点：全节点约 1,000，验证节点或本地区块构建者约 3,500，因为后两者必须足够快地处理每个区块，才能按时完成证明或区块提议。以下是常见服务器处理器的情况，采用 PassMark 截至 2026 年 10 月的单线程评分：
| 处理器 | 核心 / 线程 | 单线程评分 | 验证节点目标（约 3,500） |
|---|---|---|---|
| AMD Ryzen 9 9950X3D | 16 / 32 | 4,737 | 高于目标 |
| AMD Ryzen 9 9950X | 16 / 32 | 4,726 | 高于目标 |
| AMD Ryzen 9 9900X | 12 / 24 | 4,670 | 高于目标 |
| AMD EPYC 4585PX | 16 / 32 | 4,540 | 高于目标 |
| Intel Xeon E-2488 | 8 / 16 | 4,300 | 高于目标 |
| AMD Ryzen 7 7700 | 8 / 16 | 4,050 | 高于目标 |
| AMD EPYC 9355P | 32 / 64 | 3,747 | 高于目标 |
| AMD EPYC 9454P | 48 / 96 | 2,988 | 低于目标；用于全节点和归档节点没有问题 |
高核心数的服务器 CPU 以主频换取吞吐量。因此它们非常适合归档节点、索引器以及在一台机器上运行多条链，但不太适合对延迟敏感的验证节点。
内存与带宽
内存。32 GB 足以同时运行一个执行客户端和一个共识客户端；64 GB 能为验证节点留出余量，用于更大的缓存、验证者客户端、MEV-Boost 和监控，并避免因内存交换而导致节点错过证明。超出这一容量的内存适用于归档节点，或在一台服务器上运行多个节点。
带宽。EIP-7870 要求全节点下行 50 Mbps、上行 15 Mbps，验证节点上行 25 Mbps，本地区块构建者上行 50 Mbps。这些只是下限：初始同步要下载数百 GB 数据，而连接良好的节点会全天候向对等节点提供区块。在按流量计费的连接上，上传流量是需要重点关注的一项；在不限流量端口上则无需在意。Geth 文档明确建议不要使用有流量上限的套餐。
什么节点选什么服务器
将上述要求对应到 PowerDedi 的配置，全部配备 10 Gbps 不限流量端口：
| 选用 | 配置 | 优势 | 价格 |
|---|---|---|---|
| 全节点或供自有应用使用的 RPC | Ryzen 9 9950X、128 GB、2 × 1.92 TB NVMe | 单线程 4,726；NVMe 共 3.84 TB（做镜像则为 1.92 TB） | $159/月 |
| 验证节点 | Ryzen 9 9950X3D、192 GB、2 × 3.84 TB NVMe | 高于 EIP-7870 对验证节点的 CPU 和内存目标，并配备 3.84 TB 镜像 NVMe | $219/月 |
| 使用 ECC 内存的验证节点 | EPYC 4585PX、128 GB ECC、2 × 1.92 TB NVMe | 同样的 Zen 5 主频，并配备纠错内存 | $179/月 |
| 归档节点、索引器或多条链 | EPYC 9454P、256 GB ECC、2 × 3.84 TB NVMe | 48 个核心和十二个内存通道，适合并行任务 | $489/月 |
| 大型归档节点或多客户端 RPC | EPYC 9555P、768 GB ECC、4 × 3.84 TB Gen5 | 四块高速硬盘，内存足以支撑大容量缓存 | $949/月 |
坦白说，有两点需要注意。每月 $79 的 Ryzen 7 7700 满足 CPU 和内存目标，但它的 2 × 1 TB NVMe 对需要留出增长空间的主网全节点来说太小；我们更推荐将它用于比特币节点。另外，EPYC 9454P 的单线程评分低于 EIP-7870 的验证节点目标：请将它用于归档和索引，而不是独立运行的验证节点。
避免重新同步的部署建议
- 共识客户端请使用检查点同步：它从最近一个已最终确定的状态开始，而不是从创世区块开始重放整条信标链。
- 新节点从一开始就修剪合并前的历史数据；这样就有 300 至 500 GB 数据根本无需下载。
- 将数据库放在独立的 NVMe 卷上，并监控剩余空间：执行客户端一旦耗尽磁盘空间，可能会损坏其数据库。
- 开放客户端的 P2P 端口（例如 Geth 点对点通信使用的 30303 TCP 和 UDP 端口），并让 RPC 端口只绑定到 localhost 或置于防火墙之后。其余事项请参阅我们的上线首小时安全加固清单。
- 切勿在两台机器上运行同一组验证者密钥。用同一组密钥运行备用验证节点，是遭到罚没（slashing）的典型原因；请启用防罚没保护，并手动执行故障切换。
本指南仅涉及硬件，不构成质押或财务建议。其他链请参阅我们的 Solana 验证节点与 RPC 配置指南以及区块链节点托管。
参考资料
- EIP-7870：硬件与带宽建议 — 以太坊改进提案
- 运行您自己的以太坊节点 — ethereum.org（更新于 2026 年 8 月 17 日）
- 硬件要求 — Geth 文档
- 归档节点 — Geth 文档（编辑于 2026 年 2 月 24 日）
- 历史数据修剪 — Geth 文档
- 部分历史数据过期公告 — 以太坊基金会博客，2025 年 7 月 8 日
- CPU 单线程性能 — PassMark Software
- AMD EPYC 9355P vs EPYC 9354 和 AMD EPYC 9454P vs EPYC 9454 — PassMark Software
