-
Notifications
You must be signed in to change notification settings - Fork 2.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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Store batch proposal to disk on shutdown #3171
Comments
Another, more resilient but slower solution is to persist the pending batch proposal to disk before it is broadcasted (we cannot guarantee a clean shutdown, namely when being |
You'd want to also store the signatures that you've received for that proposal, because peers won't resign a proposal they've already seen. So just storing a proposal before it is broadcasted is not enough, you'd likely have to do it every time you receive a new signature as well. |
Happy to tackle this one, just a few questions:
|
|
I've taken an initial stab at it, and I have some issues with this approach:
That shouldn't happen by design, because we're using atomic writes; we would have to deviate from that in order to cause a storage corruption. Summing up: while it is possible to go around the cyclic dependency, it would either require a refactoring effort across a few crates, or a conversion between 2 different Your call @raychu86. |
The DataMap approach is still preferred for a unified storage. We used to use the Blob ( |
Ah yes, the value is not an issue, it's more the key that is not really meaningful for a single blob, and while it can be worked around, my only ideas are either things that would be weird at first glance (e.g. using the unit |
To share additional context on this topic: For context, during the ZKSecurity audit of the BFT, the priority was Now, there are 2 practical ways to resolve this:
|
馃殌 Feature
Store the current proposal to DB on shutdown.
Currently when a node shutdowns/reboots while a batch proposal is still in progress, the proposal is dropped. Once the node restarts, it will need to generate a new proposal for the same round. Other nodes who see this new proposal will think the node is being malicious because each validator can't have more than one proposal per round.
This is really only meaningful if the other nodes have not progressed passed this round between the shutdown and reboot.
The solution is to store the pending batch proposal to disk on shutdown and reload it on bootup.
The text was updated successfully, but these errors were encountered: