0

Let's say you have two miners: A and B.

Let's also say you have two transactions: one which increases a number at a smart contract by one (transaction X), and another which decreases the same number by one (transaction Y).

Miner A mines a block containing transaction X.

Miner B mines a block containing transaction Y.

So Miner A's view is that the smart contract number has incremented, and miner B's view is that the number has decremented. They have both updated the state of the address in their respective EVMs.

These blocks are broadcasted and nodes update their smart contract state accordingly. Eventually, let's say consensus is reached and Miner A comes out the "winner".

Are the state updates from Miner B then "rolled back" and the state update from Miner B applied?

Improve this question
0

2 Answers 2

Reset to default
1

Only the changes of A will be considered (there is nothing to roll-back since the changes of B are not considered in the new blockchain).

You are describing a fork, i.e. the situation in which we have different versions of the blockchain history and the state (one in which where there are the changes of A and one in which there are the changes of B).

Once we reach consensus (using a selection rule, e.g. the longest blockchain), then after a number of confirmation blocks, you can forget the blockchain that applied the changes of B.

You may find this answer interesting.

Improve this answer
4
  • But if a node receives Miner B's block first, wouldn't that node (after verifying the block), actually execute all the transactions within and change its own state?
    – Bastien
    Commented Nov 12, 2018 at 12:29
  • Yes, but you would have two different forks of the blockchain (for the sake of simplicity you can imagine them as two distinct copies of the blockchain and of the state) one in which the changes of A are performed and one in which B's changes are applied. When we reach consensus on the fork of A, we discard the changes applied in the fork of B.
    – Briomkez
    Commented Nov 12, 2018 at 14:38
  • I think I understand. The "unwanted" block(s) in the fork of B would just be thrown away and replaced by the blocks from the fork of A. Correct?
    – Bastien
    Commented Nov 12, 2018 at 14:55
  • Yes, literally the fork will be forgotten (after a number of confirmation blocks). Please see also my edit, I tried to add some info
    – Briomkez
    Commented Nov 12, 2018 at 17:08
0

It may be useful to read https://github.com/ethereum/wiki/wiki/Design-Rationale#uncle-incentivization and https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/

Improve this answer
1
  • 1
    Link only answer are not recommended, if the page moved or the server is down no information can be used. It is better for answers to include the basic idea and use the link to expand the details.
    – Ismael ♦
    Commented Dec 12, 2018 at 3:53

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.