Question: How does a non-validating notary knows if a participant is allowed to spend a state?

[ivica7]

Since non-validating notaries in Corda are not performing input/output state validation of a transaction, how does a notary service know that a transaction initiator is allowed to spend specific input states?

For instance, in this simple cash example:

    State0{} -issueCashTX-> State1{owner:issuer, amount: 1000 USD}
                            -transferTX-> State2{owner:issuer,   amount: 500}
                                          State3{owner:CompanyA, amount: 500}

Smart Contract Rules validate that transfer transactions are only valid, if input state is owned by the transaction initiator and sum of output amounts is equal to sum of input amounts.

[Q]: How the non-validating notary knows that spending State1 is ok, since it has no idea about the validation rules?

[anthonykeenan]

The non-validating notary would check that State1 hadn't been 'spent'. I.e., it had not been confirmed as the input of another transaction, in order to prevent double spends. It would not validate the contract as it would not see the transaction information to be able to do that. The contract would be evaluated by the parties that participated in the transaction. For further information see here.

[ivica7]

@anthonykr3 thank you for your answer. One more question: If someone would be able to "steal" the State1 from the issuer's vault and create a fraudlent transaction on it, would he be able to consume State1 by letting the non-validating notary sign his transaction? The fraudlent transaction wouldn't make sense of course, but this way the state would be marked as consumed and the real issuer wouldn't be able to create a meaningful/valid transaction anymore?

[anthonykeenan]

Unless the person who 'stole' the state 'stole' the nodes private key as well, they wouldn't be able to sign the transaction to mvoe the state, so the other party to the tranasction would reject it. This stackoverflow answer here has a bit more info: https://stackoverflow.com/questions/47387485/in-corda-what-data-is-sent-to-a-non-validating-notary-service?rq=1

[ivica7]

If the goal of the fraudlent participant would only be to get State1 marked as consumed to block it for the original issuer, he could simply create an arbitrary transaction with State1 as input and send it to the non-validating notary. Since the notary is not able to validate himself, he would sign for the case that State1 is not spent yet. After this, the original issuer could not create a valid transaction anymore, since his State1 is spent already. Right?

[anthonykeenan]

Yes, however it also records the identity of the caller, so that it would be possible for the owner to raise a dispute and subsequently undo the commit of the input states - see here

[gendal]

Hi there. We offer both options for a reason. There are no absolutes in this business, only tradeoffs :) A validating notary protects you against the attack you describe but it needs to see the transaction, as you say. In situations where malicious submitters are not in your threat model (a far more common scenario than you might imagine for the problems we're solving with Corda!) then you can gain additional privacy by not asking the notary to validate. But you risk the situation you describe. However, in such cases, there is an extra line of defence that permissioned systems like Corda possess: all parties on the network are identified... so the nonvalidating notary knows WHICH party submitted the malicious transaction. So when the attack is discovered (by somebody trying to notarise the valid transaction), the notary can provide the identity of the attacker and their cunning scheme is revealed and falls apart..! (Also reducing the incentive/attractiveness of trying in the first place. Now: this model works because of the assumptions underpinning Corda and the threat model we face. In a fully public, pseudonymous, adversarial environment such as the public ethereum blockchain, it would be a less-effective strategy. It's why I write so much about how what we're doing and what the public Ethereum community are doing are so different (complementary, not competitive, in fact). It's when you try to apply Ethereum to enterprise scenarios away from the public chain that I think there are problems -and it's what I write about a lot.

[ivica7]

@gendal @anthonykr3 thank you very much for investing your time to write an answer! I appreciate it very much. The information that it is planed to be able to raise the disupte and revert the confirmation was the missing chunk of information for me. I can see that it can work in permissioned setups where identities are known, since sanctions can be enforced ("Identity at Stake").

[edrodven]

Unfortunately for our POW colleagues & friends the body of evidence confirms the benefits of a middle-man consensus protocol such as corda. Without the notaries it is easier for an open P2P network to be exploited by unethical parties.