Ethereum walk-through

Question

Would the following story line be a fair approximation of how Ethereum would work in this simplistic scenario?

1. Simple network with just three nodes: N1, N2 and N3
2. N1 writes a contract that initiates a counter to value 0 and allows N1 and N2 (but not N3) to increment this counter.
3. N1 publishes the contract and as a result all the nodes now have a copy of the contract, associated transactions, and resulting state (counter value = 0).
4. N1 calls the counter function, and as a result, N1, N2 and N3 run the local copy of the contract. Each of them now have the same value of the contract state (counter = 1).
5. Dice are rolled and one of the nodes (N1, N2 or N3) gets selected at random and given the "authority" to update the transaction and resulting state associated with the contract on the public shared ledger (blockchain).
6. N3 is upset that he's been left out. He tries to call the increment function by publishing a transaction request, but the contract (on N1, N2 and N3) rejects this.
7. N3 tries outsmart the system, waits patiently until the dice roll to his favor and can add a block to the chain. In this step, however, N3 adds a bogus transaction leading to an invalid increment on the counter.

What happens after step 7 and what prevents the wrong state from propagating further?

• Does the miner that mines the next block need to check that the transactions included by the previous miner are valid, or
• Does the miner that processes the next transaction on the contract need to check that the transaction included by the previous miner are valid, or
• something else?

If it is any of the first two above does the new miner simply ignore the bogus transaction and roll back to the previous valid state (after cross-checking the associated transactions)?

If anyone gets to read this far please note that there are effectively 3 questions above (each of them marked in bold).

Answer 1

1. Yes
2. When a new block is received, it should be validated that the transactions included match the advertised state. Failing verification, the block would be discarded instead of propagating to other nodes
3. Since in this scenario, N3 directly writes a bogus transaction in the block they mine, it never exists in the transaction pool. The malformed transaction is discarded because the block is discarded. No rollback is necessary because the block would be invalid and not committed to the HEAD state. Of course, clients could implement a psuedo "pending" state that represents unconfirmed transactions, but some concepts have ambiguous meaning, such as the "block hash". The particular way in which they achieve this would be an implementation detail of that particular client.