执行层与共识层的接口边界是什么？以太坊与 Cosmos 两种拆法的对照

一条链为什么拆成两个进程

读以太坊节点文档时，你会反复看到两种接口词：面向钱包的 JSON-RPC，和面向”另一个自己”的 Engine API。它们背后是同一个架构事实：合并之后，一个以太坊客户端是两台机器的合影——共识层负责”哪些块构成规范链、谁在什么时候有权提案”，执行层负责”每笔交易改了什么状态、这个状态转换对不对”。两者通过一套私有协议对话：共识层告诉执行层该在哪个父块上构建，执行层交回算好的候选区块；网上飘来新区块时，共识层把它转交执行层验一遍，验得过才继续。

接口边界上发生了什么

把边界两侧的对话拆开看，最常见的三类消息各有归属。第一类是构建请求：共识层临近自己的出块时隙时，向执行层发起”在某个父块、某个状态承诺之上，按这个参数造一个块”，随后取回结果。第二类是验证请求：收到候选区块，共识层连同父信标块根交给执行层重放，拿回有效、无效或还在同步三种答复。第三类是链头通知：分叉选择的结果变了，执行层要把状态切到新的规范链上。三类消息合起来回答了一个老问题——出块的权力在质押者手里，而块的规则由执行层逐笔把关，任何一方都不能单方面替另一方做决定。

这个边界在 Solana 世界有一个对照物：ABCI。Cosmos 系的 CometBFT 文档把 ABCI 定义为”复制引擎（区块链）与状态机（应用）之间的接口”，让一个进程里的共识引擎通过套接字管理另一个进程里的应用状态。以太坊的分层是合并的产物，Cosmos 的分层是从小写的架构基因；但两家想要的是同一件事——共识软件与应用软件各自演进、各自审计，谁换实现都不需要重写对方。

这种分层买到了什么

第一是客户端多样性有了组织学基础：共识层和执行层各自有多个独立实现，任何一半出现问题，另一半还能继续运行，网络整体不至于同生共死；一个实现被攻破时，爆炸半径也被接口天然截断一段。第二是角色解耦成为可能：区块构建市场（builder 造块、提议者选块）恰好长在”构建请求”这条消息上，没有这条清晰的边界，MEV 拍卖这类市场结构就无处安放。第三是升级解耦：执行层加新预编译、新指令，多数时候不需要共识层改规则。

代价与故障时的样子

边界不是免费的。首先，多一跳就有延迟：候选区块要序列化、跨进程搬运、再反序列化，节点本地的每一毫秒都会被放大到全网时间预算里。其次，状态一致性问题变复杂：执行层在链头切换时要回滚、重组，日志里那些 reorg 记录正是这条边界的日常摩擦声。再次，运维面翻倍：你要同时盯两个进程的健康、两个数据库的一致性，还有它们之间那条带 JWT 认证的本地通道——接口文档明确说明认证不加密流量、不防窃听与重放，所以这条通道应当只留在本地或私有网络里。

故障排查时这套分层反而帮了大忙：区块没出，先看是共识层没按时发构建请求，还是执行层构建超时；节点卡住不跟随链头，先看执行层是返回了 INVALID 还是 SYNCING——前者说明规则分歧要查版本，后者只是还没追到位。用户层面不需要直接和这条边界打交道，但理解它，就理解了为什么”跑节点”是一个双进程的工程。

值得补充的是两种拆法在”可替换性”上的差异。以太坊的两半在接口处各自有独立实现可以选择，共识层换一家、执行层换一家互不牵动；Cosmos 用 ABCI 把分界做得更一般化——同一个 CometBFT 可以换底座，也可以换成其他共识引擎（学界与工程界的 Tendermint 替代方案多以此为前提），应用侧的 ABCI 方法基本不变。代价是抽象接口的表达力受限：凡是状态机想告诉共识层的信息，都得先翻译成接口里已有的字段。分层越通用，越考验这套翻译是否够用。本文只描述公开文档可见的架构设计，不构成任何投资建议。