节点内部最忙碌的一条线
跑一个完整以太坊节点，实际上是两个程序在协作：共识层客户端负责信标链、证明和分叉选择，执行层客户端负责交易与状态。它们之间靠 Engine API 通话——每 12 秒一个槽，共识层要不断把新区块头交给执行层执行、告诉它当前最优选中哪个分叉。这条通话路径在出块的临界路径上，多花一百毫秒都是全网能感知的延迟。今天这条线用的是 JSON-RPC：二进制数据先转成十六进制字符串，包成 JSON，对面再拆开。EIP-8178（2026年3月起草，本文撰写时为 Draft 状态）提议把这条管道整个换掉。
旧管道贵在哪
提案列了三笔账。第一，哈希、地址、交易、blob 这些原生二进制数据在 JSON 里都要做十六进制编码，体积直接翻倍；第二，双方在每次调用时都要做 JSON 的序列化和解析，这是白烧的 CPU；第三，共识层内部本来就用 SSZ 编码一切，过一道 Engine API 却要先转 JSON、对面再转回内部类型，一次往返转换纯属浪费。换成原始 SSZ 传输后，共识层把 SSZ 字节直接递过去，执行层直接反序列化，负载体积约为 JSON-RPC 的一半。
新管道的样子
传输形式是面向资源的 REST 加原始 SSZ：所有端点挂在 Engine API 现有端口（默认 8551）的 /engine 前缀下，比如 POST /engine/v5/payloads 对应旧的 engine_newPayloadV5。请求体的 Content-Type 是 application/octet-stream，装的就是该端点请求容器的 SSZ 序列化结果；出错时回 text/plain 的人类可读消息，而不是 JSON 错误对象。端点按资源分组——payloads、forkchoice、blobs 各成一路——路径里带版本号，沿 Beacon API 的惯例。认证完全沿用现状：每个请求必须带 JWT 的 Authorization 头。
为什么是 REST 而不是裸 TCP
提案的 Rationale 专门回答了这个选择：REST over HTTP 复用了成熟的服务器、代理与负载均衡设施，和 Beacon API 的运维经验直接对齐；同端口而不是另开端口，是为了让现有 JWT 与防火墙配置原样生效。值得注意的是提案明确这不需要硬分叉——Engine API 是客户端之间的内部接口，不属于共识规则，换传输不改区块有效性判定。
快速问答
问：这是不是意味着以太坊要抛弃 JSON-RPC？ 答：不是。这里只涉及共识层与执行层之间的内部通话；钱包和用户仍在用的 JSON-RPC 服务接口不受本提案影响。
问：对普通用户有什么可感知的变化？ 答：间接好处是出块与验证路径更省 CPU、更省带宽，前提是客户端实现跟进。
一条直觉账
把一笔含 blob 引用与完整区块体的提交想象成几十万字节的对象：十六进制编码把它撑大一倍，JSON 再套一层引号与字段名的壳，两端各解析一次。EIP-8178 做的事本质上是一句话——内部通话别再讲给人听，讲给机器听。
一次调用的两种写法
用一次新块执行做对照，最能看出体积差。JSON-RPC 时代，共识层要发出类似这样的请求：方法名 engine_newPayloadV5，参数里塞一个十六进制长串表示序列化后的执行区块，外面再套大括号与转义。到了 EIP-8178 的写法里，方法名变成 URL 路径，参数变成请求体本身——一段 SSZ 容器，字段按固定顺序紧凑排布，没有引号、没有逗号、也没有 0x 前缀。同一份数据的体积大约砍半，而两侧各省掉一次编解码。共识层尤其占便宜：它内部本来就存 SSZ，旧管道要它先把 SSZ 拆成 JSON 再让对面拼回去，现在直接把内存里的那段字节写进 socket 即可。
版本与兼容怎么管
Engine API 的痛点之一是每次升级都要给所有数据结构补 JSON schema 与测试向量，历史 fork 的方法还得一直留着。这个提案把版本信息放进端点路径，并为每个 fork 都给出对应的 SSZ 容器定义，靠类型定义本身描述兼容性；出错就回纯文本，由调用方的日志与运维体系消化。它同时明确：共识层仍可保留 JSON 端点做过渡，两套并存不冲突——迁移节奏由客户端发布周期决定，而不是被硬分叉日期绑死。
风险提示：本文为协议提案的科普介绍，EIP-8178 截至撰写时未成为任何客户端的默认行为，细节以提案原文为准；不构成投资建议或部署建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。