连接之外的另一条路
今天用钱包和网站打交道，几乎所有路径都先“连接”：浏览器注入或会话配对，网站拿到你的地址，再请求你签一笔笔操作。批量调用标准让多步操作可以打包，但前提仍是一条双向通道。草案 ERC-7946 提出了一个刻意的减法协议，叫 UWULink。它只允许一个方向的数据流：应用把一串合约调用打包成一条请求，塞进二维码、NFC 标签或链接里；钱包扫码读入、向用户展示、批准后原子执行。协议本身没有回传通道——钱包不需要也不应该把任何信息送回给应用。按仓库标注，这份 ERC 目前为草案。
为什么不连反而是一种卖点
原文把动机写得很坦率：有些用户不想为了完成一次多步操作，就把地址和一个具体网站绑定。传统流程里，网站至少通过账户请求拿到你的地址，而 UWULink 的整个交互就是用户主动导入一条交易请求，类似扫描一个支付码——发起方对你一无所知。协议规定，钱包应当像处理已连接网站的交易一样处理它，但不存在连接语境；请求畸形或不支持时，直接提示用户并拒绝即可。这条设计把隐私模型从“连上之后尽量少给数据”，换成了“从结构上就没有可给的数据”。代价是网站无法确认你是否完成，状态核对要回到区块浏览器自查，和扫码支付后去账单里确认是同一个姿势。
编码：为二维码的容量极限而设计
二维码装不下多少东西。协议用 Protocol Buffers 把请求压成二进制，再做 base64 文本编码，前面拼上 uwulink: 前缀成为一条 URI，二维码、NFC、深链都承载同一种载荷。数值编码刻意紧凑，比如一个 wei 的金额写成最短形式而不是三十三个字节；所有字段编号，保证解析器能容忍未知扩展。两种工作模式对应两种容量策略：静态模式把完整的调用清单直接装进二维码，适合步骤固定的场景；可编程模式只在二维码里放一个合约地址和参数，调用清单由那个合约在链上现场生成，二维码可以很小甚至做成永久贴纸，具体做什么取决于合约当前的版本。
原子批量与它的邻接标准
协议对执行方式的要求只有一条且是强制的：批内所有调用必须原子执行，任何一条会失败则整批回滚。这与 ERC-5792批量调用状态怎么查？ 的默认预期一致，区别在传输通道。它也常被拿来和 EIP-681 支付链接对照：681 描述的是“向某地址付某金额”的单笔请求，UWULink 描述的是“按这份清单跑完一组合约调用”的批量请求，并支持引用合约生成的动态清单，表达能力更接近你坐在电脑前点完确认的那类复杂交互。它依赖的链号规则来自 EIP-155，账户侧的委托能力则与 EIP-7702 衔接，也就是说扫码扫出来的批处理，底层机制和网站连接发起的没有两套逻辑。
用户纪律：把二维码当合同原件读
扫码发起交易最大的风险是二维码换码——贴纸被覆盖、页面图片被替换，这同样是 扫码转账安全吗？收款二维码里的地址、金额和跳转怎么读 里讨论过的老问题，只不过 UWULink 的载荷是批量调用，被换码的杀伤力更大。纪律有四条。第一，扫任何要执行合约调用的码之前，确认它出现的位置：来源渠道、域名、现场物理贴纸有没有被叠加；可编程模式尤其警惕，码本身不变不等于内容不变，清单由合约说了算。第二，钱包解码展示后逐条核对目标合约、金额、代币地址，读不懂的那条宁可不签。第三，第一次用某服务发来的码，先问能否只执行清单的一部分或用最小金额试一次。第四，签完不指望网站回执，拿交易哈希去浏览器确认每步结果。草案阶段没有钱包承诺支持，遇到声称“官方标准、务必扫码授权全部资产”的说法，一律按钓鱼处理。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。