不用 JSON-RPC 查节点数据：EIP-1767 的 GraphQL 接口为什么没普及

JSON-RPC 的两个先天毛病

2019 年 2 月 14 日，以太坊基金会工程主管 Nick Johnson 等人提交了 EIP-1767：为以太坊节点定义一套 GraphQL 接口，目标是”完整替换只读 JSON-RPC”。动因来自日常运维里两类积怨。第一类是字段规格模糊：空字节串在 RPC 里到底是空串还是 0x，各家实现各有各的写法，工具链反复踩坑。第二类更实际：RPC 是方法制的，调用 eth_getBlock 就要整块返回，节点不知道你是不是只需要高度，于是把单独存在磁盘上的字段（比如总难度）也一并捞出来多读一次盘。收据场景更夸张：主流客户端把整个区块的收据存成一整块二进制，逐笔取收据导致取完一个区块的全部收据要付出平方级的重复解压成本。

提案的规格长什么样

1767 要求兼容节点在 HTTP 上提供 GraphQL 端点，建议默认端口 8547，路径 /graphql，根路径还可以放一个 GraphiQL 交互查询页——对，提案连调试界面都替你预想好了。schema 定义了 Bytes32、Address、BigInt 等标量类型，查询入口直接映射到区块、交易、账户与过滤器，你可以写一条查询只取某个区块的交易哈希列表，节点按字段取数，不再猜你要什么。文档处理上把重组也建模进类型系统：一个区块可以沿父块指针回溯，孤块与规范链的区分在查询里是显式的，配合按哈希取数，天然覆盖了按高度查历史容易踩的歧义问题——这个思路你更熟悉的近亲是查历史状态为什么建议用区块哈希而不只是区块高度：EIP-1898 的参数写法里按区块哈希钉死历史坐标的那套参数写法。

为什么停在 Stagnant

这份提案的正式状态至今是 Stagnant（停滞），原因不需要猜，接口演进史本身就是答案。GraphQL 路线要求每个节点都内置 schema 引擎与解析器，RPC 路线则是生态默认：钱包、浏览器插件、脚本库、云服务商的默认入口都是 JSON-RPC 的 eth_ 系列方法，rpc.discover 能问出节点支持哪些方法吗：EIP-1901 与服务自述讨论的服务自述方法也生长在这套体系上。更关键的是，1767 想要的字段级精确取数，后来被另一条更便宜的路实现了——带访问列表的调用与类型化交易让客户端能声明将触碰的数据，收据的平方级问题靠批量收据接口等新方法消解，重组歧义则被按哈希查询参数解决。痛点被逐个分头解决后，整体替换的动力就消失了。

什么样的用户会接触到它

今天的现实边界很窄：主流客户端中只有个别实现过这个端点，且默认关闭；公共 RPC 服务基本不开放 8547。如果你部署节点是给自家索引器或数据分析用，走官方 RPC 加批量方法仍是第一选择。真正值得把这份提案放进知识库的用途，是理解接口选型逻辑：当所有人都从同一个入口取数时，任何”顺手要整块数据”的粗接口都会在全网规模上放大成磁盘与带宽的浪费——这正是很多链上工具明明查同一个东西、账单却差好几倍的原因之一。遇到公共 RPC 返回 429 限流时（参见RPC 请求返回 429 是什么？限流、退避重试与配额排查），同样的道理反过来成立：把轮询里的全量查询改成只取所需字段的增量对账，往往比升级套餐更快见效。

读提案时的三个提醒

第一，Stagnant 不等于失败清单上的名字，它只说明近两年无人推进，未来可复活。第二，不要把”schema 里能查孤块”读成”节点一定能查孤块”——历史状态保留策略决定了答案，多数节点只保留最近窗口，更老的数据要归档节点。第三，端口 8547 是建议值而非强制值，部署方可以改；在防火墙上照抄这份提案开端口之前，先查你所在节点软件的实际默认值，别把一个从未成为主流标准的数字当成以太坊节点的安全审查依据。风险提示：本文讨论节点接口与提案历史，不构成投资建议。