0

I was going through the quorum documentation and stumbled upon how private transactions are validated in quorum. Take the following example where there are four nodes - Node A, Node B, Node C and Node D.Consider the following steps -

1.Node A does a private transaction(assume TX1) with Node B. At this point Node A and Node B have their private tries updated to reflect the private transaction.

2. Node B uses the output of TX1 and does a private transaction with Node C. Since Node C was unaware of the TX1 in the first place how does it validate that TX1 is an actual valid transaction?

Does Node B send the un-encrypted payload of TX1 to Node C so that it can validate the transaction?If yes, then isn't Node A's identity revealed in this scenario? If not, then Node B can dupe Node C by sending using the output of TX1 to first send it to Node D and then doing a double spend and sending it to Node C after it has been sent to Node D. In essence how is a chain of private transactions validated?

Improve this question
3
  • could you add a simple example with numbers and names, for me it is not clear what do you mean with NodeB uses the output of tx1? Ethereum is state based blockchain and not UTXOs like bitcoin.
    – Majd TL
    Jul 15, 2019 at 10:45
  • So in a simple scenario how does quorum prevent double spends? Assume Node A has 500 units of Asset A. Say Node A now sends these 500 units to Node B and Node C as well. How does quorum ensure it doesn't happen?
    – Shubham Saxena
    Jul 15, 2019 at 12:57
  • C will reject it, because that asset does not exit for C. it is hard to explain, if C is not a part of the "private state" from the beginning, then C cannot be part of it later. In other words if you have a private smart contract let say ERC20 only between Node A and B, then you cannot add C later, and from the view point of C the contract almost does not exit (and to simplify, it means that everyone have 0 Tokens).
    – Majd TL
    Jul 16, 2019 at 9:16

1 Answer 1

Reset to default
0

In Quorum, as of v2.2.4, private state txns are not validated by the block minters. In your scenario, unless there is a regulator / god node that sees all transactions, its going to be surprisingly hard to guarantee private state coherence / sync as each node has different state for the private contract the nodes are communicating privately over.

We do offer some tools that make it a bit easier to maintain sync or figure out that something went wrong and there are some great examples of how to do it properly with quorum. First, the best example we've seen is the 5NodeRTGS example based on quorum-examples: https://github.com/bacen/quorum-examples/tree/master/examples/5nodesRTGS.

And for sync validation, Quorum exposes a new API that allows one to compare state root of a contract. API is called eht_storageRoot and its documented here: http://docs.goquorum.com/en/latest/Getting%20Started/api/#json-rpc-privacy-api-reference

Hope this helps, and feel free to stop by our Slack for more in depth explanations.

Improve this answer
2
  • So essentially we are saying that to keep a check on double spends, there needs to exist a regulator sort of node which will receive all transactions and hence can validate and thereby prevent double spends. But there is no way we can guarantee that a node forwards a transaction to this god node/regulator right?
    – Shubham Saxena
    Jul 22, 2019 at 7:30
  • Well, smart contracts can pretty well define the rules to prevent double spends, but a validation may be needed depending on the relationship of the parties. Outlined above is how one would go about checking the synchronicity (via storageRoot), or through having an authority that sees everything (RTGS regulator node).
    – fixanoid
    Jul 22, 2019 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.