隐私稳定币要走向现实，合规必须是原生能力
compliant-privacy-stablecoin 是我设计并实现的一个项目。
这个项目最重要的地方，不是“又做了一个隐私稳定币”，而是我从一开始就没有把“隐私”和“合规”当成对立面，而是尝试把两者一起写进协议路径里。
很多隐私项目的默认叙事是：先把匿名性做强，合规以后再补。这个项目的思路正好相反。我真正想解决的问题是：
如果稳定币既想保留链上交易隐私，又想进入真实支付与监管场景，那么合规能力必须是协议原生能力，而不是事后外挂。
这个项目到底在做什么
从结构上看，它是一个基于 ZK 证明、Merkle 树、门限审计和链下客户端协作的隐私稳定币协议。
项目核心由几部分组成：
ShieldedPool.sol负责隐私资金池、存款、隐私转账和提款。AuditRegistry.sol负责审计节点名录、DKG 数据上链和全局审计公钥公示。joinsplit电路负责证明“这笔交易在隐私上是成立的，在金额上是守恒的，在双花上是安全的”。- Rust 客户端负责本地生成 Note、构造证明、执行门限审计加解密。
如果只看这些组件，它仍然像一个典型的“隐私资产协议”。
但我认为它真正的辨识度，不在隐私部分，而在合规设计被拆成了三层，而且每一层都不是口头上的合规，而是写进了实际流程里。
第一层合规：资金进入前先拦截
这个项目的第一条合规轨道，是我在存款前放进去的前置审查机制。
在 ShieldedPool.sol 里，合约有一个 complianceSigner。如果启用这条路径，用户存款时不仅要提交 commitment 和金额，还要提交由合规签名者签发的 ECDSA 签名。合约会验证这份签名是否匹配当前用户、当前金额和当前 commitment。
这意味着什么？
这意味着我不是把黑钱先放进池子，再寄希望于后续识别；而是在资金进入隐私池之前，就先做一轮入口控制。
这条路径有两个很现实的特点：
-
它符合稳定币世界里常见的 KYC/AML 直觉。
不是所有用户都能无条件进入隐私池，至少在协议设计上，发行方或合规服务商可以做前置放行。 -
它把“合规结果”从链下判断，变成链上可执行条件。
合规审查本身可能发生在链下，但链上合约不会只信口头结果，而是要求一个可验证的签名结果。
这一点很重要。因为很多项目说自己“支持合规”，实际只是说“我们可以接一个合规 API”。而这里的思路更硬：没有签名，就不能进池。
第二层合规：提款时做资金清白证明
如果说第一层是“入口拦截”，第二层就是“出口约束”。
我在 transact 路径里引入了 cleanTreeRoot，也就是所谓的“干净资金树根”。合约会检查这个树根是否在 approvedCleanRoots 白名单内，然后把它作为公共输入送进 ZK 验证。
这背后的逻辑不是简单黑名单，而是一种更接近 Proof of Innocence 的思路：
- 总 Merkle 树记录所有 commitment；
- 干净树只记录被认定为“合规来源”的 commitment；
- 用户提款或交易时，不仅要证明自己的 note 存在于总树中；
- 还要证明它存在于干净树中。
也就是说，这个项目不是只问“你有没有钱”，还要问“你这笔钱是不是来自可接受的集合”。
这和传统隐私池有一个明显差别。
传统隐私池更强调“只要证明拥有某个 note，就可以花”。
这个项目强调的是：“你不仅要证明拥有它，还要证明它属于被认可的来源集合。”
这就是它“合规”两个字真正落地的地方。它不是在 UI 上加一个免责声明，而是把合规条件变成了证明系统本身的一部分。
第三层合规：隐私不等于无法审计
这个项目里，我没有把隐私理解成“任何人永远看不到”。
我选择的路线是：默认情况下隐藏交易细节，但在满足门限授权条件时，受认可的审计节点可以联合还原交易信息。
具体做法是：
- 用户在发起隐私交易时，会生成一把一次性对称密钥；
- 交易明文的一部分会在电路里被这把对称密钥加密，并与证明绑定；
- 同时，这把对称密钥又会被全局审计公钥加密；
- 对称密钥密文和审计密文会随交易事件上链；
- 任何单个审计节点都无法独立解密；
- 只有满足
3-of-5门限的审计节点联合提供解密份额，才可以还原出交易明文。
这里的设计非常关键。
它不是“给管理员一把总钥匙”，也不是“部署一个中心化后门”。
我想实现的是一种分布式可审计隐私：
- 日常情况下，用户享有隐藏金额、发送者和接收者的隐私体验；
- 但在司法、监管或合规调查需要时，可以通过多方联合授权恢复交易上下文；
- 单点作恶或单点泄露都不足以解开全部隐私。
对稳定币来说，这比“绝对匿名”更接近现实世界的制度要求。
因为真正的问题从来不是“能不能做匿名”，而是“能不能在合法场景中保留隐私，同时在必要时接受审计”。
这个项目最有价值的地方：把合规写进协议，而不是写进公告
如果只用一句话概括这个项目，我会说：
这个项目最重要的贡献，不是证明隐私稳定币可以做，而是证明“合规隐私稳定币”可以被拆解成一组明确的协议机制。
这组机制大致是：
- 前置 KYC/AML 签名，控制谁可以入池。
- 干净树证明，控制哪些资金可以顺利流出或被认可使用。
- 门限审计解密，保证隐私不是绝对黑盒。
这三层叠在一起，项目表达的就不再是“匿名支付”，而更像是：
一种面向真实支付基础设施场景的、默认隐私但可受控审计的稳定币协议。
这比传统隐私协议更接近金融基础设施，而不是单纯的密码学实验。
为什么这条路比“纯匿名池”更现实
传统隐私池的问题，不只是监管不喜欢，而是它很难与稳定币发行方、支付机构、托管机构和合规服务商形成长期兼容。
原因很简单：
- 稳定币发行方天然要面对冻结、制裁、AML、KYC 压力；
- 支付场景要求风险可控、责任可追踪；
- 如果隐私协议完全拒绝任何可审计性，那么它很难成为主流稳定币基础设施的一部分。
我做这个项目，本质上是在回答一个更现实的问题：
不是“如何把稳定币变得最匿名”，而是“如何让稳定币在保有隐私的前提下，仍然能被金融体系接受”。
这是一个更难的问题，但也更有长期价值。
我认为它还有哪些现实张力
我认同这个项目的方向，但它也保留了很明显的现实张力。
1. 合规权力仍然需要治理
比如：
- 谁来担任
complianceSigner？ - 谁来维护
approvedCleanRoots？ - 谁来定义“干净资金”？
- 谁来决定何时启动审计？
这些问题没有因为用了 ZK 或门限密码学就自动消失。它们只是从“后台人工审批”变成了“协议参数和治理权配置”。
换句话说，项目把合规做进了协议，但合规权力本身仍然需要制度安排。
2. 门限审计降低单点风险，但不等于没有中心化风险
3-of-5 比单管理员后门强很多，但它仍然是一种受控权限结构。
如果 5 个审计节点高度同质、背后利益一致，或者治理结构过于集中，那么门限只是技术上的多签，不一定天然等于治理上的分权。
3. 干净树模式适合合规叙事，但会带来新的运维复杂度
干净树不是一劳永逸的。
它需要持续更新、同步、纠错和争议处理。
一旦某个地址后来被重新认定，或某笔资金的风险标签发生变化，干净树的维护逻辑就会变成一项长期工程，而不是一次性的技术动作。
所以这类协议最终成不成立，不只看密码学，也看治理和运营能力。
为什么我觉得这个项目值得写下来
因为它把一个很常见、但经常被说空的话题，做成了具体结构：
隐私和合规不是非此即彼，关键在于你把合规放在哪一层，以及是否愿意把它变成真正可执行的协议条件。
这个项目给出的答案是：
- 隐私放在交易表现层；
- 合规放在资金入口、资金出口和事后审计三个环节；
- 审计能力不是管理员单点后门，而是门限联合能力；
- 合规不是产品说明书，而是约束、签名、证明和事件数据的一部分。
即便它距离真正可大规模上线的金融级系统还有距离，这个方向本身已经很值得重视。
至少它说明了一件事：
下一代稳定币隐私协议，重点可能不再是“怎么更像 Tornado Cash”，而是“怎么在不走向完全透明的前提下，成为可被监管和支付体系接受的资产流转基础设施”。
结语
如果把这个项目只看成一个 ZK 稳定币 Demo，会低估它。
它真正有意思的地方，是试图回答一个更长期的问题：
稳定币的隐私能力，能不能从“监管冲突点”变成“合规金融基础设施的一部分”。
我的判断是，这个问题未来会越来越重要。
因为稳定币一旦真的进入支付、清算和跨境流通场景，市场需要的就不会是“绝对透明”或“绝对匿名”这两种极端，而是：
默认保护普通用户隐私，但在制度化授权下保留审计和执法接口。
而这个项目，就是我对这条路的一次具体实现。