原创主题配图: 链观 BTC866 原创主题图解 · ChainView BTC866 Editorial · CC BY 4.0
两种客户端分别验证什么
在以太坊权益证明架构中，执行客户端处理交易、执行智能合约并验证状态转换，共识客户端负责共识消息、链选择与最终性相关逻辑。验证者签名功能又有自己的密钥和运行要求，不能把所有进程统称为一个节点后忽略依赖。画出交易进入、执行结果、共识选择和对外查询的数据流，能够判断问题位于哪层。执行层看似持续运行，并不代表共识层已经同步；钱包能查询旧余额，也不说明节点提供的是最新规范链状态。
引擎接口与信任边界
两层通过引擎接口交换执行负载与链头信息，接口需要按官方文档配置认证和网络访问。认证令牌用于组件间身份验证，并不意味着接口适合公开到互联网；仍应限制监听地址、端口和访问来源。普通 JSON RPC、共识 API 与引擎 API 的用途和权限不同，反向代理也要分开处理。检查日志时保留错误码与请求时间，但不要将认证秘密放进公开工单；仅凭接口返回成功无法证明整个网络健康。
兼容矩阵与同步检查
升级前核对执行与共识客户端的兼容版本、网络参数、数据库迁移和已知问题，不能只更新其中一个包就宣称升级完成。监控执行高度、共识槽位、对等连接、最终性延迟与资源占用，并与独立来源比较。系统时间错误、磁盘不足或防火墙配置都可能造成表面像协议问题的异常。若运行验证者，还要检查职责执行与防重复签名措施；恢复备份时复制同一密钥到两台同时在线设备可能引入惩罚风险。
用分层证据定位故障
假设查询交易的 RPC 正常，但最终性长期不前，应分别检查共识同步、客户端连接和网络整体状态，而不是不断重发交易。记录两层版本、配置摘要、最近高度与时间，先保护日志和密钥，再按支持文档采取措施。不要把数据库降级或重建当成默认第一步，这些操作会延长恢复并可能丢失证据。维护记录应说明哪项检查恢复正常、哪项仍未知，让后来接手者能够复现判断，而不只看到已重启的结论。
