验证者、客户端、证明者：Aleo 为什么把节点拆成三种岗位

同一份代码，三种岗位

多数公链的节点是一个全能工种：收交易、执行、出块、对外提供数据，都由同一台机器包办。Aleo 把岗位拆开：官方 snarkOS 仓库的 README 写明，网络中存在验证者、客户端、证明者三类节点，全部由同一个二进制程序启动，用命令行参数决定岗位。拆开的好处是每台机器只优化一件事，代价是每条链上的信任边界要按角色重新讲一遍。

验证者：只管共识，不负责对外服务

验证者参与 AleoBFT 共识，接收到的每个区块都要验证并执行，新区块也由它们协商生产。启动验证者需要把账户绑定进委员会（bonded into the committee），未入组的机器没有入场资格。节点之间除了普通 P2P 端口，还有一条专门的 BFT 端口用于共识通信，防火墙只放行给受信任的验证者地址。官方 README 同时提醒：验证者上 REST 服务应当保持关闭。这三个细节拼出同一个姿态——验证者尽量不对公网暴露，公共请求交给客户端去挡。

客户端：全节点，但不投票

客户端同样是全节点：验证并执行收到的区块、维持完整账本副本，却不参与共识。它承担对外服务：回答查询、中继未确认交易、转发证明方案。官方文档把客户端分成两种位置——核心客户端直接连验证者，不开 REST，替验证者预过滤流量；外层客户端只连其他客户端或证明者，开放 REST 服务，是开发者和应用看到的公共入口。由此形成分层拓扑：公网流量先到外层客户端，再到核心客户端，最后才可能触达验证者。读 Aleo 的网络图时，这条过滤链是理解它抗攻击设计的关键：验证者的安全性不靠裸露在公网的韧性，而靠流量在到达之前被逐层验过。

证明者：不记账，专职解题

证明者是轻装角色：不维持账本、不参与共识，专门解网络出的谜题换取区块奖励。官方 FAQ 的说法是：证明者用专用硬件为目标出解、按提交占比分得 coinbase 奖励的一部分；README 进一步解释，当前 snarkOS 的谜题并不利用 CUDA 加速——那是早期遗留的部分，是否重新启用要随 ARC-43 等提案落地再看。与交易相关的密码学部分则完全在用户侧：交易自带 snarkVM 生成的程序证明，验证者验证明、而不是替每笔交易重新执行计算。用户本地出证明最保护隐私但受个人硬件限制；交给第三方出证明更快，代价是要向对方交出部分输入数据。对隐私链来说，把谁来算答案摆成用户自己的选择题，而不是协议暗礁，是很典型的取舍外露。

费用与风险怎么落在这套分工上

谜题奖励与证明目标挂钩，个体回报按个人解的证明目标占提交总量的比例计算，而非赢家通吃，因此证明侧的投入近似一场持续的设备竞赛。角色拆分也反映在端口与服务的开放面上：共识端口只对受信任的验证者地址放行，指标端口留在内部网络，公网可见的入口集中在外层客户端——排查 Aleo 节点连通性问题时，这份端口与角色的对应表比笼统的重启更有用。信任边界则要按角色分开评估：共识安全看验证者委员会，数据与查询可用性看客户端层，出块公平与奖励分配看证明机制的参数。读任何一条链的架构说明前，先看清它的节点是不是分岗——分工越细，单点故障越局部，但需要信任的环节数量也在增加。

风险提示：本文为机制说明，不构成投资建议；节点角色、奖励参数与谜题设计会随协议与提案更新，运行或接入前请以 Aleo 官方文档与 snarkOS 仓库说明为准。