Plutus UPLC 版本间评估结果差异问题分析

问题背景

在Plutus项目中，用户nau报告了一个关于UPLC（Untyped Plutus Core）评估器在不同版本间行为差异的问题。具体表现为：当使用1.30.0.0版本和1.31.0.0版本的uplc工具评估同一个Plutus V1脚本时，得到了不同的评估结果。

技术细节

该问题涉及到一个Plutus V1脚本的评估过程，该脚本通过unsafeFromBuiltinData函数将ScriptContext转换为内置数据。用户提供了一个完全应用的flat十六进制编码脚本，并使用两种版本的uplc工具进行评估。

评估结果的主要差异体现在lambda表达式的变量引用上：

• 1.30.0.0版本输出：(delay (lam i2 (lam i3 i2)))
• 1.31.0.0版本输出：(delay (lam i2 (lam i3 i3)))

这种差异看似微小，但实际上反映了变量绑定和引用机制的变化，可能对程序语义产生重要影响。

问题根源

经过项目维护者kwwxm和effectfully的调查，发现问题的根源在于UPLC AST中名称表示方式的变更：

1. UPLC AST内部使用两种名称表示形式：

   • 字符串与唯一标识符配对
   • 字符串与de Bruijn索引配对

2. 在1.31.0.0版本中，默认的打印模式从显示唯一ID变为了显示de Bruijn索引（或反之），这导致了输出结果的差异。

3. 用户没有指定--print-mode Classic选项，导致使用了新的默认打印模式。

解决方案

要获得一致的评估结果，用户应该：

1. 在1.31.0.0及更高版本中明确指定--print-mode Classic选项
2. 这样将强制使用传统的打印方式，确保与早期版本的结果一致

深入分析

Simple打印模式虽然在某些场景下有用（如golden测试中避免因变量重排序导致的测试变更），但在常规使用中可能会产生"不正确"的UPLC输出。这是因为：

1. 它会忽略变量的唯一标识符
2. 可能导致变量捕获问题
3. 在重新解析时可能创建新的唯一标识符

因此，对于需要精确结果的场景，建议始终使用Classic打印模式。

结论

这个问题揭示了Plutus UPLC实现中名称处理和打印模式的重要细节。虽然表面上是打印输出的差异，但实际上反映了底层AST表示和变量绑定机制的复杂性。开发者在跨版本使用UPLC工具时，应当注意打印模式的配置，以确保结果的一致性和正确性。

项目维护者已经意识到这个问题，并计划进一步改进打印模式的处理逻辑，使其在不同场景下的行为更加明确和一致。