-
Notifications
You must be signed in to change notification settings - Fork 20.5k
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
checkpointing broken in lightmode on mainnet #20134
Comments
Could you please try the latest master? There was an initialization error before and is fixed on master now. |
When is the next release? We usually roll up production versions with md5 hash announced on our end, you fixed in #20120 right? Looks ok, when is 1.9.6 going to release? |
@sidhujag Usually we have our biweekly release. In theory, we will have a new release in following 1 or 2 weeks. But it's Devcon very soon, not sure about it. |
@sidhujag Regarding the fix, yes it's 20120 |
ok please ping me when you have it and I will give an update on this ticket, enjoy Devcon! |
@sidhujag will do! |
@sidhujag 1.9.6 is released. Please check it. Close the issue now and feel free to reopen if issue still there. |
Tested ACK |
System information
Geth version:
1.9.5
OS & Version: OSX
Commit hash : stable
Expected behaviour
Mainnet to sync from hardcoded checkpoint in light mode
Actual behaviour
Mainnet in lightmode does not sync from hardcoded checkpoint, starts from 0 every time.
Steps to reproduce the behaviour
Backtrace (with verbosity enabled)
Note that if you have a hardcoded checkpoint you should never see that message if checkpointing is enabled.
I get the:
DEBUG[09-27|14:29:01.460|les/sync.go:130] Disable checkpoint syncing reason="empty checkpoint"
message meaning it will disable checkpoint and fall back to lightSync mode:
go-ethereum/les/sync.go
Line 129 in 32b07e8
where it will completely disable checkpointing, hardcoded/oracle or whatever.
Note the fix is to simply post (hack imo) a checkpoint on the mainnet oracle https://etherscan.io/address/0x9a9070028361f7aabeb3f2f2dc07f82c4a98a02a#events which was created 80 days ago but no checkpoints posted. Rinkeby has checkpoints and thus even though the checkpoints are older than the hardcoded one, it still relies on the hardcoded checkpoint because of the fact that checkpoints response is not empty.
The proper fix likely is to re-validate the logic that you should probably fallback to legacy checkpoint mode if no oracle checkpoints exists (what you had before this bug existed).
The text was updated successfully, but these errors were encountered: