有一类需求长得很拧巴：你必须向我证明某件事，但我不需要知道你是谁。混币协议里，协调者要让所有人确认「这串输出和那串签名严格一一对应、没人冒充别人」，却恰恰不能让任何人看出哪串属于谁；储备证明里，发行方要证明「这笔余额对应的私钥我持有」，却不想把私钥亮出来。把这类需求推到底，会推出同一个密码学零件：DLEQ 证明。它低调地活在许多隐私协议的内部，值得专门拆开。
问题设定：一个秘密，两把锁
椭圆曲线密码的常识：私钥 x 乘基点 G 得公钥 P = xG。DLEQ 处理的问题是：给定两组「基点与结果」——(G, P=xG) 与 (H, Q=xH)——证明存在同一个 x 同时满足两式，且不透露 x。听起来微小，威力却具体：只要第二组是「把某个可追踪的元素（比如一枚混币输出的盲化标记）挂上密钥」，DLEQ 证明就把「密钥归属」钉死在两份数据之间，谁都能离线验证，验证过程一个字都不泄露 x 是什么。它是普通 Schnorr 知识证明的自然推广：Schnorr 证「我知道这一个元素的离散对数」，DLEQ 证「这两个元素共享同一个离散对数」，构造思路同型——承诺一个随机数、用挑战哈希绑定、给出线性响应。
真实场景一：混币的密钥选举
以 Wasabi 这类协调式混币为例：每轮混币要防止「一个参与者谎称自己控制多个密钥、投出多份同意票」。做法是每个参与者提交公钥，并对协调者公布的盲化值做 DLEQ 证明。投票时别人只能验票不能对号入座，最终聚合出来的记录又能证明每张票合法。没有 DLEQ，要么暴露身份映射（隐私破产），要么信任协调者不作假（中心破产）——它精确地站在了两个破产之间。
真实场景二：储备证明里的绑定
稳定币的默克尔树储备证明常被提到「可验证签名版的余额声明」：发行者为每个账户承诺一个与密钥绑定的值并附 DLEQ 证明，审计者验证「持有该证明的人确实控制对应私钥」，从而阻止把别人的余额拿来虚报。同样是「绑定而不暴露」的主题变奏。
直觉账本
构造细节不必手推，抓住三段式即可：证明者先随机生成一个承诺点并公布；验证者（或随机信标、或哈希 Fiat-Shamir 变换）给出挑战数；证明者用挑战乘私钥加上随机数作为响应。有人想对两个群元素同时蒙混，就需要在两条独立的挑战路径上给出兼容答案，离散对数假设下概率可忽略。成本也便宜：验证是几次点乘，链下毫秒级，这也是它比重量级 zk 系统更适合嵌进协议日常流程的原因——够用、够快、审计面小。反过来说，当你看到一个隐私协议连 DLEQ 都省了、直接公开密钥映射表来图省事，那通常意味着设计者要么默认信任协调者，要么根本没把「谁都可以自行验证」当目标——这两种妥协在审计时都值得点名。
快速问答
问：DLEQ 和零知识证明是两回事吗？ 答：不是，它是零知识证明家族里最轻巧的一种特例（Schnorr 型 sigma 协议），只表达「相等」这一种关系。
问：它防得住什么攻击？ 答：防「用他人密钥冒名绑定」与「事后抵赖绑定关系」；不防私钥本身被盗——密钥丢了，绑定再正确也没用。
问：普通用户会接触到它吗？ 答：会，混币轮次记录与部分储备证明的核验代码里就跑着它，只是界面上不会写这个名字。
常见误区
一是把「能验证」读成「能追溯到本人」。DLEQ 的全部要点恰恰是验证者与本人之间不需要第三条关联通道。二是把它当万能包含——它只会证离散对数相等这一件事，复杂关系要靠完整 zk 电路。三是忽略参数一致性：挑战值若可被证明者预控，绑定就失去意义，成熟实现对此有严格约定。
风险提示：涉及混币与证明的服务合规与隐私边界因地区而异；本文只做技术解释，不构成任何使用或投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。