ERC-7945 保密交易代币：余额和转账金额藏进密文后，接口还兼容谁

ERC-20 的世界里，余额和转账金额天生公开：balanceOf 谁都能调，Transfer 事件谁都能订阅。想要保密，此前只有各家自建方案——Tornado Cash 与 Zeto 用合约内 UTXO 模型，学术项目 Zether 用同态加密，接口互不相通，钱包和交易所每接一个隐私代币都要重做集成。ERC-7945（Confidential Transactions Supported Token）换了一个思路：不统一加密方案，只统一接口形状。按以太坊 ercs 仓库的记录，这份提案状态为 Last Call，创建于 2025 年 5 月 9 日。

六个函数把隐私装进账户模型

接口围绕六个函数展开。confidentialBalanceOf 接收地址，返回的不是数字而是密文形式的 bytes 余额——只有持有相应查看密钥的人能把它还原成明文。confidentialTransfer 是保密转账主函数，参数里除了收件地址，还带一个保密金额编码和一个 _proof 证明字节；证明验证不通过就必须回滚。confidentialTransferFrom 让被授权方代替持有人发起保密转账，confidentialApprove 与 confidentialAllowance 则把授权额度本身也保密化。另有可选的 confidentialTotalSupply 返回密文形态的总供应。标准的取舍很清楚：只标准化余额查询、转账、代付、授权和对应事件这些最小互操作面，让不同的证明系统、密文编码与合规流程都能躲在同一套函数签名后面，客户端不必绑定某一种实现。

_proof 是理解这套接口的钥匙。以标准举的 Zether 类实现为例，转账金额用 ElGamal 公钥做同态加密，_proof 由三部分验证组成，合约只需验证”加密后的数字运算合法”而无需知道数字本身。证明系统是可插拔的：换成别的零知识体系，函数签名不变，钱包照常对接。

隐私和审计不是二选一

标准专设一节讲反洗钱与审计，给出的技巧值得展开：在不改 confidentialTransfer 函数签名的前提下，调用方可以把金额冗余加密给多方——付款者自己、收款者、以及一组审计者的公钥各一份。这样合约仍然只见密文，但相关方能还原真实金额；confidentialTotalSupply 同理。对受监管的银行类发行方，这就是”默认保密、按需可审”的实现路径。读一个 7945 代币时，看它的加密参数把哪些公钥编进去了，就能判断它偏向纯隐私还是合规隐私。

用户视角的三条边界

与 UTXO 混币路线的分岔口

同样追求保密，合约内 UTXO 模型（Tornado Cash、Zeto 一系走的路）与本标准代表的账户模型路线在工程性格上分道扬镳。UTXO 路线把资金打成固定面额的承诺，用户进出混币池，隐私来自金额拆分与 anonymity set 的混合；7945 则保留”每个地址一个余额”的账户直觉，只是余额以密文形态存在，转账依然是一对一的定向支付，可以挂授权、可以代人付款。这个差别对应用层的意义很实际：UTXO 池很难做”按额度授权”或”订阅扣款”这类依赖账户语义的功能，而 7945 代币理论上能让钱包、借贷、做市在不见金额的条件下复用既有逻辑。标准的取舍也因此清晰——它刻意只覆盖账户模型下的最小互操作面，把证明系统留给各家，连它引用的 Zether 式实现也只是可选样例之一。评估某个 7945 部署时，问题因此从”用了哪种零知识方案”细化为”在这套统一接口后面，它的证明验证要求什么、查看密钥怎么发放、审计编码入了哪些公钥”，接口统一了沟通语言，但每一个部署的信任画像仍要各自打开看。

第一，保密的是链上可见性，不是密码学之外的安全：查看密钥或私钥泄露，一切归零，这与自托管钱包的风险结构相同。第二，接口兼容不等于体验兼容：bytes 密文对区块浏览器就是一串乱码，链上数据浏览器显示的将只有”发生了一次保密转账”，地址级的资金流分析对这类交易基本失效——合规团队与个人查账都要改用代币自己的查看工具。第三，Last Call 状态说明接口文本接近定稿但仍可能微调，接入前以合约实际暴露的函数与事件为准。本文为机制说明，不构成任何投资建议。