-
Notifications
You must be signed in to change notification settings - Fork 6
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
Poison block handling: Interrupt block validation to produce block #1039
Comments
heifner
added a commit
that referenced
this issue
Nov 20, 2024
heifner
added a commit
that referenced
this issue
Nov 21, 2024
bhazzard
changed the title
Interrupt block validation to produce block
Poison block handling: Interrupt block validation to produce block
Nov 21, 2024
heifner
added a commit
that referenced
this issue
Nov 22, 2024
heifner
added a commit
that referenced
this issue
Nov 22, 2024
heifner
added a commit
that referenced
this issue
Nov 22, 2024
heifner
added a commit
that referenced
this issue
Nov 22, 2024
heifner
added a commit
that referenced
this issue
Nov 22, 2024
heifner
added a commit
that referenced
this issue
Nov 25, 2024
…r new best head to be received from network if forkdb contains a poison block
heifner
added a commit
that referenced
this issue
Nov 26, 2024
heifner
added a commit
that referenced
this issue
Nov 26, 2024
heifner
added a commit
that referenced
this issue
Nov 26, 2024
heifner
added a commit
that referenced
this issue
Nov 27, 2024
heifner
added a commit
that referenced
this issue
Nov 27, 2024
heifner
added a commit
that referenced
this issue
Nov 27, 2024
…le to work through the fork switches and apply any forked out blocks
heifner
added a commit
that referenced
this issue
Dec 4, 2024
heifner
added a commit
that referenced
this issue
Dec 4, 2024
heifner
added a commit
that referenced
this issue
Dec 5, 2024
…dation Interrupt block validation on new best head
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A BP will always produce on schedule with this approach. The produced block should nominally be a new best-head on all other nodes since it will have a higher block timestamp. When the newly produced block comes into nodeos, it will determine it is a new best-head, interrupt validation of the current block, and switch over to validating the new fork which includes the block. This provides a natural recovery when a node is stuck validating a block.
This approach brings back the old drop-late-blocks functionality as a BP will begin producing blocks immediately when scheduled to do so. If the BP is in the middle of validating a block from the previous BP, it will interrupt that validation and produce on the previous block. We could potentially provide a bit of time for validation to potentially complete before interruption. However, it is simpler to just interrupt immediately. BPs already have a mechanism for making sure their blocks are received by the next BP in time.
This also provides faster switching to a better fork under normal conditions.
In all cases interrupted blocks will not be removed from the fork-database. In nominal cases, the interrupted block will be purged from the fork-database when irreversible moves so that the branch is purged. However, the block could potentially be used again if a fork switch to its branch is received from the network. In that situation the node will begin validating the block no matter how long it takes; or until it receives yet another better block to validate.
The text was updated successfully, but these errors were encountered: