“帮我把沙巴币换成支柱币""钱包里的 USDC 能买到多少某币”——ERC-7845 规范开头开宗明义地列了这类对智能音箱或助手说话的例句。它想标准化的不是语音，而是这些愿望通向区块链之前那一跳：一个管理钱包的系统（网站、App、设备、服务端程序都算）向所谓的 Orchestrator（编排器）请求”解决方案”时，双方该说哪种格式的话。这份草案（Draft）给的是数据结构而不是能力承诺，正因如此，读它的字段比读它的宣传语更有用。
骨架：三层嵌套的请求对象
规范遵循以太坊 JSON-RPC 的顶层形状：一个请求对象带 id、jsonrpc、method、params，方法名默认是 orchestrator_findSolutions。params 里装一个或多个 Problem 对象：Problem 必填字段只有 actions（一个数组），可选的 chainId 不填时默认按 1 处理。往下是真正有意思的 Action 对象：from 必填，写这笔动作是为哪个钱包地址做的；towards 必填，是一个由 Asset 或 Destination 组成的数组，也就是动作的目标——某种资产或某个接收地址；with 可选，列出钱包愿意动用哪些资产来完成这件事，留空时规范明确要求编排器要考虑该地址空间里全部可用资产；type 可选，可填 transfer、swap、call 之类的分类词，不填则默认按 transfer 理解。还有 functionCallName 与 functionCallData 两个配套字段描述要调用的合约函数，deadline 用 Unix 时间戳给方案设一个有效期。
默认值与缺省语义才是重点
把字段过完，你会发现这份规范的性格全在缺省语义上：不给链号就当以太坊主网，不给资产来源就”钱包里全都能动”，不给类型就当转账。这些默认值对开发端是省事，对用户是一句话——一份合法格式的 Problem 完全可以在你没指定边界的情况下，被解出一个跨多条链、动用多个资产的执行方案。规范把这种取向命名为”链抽象优先”：只要资产跨链存在，编排器的方案默认就该跨链地搬运它们。
与意图类方案的关系
如果你读过 ERC-7521 通用意图：钱包不再照单执行，交给求解器拼交易 那类”钱包不照单执行、交给求解器拼交易”的意图设计，会把 ERC-7845 认出一半亲戚。区别在于位置：意图提案重构的是用户签名那一环，ERC-7845 只标准化请求与应答的报文形状，明确不规定编排器怎么求解、怎么收费、要不要上链担保。也因此它与任何执行层方案都不冲突：同一份 orchestrator_findSolutions 请求，背后可以接自动化做市路由，也可以接人工审批队列。
用户侧的四项核对
假设某天你的钱包接上了这类助手，规范文本本身给了四条可执行的核对习惯。第一，看 deadline：没有时间戳的方案等于无限期悬着，优先拒绝或自己填上限。第二，看 with 是否留空：留空意味着解算面是全量资产，大额钱包应当显式圈定出资范围。第三，看最终拼出的交易：链抽象方案往往拆成多步，签名前逐项确认涉及的链与合约地址，与 合约页先查出生纸：Contract Creator 与创建交易能说明什么 里逐项核对网络参数是同一纪律。第四，记一句判断口径——格式标准化不等于信任消解，编排器仍是那条链下服务通道，出事时责任归属看它的条款而不是这份 ERC。
一个填写示例的读法
把规范里的请求样例翻译成中文：顶层 method 填 orchestrator_findSolutions；params 放一个 Problem，里面 actions 数组有两项——第一项 type 为 swap，from 是你的地址，towards 指向目标资产，with 写明只允许动用某个链上代币；第二项 type 为 transfer，towards 换一个接收地址，deadline 填一小时后的时间戳。整个请求没有任何一处出现具体路由合约地址、桥地址或滑点参数——这些全部留给编排器去”解”。这就是它和传统交易签名弹窗的本质分工：你签的不再是”按这个字节执行”，而是”按这个目标去解”。信息量少了，出错的面反而需要靠 deadline 和 with 两处边界补回来，这也是上一节四条核对习惯的由来。
状态与实现
ERC-7845 目前为 Draft，接口定义也可能随讨论修改；文中引用的字段名与缺省规则均出自规范文本本身，实际产品实现范围以其文档为准。
风险提示：委托任何链下系统代为构造或执行交易都涉及资产风险，授权前请核对请求边界与最终交易内容，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。