Avoid erronous or incomplete state changes in database

[nicksavers]

The ideal is to be able to download the chain, shutdown (either because the block or tx is invalid or because of other reasons) and try again later after restarting, perhaps having fixed a bug.

In some scenario's this doesn't happen. If a block or transactions produces an incorrect result (post tx state or block state root conflicts with the state given in the block) then the state changes are not rolled back. This makes it difficult to stop processing the chain and restarting again later.

Changes to the state should only be applied after all transactions in a block (and the block-reward) have been processed correctly and all the post tx states and block state root are as expected.

[romanman]

The way to reproduce this issue, is like this in the link you have db for 10,000 blocks loaded from start , if the client will go on from it it will bump to wrong state on no. 10929 block where loaded from the start it's on the no. 12371

https://app.box.com/s/z0bcp4usgaq5j6kin0eh

[alonmuroch]

We should probably do that in an ACID like transaction operation

[nicksavers]

@romanman
The issue you describe is not exactly the same. This issue is about ethereumj while calculating the postTx state, is directly updating the database, so when you close the application mid-processing a block.. it means the database is now corrupt.

Does the state conflict at no. 10929 still occur for you while loading from a database containing 10,000 blocks?