-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Restore MemoryPool transactions from saved consensus context. #575
Conversation
…to correct view on restart).
If you let a consensus node start on the view it left off, you'd better clear the I think the best way is to not handle the view changing with recovery log and leave it to the message replay mechanism. |
How about I save and restore the memory pool? I was planning to make that change soon anyway. Actually, I guess that doesn’t work well since it will only be saved on a clean shutdown. What if we add the ones back to the be memory pool that are saved in the consensus context? |
@erikzhang if you want to leave it to message replay system that is fine too. Are you working on that PR now? |
I will start the work for message replay system next week. |
Ok, no problem. I’ll make one other change here that loads the transactions into the memory pool from the consensus context. You can decide later whether to take or leave this. |
I will check with careful, @jsolman. |
One more change coming to load the pool initially with transactions in the ConsensusContext on start-up. |
@erikzhang Have a look, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me @jsolman, I prefer to let @erikzhang decide about, if necessary, when and how to merge.
I am worrying more about the regeneration during the operation and not very much when hardware fails, but this PR looks like as an additional useful mechanism.
A critical point of the Regeneration is when we just lose messages and reach another view different than those who are committed.
@vncoelho |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds import in case of a quick restart.
…kchain subsystem.
This is addressed now. It reads the transactions form the serialized |
This should be ready now. I’ve tested these changes with the change from #596 |
Closing in favor of #598 |
* Add commit phase to consensus algorithm (#534) * Add commit phase to consensus algorithm * fix tests * Prevent repeated sending of `Commit` messages * RPC call gettransactionheight (#541) * getrawtransactionheight Nowadays two calls are need to get a transaction height, `getrawtransaction` with `verbose` and then use the `blockhash`. Other option is to use `confirmations`, but it can be misleading. * Minnor fix * Shargon's tip * modified * Allow to use the wallet inside a RPC plugin (#536) * Clean code * Clean code * Minor fix on mempoolVerified * Add MemoryPool Unit tests. Fix bug on initital start of Persisting the Genesis block. * Prevent `ConsensusService` from receiving messages before starting (#573) * Prevent `ConsensusService` from receiving messages before starting * fixed tests - calling OnStart now * Consensus recovery log (#572) * Pass store to `ConsensusService` * Implement `ISerializable` in `ConsensusContext` * Start from recovery log * Fix unit tests due to constructor taking the store. * Add unit tests for serializing and deserializing the consensus context. * Combine `ConsensusContext.ChangeView()` and `ConsensusContext.Reset()` * Add `PreparationHash` field to `PrepareResponse` to prevent replay attacks from malicious primary (#576) * Fixed a problem where `PrepareResponse.PreparationHash` was not assigned. * Load context from store only when height matches * Recover nodes requesting ChangeView when possible (#579) * Fixes bug in `OnPrepareRequestReceived()` * Send `RecoveryMessage` only when `message.NewViewNumber <= context.ViewNumber` * Fix and optimize view changing (#590) * Allow to ignore the recovery logs * Add `isRecovering` (#594) * Fix accepting own prepare request (#596) * Pick some changes from #575. * Fixes `Prefixes` * Restore transactions from saved consensus context (#598) * Refactoring * AggressiveInlining (#606) * Reset Block reference when consensus context is initialized after block persist. (#608) * Change `ConsensusPayload` for compatibility (#609)
This causes the saved transactions from the
ConsensusContext
to be sent to theBlockchain
before theLocalNode
is started. Also, I included some clean-ups for saving and restoring the consensus context.If the node saves the consensus context after sending commit. It should upon restoring it still have the transactions in its memory pool to be able to send to other nodes. With the consensus recovery mechanism it can recover other nodes and should be able to give them the transactions in the case it is recovering their node state.
In a worst case scenario where only 1 consensus node saved commit, and all other consensus nodes had to start over from scratch from a chain file, when they were synced, the one remaining node that had its consensus context saved in the commit state would be able to recover all the other nodes including the primary to the view in which the commit was saved, and allow the primary to create the block.