在 Solidity 中构建隐私混合器：为什么我的 Merkle Proofs 失败了

Source: Dev.to

Web3 中的隐私常被视为一盒“黑箱”，里面充满了复杂的零知识证明。然而，大多数隐私协议（如 Tornado Cash）的核心其实是一个更古老、更简单的结构：Merkle 树。

最近，在构建一个基于研究的 ETH Mixer 时，我遇到了链上验证与链下证明生成之间的经典同步问题。以下是我对 Merkle 树稳定性的认识以及如何避免“无效证明”陷阱的经验。

架构

目标很简单：

1. 存款 – 用户发送 1 ETH 并提供一个哈希（承诺）。
2. 混合 – 将该承诺加入 Merkle 树。
3. 取款 – 用户提供 Merkle 证明，以在不泄露原始存款的情况下，将 1 ETH 提取到一个新地址。

陷阱：排序哈希

最初，我使用了排序哈希的 Merkle 树。在这种方法中，节点在哈希之前会先排序：

// Vulnerable logic for manual proof generation
computedHash = a

#solidity #blockchain #web3 #security #foundry