区块链隐私的最大问题不在密码学

thisvishalsingh 发布于 2026-05-18 阅读 170

区块链隐私不仅是加密原语的问题,更是系统级的安全承诺。

Image

一个隐私协议可以拥有有效的 ZK 证明,但仍然无法实现其隐私主张。

这是令人不安的部分。

电路可以经过约束,验证者可以是正确的,空值器可以防止双花,承诺可以是绑定的,Merkle 根可以是有效的。然而,用户仍然可能被去匿名化。

不是证明系统失败了,而是协议在边界处泄露了信息。

在阅读了 PSE 对 38 个私人转账团队的访谈研究后,我的主要收获是:

隐私不是一个原始要素,而是一个系统级的主张。当实现、基础设施和用户流程未能维护这种主张时,系统级的主张就会失败。


“我们使用 ZK” 并不是一个隐私主张

ZK 证明隐藏了见证信息,但它不会自动隐藏:

  • 用户行为、交易时间、Gas 支付来源、桥接路径、钱包指纹、中继元数据、RPC 可见性、索引器可见性、DeFi 意图、提现模式

这是许多隐私讨论犯的错误。

他们描述了加密原语,然后假设产品继承了隐私保证。

但事实并非如此。

真实用户不会与“证明”交互。

真实用户会存入资金、打开钱包、扫描备注、生成证明、使用中继、支付 Gas、可能桥接、可能接触 DeFi,并最终提现。

每一步都会产生可观察的信息。证明可能是沉默的,但系统不是。

这就是审计面。


第一个审计问题不是“电路是否正确?”

那个问题很重要,但它不是起点。

第一个审计问题应该是:

该协议声称要隐藏什么?

发送者?接收者?金额?资产类型?余额?交易图?DeFi 意图?提现目标?

第二个问题:

对谁隐藏?

公共链观察者?中继?RPC 提供商?索引器?钱包应用?证明服务器?验证者?外部委员会?

第三个问题:

在什么假设下?

大的匿名集?延迟提现?本地证明?诚实的中继?没有地址重用?没有桥接关联?没有元数据泄露?

如果一个隐私主张不能精确地写出来,就不能被精确地审计。如果不能被审计,就不应该被信任。


当上下文缺失时,隐私就会失败

隐私系统中许多高影响力的漏洞不会表现为“密码学被破坏”。

它们会表现为上下文失败。

证明被接受用于错误操作、空值器未绑定到正确资产、Merkle 根针对错误池有效、公共输入从声明中省略、域分隔符跨流程复用、链上和电路中针对不同编码计算的哈希值、为一个上下文生成但在另一个上下文中被接受的证明。

这就是我所说的漏洞类别:有效的证明,错误的上下文。证明验证通过了,但它验证的声明比协议认为它验证的要弱。这可能导致重放、双花变种、错误的提现、会计混乱或隐私损失。

对于审计人员来说,这就是审查应该变得非常具体的地方:

资产 ID 是否被绑定?金额是否被绑定?接收者是否被绑定?空值器是否被绑定?链 ID 是否被绑定?根是否被绑定?操作类型是否被绑定?验证者版本是否被绑定?合约地址是否被绑定?证明能否跨池、链、合约、资产或升级移动?

验证者不仅仅是一个加密端点,它是一个上下文边界。


哈希边界值得怀疑

以太坊使用 Keccak。许多 ZK 电路更喜欢 ZK 友好的哈希。这种转换层通常是漏洞的多发地带。

一个协议可能在链上使用 Keccak,并在电路中使用 Poseidon、MiMC、Pedersen 或其他 ZK 友好的构造。

这没问题,但问题是:

双方是否都承诺了相同的消息?

常见的失败模式:

  • 序列化不一致
  • 字节序不匹配
  • 字段截断
  • 缺少范围检查
  • 模糊的打包编码
  • 复用的域分隔符
  • 哈希参数不匹配
  • 叶子构造不同
  • 检查针对不同树模型的 Merkle 路径

哈希粘合代码看起来乏味,直到它成为电路证明一条消息而合约验证另一条消息的原因。

对于审计人员来说,哈希边界应该像协议边界一样对待。

不仅要检查哈希是否存在,还要精确检查它绑定了什么。


证明基础设施改变了威胁模型

Image

证明速度慢不仅仅是用户体验问题。

它常常促使团队转向服务器端证明、辅助证明、外包证明或专门的证明基础设施。

这可能是合理的,但它改变了隐私模型。

一个证明服务可能了解到:

  • IP 元数据
  • 请求时间
  • 资产类型
  • 金额模式
  • 钱包/会话标识符
  • 证明生成频率
  • 用户行为随时间的变化

在更糟糕的设计中,它可能看到见证材料或足够的辅助数据来关联用户。

