不露金额过合规关：ERC-8262 零知识合规神谕的证明口径

链上合规的默认画面是亮出一切：身份证明、交易金额、对手方信息交给筛查机构再流转。ERC-8262 换一套逻辑：用户在本地用零知识证明完成自证，链上只验一个布尔结果。文件头记录创建于 2026 年 4 月 7 日，仓库状态 Draft，声明依赖 ERC-165，不引入可信第三方或可信执行环境。

证明的九种问法

checkCompliance 与 checkComplianceByType 是主入口，证明类型覆盖合规证明、风险分证明、模式检测、凭证验证、成员与非成员证明，外加签名版的合规、风险分与多人共签三种。成员与非成员证明走稀疏默克尔树：非成员证明要同时给出相邻两条目，断言“低于我的一条与高于我的一条在树上相邻”，回路额外要求两条目索引恰差一，堵住跳过真实中间条目的伪造路径。多人共签版把签名槽并到五个，每个非零槽独立验一把 secp256k1 签名、独立断言该提供者的风险分低于辖区红线，伪造需要同时拿下 M 把注册私钥，阈值不得低于各辖区声明的最小提供者数。

两条防重放的分岔

原文在安全章节写得很坦率：无签名的证明类型不把链 ID 作为公开输入，同一串证明字节理论上能在另一条链或另一个神谕部署上重放，链上唯一的防线是证明哈希去重，只防同一对链与神谕内的重复入库，没有回路内的绑定。签名类型则把链 ID、神谕地址、提供者集合哈希、信号、权重、时间戳与提交者全部压进域分离的摘要，重放到别处就要伪造注册提供者的新签名。威胁模型含跨部署重放的集成方，标准建议直接分叉无签名回路、把两个字段加为公开输入。

工程细节里的坑位清单

部署方要自答的策略题

标准把大量裁量推给部署配置，逐项列出来就是集成方的作业清单。验证器选择：部署时绑哪套回路、升级节奏如何、按版本解析后写入记录的地址是否与实际验证地址一致，原文用 TOCTOU 的措辞专门警告了中间升级造成的记录错位。提供者集合与权重：多个筛查信号源并存时，权重表进承诺哈希，改权重等于开一代新配置，事件与注册表版本一起构成可追溯谱系。辖区参数：每个辖区的最低提供者数、高危线阈值、报告阈值都登记在链上可查，签名证明的通过条件随辖区切换而变。有效期的选择更微妙——attestation 有生存期，太短逼用户频繁重证，太长让过期豁免继续放行，时间戳的粒度只能支撑天级窗口。把这套清单反过来用，就是审查一个部署的话术检测器：看它有没有暴露辖区配置、有没有版本化的验证器记录、无签名证明是否做了链绑定，三处空白一处都解释不清的“零知识合规”，大概率只是给常规名单筛查加了一层哈希外衣。协议文本能承诺的密码学边界写得越清楚，这类照妖镜越好使。

时间戳只能量天级的窗口，区块生产者对 block.timestamp 有父块约束内的微调权，更细的排序要用显式序号。验证器版本解析必须在一次提交里只发生一次，同时用于验证与入库记录，否则升级正好夹在交易中间会记错验过证明的地址，追溯审计失效。验证器接口必须是 view，靠静态调用禁止回调改状态；批量验证的回路成本约每证二百四十万 gas 并随批量线性放大，上限必须按目标链区块上限预留；注册表对重复登记与缺失吊销必须回滚而不是静默无操作。与 Privacy Pools 的差别原文划清了：成员集合只是合规的一个子集，这条提案扩展到风险评分、拆分交易检测与凭证维度。Draft 阶段，引用前核对当前草稿的回路口径。本文为机制说明，不构成任何投资建议。