你在一款链游或交易类应用里点”铸造”，签名弹窗的说明却让你把同一笔操作发去一个陌生网址完成——这种”链上合约、链下执行”的结构，正是 ERC-7884 试图标准化的场景：合约用一份标准接口告诉你，某个写操作该在哪条链、哪个合约、或者哪个链下网关上办。本文按机制、流程、风险三层拆开它。提案在标准仓库中标注为草案（Draft）。
一个只读函数，两种”报错即答案”
按规范，合约实现一个名为 getOperationHandler 的视图函数，你把准备执行的、已经 ABI 编码好的函数调用（即原始 calldata，读法见交易的 Input Data 怎么读？方法选择器与参数解码）作为参数喂给它，它不落任何状态，只通过两种自定义错误回话：一是 OperationHandledOnchain，带链号和合约地址两个参数，意思是”这个操作请在该链该合约上重做”；二是 OperationHandledOffchain，带三样东西——一个 EIP-712 域定义（合约名称、版本、链号、验证合约地址四件套）、一个网关 URL，以及一条消息数据。消息数据里装的是你原始的编码调用、发起操作的账户地址、还有一个到期时间戳。第三种报错 FunctionNotSupported 则表示”这个函数不归我路由”。用报错传答案是刻意的：视图调用拿到 revert 数据既便宜又标准化，客户端解析成本最低。
链下流程借了两条老规矩
网关通信没有发明新协议：HTTP 请求按 EIP-3668 的风格拼成 /{sender}/{data}.json 形态的 URL，让一个 API 看起来像合约调用一样工作；身份认证则用 EIP-712 签名——你用钱包对那份域定义加消息数据签一次名，向网关证明”这个账户确实授权了这次链下变更”。到期时间戳就是这条签名的寿命：过期后网关应当拒收。对用户的直接含义是：你在链下办的那笔”写操作”既没有上链的公开可查性，也不再由链的共识保护，它的可靠性完全取决于网关运营方。消息数据里的到期时间决定了”这枚签名作废前被人抢跑”的窗口长度，时间给得越长，中间人复用风险越大。
规范自己点名的坑：multicall 不能一把路由
规范明确提醒：getOperationHandler 靠传入的单个编码函数判断去向，所以一笔把多件事发往不同合约的 multicall 没法一次路由——必须先对每段调用分别问一遍路由，拿到答案后再按目标逐笔执行。这条限制对用户很实用：如果某个聚合操作页面”顺手”把跨网关的多步合成一次签名，说明它根本没走标准路由，各步去向您得自己逐项确认。
用户视角的信任账本
回到最初那个场景，标准给了你三个可问的问题。问一：这笔操作被路由到哪？链号与地址来自合约自己的回答，可在浏览器验证目标合约的创建者与源码验证状态。问二：网关域名与 EIP-712 域里的合约名是否对得上？弹窗里的域名核对纪律与搜索引擎广告位里的假官网：从点击到钱包弹窗的完整链条的假官网识别一脉相承。问三：到期时间多长？能给短就给短。链下执行意味着纠纷取证要靠网关日志而非链上收据，事后维权难度天然高一档——这是便利的定价，不是缺陷。
它适不适合被普及
从设计看，这套接口最适合”状态主体在链下、证明锚在链上”的产品：链游库存、撮合引擎、企业账务链。对纯链上协议，路由到另一条链的提示则省掉了用户手动换链的出错空间。作为用户，你不需要跟踪该提案的进展，但当弹窗出现”请到某网站完成这笔操作”字样时，你已经知道它背后的协议长什么样、该问哪三个问题。
风险提示：链下执行的写操作不受目标链共识保护，网关随时可能变更或停服；任何涉及资产的签名先核域名、域信息与到期时间，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。