在相同类型的 Corda 状态中强制执行属性值的唯一性？答案

【问题标题】：Enforcing the uniqueness of property values across Corda states of the same type?在相同类型的 Corda 状态中强制执行属性值的唯一性？
【发布时间】：2018-09-20 04:46:39
【问题描述】：

我如何确保一个状态的属性对于账本上该状态的所有实例都是唯一的？

假设我有一个PersonState 具有属性name 和ssn（社会安全号码），如何确保没有PersonState 被写入具有与任何ssn 值相同的分类帐PersonState 已经存在于账本上？

如果PersonState 是一个数据库表，而name 和ssn 是列，那么在ssn 上指定唯一性约束很容易，但我不知道如何使用Corda 来做到这一点。

新交易的提议者会在账本上产生一个新的PersonState，显然可以在构建提议时检查现有状态。但这仅在初始提案时确认了唯一性-我看不出如何确保事物在相关流程的生命周期内保持唯一性，以使该值始终保证是唯一的直到结束finality flow（或者如果它不再是唯一的，则保证在此时被拒绝）？

我试图思考是否可以通过公证人以某种方式强制执行的预言机来实施某种独特的价值服务？也许我可以围绕这些想法想出一些东西（可能存在一些致命的逻辑缺陷），但如果 Corda 已经为这类事情制定了一些既定流程，那显然会更好。

PS 是的，我知道将 SSN 存储到分类帐可能是个坏主意，这只是一个示例。

【问题讨论】：

标签： corda

【解决方案1】：

将这项工作委托给公证人有几个缺点：

通过强制使用验证公证人构成隐私泄露。在大多数部署中，您可能希望使用非验证公证人
这意味着只有运行自定义流程的特殊公证人才能用于对这些 SSN 交易进行公证
它排除了一些分布式公证人算法，因为集群中的所有公证人都必须就 SSN 唯一性和事务唯一性达成共识

在这种情况下，我更喜欢预言机。预言机将保留已分配 SSN 的内部数据库，并且仅对以前未使用过 SSN 的交易进行签名。您可以使用撕下来防止预言机看到交易的其余部分（请参阅https://docs.corda.net/key-concepts-oracles.html#hiding-data），这样可以保护隐私。

预言机只需要签署发行 - 合约规则可以确保一个状态的 SSN 在发行后不会被修改。

【讨论】：

在“大多数部署中，您希望使用非验证公证人”真的是这样吗？当交易提议者找到需要签署交易的声明时，任何参与者都可以声明他们只需要签署给定的交易，并且非验证公证人将接受这一点。这对于“大多数部署”真的可以接受吗？在所有参与者都很少且很大的系统中，例如银行，这种行为（无论是故意的还是偶然的）都会受到惩罚和解决，在参与者较小且来来往往的系统中，这种行为似乎是一个更大的问题？

【解决方案2】：

我认为您需要在验证公证人流程中检查此 ssn 的唯一性。每次您收到一笔交易时，您都会通过 Corda 中的公证人检查双花，因此在这种情况下，他只需在 FLow 的每一步检查他是否还没有收到带有特殊规则的 PersonState 状态应用于此ssn。

请注意，这会将这些数据泄露给公证人。

【讨论】：

【解决方案3】：

用户@Anoop 发布了一个答案，该答案因我不清楚的原因而被删除。以下是他的答案的扩展。

Corda API docs for persistence 描述了您如何使用 JPA 来指定您的状态如何映射到底层保险库数据库。

他们以PersistentCashState 为例 - 如果您查看它，您会看到：

class PersistentCashState(
        /** X500Name of owner party **/
        @Column(name = "owner_name")
        var owner: AbstractParty,

        @Column(name = "pennies")
        var pennies: Long,
        ...

注意：以上是 Kotlin 而不是 Java。

如您所见，使用了 @Column 注释 - 如果您查看 @Columndocumentation，您会发现您可以使用 unique=true 将列标记为唯一：

列是否是唯一键。这是表级别的 UniqueConstraint 注释的快捷方式，在唯一键约束仅对应于单个列时很有用。除了主键映射所需的任何约束以及在表级别指定的约束之外，此约束也适用。

我还没有尝试过这个，看看它在实践中是如何工作的。仅当您使用公证人时，使用这样的约束才有意义 - 因为只有公证人才能保证所有各方都尊重的排序。 IE。如果您不使用公证人，一方可能会有效地提交涉及具有给定ssn 的状态的交易，而另一方可能首先提交涉及相同ssn 的不同交易。

我不确定当 Notary 尝试 FinalityFlow 然后在将状态持久保存到数据库时失败时会发生什么。但是这种方法听起来比我迄今为止看到的任何其他方法都更少受竞争条件的影响（即首先检查保险库，然后希望另一个线程中没有什么比你坚持一个涉及应该是唯一的值的状态），即听起来像它应该实现所需的事务性。

【讨论】：