直接结论是：关联集合更新后，之前生成的证明通常不能再使用。前提是生成证明时所绑定的旧关联集根（aspRoot）已被新版本替换。
这不是协议针对某个用户，而是提款证明的设计决定了它只能对应"生成那一刻"的链上状态。
为什么旧证明会失效——证明里"绑死"了当时的关联集根
Privacy Pools 的提款证明需要同时验证两件事：一是存款承诺在状态树中，二是存款对应标签在关联集树中。关联集树的根（aspRoot）会作为公开信号"绑定"进生成的 Groth16 证明中。
合约验证时会检查证明中携带的 aspRoot 与当前 ASP 发布的根是否一致。如果 ASP 更新了关联集（例如剔除新发现的非法存款），合约中记录的 aspRoot 会发生变化，旧证明中绑定的 aspRoot 无法匹配，验证就会失败。
真的会"完全失效"吗？——分情况看
大部分情况下：如果关联集更新只是增加新的合规地址，旧证明大概率仍可使用，因为旧的 aspRoot 可能还在合约认可的历史记录中。合约会存储最近几个状态树根和关联集树根，以避免证明因轻微滞后而失效。
核心风险在于：如果更新涉及"排除"操作——例如生成证明时所用集合中的某个地址后来被 ASP 标记为非法。此时证明可能仍能通过验证，但"合规信号"本身会被稀释，外部观察者无法判断你的存款是否属于被剔除的那一批。
实操建议：不要提前生成证明"备用"
如果为了以后提款方便，打算先存款、生成好证明，等需要时直接提交，这个策略在 Privacy Pools 中不成立。
关联集是动态的，ASP 会持续监控链上交易并定期更新集合。存款时是干净的，不代表 ASP 下次更新时仍是干净的。如果提前生成证明，等到使用时 ASP 已经更新，旧证明大概率无法使用。
正确做法是：什么时候提款，什么时候生成证明。生成时使用的 aspRoot 必须是最新版本。
