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
client invalidateheader and resetchainhead #3618
Conversation
the header is specified by its (cycle)hash?
what is a header extension? what does reapplying a header mean? is this updating a constant amount of state?
can this rewind beyond the horizon, if the node saw preceding blocks? |
No guarantees to this working 100% correctly and it may brick you local That said, the following works for me -
The node then transitions into "header sync" when the syncer process next runs (a few seconds later). |
Yes by hash.
We interact with the header MMR via a "header extension". This allows us to rewind/truncate and append new data to the header MMR.
No sure yet. I have only experimented with rewinding within the horizon. |
|
|
We can now do the following -
We maintain a local set of invalid headers (denylist). We can simply invalidate a particular chain fork by identifying a header on the fork and invalidating it via By resetting chain state to an earlier header via A simple node restart will clear out the current "denylist". This should only ever be a temporary measure to help the local node navigate to the correct chain fork. Once on the correct "winning" fork the local "denylist" can be safely discarded. |
as it is readonly when interacting with txhashset extension
needs error handling etc.
d4f06f8
to
c12ea53
Compare
is this one ready for assignees? |
Going to merge this shortly to |
Resolves #3607
Experimenting with a different approach here to resolving the various issues around sync and how it interacts with a chain fork.
This PR adds an endpoint and handler for
resetchainhead
via the owner api.This will take a block hash and will do something roughly along the following lines -
header_head
to the existinghead
via "rewind and reapply" on the header extensionhead
(andheader_head
consistently) via "rewind and reapply" on txhashset extension (full blocks)The should result in the ability to arbitrarily "rewind" or "reset" to an alternative block header.
Rather than trying to resolve all edge cases related to sync I'm proposing it makes more sense to have additional flexibility and allow a node operator to "manually" work around a fork via this api endpoint.
If we can get this working robustly then there is an additional api endpoint that could be added -
invalidateheader
These could be used together to invalidate one chain fork and then reset the local chain to a header on an alternative fork.
I believe these would allow most fork scenarios to be recovered from reasonably gracefully albeit manually.
If this approach works then we may consider extending this and doing the "reset" in a more automated fashion without api involvement.
Non-archival node should be able to "reset" to prior to the horizon by -
head
(andtail
)This would potentially be a convenient way of retaining headers (up to reset point) locally while still resyncing state.
TODO