rpc.discover 能问出节点支持哪些方法吗：EIP-1901 与服务自述

文档会过时，抓包会越界

排查 RPC 问题时，最常用的两个土办法是读客户端文档和拿真实请求去试。文档会过时——各家节点的接口面一直在变；试错有边界——向第三方服务持续发非常规请求，可能违反服务条款，也可能触发 RPC 请求返回 429 是什么？限流、退避重试与配额排查 里那种限流。EIP-1901 提供了一个体面得多的答案：让节点自己开口，一份机器可读的清单回答”我这里支持哪些调用、参数长什么样”。提案 2019 年 2 月提交，目前状态 Stagnant。

自述文件的格式与门牌号

提案选用的载体是 OpenRPC 规范：一门与编程语言无关的接口描述语言，专写 JSON-RPC 2.0 服务，地位相当于 REST 世界里的 OpenAPI。节点要支持它，只需提供一个方法，方法名固定为 rpc.discover，返回值是该接口的 OpenRPC 文档。为什么这个门牌号能占：JSON-RPC 2.0 规范把 rpc. 前缀留作系统扩展专用，各实现互不侵占。节点可以把文档静态挂在服务里，也可以按当前运行版本动态生成——后一种更可信，报的是此刻真实暴露的接口面。

一份清单能换掉多少手工活

拿到这份文档，围绕接口的体力活都能自动化：按描述生成多语言客户端与测试桩，搭出行为一致的模拟服务，接口变更后立刻对比差异，直接生成人类可读的文档页。提案作者当时举的例子是一台开了这个开关的多客户端聚合节点，工具连上之后自动生成交互文档和调用代码，人不必再翻版本说明。对普通用户，这套机制的感知大约等于”连上之后，工具能自己搞清楚该问哪些方法”。但必须说清现状：提案引用的实现只有 multi-geth 的可选开关一类实验产物，以太坊主流节点并未把它作为标配能力，接口面信息仍主要靠版本发布说明与各家文档传播，所以核对 RPC 信息时更稳的做法仍是 钱包 RPC 出错要换节点？先做链标识、高度与编号三项一致性核验 里那套链标识、高度与编号三项一致性核验——先核链，再问高度，最后比编号。

值不值得等待

判断很简单：文档描述的接口面若与节点实际支持不一致，自述就失去意义，因此动态生成加版本绑定才是可信形态；只有文档、没有实现的提案，等于把接口定义权从代码挪进另一份可能过时的文档。对普通用户，它不是今天能依赖的能力，但背后那个习惯值得抄一条：凡有程序接口可查的事实，就别只靠文档转述和网站申报——能直接向节点问 eth_chainId 与 net_version，就别只信页面上的链名，这也正是那三项核验的第一步。

落到今天的三次问法

服务自述的精神可以照搬，工具却没有，所以手工版要自己排好次序。第一次问静态问题：这个服务报的链号是多少——eth_chainId 一个请求就能问出，这是所有排查的地基。第二次问动态问题：你 sync 到哪了——eth_blockNumber 与浏览器对一下，差距过大说明接口滞后，这比”支不支持某个方法”更容易坑人。第三次才轮到方法面：手头的调用报 -32601，说明该节点没实现这个方法，换服务商或自建节点，而不是怀疑链出了故障。三步的顺序本身就是 rpc.discover 想自动化而没能落地的东西——先确认识哪条链、再确认站到哪个高度、最后才是问它会什么。顺序倒了，任何自动生成的接口清单也救不了一次错链操作。

本文为技术说明，不构成投资建议；接口信息请以节点实际回答与版本发布说明为准。