本页目录 12 个章节
根据截至 2026 年 10 月的 Avalanche 文档，低质押量的验证节点需要 4 核/8 线程、16 GB 内存、1 TB 本地 NVMe SSD 和 100 Mbps 对称带宽；高质押量则需要 8 核/16 线程、32 GB 内存、2 TB 存储和 1 Gbps 带宽。C-Chain 归档节点需要 12.5 TB 或更多。
以上数据来自 Avalanche Builder Hub 的系统要求（System Requirements）页面，该页面于 2026 年 10 月初针对 Helicon 升级进行了修订；Helicon 自 2026 年 9 月 22 日起已在主网激活。Helicon 没有改变硬件档位，但改变了磁盘维护方式和质押规则。本指南涵盖硬件、磁盘规划和部署，不构成质押或财务建议。
简要结论
| 节点类型 | CPU | 内存 | 磁盘 | 网络 |
|---|---|---|---|---|
| 主网络验证节点，低质押量 | 4 核 / 8 线程 | 16 GB | 1 TB 本地 NVMe | 100 Mbps 对称 |
| 主网络验证节点，高质押量 | 8+ 核 / 16 线程 | 32 GB | 2 TB 本地 NVMe | 1 Gbps 对称，低延迟 |
| API 节点（状态同步，开启修剪） | 无单独数据；README 给出的最低要求为 8 个 vCPU | 16 GiB（README） | 同步后约 500 GB，随着快照累积增至 750 GB–1 TB | 未说明 |
| C-Chain 归档（完整同步，关闭修剪） | 未说明 | 未说明 | 2025 年 12 月为 12.5–13 TB+，每月增长约 500 GB | 未说明 |
| Avalanche L1 验证节点，仅同步 P-Chain | 2 / 4 / 8+ 核 | 4 / 8 / 16+ GB | 100 GB / 500 GB SSD / 1 TB+ NVMe | 25 Mbps / 100 Mbps / 1 Gbps |
L1 一行分别给出了低、中、高三个吞吐量档位。每个档位都要求 Ubuntu 22.04 LTS 或 macOS 12 及更高版本，每个节点都必须接受端口 9651 上的入站 TCP 连接，而主网络（Primary Network）验证节点至少需要质押 2,000 AVAX。
验证节点硬件：为什么由质押量决定档位
Avalanche 按质押权重来确定主网络验证节点的配置：“质押量更高的验证节点会收到更多流量，必须处理更多数据，因此需要更好的硬件。”验证节点之间按与质押量成正比的概率相互抽样，因此获得大量委托的节点要响应更多查询。文档给出了示例硬件：低质押量用 Ryzen 5 或 Core i5，高质押量用 Ryzen 7/9 或 Core i7/i9；但没有给出两个档位之间的分界线，并建议从低档起步，在 CPU、内存或网络出现饱和时再升级。
有三个官方来源给出了最低要求：
| 来源 | CPU | 内存 | 存储 | 状态 |
|---|---|---|---|---|
| Builder Hub 系统要求 | 低质押量 4C/8T，高质押量 8C/16T | 16 / 32 GB | 1 / 2 TB 本地 NVMe，至少 3,000 IOPS | 现行文档 |
| AvalancheGo README | “相当于 8 个 AWS vCPU” | 16 GiB | 1 TiB | 任何主网节点的最低要求 |
| ACP-256 | 8 个 AWS vCPU | 16 GB | 1 TB 本地 NVMe；大型历史状态“最多约 15 TB” | 仅为提案；不涉及协议变更 |
如果把 vCPU 理解为硬件线程，README 中的 8 个 vCPU 正好与低质押档位相当。各来源在存储类型上存在分歧：系统要求页面称验证节点必须使用本地 NVMe，因为云块存储“会引入延迟，导致性能不佳、错过区块，并可能被其他节点暂时搁置（benching）”；而 ACP-256 则允许所存状态低于 500 GB 的验证节点使用网络附加存储。在机箱内自带 NVMe 的独立服务器上，这个问题根本不存在。
Avalanche 节点需要多少磁盘空间
对于主网络节点，文档按 C-Chain 的 EVM 状态来估算磁盘容量：
| 状态 | C-Chain 大小 | 获取方式 | 增长 |
|---|---|---|---|
| 活跃状态 | 约 500 GB | 状态同步，数小时完成 | 极少，每月低于 10 GB |
| 活跃状态加状态同步快照 | 750 GB–1 TB | 先状态同步，再在开启修剪的情况下正常运行 | 每月 150–200 GB |
| 归档状态 | “约 13 TB+（且仍在增长）”；系统要求页面为 12.5 TB | 关闭修剪，从创世区块完整同步，需数天 | 每月约 500 GB |
请按中间一行来规划。在默认的 hash 状态方案下，修剪节点每 4,096 个区块会写入一个状态同步快照，供其他节点同步使用，而且“大多数长期运行的验证节点都处于这种状态”。一个从 500 GB 起步的节点，几个月内就可能超过 1 TB。文档将磁盘告警阈值设为 80% 和 90%，并称磁盘占用是“验证节点最常见的问题”。
Helicon 取消了原地清理的办法。以前可以通过离线修剪在同一台机器上删除这些快照。自 Helicon 起，AvalancheGo v1.15.0 及更高版本中的 C-Chain 会忽略 offline-pruning-enabled，文档称重新进行状态同步是“清除累积快照的唯一方法”。这种定期状态同步需要运行第二个节点直至其同步完成，然后停止两个节点，并将 staker.crt、staker.key 和 signer.key 移到新节点上；新节点在通常 5 至 15 分钟的停机后，以相同的 NodeID 继续验证。Subnet-EVM L1 链仍可进行离线修剪。
磁盘容量决定了重新同步的频率。按我们的计算，以 500 GB 起步、每月增长 150–200 GB、在达到 80% 告警时处理：
- 1 TB：每 1.5 至 2 个月重新同步一次。
- 1.92–2 TB：每 5 至 7 个月一次。
- 3.84 TB：每 13 至 17 个月一次。
这些容量数据有多新？文档仓库的提交记录显示了它们的修改日期：12.5 TB 的归档数据写入于 2025 年 12 月 18 日（取代了“约 3 TB+”），约 13 TB 的数据写入于 12 月 22 日，增长速度则更新于 2026 年 2 月 4 日，当时归档增长的估算值从每月约 250 GB 提高到 500 GB。Helicon 修订没有改动其中任何一项。以 12 月的数据为基础，按这些速度推算，到 2026 年 10 月中旬，完整归档约为 15 至 18 TB：这是我们的推算，而非实测，也是我们按 20 TB 或以上来配置归档服务器的原因。
Helicon 升级后的状态同步与引导同步
状态同步在 C-Chain 上默认开启，也推荐新验证节点使用；它从其他验证节点下载最新状态，而不是重放自创世区块以来的每个区块：只需几小时，而不是几天。v1.15.0 的发行说明补充了三项限制：
- 在同步过程中重启节点“将从头开始重新同步”，因此请先完成操作系统更新和重启。
- 在部分同步后禁用状态同步“可能导致不可恢复的
FATAL错误”；恢复的办法只能是删除数据库。 - 实验性的 Firewood 状态方案无法进行状态同步，因此主网上的 Firewood 节点要从创世区块开始执行每一个区块。
C-Chain 归档节点要求
归档节点保存每个区块的状态，用于查询诸如某个账户在区块 1,000,000 时的余额之类的问题；文档将其限定用于“区块浏览器、索引器和专门的分析应用”。它需要在 C-Chain 配置中设置 "pruning-enabled": false 和 "state-sync-enabled": false，然后从创世区块开始完整同步。将现有节点转换为归档节点需要重新引导同步。
一种更轻量的方案是在关闭修剪的情况下进行状态同步，由此得到一个“归档 RPC”节点，保存从同步高度起的完整状态：初始为 750 GB–1 TB，之后按归档速度增长。它无法回答更早区块的查询，但成本只是从创世区块开始的归档节点的一小部分。
Avalanche 没有给出归档节点的 CPU 或内存数据。ACP-256 规定归档节点必须使用本地 NVMe；2026 年 10 月 1 日发布的 v1.15.1 修复了“在大型 hashdb 归档上”区块执行滞后的问题，因此请运行最新版本。
Helicon 升级后的验证节点质押规则
截至 2026 年 10 月，主网（Mainnet）上的主网络规则如下：
| 参数 | 数值 |
|---|---|
| 验证节点最低质押量 | 2,000 AVAX |
| 验证期限 | 48 小时至 1 年（Helicon 之前最短为两周） |
| 获得奖励所需的在线率 | Helicon 激活时或之后开始的验证为 90%；此前开始的为 80% |
| 最低委托量 | 25 AVAX，期限为两周至一年 |
| 最低委托费率 | 2% |
| 验证节点最大权重 | 3 百万 AVAX 与验证节点自身质押量五倍中的较低者 |
奖励要么全拿，要么全无，且没有罚没（slashing）：低于阈值的验证节点保留本金，但失去奖励。在线率由其他验证节点评判，并按质押量加权，因此请查看 info.uptime 和 Validator Health 仪表板。10% 的容许停机时间在 48 小时的验证期内为 4.8 小时，在两周的验证期内为 33.6 小时。质押期少于两周的验证节点无法接受委托，因为委托必须持续两周，并且须处于验证节点的验证期之内。
Helicon 还新增了自动续期质押（ACP-236）：验证节点设定周期长度和再质押比例，只要满足在线率要求，就会在每个周期结束时自动续期；将期限设为 0 即可停止自动续期。传统验证一经发起，就无法更改或提前撤回。
ACP-77（Avalanche9000）之后的 L1 验证节点
Etna 升级（又称 Avalanche9000）于 2024 年 12 月 16 日在主网激活了 ACP-77，将 L1 验证与主网络分离。L1 验证节点：
- 无需质押 2,000 AVAX，也无需验证 C-Chain 和 X-Chain。质押规则由 L1 自己的验证者管理合约（validator manager）设定，ACP-267 的 90% 在线率规则不适用。
- 需持续支付费用：从预付余额中向 P-Chain 支付；在活跃 L1 验证节点不超过 10,000 个时，费用至少为每秒 512 nAVAX，约合每月 1.33 AVAX。超过这一目标数量后，费率将呈指数级上升；余额耗尽的验证节点会被停用。
- 只同步 P-Chain，需使用
--partial-sync-primary-network=true。如果不加该参数，节点还会同步 X-Chain 和 C-Chain，文档要求此时再加上主网络的硬件要求。
采用部分同步时，硬件要求随流量增减：约 10 TPS 以下需 2 核、4 GB 内存和 100 GB 存储；100 TPS 以内需 4 核、8 GB 内存和 500 GB SSD；超出后则需 8+ 核、16 GB+ 内存和 1 TB+ NVMe。
端口与带宽
| 端口 | 协议 | 选用 | 开放范围 |
|---|---|---|---|
| 9651 | TCP | 质押与点对点通信（--staking-port） | 开放入站，经由 IPv4、IPv6 或两者 |
| 9650 | TCP（HTTP） | API（--http-port）：/ext/info、/ext/health、/ext/metrics、/ext/bc/P、/ext/bc/X、/ext/bc/C/rpc、/ext/bc/C/ws | 默认监听 127.0.0.1；仅对受信任的地址开放 |
| 出站 | 全部 | 与对等节点的连接 | 允许 |
如果验证节点的端口 9651 无法访问，或对外通告的地址有误，在线率就可能偏低；质押指南给出的解决办法是设置 --public-ip 并开放端口。安装程序会询问 RPC 应为公开还是私有，并警告验证节点“不应（SHOULD NOT）开放其 RPC 端口”。
Avalanche 以链路速度来表述带宽，没有给出每月流量数据。每台 PowerDedi 服务器都配备独享的 10 Gbps 不限流量端口，因此无论是验证节点的流量，还是 500 GB 的重新同步，都不会出现在账单上。端口 9651 前部署了常开的网络 DDoS 缓解防护，并包含一个路由的 IPv6 /64 地址段。
Avalanche 节点选哪款 PowerDedi 服务器
以下所有配置都配备本地 NVMe，按月计费；我们的可接受使用政策允许运行节点和验证节点，但不允许挖矿。双硬盘服务器默认采用 RAID 1，即容量相当于一块硬盘的镜像；下单或重装系统时也可以选择 RAID 0 或无 RAID，详见我们的软件 RAID 指南。四硬盘服务器默认采用 RAID 10，也可选择 RAID 5 和 RAID 0。
| 角色 | 配置 | 磁盘与适用性 | 价格与城市 |
|---|---|---|---|
| 部分同步的 L1 验证节点，低或中吞吐量 | Ryzen 5 7600：6 核、32 GB DDR5、2 × 512 GB NVMe | 512 GB 镜像，处于中档要求的边缘；用作主网络节点则太小 | $55/月；AMS、FRA、LON、PAR、NYC、MIA、LAX、SIN |
| 主网络验证节点，低质押量 | Ryzen 7 7700：8 核 / 16 线程、64 GB DDR5、2 × 1 TB NVMe；或配备 ECC 的 Xeon E-2488 | 1 TB 镜像满足低质押档位，每 1.5 至 2 个月需重新同步一次；条带化后 2 TB 满足高质押档位的全部指标，但没有冗余 | $79/月（AMS、FRA、LON、PAR、NYC、MIA、LAX、SIN）或 $95/月（AMS、FRA、LON、PAR、ZRH、NYC、MIA） |
| 高质押量验证节点 | Ryzen 9 9950X：16 核、128 GB DDR5、2 × 1.92 TB NVMe；或配备 ECC 的 EPYC 4585PX | 1.92 TB 镜像，比 2 TB 的指标低 4%；每 5 至 7 个月重新同步一次 | $159/月（AMS、FRA、LON、NYC、MIA、LAX、SIN、TYO）或 $179/月（AMS、FRA、LON、NYC） |
| 重新同步次数更少的验证节点或 API 节点 | Ryzen 9 9950X3D：16 核、192 GB DDR5、2 × 3.84 TB NVMe | 3.84 TB 镜像：两次重新同步之间可间隔一年或更久 | $219/月；AMS、FRA、NYC、LAX |
| 从近期同步点开始的归档 RPC | EPYC 9555P：64 核、768 GB ECC、4 × 3.84 TB NVMe Gen5 | RAID 10 下 7.68 TB：在达到 80% 告警前约可容纳十个月的归档增长；24 小时内组装完成 | $949/月；AMS、FRA、NYC、TYO |
| 从创世区块开始的完整 C-Chain 归档 | EPYC 9965：192 核，1.5 TB ECC，4 × 7.68 TB NVMe Gen5 | RAID 5 下 23 TB，可承受单块硬盘故障；RAID 10 的 15.36 TB 太小；72 小时内组装完成 | $1,790/月；AMS、FRA、NYC |
有四点需要注意：
- 条带化还是镜像。链数据可以重新同步，因此只要质押密钥已备份到服务器之外，用 RAID 0 换取容量是合理的取舍。但这样一来，一旦硬盘故障，就要花几个小时进行状态同步，而按 90% 规则，48 小时的验证期只允许 4.8 小时停机。验证期较短时，请保留镜像。
- 重新同步需要第二台机器。文档中的流程是在旧服务器继续验证的同时同步一台新服务器；现货配置会在付款于链上确认后约 15 分钟交付。我们的建议：轮换使用两台服务器，每次切换后清除旧节点的密钥和数据库。切勿同时运行两个使用相同质押密钥的节点。
- 归档服务器选的其实是硬盘。只有 EPYC 9965 能容纳从创世区块开始的归档并留有余量，因此您租用 192 个核心，其实是为了获得 30.72 TB 的原始 NVMe 容量。RAID 5 会增加校验写入；RAID 0 可提供全部容量，但没有保护。我们的存储服务器主要以机械硬盘提供大容量，而本地 NVMe 的要求排除了这类服务器。
- 位置。Avalanche 文档没有对位置提出要求，因此请选择适合您运维需要的城市。
如何运行 Avalanche 节点：部署概要
在全新的 Ubuntu 服务器上，最快的方式是使用 Avalanche 的安装脚本：它支持 amd64 或 arm64 上的 Debian 系和 RHEL 系发行版，并将最新版 AvalancheGo 安装为 systemd 服务。截至 2026 年 10 月中旬，最新版本为 v1.15.1；自 Helicon 起，主网要求 v1.15.0 或更高版本。以下命令来自文档：
# 1. Download the installer
wget -nd -m https://raw.githubusercontent.com/ava-labs/builders-hub/master/scripts/avalanchego-installer.sh
chmod 755 avalanchego-installer.sh
# 2. Validator: fixed IP, local-only RPC, state sync on
# (public API node: --rpc public, behind a firewall)
./avalanchego-installer.sh --ip static --rpc private --state-sync on
# 3. Follow the bootstrap, then check the C-Chain
sudo journalctl -u avalanchego -f
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.isBootstrapped","params":{"chain":"C"}}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info
# 4. NodeID, BLS public key and proof of possession, needed to stake
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.getNodeID"}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info如需完整归档，安装程序的 --archival 参数会关闭修剪。在我们于 2026 年 10 月 15 日下载的脚本中，将它与 --state-sync off 一起使用时，写入的两项设置之间缺少逗号，不是有效的 JSON。在该问题修复之前，请在安装后停止服务（sudo systemctl stop avalanchego），将 ~/.avalanchego/configs/chains/C/config.json 修改为与下方代码块一致，用 python3 -m json.tool 检查，然后重新启动服务：
{
"pruning-enabled": false,
"state-sync-enabled": false
}然后将 ~/.avalanchego/staking 中的 staker.crt、staker.key 和 signer.key 备份到服务器之外：丢失 staker.key 会让节点获得新的 NodeID，丢失 signer.key 则会导致 BLS 密钥与您已注册的验证节点不再匹配。请参照我们的上线首小时安全加固清单，用防火墙屏蔽除 SSH 和端口 9651 之外的所有流量，并通过 Core web、platform-cli 或 Builder Console 质押工具注册验证节点。
常见问题
质押 AVAX 需要自己运行节点吗？不需要。委托给现有验证节点只需 25 AVAX，期限至少两周，无需任何硬件；验证节点会从您的奖励中收取至少 2% 的费用。
可以在 VPS 或云实例上运行验证节点吗？只有配备本地 NVMe 时才可以：系统要求页面明确排除了 AWS EBS 或 GCP Persistent Disk 之类的云块存储。
AvalancheGo 能在 Windows 上运行吗？现在已经不能：2025 年 7 月 22 日发布的 v1.13.3 移除了对 Windows 的支持。
其他 EVM 链请参阅我们的以太坊节点硬件指南。当前库存和机房位置请见我们的区块链节点托管页面，每种配置都可以用 BTC、ETH、XMR、TRON 链上的 USDT 或 SOL 支付。
参考资料
- 系统要求 — Avalanche Builder Hub（修订于 2026 年 10 月）
- 链状态管理和定期状态同步 — Avalanche Builder Hub
- 简介和如何质押 — Avalanche Builder Hub
- Helicon 升级 — Avalanche Builder Hub；Helicon：改进的质押经济模型与持续执行 — Avalanche Builder Hub 博客（2026 年 9 月 8 日）
- C-Chain 配置和AvalancheGo 配置参数 — Avalanche Builder Hub
- 安装 AvalancheGo、节点配置与维护和准备环境 — Avalanche Builder Hub；avalanchego-installer.sh — ava-labs/builders-hub，GitHub（查阅于 2026 年 10 月 15 日）
- ACP-77：重塑 Subnet和ACP-256：硬件建议 — Avalanche Builder Hub
- Avalanche9000 背后的动机 — Avalanche Builder Hub 博客
- AvalancheGo README — ava-labs/avalanchego，GitHub
- AvalancheGo 版本发布 — Avalanche Builder Hub；v1.15.0、v1.15.1 和 v1.12.0（Etna） 的发行说明 — ava-labs/avalanchego，GitHub
- system-requirements.mdx 的历史记录以及提交 291f09e、972995c 和 48c5190 — ava-labs/builders-hub，GitHub
