本页目录 9 个章节
Base 节点需要 8 核或以上、单核性能良好的现代 CPU，至少 32 GB 内存（建议 64 GB），本地直连 NVMe，以及以太坊 L1 RPC 和信标端点。Reth 现已是唯一受支持的客户端。2026 年 10 月 15 日，Base 的完整快照为 902 GB，归档快照为 4.2 TB。
Base 官方节点要求
Base 在其“节点性能”页面上发布了硬件指导，网络和 L1 方面的细节则见于运行节点教程。以下内容于 2026 年 10 月 15 日核实：
| 组件 | Base 的建议 |
|---|---|
| CPU | 现代多核 CPU，8 核以上，单核性能良好 |
| 内存 | 至少 32 GB；建议 64 GB |
| 存储类型 | 本地直连 NVMe SSD，强烈建议优先于网络存储；RAID 0 可提升性能 |
| 存储容量 | 2 × 当前链数据大小 + 快照大小 + 20% 余量 |
| 软件 | base-reth-node（执行层）和 base-consensus，通过 Docker Compose 运行 |
| L1 访问 | 以太坊 L1 RPC（不是 Base 的 RPC）和 L1 信标端点 |
| 入站端口 | 30303 和 9222，TCP 和 UDP |
作为参照，Base 自己的 Reth 归档节点运行在 AWS i7i.12xlarge 或更大规格的实例上，AWS 标注该实例配有 48 个 vCPU、384 GiB 内存和 3 × 3,750 GB 本地 NVMe，组成 RAID 0 条带并使用 ext4。Base 还提醒，如果您还不清楚为什么需要自己的节点，那多半就不需要：其公共端点 mainnet.base.org 可用于入门，但有速率限制，不适用于生产环境的应用。
Base 节点与 Reth：仅存的客户端
Base 的性能页面称 Reth 是 Base 上“目前性能最好的客户端”，而这一选择此后已成为强制要求。自 2026 年 5 月 28 日起在主网上线的 Azul 升级仅支持 base-reth-node 和 base-consensus；运行 op-geth 或 Nethermind 的节点必须改用 base-reth-node 从头开始，最好从 Reth 快照启动，op-node 也由 base-consensus 取代。6 月 25 日上线的 Beryl 将 Reth V2 定为参考执行客户端；主网运营者须在 8 月中旬前迁移到 V2 存储，Base 也正在停用 V1 快照。
代码也迁移了。自 v1.3.0 起，运营者节点改由 base/base 仓库以 ghcr.io/base/node 镜像的形式发布，旧的 base/node 仓库已于 2026 年 9 月 4 日归档。当前版本 v1.5.0 于 2026 年 10 月 14 日发布。
Base 归档节点与全节点数据量对比：需要多少磁盘？
Base 发布每周更新的快照，可以跳过大部分初始同步。以下是 2026 年 10 月 15 日 chain.base.org/snapshots 页面上列出的预设（主网区块高度 52,616,526）：
| 预设 | 内容 | 快照大小 | 公式下限（我们的估算） |
|---|---|---|---|
| 最小 | 仅含状态和区块头 | 778.1 GB | 约 2.8 TB |
| 完整 | 增加交易、收据和状态历史；适用于 dApp 后端和通用 RPC | 901.6 GB | 约 3.2 TB |
| 归档 | 完整历史数据，适用于索引器和 RPC 服务商 | 4.2 TB | 约 15.1 TB |
| 归档 + 证明 | 归档数据外加执行证明 | 5.1 TB | 约 18.4 TB |
Base 提醒，解压后的数据“明显大于”下载的文件。文档引用其统计页面作为当前链数据大小的依据，但该页面并未以我们能够核实的形式提供这一数字；因此最后一列套用 Base 的公式，用各快照的大小代替链数据大小，并在总量上再加 20%。请将这些数字视为下限。
- 节点类型在首次同步时就已确定。不支持将归档节点转为修剪节点，也不支持将修剪节点转为全节点；通过
RETH_PRUNING_ARGS自定义修剪则需要从归档快照开始。 - “完整”预设保留多少历史，目前仍在变化。Base 的快照常见问题称，Reth 的完整（full）预设保留最近 10,064 个区块，在 Base 上约合 5–6 小时；而 2026 年 9 月 1 日发布的 v1.3.0 版本说明则称，完整预设现在保留一个月的历史。请查看您所部署版本的发行说明。
- 历史证明需要额外开销。要高效提供
eth_getProof及相关方法，需要启用证明扩展；据 Base 称，该扩展会增加数百 GB 数据、需要更高的 I/O，而且除非从证明快照恢复，否则在主网上回填需要 24–48 小时。大多数运营者并不需要它。
L1 要求：以太坊 RPC 与信标端点
Base 节点根据发布到以太坊的数据派生出自己的链，因此需要在 .env.mainnet 中配置两个 L1 端点：BASE_NODE_L1_ETH_RPC（以太坊全节点 RPC）和 BASE_NODE_L1_BEACON（信标节点）。Base 的派生规范通过信标 API 的 /eth/v1/beacon/blob_sidecars/ 端点获取以 blob 形式发布的批次数据，并建议为此使用本地信标节点。
这两个端点都可以租用，但 Base 提醒，同步“可能需要数天”，并且“会消耗大量的请求配额”。自行运行 L1 节点可以免受配额限制，但它必须先完全同步：在 L1 节点同步完成之前，Base 节点无法完成同步。L1 节点的硬件需要单独规划：执行客户端和共识客户端各需配备自己的 NVMe，详见我们的以太坊节点硬件指南。如果都放在一台服务器上，请把两部分磁盘需求相加。
CPU、内存，以及向 200 ms 出块时间的过渡
Base 要求 8 核或以上、单核性能良好的 CPU，以及 32 GB 内存（建议 64 GB）。其故障排查指南还指出，节点同步缓慢时，瓶颈往往在磁盘 I/O，这正是它坚持使用本地 NVMe 的原因。在我们看来，超出最低要求的内存应视为应对 RPC 负载和操作系统文件缓存的余量，而不是硬性要求。
每秒负载即将发生变化。Denim 升级会把每两秒一个区块改为每秒五个规范区块，并同时取代 Flashblocks。该升级将于 2026 年 10 月 21 日在 Base Sepolia 上激活，Base 计划于 11 月 2026 日在主网激活。Base 没有为此给出新的硬件数据，因此我们建议预留 CPU 和磁盘余量，并在激活后重新评估增长情况，而不是只按目前的链来规划配置。
端口与带宽
| 端口 | 目的 | 开放范围 |
|---|---|---|
| 30303 TCP/UDP | 执行层 P2P：节点发现（discv4）与 RLPx | 开放入站 |
| 9222 TCP/UDP | 节点发现 v5（discv5） | 开放入站 |
| 9200 UDP，30301 TCP/UDP | 连接 Base 引导节点 | 允许出站 |
| 8545, 8546 | 基于 HTTP 和 WebSocket 的 JSON-RPC | 仅限您自己的应用 |
| 8551 | base-consensus 与执行客户端之间的 Engine API | 内部 |
| 7545 | base-consensus RPC，包括 optimism_syncStatus | 本地 |
封锁出站端口 9200 和 30301 会让节点连接不到任何对等节点；而且与有状态防火墙不同，网络 ACL 还需要在出站方向开放 32768–60999 的临时端口范围。Base 没有公布带宽数据。唯一可以预见的大流量传输是初始快照：以 1 Gbps 持续速率计算，完整预设约需两小时，归档约需九小时。Base 的下载工具默认并行运行 8 个传输任务，并建议在较大的机器上设为物理核心数的两倍；因此在 10 Gbps 不限流量端口上，决定下载速度的更可能是快照服务器，而不是您的链路。
Base 节点选哪款 PowerDedi 服务器
| 选用 | 配置 | 适用人群 | 价格 |
|---|---|---|---|
| 供自有应用使用的全节点 | Ryzen 9 9950X：16 核、128 GB DDR5、2 × 1.92 TB NVMe | 内存为建议值的两倍；3.84 TB 条带化存储仅略高于 3.2 TB 的下限，增长空间很小 | $159/月 |
| 留有余量的全节点 | Ryzen 9 9950X3D：16 核、192 GB DDR5、2 × 3.84 TB NVMe | 7.68 TB 条带化存储：留有增长空间；如果合计数据量放得下，也可同时运行 L1 节点 | $219/月 |
| 使用 ECC 内存的全节点 | EPYC 4585PX：16 核、128 GB DDR5 ECC、2 × 1.92 TB NVMe | 频率和磁盘上限与 9950X 相同 | $179/月 |
| 高负载 RPC 全节点 | EPYC 9355P：32 核、384 GB ECC、2 × 3.84 TB NVMe Gen5 | 更多核心和内存，可应对并发查询；24 小时内组装完成 | $519/月 |
| 归档节点 | EPYC 9555P：64 核、768 GB ECC、4 × 3.84 TB NVMe Gen5 | 核心、内存和磁盘均高于 Base 所用的 i7i.12xlarge；15.36 TB 条带化存储，仅略高于 15.1 TB 的下限；24 小时内组装完成 | $949/月 |
坦白说，有三点需要注意。第一，归档节点的容量比较紧张。EPYC 9555P 应该能容纳目前的归档数据并留有余量，因为 Base 自己的归档节点也是从 11.25 TB NVMe 起步；但它只是勉强超过公式下限，而解压后的链数据比快照更大；如果加上证明，下限会提高到约 18.4 TB。我们销售的配置中，NVMe 容量比它更大的只有 EPYC 9965（$1,790/月，4 × 7.68 TB，72 小时内交付），但其 2.25 GHz 的基础频率与 Base 关于单核性能的建议相悖。第二，上述所有方案都假定硬盘做了条带化，Base 自己也是这样做的：一块硬盘故障就意味着要重新从快照恢复，因此请将配置过程脚本化；我们的软件 RAID 指南介绍了各种布局。第三，如果您只需要读取 Base 数据或发送交易，使用 RPC 服务商就足够了。
如何运行 Base 节点：部署概要
以下命令来自 Base 的文档和 base/base 的 README；请将 L1 占位符替换为您自己的端点。
# 1. Install the release binaries, including the base-reth-node CLI
curl -fsSL https://raw.githubusercontent.com/base/base/main/baseup/install | bash
# 2. Get the operator compose file and environment templates
git clone https://github.com/base/base.git
cd base
# In .env.mainnet, set BASE_NODE_L1_ETH_RPC and BASE_NODE_L1_BEACON
# 3. Restore a snapshot (--minimal, --full or --archive)
mkdir ./reth-data
base-reth-node download --full --datadir ./reth-data --chain base --resumable
# 4. Start the node (pin a release with NODE_TAG=vX.Y.Z)
docker compose up
# 5. Check that the RPC answers
curl -d '{"id":0,"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false]}' -H "Content-Type: application/json" http://localhost:8545用 docker compose logs -f execution 和 docker compose logs -f node 跟踪日志，参照我们的上线首小时安全加固清单，确保端口 8545、8546 和 7545 不暴露在公网上，当前库存请见区块链节点托管。
参考资料
- 节点性能 — Base 文档
- 运行节点 — Base 文档
- 节点快照和节点故障排查 — Base 文档
- 快照 — Base（查询于 2026 年 10 月 15 日）
- 节点升级指南和升级 — Base 文档
- 派生（Ecotone 升级） — Base 文档
- base/base 发行版本（v1.3.0 至 v1.5.0）和 .env.mainnet — Base，GitHub
- Amazon EC2 I7i 实例 — Amazon Web Services
