我发现有个技术改动，被合并进Dusk的PLONK主分支。修改对象是压缩电路文件的反序列化流程：正文解析完后若仍有多余字节，compile_with_compressed会返回InvalidCompressedCircuit；官方回归测试专门追加了一个合法的MessagePack尾值，确认修复前会被接受、修复后会被拒绝。
同一份压缩电路，正文一模一样，末尾只多塞一个无关字节。任何按原始字节算哈希的风控或缓存系统，都会把它认成另一份文件；旧版PLONK却可能照常读进去。
看到这里，我其实有点担心。文件明明变了，证明工具却说“没变”。对金融系统，这比直接报错更麻烦：一份东西，同时有两张身份证。
我先来敲准对象。这次改的是生成证明所用的压缩电路文件，链上已经生成的证明不在这次范围。Dusk最新合并的处理很干脆：电路正文读完后，只要后面还有多余字节，整份文件直接判无效。
坦白说，我起初有点嫌它较真。旧工具能跑，何必为了几个尾字节砍掉兼容性？可把它放进交易系统，想法就变了。原始文件若被审计、缓存或版本库按字节识别，编译器却把两份不同文件当成同一套规则，出了问题很难说清到底用了哪一版。
这就给我一个很实用的判断：升级后某些ZK应用突然失败，先看InvalidCompressedCircuit、工具版本和重新导出文件后能否恢复。旧文件失败、新文件正常，更多像格式迁移；规范文件仍大面积失败，才需要往证明逻辑或网络故障深挖。别把两种风险混在一根K线上。
对于$DUSK，这项收紧短期可能减少成功调用，甚至让旧工具停一阵；长期价值要看下游迁移后，证明故障、版本争议和机构复核成本有没有下降。解析器不会直接创造买盘。它能做的，是让每一份电路只认一张身份证。
交易中，我不会把“尽量能读”当友好，我认为，金融账本更需要合法唯一性。DYOR！
#dusk $DUSK @Dusk
同一份压缩电路，正文一模一样，末尾只多塞一个无关字节。任何按原始字节算哈希的风控或缓存系统，都会把它认成另一份文件；旧版PLONK却可能照常读进去。
看到这里，我其实有点担心。文件明明变了，证明工具却说“没变”。对金融系统，这比直接报错更麻烦：一份东西，同时有两张身份证。
我先来敲准对象。这次改的是生成证明所用的压缩电路文件，链上已经生成的证明不在这次范围。Dusk最新合并的处理很干脆：电路正文读完后，只要后面还有多余字节，整份文件直接判无效。
坦白说，我起初有点嫌它较真。旧工具能跑，何必为了几个尾字节砍掉兼容性？可把它放进交易系统，想法就变了。原始文件若被审计、缓存或版本库按字节识别，编译器却把两份不同文件当成同一套规则，出了问题很难说清到底用了哪一版。
这就给我一个很实用的判断：升级后某些ZK应用突然失败，先看InvalidCompressedCircuit、工具版本和重新导出文件后能否恢复。旧文件失败、新文件正常，更多像格式迁移；规范文件仍大面积失败，才需要往证明逻辑或网络故障深挖。别把两种风险混在一根K线上。
对于$DUSK，这项收紧短期可能减少成功调用，甚至让旧工具停一阵；长期价值要看下游迁移后，证明故障、版本争议和机构复核成本有没有下降。解析器不会直接创造买盘。它能做的，是让每一份电路只认一张身份证。
交易中，我不会把“尽量能读”当友好，我认为，金融账本更需要合法唯一性。DYOR！
#dusk $DUSK @Dusk