data inconsistency due to private transactions

hitarshi commented 6 years ago

System information

Geth version: `geth 1.6

OS & Version: Ubuntu 16.04

Branch, Commit Hash or Release: git status - origin/master

Actual behaviour

Quorum-RAFT network comprising of 3 nodes (node-A, node-B, node-C) Private contract is deployed on all 3 nodes 2 accounts (acc1 and acc2) have been initialized with 100 tokens each

1) Initialized value on all nodes (acc1=100, acc2=100)

2) Private transaction is executed between A and B where 50 tokens is transferred from acc1 to acc2. Transaction succeeds and account balance on nodes A and B is observed as (acc1=50, acc2=150). Account balance on node C (acc1=100, acc2=100) as it was not part of this transaction

3) Private transaction is executed between B and C where 150 tokens is transferred from acc2 to acc1. Transaction succeeds on node B and resultant balance is (acc1=200, acc2=0) Transaction fails on node C because it didn't have the latest balance of acc2 in its local ledger

Expected behaviour

How do we prevent such ledger inconsistencies resulting because of private transactions? Will this be prevented or handled at the protocol layer?

jpmsam commented 6 years ago

@hitarshi currently, there is no consensus on the private state. We are expecting this to be managed on the application level by sending the private transaction to the correct nodes and it can use the eth_storageRoot RPC call to verify the state. We are planning to improve this on the protocol level in a future release.

shun-tak commented 5 years ago

any updates or plans on this?

fixanoid commented 5 years ago

@shun-tak this is an area we are working on and will have some suggested solutions in the future. There is a way to check that the state is consistent through an off-chain API: eth_storageRoot described here: https://docs.goquorum.com/en/latest/Getting%20Started/api/

yashukla47 commented 4 years ago

Any solid solution for this Issue ?

Consensys / quorum