因此,审计问题变成了:

什么离开了用户设备?证明者能看到私有输入吗?它能关联证明请求吗?它能拒绝帮助用户退出吗?它能选择性地延迟证明吗?如果服务消失,用户能否本地证明?如果证明服务是敌对的,协议是否仍然安全?

更快的用户流程可能隐藏了更大的信任假设。


钱包是协议的一部分

对于隐私系统,钱包不仅仅是用户界面。

它们处理:

  • 花费密钥
  • 查看密钥
  • 备注扫描
  • 地址生成
  • 恢复
  • Gas 支付
  • 签名上下文
  • 私有/公共账户分离

如果钱包在这方面出错,即使电路是正确的,协议也可能无法实现其隐私主张。

值得提出的问题:

查看密钥会成为隐私负担吗?

花费和查看权限会混淆吗?

同步时备注会丢失吗?

恢复会泄露交易历史吗?

地址重用会破坏匿名性吗?

Gas 支付会链接私有和公共账户吗?

dapp 能欺骗钱包签署破坏隐私的元数据吗?

如果钱包关联了用户的活动,用户不会在乎密码学有多优雅。

隐私主张失败了。


私有 DeFi 并非“私有转账 + DeFi”

私有转账很难。私有 DeFi 更难。DeFi 假设可见的共享状态:

余额、授权、储备、抵押品、债务、LP 头寸、清算健康度、交换路径。

隐私系统通常会隔离状态。这种不匹配是危险的。一旦私有资产接触到公共 DeFi,意图就可能泄露。

用户可以私下存入,公开解包,交换,桥接,借贷,偿还和提现。证明可能是有效的,流程仍然可能显而易见。这就是为什么私有 DeFi 应该被作为独立的安全问题来审查,而不是作为带有 DeFi 集成的私有转账协议。

审计问题:

包装或解包是否暴露了意图?

资产 ID 是否暴露?

金额能否被关联?

交换路径能否对用户进行指纹识别?

清算能否揭示私人头寸?

桥接路径能否缩小匿名集?

DeFi 操作是否使提现关联更容易?

需要审查的是组合本身。


外部网络不仅仅是“基础设施”

中继、索引器、RPC、FHE 协处理器、TEE、链下存储、备注发现服务和应用后端都是隐私模型的一部分。

它们应该被视为安全假设。

如果中继进行审查,用户能退出吗?

如果索引器撒谎,用户会错过资金吗?

如果 RPC 观察所有请求,它能关联什么?

如果密文存储消失,用户能恢复吗?

如果 TEE 泄露,哪些隐私丢失了?

如果 FHE 委员会勾结,哪些信息可以被解密?

每个外部依赖都应该被建模为:不可用、敌对、审查、勾结或元数据泄露。

隐私协议不仅仅是在链上发生的事情。

它也是使用它所需的基础设施。


存款和提现往往是真正的泄露点

这是人们低估的部分。

一个用户存入 10 ETH。几分钟后,有人将 9.99 ETH 提现到一个新地址。不需要破解任何密码学。模式本身就是证据。

时间关联、金额关联、Gas 支付者关联、桥接路径和流动性不足可以在不触及证明系统的情况下破坏隐私。

入口和出口泄露的信息可能比屏蔽转账本身更多。

所以问题不仅仅是:用户能私下转账吗?

而是:用户能进入和退出而不变得明显吗?

这是一个更难的问题。


审计方法

Image

对于一次严肃的隐私审计,我会从绘制生命周期开始:

存款 → 屏蔽 → 扫描 → 证明 → 转账 → 组合 → 桥接 → 提现

然后我会标记每一处:

  • 状态变得公开
  • 元数据离开用户
  • 外部参与者被信任
  • 操作可以被重放
  • 时间可以关联
  • 金额可以关联
  • 密钥可以混淆
  • 根可能过时
  • 空值器可能错误绑定
  • 哈希编码可能产生分歧
  • DeFi 揭示意图
  • 基础设施可以审查
  • 用户可能无意中削弱自身

这个地图是许多真实发现出现的地方。并不总是在数学内部,经常在其周围。


结论

区块链隐私不是“加上 ZK 然后发布”,它是一个全栈的安全承诺。

一个协议可以有有效的证明,但仍然失败,因为生命周期通过钱包、中继、桥接、DeFi、证明基础设施、RPC、索引器或用户行为泄露信息。

对于构建者:要让隐私主张精确。

对于审计者/研究者:要测试实现是否维护了该主张。要测量在证明之后仍然泄露了什么。在隐私审计中,证明只是一个见证者。系统的其余部分也在作证。审计边界。

  • 原文链接: x.com/thisvishalsingh/st...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论