刷到一个页面写着 web3 开头的一串地址，点下去弹出来的不是网页，而是一个钱包确认框——这就是 ERC-4804 描述的场面。这份提案已经定稿（状态：Final），它规定的是一件很具体的事：一条以 web3:// 开头的网址，在支持它的客户端里会被翻译成一笔对以太坊合约的调用消息，而不是去请求一个 HTTP 服务器。本文把它拆到语法层面，并说清它与 NFT 收藏者的交集在哪里。
先看网址本身长什么样。ERC-4804 规定 web3 协议头后面依次是合约地址、函数名与参数，可选地在问号后面带一组链参数，比如标明这条链接只适用于哪一条链，用的是 EIP-155 定义的那种链编号写法。合约函数的标准写法带圆括号和类型标注，比如 transfer(address,uint256)；在链接里可以原样保留这套函数式写法，也可以走省略圆括号的简化路径形式，参数的呈现习惯则与 ERC-681 支付链接对齐。规范同时为未知字段定义了类型推断规则，客户端解析模式也因此被归到自动模式那一族。整条链接没有域名、没有端口，也没有传统意义上的查询串，因为它根本不是给网络浏览器发请求用的，而是给钱包或 dapp 浏览器做本地解析用的。
规范为这个机制划定的落地范围非常克制，第一期只覆盖 ERC-20 代币合约上最常用的三个函数。按函数式写法，三个例子分别是以 transfer(address,uint256) 结尾的转账请求、以 approve(address,uint256) 结尾的授权请求、以 transferFrom(address,address,uint256) 结尾的代扣请求，参数按函数签名的顺序依次排在地址与括号里。参数顺序就是函数签名里的参数顺序，这一点在规范文本里反复强调，因为它是歧义最少的约定方式。
为什么 NFT 用户也要关心一份只管 ERC-20 的标准？三个接触点。第一，NFT 的购买、铸造与白名单费用经常用 ERC-20 结算，一条设计良好的 web3 链接可以把付款参数固定下来，省掉手动填地址的手续，也少一次手滑转错的机会。第二，ERC-4804 明确它与 ERC-681 支付链接共享地址与参数的呈现习惯——后者是那条 ethereum: 开头、扫码付款常见的老标准，两者一个面向浏览器链接、一个面向钱包支付串，但字段语义尽量对齐。仓库里甚至有人专门写过文章解释那份被放弃的 ERC-67 怎么让位给 ERC-681，可见这条网址翻译路线的谱系有多长。第三，后续的扩展提案沿着它继续走，有人用它包装大文件、压缩包和解压显示，web3:// 生态由此展开，ERC-4804 是那块地基。
风险面恰恰也藏在省掉的部分里。网址文本没有内建任何可信度标记：谁生成的链接、指向的合约是不是你以为的那个、数量字段有没有被乘以精度倍数，客户端翻译出来什么，用户就容易照单签什么。给这类链接做防错，可用的动作都很朴素：把网址里的合约地址复制到区块浏览器，核对它是否是你认识的那个代币的部署地址；把数量字段按代币的小数位换算一遍，确认不是把金额写成最小单位时少除了一位；如果链接带了链参数，确认它的链编号和你正要操作的链一致。任何一步对不上，就当链接被改写处理。
还有一个工程细节值得记录：规范选择用路径而不是查询串传参，是为了让不同客户端的解析器尽量不需要理解函数 ABI 也能工作，代价是复杂参数的表达力有限，所以它把适用范围钉死在三个最简单的函数上。机制类标准常做这种交换——先覆盖最常用、最不容易出错的窄场景，再谈推广。
回到收藏者的日常：ERC-4804 本身不创造任何新的授权方式，它只是把已有的合约调用换了一种触达形式。链接缩短服务、二维码和自动跳转都可能在这一形式上叠加额外风险，所以处理原则与处理任何陌生合约调用没有区别——签名前把解码后的目标合约、函数名、参数值逐项读完，读完再决定。链上执行不可逆，网址看起来无害不等于调用结果无害。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。