节点该配什么电脑：EIP-7870 的硬件与带宽推荐表怎么读

一句话定位

EIP-7870 创建于 2025 年 1 月 26 日，状态是 Living——它不是一次性的规范，而是一份随网络演进持续修订的推荐清单：跑什么样的机器才能代表网络的主流性能水平。它把节点分成全节点、只做投票的验证者、本地构建区块的出块者三档，分别给出存储、内存、CPU 核心数与跑分、上下行带宽的具体数字。注意它说清楚了一点：低于推荐值也可能跑得动客户端，但所有基准测试与协议决策都以推荐机器为准。

表格三档怎么读

按提案文本里的表格：全节点、投票验证者与本地出块者都用 4TB NVMe 存储、顺序读写约每秒 500MB、4K 随机读约 5 万 IOPS 的盘；差异在别处。全节点推荐 32GB 内存、4 核 8 线程、PassMark 单线程约 1000 多线程约 3000，带宽下行 50Mbps 上行 15Mbps。投票验证者把内存翻倍到 64GB、CPU 提到 8 核 16 线程、单线程跑分约 3500，上行提到 25Mbps。本地出块者与验证者同配，但带宽进一步到下行 100Mbps、上行 50Mbps。三张单子假设执行层与共识层客户端同机运行，数字是两者合并后的用量。

为什么用跑分而不是型号

提案刻意用 PassMark 单线程与多线程分数作门槛，而不是列具体 CPU 型号。理由直接：硬件市场半年换一代，型号清单半年就发霉；跑分让推荐跨过具体产品周期，也让不同机房的人能在同一把尺上自测。提案还附了用 fio 命令实测磁盘顺序读写与 4K 随机读写的方法——存储列它不只给容量，还给了 IOPS 下限，因为节点性能瓶颈往往先出现在随机小 IO，而不是盘装不装得下。

三档差距的技术根源

为什么出块者带宽几乎翻倍？提案的回答：出块者在槽位里制造区块后要立刻把数据广播出去，让投票者在期限内验证，时间压力全压在它的上传通道上。为什么验证者 CPU 要求高过全节点？投票者要在严格时限内验证区块、算证明、参与各类委员会职责，单线程性能决定它能不能按时交票。全节点只跟链尖同步，容忍度最高，因此是三档里最省的。

低于推荐值会发生什么

提案承认低配可能跑通，但后果以责任转移的形式出现：低配验证者的延迟可能表现为错过部分职责带来的收益损失，低配出块者可能构建超时让槽位空转。更隐蔽的一层在治理侧——如果基准测试在不同机器上跑，数字就失去可比性，客户端团队的优化决策、协议对资源消耗的评估都会失真。这份 Living 文档的真正功能是给整个生态一张统一的性能背景布：先统一标尺，再谈快慢。

一笔带宽账

按表格最高档算：本地出块者的上传按 50Mbps 折算约每秒六兆字节出头，一个约两百千字节量级的完整区块要在亚秒内推给相邻节点，再叠加证明与聚合签名的小包往返，上传通道的余量直接决定传播延迟的尾巴。下载侧 100Mbps 看似宽裕，但区块同步期与拥堵期的突发流量都吃这个池子。推荐值不是压线跑出来的，而是留出突发余量的目标值——这也是提案用 Mbps 而不是字节数表述的原因：给运营者换算真实线路规格时留出冗余心智。