把panic改成结构化错误，保护的是整个节点而不只是一笔坏交易
我判断一段密码学代码是否成熟，会特别看它怎样面对错误输入。能够正确处理正常数据只是第一步；面对截断、畸形或故意构造的数据时，是返回一个可分类错误，还是直接panic让进程展开，决定了攻击影响会停在一笔请求，还是扩大到整个服务。Dusk本周为Phoenix Core的错误逐项补齐到Dusk Bytes结果的映射，并把可达的unwind路径替换成结构化错误，这属于典型的“失败也要可控”。
结构化错误的价值不只是日志更好看。节点收到一份无效数据后，可以根据错误类型拒绝、计数、限速或标记来源；钱包则能告诉用户是长度错误、解密失败还是格式不支持。如果所有异常都变成同一个崩溃，运维系统只能看到进程退出，既无法区分恶意输入与普通损坏，也容易在自动重启后重复触发同一问题。
更值得注意的是错误映射必须完整。底层库新增一个错误分支，上层若用通配符草率处理，可能把本应拒绝的情况吞掉，或把内部细节暴露给外部。较稳妥的做法是枚举Phoenix Core每个可达错误，定义对应的Dusk Bytes结果，并用测试确认没有路径越过边界触发panic。对不可信输入，还要先做长度与格式检查，再进入昂贵的解密或曲线运算。
当然，“不崩溃”不等于输入有效，也不意味着旧的Phoenix交易重新开放。Boreas之后，主网已在指定边界停止接受新的Phoenix交易，但节点仍需保留历史解码与执行能力，才能同步和重放旧区块。
所以我认为@Dusk 这次错误处理加固，真正保护的是网络的故障半径。金融基础设施无法保证永远看不到坏数据，却可以保证坏数据只得到一个明确拒绝，而不会把无关用户一起拖下线。
@Dusk $DUSK #dusk
我判断一段密码学代码是否成熟，会特别看它怎样面对错误输入。能够正确处理正常数据只是第一步；面对截断、畸形或故意构造的数据时，是返回一个可分类错误，还是直接panic让进程展开，决定了攻击影响会停在一笔请求，还是扩大到整个服务。Dusk本周为Phoenix Core的错误逐项补齐到Dusk Bytes结果的映射，并把可达的unwind路径替换成结构化错误，这属于典型的“失败也要可控”。
结构化错误的价值不只是日志更好看。节点收到一份无效数据后，可以根据错误类型拒绝、计数、限速或标记来源；钱包则能告诉用户是长度错误、解密失败还是格式不支持。如果所有异常都变成同一个崩溃，运维系统只能看到进程退出，既无法区分恶意输入与普通损坏，也容易在自动重启后重复触发同一问题。
更值得注意的是错误映射必须完整。底层库新增一个错误分支，上层若用通配符草率处理，可能把本应拒绝的情况吞掉，或把内部细节暴露给外部。较稳妥的做法是枚举Phoenix Core每个可达错误，定义对应的Dusk Bytes结果，并用测试确认没有路径越过边界触发panic。对不可信输入，还要先做长度与格式检查，再进入昂贵的解密或曲线运算。
当然，“不崩溃”不等于输入有效，也不意味着旧的Phoenix交易重新开放。Boreas之后，主网已在指定边界停止接受新的Phoenix交易，但节点仍需保留历史解码与执行能力，才能同步和重放旧区块。
所以我认为@Dusk 这次错误处理加固，真正保护的是网络的故障半径。金融基础设施无法保证永远看不到坏数据，却可以保证坏数据只得到一个明确拒绝，而不会把无关用户一起拖下线。
@Dusk $DUSK #dusk