-
Notifications
You must be signed in to change notification settings - Fork 754
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
[Denial of Service] "Opted to halt, unprepared for protocol change" #269
Comments
Worth noting for the record that halting is an opt-in thing. It's actually very useful for a full node to prevent it following a non-upgraded chain if it misses an update and then having to completely resync to get back to the correct chain because it no longer has world states old enough to handle the very large reorg. Also, the recommended protocol version is updated prior to the required protocol version being updated which causes op-geth to log an error about being out of date but not halt.
I believe you can achieve a policy of only ever logging by using the options from
You can instruct it to load protocol versions but not opt in to rollup halt and op-node will use the JSON-RPC call to also check that its op-geth is up to date. |
How is this opt-in? I did not set the |
If you look at Lines 616 to 625 in 425e757
s.config.RollupHaltOnIncompatibleProtocolVersion is not set, it does not halt. That config var is set in Line 1848 in 352fbe6
rollup.halt flag which has now default value: Lines 888 to 892 in 352fbe6
So it's off by default. If op-geth halted then something must have set that flag. What version of op-geth were you running? |
Hey could we maybe not automatically halt when a major version change is encountered and just log an error instead?
This is the opposite of designing your distributed system to be antifragile.
op-geth/eth/backend.go
Lines 612 to 640 in 336d284
The text was updated successfully, but these errors were encountered: