我想向我的状态添加验证注释，以避免使用Corda Transactions时的样板。例如，我可能想用注释来注释我的状态，以防止状态以负数为负数：
class MyState(@Min(0) val amount: Int): ContractState {
override val participants = listOf<AbstractParty>()
}
我想在合同验证期间检查这些注释，并在违反任何注释的情况下施加例外。
Corda是否支持合同验证中现有验证注释库的使用？我可以提供自己的自定义验证注释吗？
一种注释方法将使代码更加清晰，尤其是在数据模型非常复杂的情况下。
现在您有两个选择
-
将验证器引擎嵌入您的cordapp中是正常的依赖性，在这种情况下，您将为您的成员提供实施，谁必须信任您。
-
各个成员可以将其选择的验证器引擎连接到交易中，作为正常附件，这将使合同验证期间的验证者类可在classPath上可用。在这种情况下，每个交易的对手都负责检查附件哈希列在他们先前已审核的验证者的白名单中。
但是，我们想警告您一些相关的风险，这些风险如下列出。
-
确定性。将来，Corda将在确定性的JVM(DJVM(内运行合同，任何非确定性代码都将无法执行。一些可用的JSR303验证器实现可能依赖于非确定性代码。重要的是要强调，一旦DJVM充分实施，现在确实有效的合同可能会在将来停止工作。R3打算提供一个Gradle插件，该插件将在构建时间内验证确定性代码，这将帮助开发人员从合同中消除所有非确定性库。
-
一些JSR303实现(例如Hibernate的实现(非常重(大约120k的代码线(。将来，合同类将由交易范围的classloader加载，即，将从划痕中重新加载类以验证每次交易。鉴于冬眠验证器需要大约20-30秒才能进行自我定位，因此它将成为性能瓶颈。可能需要编写JSR重新使用Hibernate的验证器逻辑的自定义实现，但要删除在合同上下文中无关紧要的更高级功能。
-
作为一般建议，我们鼓励您考虑将一些繁重的升降机移至流动，因为它们没有任何与DJVM相关的限制。
-
如果使用注释，Corda仍然需要某种形式的验证，这些验证不提供任何JSR303注释，例如交易级别验证，例如匹配签名者与参与者等。因此，某些合同代码仍然必须必须写。
-
您必须为您的成员提供审核和验证所选验证实现的机制。由于这将构成他们作为签署方的合同的一部分。如果发现验证者将来有缺陷，那么值得讨论。
我们真的很喜欢使用JSR303注释进行数据模型验证的想法，我们将帮助您完成实施它的旅程，因此，如果您遇到任何问题，请告诉我们。