Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid erronous or incomplete state changes in database #91

Closed
nicksavers opened this issue Aug 24, 2014 · 3 comments
Closed

Avoid erronous or incomplete state changes in database #91

nicksavers opened this issue Aug 24, 2014 · 3 comments
Labels

Comments

@nicksavers
Copy link
Contributor

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.

@nicksavers nicksavers added the bug label Aug 24, 2014
@romanman
Copy link
Contributor

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
Copy link
Contributor

We should probably do that in an ACID like transaction operation

@nicksavers
Copy link
Contributor Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants