0

In terms of go-ethereum code, transaction errors can be grouped into (I made up the terminology) several categories by their effect on state transition.

  1. System errors: like database connection issues. These, understandably, lead to cancelling the whole state transition. Retry follows.
  2. Contract errors: like stack overflows or out of gas. These lead to reverting the transaction progress, still applying the gas fee and other post-processing, and proceeding with the next transactions.
  3. Consensus errors: like invalid transaction nonce or unsuccessful balance transfer (only the initial one; doesn't apply for any following nested "insufficient balance for transfer"). These errors lead to discarding the whole state transition and marking the block invalid.

The question is why category (3) needs to be so fatal that the whole block would be rendered invalid? Intuitively seems like those are still "client" errors that could be scoped to the individual transactions, allowing the others to be executed.

Improve this question
1

It is a miner mistake to allow invalid transactions. A block with invalid transactions is using blockchain space with something useless for infinite time.

  • If the user doesn't have enough balance the miner cannot charge a fee.
  • nonces serve the purpose of having a defined execution order and protecting from certain attacks like transaction replay.
Improve this answer
  • >> It is a miner mistake to allow invalid transactions -- If there were no fatal transaction errors, it wouldn't have been a mistake >>A block with invalid transactions is using blockchain space with something useless for infinite time -- Transactions with contract errors are useless too by this token >> If the user doesn't have enough balance the miner cannot charge a fee -- Yes it can. Say the unsuccessful transfer amount were 1000 eth, and the gas fee costs 100 – oleg.lukyrych Oct 2 '19 at 20:18
  • >>>> nonces serve the purpose of having a defined execution order and protecting from certain attacks like transaction replay ==== You could still fail those transactions right away, just not canceling the whole block – oleg.lukyrych Oct 2 '19 at 20:20
  • I don't think this post has answered the question – oleg.lukyrych Oct 2 '19 at 20:21
  • However, I like the point about minimizing junk. Probably this was a(the) reason why the designed it this way. Upvote. – oleg.lukyrych Oct 2 '19 at 21:16
  • Who will you charge if the sender doesn't have funds? If you send two consecutive transactions a miner can reorder knowing the second one will fail and force you to pay extra fees. – Ismael Oct 2 '19 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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