Verus项目中关于扩展性相等证明的优化探讨

在形式化验证工具Verus的开发过程中，我们遇到了一个关于序列相等性证明的有趣现象。当开发者尝试证明两个序列相等时，即使已经证明了它们的长度相同且所有对应元素相等，验证有时仍无法自动通过。本文将深入分析这一现象的技术背景，并探讨Verus可以做出的改进方向。

问题现象

考虑以下典型场景：我们需要证明两个序列a和b的前k个元素相等。开发者通常会：

1. 证明两个子序列长度相等
2. 证明所有对应位置的元素相等

然而，即使完成了这两步证明，Verus有时仍无法自动推导出序列相等的结论。有趣的是，如果在证明体末尾添加一个看似冗余的assert语句，验证反而能够通过。

技术原理

这种现象源于Verus内部处理序列相等性的机制。Verus默认使用"严格相等"，而序列这种数据结构通常需要"扩展性相等"（extensional equality）的判断逻辑。扩展性相等的核心是：

• 长度相同
• 所有对应位置的元素相同

当开发者显式写出assert语句时，Verus会尝试使用扩展性相等的推理策略。但在仅依赖postcondition的情况下，这个策略有时不会被自动触发。

当前解决方案的局限性

目前开发者有三种应对方式：

1. 添加冗余的assert语句
2. 使用特殊的=~=运算符
3. 手动写出完整的元素级证明

特别是，我们发现assert(x==y)和assert(x==y) by {}的行为不一致，这违反了最小惊讶原则。前者会自动触发扩展性相等，后者却不会。

改进建议

Verus可以在以下方面进行优化：

1. 统一assert的行为：确保assert(x)和assert(x) by {}在触发扩展性相等方面表现一致

2. 智能postcondition处理：当postcondition中出现序列相等判断时，自动尝试扩展性相等的证明策略

3. 更好的错误提示：当序列相等证明失败时，提示开发者尝试扩展性相等的可能性

4. 文档完善：在教程中明确说明序列相等证明的最佳实践

实际影响

这个问题看似微小，但在实际验证工作中会产生显著影响：

• 增加了不必要的验证负担
• 导致开发者采用次优的验证策略
• 降低了验证代码的可读性

通过优化这一机制，可以显著提升Verus的用户体验和验证效率，特别是在处理复杂数据结构时。

结论

Verus作为先进的形式化验证工具，在处理数据结构相等性证明方面仍有优化空间。通过改进扩展性相等的自动触发机制，可以使验证过程更加自然流畅，减少开发者的认知负担。这不仅是技术实现上的改进，更是对验证体验的重要提升。