钱包发送交易到执行客户端（EL）的 RPC，不表示共识客户端（CL）已经选它所在的链头。EL 负责 EVM 执行、状态和交易入口；CL 负责共识网络、头选择与最终性判断；验证者客户端持有签名职责并参加提议/投票。两端通过 Engine API 协作：共识端请求构建执行载荷，并让执行端验证收到的载荷，不能只启动其中一个进程就称作完整的 PoS 节点。

先修区块链（16）：Gasper 中链头与终局是两次不同判断。在私网里还须冻结执行与共识客户端的兼容版本、chain ID、genesis、fork 时间表、认证材料、验证者存款与网络连接；否则“节点同步”可能只是一端准备就绪，甚至连接了另一条链。Engine API 的认证材料是本地进程凭据，不可纳入博客素材。

sequenceDiagram
  participant U as 钱包/应用
  participant EL as 执行客户端
  participant CL as 共识客户端
  participant V as 验证者
  U->>EL: 提交签名交易
  CL->>EL: Engine API: 请求构建/验证载荷
  EL-->>CL: 执行结果与载荷状态
  CL->>V: 提议/投票职责
  V-->>CL: 签名消息
  CL-->>U: 头选择与终局需分层查询

若 EL 停机，CL 不能把未验证执行结果直接当有效载荷；若 CL 停机，EL 的 eth_call 成功也没有产生最终性。交易回执表示按对应区块执行过，记录 status、blockHash、高度与输入条件；它既不证明区块已 finalized，也不证明线下订单交付。Anvil 可做本地 EVM、合约和 RPC 测试，但不是搭配真实共识客户端的私网终局验收。

四种“服务在线”不代表同一进度

钱包通过 EL 的公共 RPC 投递交易，但 EL 立即返回标识只说明本次提交处理，不表示共识端已经选中相应载荷。验证者准备提议时，CL 通过受认证的 Engine API 与 EL 交互以构建执行载荷；接收到其他提议时，EL 还要在相同 fork 规则下验证执行。CL 报 head 更新说明选链进度，返回 finalized 检查点说明另一层终局状态。应用必须核实自己的回执所在块能关联到该检查点下的规范历史；光保存 status=1 不能穿过这条关联链。

假设 EL 已同步到最新区块，但 CL 卡在旧检查点：应用可能取得一个交易回执，却无法据此按“最终确认”交付。若 EL 正在重放状态或 Engine API 认证不通，CL 即使仍有 P2P 连接，也不能把未经 EL 验证的执行状态说成已合法。验证者客户端签名又是独立密钥权限；控制者不该因为查询订单而把它复制到公开 RPC 服务器。验收私网必须保存配对客户端版本、genesis/fork 配置、每笔订单回执、EL 载荷验证状态、CL 选链和最终性观测；钱包的 HTTP 状态、Anvil 的本地块或同一台机器运行两种进程的截图都不足以代替它们。

练习一：有交易哈希、receipt.status=1 而共识端无法返回可信 finalized 检查点，后台该标什么？答案：执行已观察、最终性未证实；不能写最终结算。练习二：只关掉 EL 时验证者客户端仍在签名，能说明执行载荷已合法？答案：不能，必须关联 EL 的载荷验证、CL 的投票与网络 fork 条件。真实执行/共识/验证者私网及故障恢复 NOT_RUN。

可迁移原则：两个进程组成的协议须保存跨边界的状态关联与失败定位。参考：Ethereum 节点与客户端、Engine API 规范（release、SHA、实际方法语义待核）；导航：区块链（16）：Gasper 中链头与终局是两次不同判断 · 17 · 区块链（18）：EVM 执行后哪些状态进入状态根。