运行一个以太坊全节点，通常要同时启动执行客户端和共识客户端两套软件。合并之后，网络把“交易如何执行”和“链如何达成共识”拆成两个必须协作、职责不同的层。执行客户端负责交易验证、EVM 执行、状态管理与交易池，并通过 JSON-RPC 对外提供查询和交易提交入口；共识客户端负责接收区块与证明、运行分叉选择、跟踪链头和最终性。两者通过本地 Engine API 连接：共识客户端把交易集合交给执行客户端执行，执行客户端返回执行结果，共识客户端据此推进链。验证者软件是可选附加组件，负责提议区块和作证，需要质押才能激活；只跑全节点、不质押，同样可以同步链、验证交易、提供 RPC。
从基础设施公司的分工看，两种客户端对应两类能力，也对应不同的运营边界。执行侧更接近“计算与状态服务”：维护状态树、执行交易、承接 RPC 请求，资源消耗偏向 CPU、内存和磁盘 I/O。共识侧更接近“链头与共识服务”：持续处理区块和证明、判断应跟随的链，网络与时钟敏感性更强。把两者分开，既让不同团队可以独立实现和优化，也让运营者可以按需替换其中一层，而不是被单一软件栈锁死。
下面的对照表把常见混淆点拆开，便于判断一项工作属于哪一侧：
| 工作内容 | 执行客户端 | 共识客户端 | 验证者软件 |
|---|---|---|---|
| 交易 gossip、交易池管理 | 负责 | 不负责 | 不负责 |
| EVM 执行、状态与收据树 | 负责 | 不负责 | 不负责 |
| 区块与证明 gossip、分叉选择 | 不负责 | 负责 | 不负责 |
| 提议区块、作证 | 不负责 | 不负责 | 负责 |
| 对外 JSON-RPC 查询与提交交易 | 提供 | 不直接提供 | 不提供 |
| 是否需要质押 | 不需要 | 不需要 | 需要 |
这张表解释了一个常见误解：有人把“共识客户端”当成“验证者”。其实共识客户端不质押也能运行，它只负责跟随链头；验证者才是质押并承担提议、证明职责的附加组件。反过来，执行客户端也不是“整条网络”，它只是本节点执行与状态这一侧的实现。两类客户端各有自己的接口职责：执行侧对外提供 JSON-RPC，共识侧管理共识状态并驱动执行侧，两者不能互相替代。
产业评估时，建议把三类角色分开看，不要混成一个“客户端市场”：
- 开源实现：执行侧和共识侧都有多个独立实现，选型要看维护活跃度、版本兼容、运维复杂度和故障恢复能力。多实现并存的价值在于降低单一软件缺陷影响整条链的风险，但不等于任意两个实现可以随意混搭而不做联调。
- 托管节点：基础设施公司替客户运行全节点，客户买到的是可用性和运维责任，不是某一家客户端产品的“所有权”。托管方仍需同时维护执行与共识两层，并处理升级窗口。
- RPC 服务：面向应用提供查询和交易提交入口。RPC 运营商可以在后端跑全节点，也可以做缓存、限流和负载均衡；一个 RPC 端点背后可能是多台节点，不能把某个 RPC 品牌等同于“以太坊网络本身”，也不能把某一家客户端产品说成全部 RPC 运营商。
用一个独立的教学例子说明分工判断。假设一家公司要为内部应用提供链上数据查询，同时偶尔代客户广播交易。只读查询和交易提交对后端的要求不同：查询可以靠缓存和分流降低对单节点的压力，交易提交则必须落到执行客户端验证并进入交易池。合理的做法是把只读流量与写入流量分到不同后端池，每个池都具备执行与共识两层，并分别监控执行侧的 RPC 可用性与共识侧的链头跟随情况。这个例子不涉及具体吞吐数字，也不预测任何公司收益或市占，只说明“两种客户端”在运营上对应“执行容量”和“共识跟随”两类指标。
判定一个节点方案是否完整，可以按四步检查：第一，执行客户端和共识客户端是否都在运行并完成握手；第二，执行侧 RPC 是否可用，共识侧是否持续跟踪链头和最终性；第三，是否明确区分“全节点”和“验证者”，没有把质押要求强加给普通节点；第四，若使用托管或 RPC 服务，是否说清对方负责哪一层、升级由谁执行。按这四步看，两种客户端不是重复建设，而是把执行与共识的责任边界摆到台面上，让基础设施公司能分别评估计算、网络、运维和接口能力。