我可以在Corda合同中使用验证注释(例如Spring,JPA或自定义注释)进行验证逻辑吗?

时间:2018-02-21 17:28:49

标签: corda

我想在验证Corda事务时向我的状态添加验证注释以避免样板。例如,我可能想要使用注释来注释我的状态,该注释会阻止使用负数创建状态:

class MyState(@Min(0) val amount: Int): ContractState {
    override val participants = listOf<AbstractParty>()
}

我希望在合同验证期间检查这些注释,并在违反任何注释时抛出异常。

Corda是否支持在合同验证中使用现有的验证注释库?我可以提供自己的自定义验证注释吗?

1 个答案:

答案 0 :(得分:2)

注释方法可以使代码更加清晰,尤其是在数据模型非常复杂的情况下。

现在您有两种选择

  1. 将验证器引擎嵌入您的cordapp中作为正常的依赖关系,在这种情况下,您要为您的成员提供实施,您必须信任您。

  2. 各个成员可以将他们选择的验证器引擎作为普通附件附加到事务,这将使合同验证期间类路径上的验证器类可用。在这种情况下,事务的每个交易对方负责检查附件散列是否列在他们先前已审计过的验证器的白名单中。

  3. 但是,我们想提醒您一些相关的风险,如下所示。

    1. 确定性。在未来,Corda将在确定性JVM(DJVM)中运行合同,其中任何非确定性代码都将无法执行。一些可用的JSR303验证器实现可能依赖于非确定性代码。重要的是要强调,一旦DJVM完全实施,现在可以工作的合同可能会在将来停止工作。 R3打算提供一个Gradle插件,它可以在构建期间验证确定性代码,这将有助于开发人员从合同中删除所有非确定性库。

    2. 一些JSR303实现(例如来自Hibernate的实现)非常繁重(大约120k行代码)。将来,合同类将由事务范围的类加载器加载,即,将从头开始重新加载类以验证每个事务。鉴于hibernate验证器需要大约20-30秒进行自我初始化,它将成为性能瓶颈。可能需要编写JSR的自定义实现,重新使用Hibernate的验证器逻辑,但要删除与合同上下文无关的更高级功能。

    3. 作为一般性建议,我们建议您考虑将一些繁重的工作转移到流量上,因为他们没有任何与DJVM相关的限制。

    4. 如果使用注释,Corda仍然需要某些形式的验证,这些验证不是由任何JSR303注释提供的,例如事务级别验证,例如匹配签名者与参与者等。因此,某些合同代码仍然必须写的。

    5. 您必须为成员提供审核和验证所选验证实施的机制。因为这将成为他们作为签约方的合同的一部分。如果发现验证器将来发生故障,则值得讨论这种情况。

    6. 我们非常喜欢使用JSR303注释进行数据模型验证的想法,我们将帮助您完成实现它的过程,因此如果您遇到任何问题,请告诉我们。