ERC-7654 请求方法类型：把 GET、POST、PUT 搬进合约接口

对接一个链上合约，常规路径是拿到 ABI 或读源码；如果两者都没有，只剩一堆含义不明的函数选择器。ERC-7654（Request Method Types）借来了 Web 世界的表达习惯：合约把自己支持的操作按 GET、POST、PUT、OPTIONS 四类标注，并留出四个查询函数，让任何调用者在真正发起交易之前，先把“这里有什么、叫什么、怎么调、返回什么”问清楚。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2024 年 3 月 13 日。

四种方法类型与六步发现流程

标准定义的枚举只有四项：GET 请求合约读取记录，POST 创建新记录，PUT 更新既有记录，OPTIONS 查询支持哪些方法类型。发现流程被写成六步：先调用 options 拿到该合约支持的方法类型集合；再用 getMethods 按类型取方法名清单；用 getMethodInstruction 读某个方法的说明文本；用 getMethodReqAndRes 拿到请求参数与响应的数据类型；然后才编码参数、实际调用 get、post 或 put；最后按声明的类型解码响应。注意写操作的返回路径：post 与 put 的结果通过 Response 事件携带字节负载发出，而不是当作函数返回值——这是链上环境与 HTTP 语义最大的分歧点。

自描述能力的边界，别把比喻当真

标准在安全部分给了一个分类纪律：GET 与 OPTIONS 是安全方法，只读、不改变合约状态，可以放心走静态查询或模拟调用，不花 gas；POST 与 PUT 是不安全方法，可能改变记录状态，真发交易前应先在模拟环境确认参数编码不会触发意外的写入分支。这套分法与 EVM 的只读调用习惯天然对齐：先用 OPTIONS 和 GET 把接口全貌摸清，再决定哪笔 POST 值得上链。索引器侧的规矩同样清晰：写操作的真相在 Response 事件负载里，只盯返回值会漏掉整条结果链，日志解析要按 getMethodReqAndRes 声明的数据类型把字节还原成结构化记录。

对做数据面板与监控的读者，这套接口还藏着一个工程红利：支持它的合约可以被通用爬虫自动盘点——OPTIONS 探边界、GET 拉数据、按声明的类型解码，接入一个新源不再需要人工写适配层。当然它无法消除对实现方的信任：记录内容本身由写入者决定，接口只保证取到的字节与合约声明的类型一致。判断某个登记结构值不值得依赖，问题清单很短：谁有权 POST 与 PUT、POST 是否需要审批流、PUT 的覆盖历史是否另留事件痕迹。接口统一了读法，治理决定了读到的内容值不值得信。

另外注意命名带来的小歧义：这里的 GET 与 POST 只是标签，背后仍是 EVM 的函数调用，没有任何 HTTP 栈或网络请求参与，别指望能用浏览器直接访问，也没有头信息与状态码；它借的只是方法语义这一层皮，其余一切以链上规则为准。

对不熟悉链上开发的读者，它的类比价值也值得一提：过去理解一个陌生合约要先学会读 ABI，现在可以先像浏览接口文档一样问一圈，读合约的门槛从字节码降到了文本。

这套接口的价值在可读与可发现：一个没有官方文档的合约，也能被第三方工具枚举出记录与调用方式，对元数据登记处、投票与工单类合约尤为实用。但三点边界必须写清楚。其一，自述内容不是可信凭据，合约可以声称自己是任何说明文本，说明与实际字节码行为的一致性没有任何强制，安全判断仍要回到源码或反编译。其二，链上调用是交易不是请求：post 与 put 会产生 gas 消耗、需要外部触发才会执行，PUT 也没有 HTTP 意义上的幂等保证，重试语义要自己设计。其三，写操作的结果落在事件日志里，意味着调用者必须扫描日志才能知道执行结果，索引器漏采就等于“没返回”。把它当作一份链上的自述说明书来读——降低理解成本，但不替代审计。标准仍是草案，字段以仓库当前文本为准。本文为机制说明，不构成任何投资建议。