Corda中Vault查询与交易输入状态的旧数据反序列化差异及疑问

问题1：Vault查询与交易输入状态在旧数据Blob反序列化上的差异 #

• Vault查询的反序列化逻辑：Corda的Vault存储状态时，会同时保存状态的完整序列化Blob和基于自定义Schema的结构化数据库记录。执行Vault查询时，多数场景下会直接读取结构化的数据库字段匹配查询条件、返回结果，不会完整反序列化原始状态Blob。即便Blob中包含已移除的字段，查询过程无需解析这些内容，因此不会触发序列化异常。
• 交易输入的反序列化逻辑：当旧状态作为交易输入时，Corda必须完整反序列化原始状态Blob，重建出完整的State对象，用于合约验证、流程执行等核心逻辑。这个过程会严格校验类结构与序列化Blob的匹配性，一旦Blob中存在当前State类未定义的字段，就会触发NotSerializableException。

问题2：为何可空字段移除也会出现序列化错误？ #

你提到的文档说明“可空字段移除无需构造函数”是有前提的：仅当旧数据中该可空字段**从未被赋值（始终为null）**时，Kryo序列化框架会跳过该字段的序列化，Blob中不会包含该字段的元数据。这种情况下，移除字段后反序列化不会有问题。

但如果旧数据中该可空字段曾经被赋值（即使后续又设为null），或者序列化配置强制写入可空字段的元数据，那么旧的Blob中会包含该字段的名称和类型信息。当当前State类移除该字段后，Kryo反序列化时无法找到对应的字段匹配这些元数据，也没有@DeprecatedConstructorForDeserialization注解的构造函数接收这些额外数据，就会抛出序列化异常。

内容的提问来源于stack exchange，提问作者Benjamin