#dusk $DUSK
这两天看 @Dusk 最新一轮 Developer Update，有个更新我觉得比“又加了一个 ZK 功能”更值得看。
zk-tools 现在开始补 Groth16 Solidity verifier 的生成和验证工具。
乍一看挺小。
但如果真写过 ZK 应用，就知道 proof 做出来只是前半段。
后面还有个很现实的问题：
Solidity 合约到底怎么认这份 proof？
Circuit 定义规则，prover 生成 proof，到了 EVM 这一边，还需要 verifier contract 去检查 proof 和 public inputs 是否满足原来的约束。
这层接口没做好，底下密码学再强，对普通 Solidity 开发者还是很远。
所以我现在看 Dusk 这次更新，重点不是 Groth16 这个名字。
而是它在补：
proof → verifier → Solidity application
中间这段工程链。
当然，verifier 也不是万能的。
它能确认一份 proof 是否符合预先写好的 circuit，但数据从哪里来、这个规则有没有业务意义、资格现在还是否有效，还是应用自己要定义。
这点我反而觉得正常。
密码学负责把“证明”验明白，产品自己负责决定拿这个证明干什么。
DuskEVM 现在还在 Testnet，我不会因为多了一个 verifier tooling 就直接说整套 ZK workflow 已经成熟。
但这种更新至少比一句“支持 ZK”更实在。
真正能让开发者用起来的，往往就是这些看起来不太性感的接口。
这两天看 @Dusk 最新一轮 Developer Update，有个更新我觉得比“又加了一个 ZK 功能”更值得看。
zk-tools 现在开始补 Groth16 Solidity verifier 的生成和验证工具。
乍一看挺小。
但如果真写过 ZK 应用，就知道 proof 做出来只是前半段。
后面还有个很现实的问题：
Solidity 合约到底怎么认这份 proof？
Circuit 定义规则，prover 生成 proof，到了 EVM 这一边，还需要 verifier contract 去检查 proof 和 public inputs 是否满足原来的约束。
这层接口没做好，底下密码学再强，对普通 Solidity 开发者还是很远。
所以我现在看 Dusk 这次更新，重点不是 Groth16 这个名字。
而是它在补：
proof → verifier → Solidity application
中间这段工程链。
当然，verifier 也不是万能的。
它能确认一份 proof 是否符合预先写好的 circuit，但数据从哪里来、这个规则有没有业务意义、资格现在还是否有效，还是应用自己要定义。
这点我反而觉得正常。
密码学负责把“证明”验明白，产品自己负责决定拿这个证明干什么。
DuskEVM 现在还在 Testnet，我不会因为多了一个 verifier tooling 就直接说整套 ZK workflow 已经成熟。
但这种更新至少比一句“支持 ZK”更实在。
真正能让开发者用起来的，往往就是这些看起来不太性感的接口。
