跨链一手交钱一手交货：ERC-7573 的条件解密交割

跨链交易最原始的恐惧是顺序问题：先付款的哪一方，承担对方不交货的全部风险。ERC-7573（Conditional-upon-Transfer-Decryption for DvP）给“券款对付”（delivery-versus-payment）一个程序化答案：一条链上锁定资产，另一条链上准备付款，把资产私钥的解密与付款交易的成败绑定在一起——付款成功，密钥解出，资产释放；付款失败，密钥永远解不出，资产退回。按 ercs 仓库记录，提案状态为 Draft（草稿），创建于 2023 年 12 月 5 日。

两条链各一枚合约

方案由两侧合约夹一个预言机组成。资产链上的合约实现 ILockingContract：inceptTransfer 建立一笔交割并把资产锁进合约，completeLock 完成锁定，cancelTransfer 在约定条件内取消；合约持有的是一把密钥的密文表示，只认两个承诺值之一的哈希匹配。付款链上的合约实现 IDecryptionContract：同样有 inceptTransfer、confirmTransfer、cancelTransfer 生命周期函数，另有 transferAndDecrypt——把付款转账和解密请求绑成一步。密钥的解密交给挂靠在付款链上的一个无状态解密预言机，谁调用 releaseKey 提交交割编号与密钥，谁就触发资产链上的 transferWithKey 释放资产。

时序串起来是这样的：资产链锁定并承诺两把可能密钥之一；付款链发起付款条件；付款成功这条路走通，预言机解出对应密钥，密钥被提交到资产链完成交割；付款失败这条路走通，解出的是“退回密钥”，原持有人取回资产。规范允许异步生成密钥的实现（ILockingContractWithKeyGeneration 等扩展接口），并给链上接收方留了完成回调，可以事后读取这笔交割的不可变上下文。

无状态预言机意味着什么

这套设计免除的是一类中间人——不需要一家托管机构同时碰两边资产；但引入的另一类依赖必须说清：预言机持有解密密钥的能力。它“无状态”只说明它不记账、不排序、不 censor 交易的排队顺序由合约逻辑约束，而“能解密”意味着在协议设定的那一刻，密钥的生成方式保证了没有任何一方能同时拿到两把钥匙——这份保证来自密码学构造和实现审查，而不是接口声明本身。审计这份实现时，密钥生成仪式（谁参与、 entropy 怎么来、能否合谋出全部密钥）是第一问题，接口规范不回答它。

失败与卡死的现实路径

规范给了 cancel 系列函数，但跨链交割最险的是半程卡死：付款在 B 链已确认、A 链的锁还没释放；或密钥已解出却没人替你去 A 链提交 transferWithKey。前一种要靠承诺值与哈希比对保护，后一种意味着任何一方或第三方在期限内提交密钥都能推进交割——速度本身成为博弈资源。普通用户参与此类机制，实际风险不在概念而在细节：deadline 设多长、取消要不要对方配合、gas 不足时谁来补提。

与跨链桥、原子互换的关系

交割单上的四组函数

按规范文本，两枚合约的函数名可以当作交割单的验真锚点。付款链一侧，inceptTransfer 登记这笔交割的条件，confirmTransfer 确认付款动作就绪，cancelTransfer 在条件不成立时取消；资产链一侧，同样的生命周期函数外还有 completeLock 与最关键的 transferWithKey(id, key)——密钥出现并被提交的那一笔，才是交割真正完成的时刻。逐组在浏览器里查“存在且被调用过”：任何一组函数缺失的所谓“跨链券款对付”，都值得追问它的原子性从何而来。验证交割是否走通的标准动作，是把两条链上同一交割编号的区块时间排在一起：锁定、付款、解密、释放四步的时间差与调用顺序，读起来就是一句话的结论。

原子互换用哈希锁在两条链玩同一把预像游戏，两侧都是用户自己主导；跨链桥把资产打包给验证者网络转达意图；ERC-7573 的路线介于两者之间——密钥承诺提供原子性味道，解密预言机提供桥的可操作性味道。三类方案对“信任什么”的回答各不相同：数学、验证者集合、预言机密钥仪式。读任何“跨链一手交钱一手交货”的宣传时，先定位它属于哪条路线，再看它失败路径上有没有你必须手动执行的救援函数。本文为机制说明，不构成任何投资建议。