Customising Notary Logic


(Gavan) #1

How would I go about customising the logic for a notary service?

For example when someone submits an health insurance claim I would like the notary to consider the claim to be a double spend if a similar claim has been made within the past month. But if a similar claim has been made a year ago, then this should be ok.

Also is it possible for the notary to just change the state and then sign it. Like say set a flag that this transaction could possibly be a double spend.


(Mike Hearn) #2

Notaries are defined to never accept double spends. If you built a notary that did, things would break. Notaries also cannot change states before signing (it would invalidate all other signatures). They aren’t meant to hold that kind of app specific logic. So, I’d forget about notaries. They aren’t designed to detect similar transactions.

Now, can we do what you want in other ways? Sure!

Consider that in an insurance use case, every claim is going to have a unique claim ID. That includes claims that are duplicates, until their duplicate-ness is detected. So the lifecycle of a claim is going to need to include something like “closing as a duplicate of claim C”. You could do this by putting logic like this in your contract code:

  • If there are two input claims
  • And a command that says this transaction is resolving duplicates
  • And both input claims appear to be the same (or very similar) other than the claim ID
  • Then there must be only one output claim, which is a copy of one of the input claims

This would let you delete a claim from the ledger, in a single transaction. The degree of similarity required can be encoded into the contract.

However, I would question whether even this is the right thing to do. Because the smart contract code is intended to govern shared logic. But surely if you’re an insurance company, only you can decide if two claims from your customers are duplicates, and it’s entirely your own concern - not something any other institution on the ledger would care about.

If the parties who are sharing the ledger in this case include end users then I’d understand, but right now Corda isn’t really designed for ordinary consumers to directly access the ledger. It could be done technically, but typically those users will expect someone to interact with the ledger for them (as getting access to the ledger involves downloading software, setting it up, getting an identity issued by the network operator etc).


(Gavan) #4

Hi Mike,

Thanks for the reply, so I understand a notary is not really the way to go for this.

The specific problem I am looking at is a double claim. Where Client A will seek to make a claim for the same incident from both Insurance Company A and Insurance Company B.

I would like to implement a way where whenever a claim is submitted, it is sent to some kind of notary/regulator who will be able to tell you if a similar claim has already been submitted to another Insurance Company.

One key issue here is that we don’t want the specific details of every claim to be broadcast to every participant in the network. We just want to know if it’s a double claim.

So as a double claim is technically not a double spend would it be feasible to have a regulator run as a node as opposed to a notary? And so I would need to create a flow where the claim is passed to the regulator node, which runs some logic to check for a double claim.
And then in this case I wouldn’t really even need a notary since the regulator node would be the one handling consensus.


(Mike Hearn) #5

Yes, that’s an interesting use case. I didn’t actually realise that was a problem, if you have two policies from two companies why would they not both pay out? The issue here is policies that say you can’t do that but people do anyway, knowing the companies can’t detect violations of that part of the agreement?

So, as we established, a notary/consensus cluster in Corda isn’t the right place to do this. They are designed for very different tsaks. The two approaches are to broadcast the claims to every insurance firm in the network (not every participant), which is what “Data distribution groups” are for, or to have a central meeting point that fuzzy matches claims and deduplicates them.

Is “regulator” the right term to use here? That makes me think of a government agency. I’m not sure regulators are normally providing business services to their industry, or would this be an exception?

Perhaps what you want here is more like “matcher” or “matching service”.

A few questions pop to mind:

  1. Are there any institutions that would be trusted with the details of every claim for deduplication purposes? Is there enough trust in the industry to pull that off? If so then implementing it on top of Corda is quite straightforward.
  2. If not, how complex is the matching process? Can cryptographic techniques square the circle here, by (for example) allowing the data matching process to be run inside a trusted computing enclave? That would eliminate the need to trust humans as long as the software to do the matching is sufficient. How complex does the matching process have to be?
  3. If the answer to (2) is “yes that’s feasible” what sort of market size are we talking about here? Is it a product that’d make sense for a company to develop, is there enough money in this kind of service to be worth it?