Skip to content
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

Closed
wants to merge 45 commits into from

Conversation

jsolman
Copy link
Contributor

@jsolman jsolman commented Jan 25, 2019

This causes the saved transactions from the ConsensusContext to be sent to the Blockchain before the LocalNode 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.

@jsolman jsolman added the critical Issues (bugs) that need to be fixed ASAP label Jan 25, 2019
This was referenced Jan 25, 2019
@erikzhang
Copy link
Member

erikzhang commented Jan 25, 2019

If you let a consensus node start on the view it left off, you'd better clear the ConsensusContext.Transactions. Because the memory pool has changed and may contains conflicting transactions.

I think the best way is to not handle the view changing with recovery log and leave it to the message replay mechanism.

@jsolman
Copy link
Contributor Author

jsolman commented Jan 25, 2019

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?

@jsolman
Copy link
Contributor Author

jsolman commented Jan 25, 2019

@erikzhang if you want to leave it to message replay system that is fine too. Are you working on that PR now?

@erikzhang
Copy link
Member

I will start the work for message replay system next week.

@jsolman
Copy link
Contributor Author

jsolman commented Jan 25, 2019

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.

@vncoelho
Copy link
Member

vncoelho commented Jan 25, 2019

I will check with careful, @jsolman.
But I prefer to merge every little piece in the Improved_DBFT now with carefully, because we already have a different template for doing the job (which we can surely be benefited by in the future).
Let's wait for Erik's insights on the code and then we keep checking carefully for ensuring a template that will proportionate a long term evolution smooth and in an well biased evolutionary direction.

@jsolman
Copy link
Contributor Author

jsolman commented Jan 25, 2019

One more change coming to load the pool initially with transactions in the ConsensusContext on start-up.

@jsolman
Copy link
Contributor Author

jsolman commented Jan 25, 2019

@erikzhang Have a look, the MemoryPool now starts with the transactions from the saved ConsensusContext.

Copy link
Member

@vncoelho vncoelho left a 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.

@jsolman jsolman added potential enhancement and removed critical Issues (bugs) that need to be fixed ASAP labels Jan 27, 2019
@jsolman
Copy link
Contributor Author

jsolman commented Jan 27, 2019

@vncoelho
These changes are mainly to speed up consensus in the case CN nodes are restarted for some reason (crash or otherwise) after having changed view.

vncoelho
vncoelho previously approved these changes Jan 27, 2019
Copy link
Member

@vncoelho vncoelho left a 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.

@jsolman jsolman added enhancement Type - Changes that may affect performance, usability or add new features to existing modules. and removed potential enhancement labels Jan 28, 2019
neo/NeoSystem.cs Outdated Show resolved Hide resolved
@jsolman
Copy link
Contributor Author

jsolman commented Feb 19, 2019

But the only problem is that it increases the coupling between mempool and consensus. Because mempool reads the contents of the serialized ConsensusContext directly from the store. This is not a good design.

This is addressed now. It reads the transactions form the serialized ConsensusContext just before starting the LocalNode and tells the Blockchain about them.

@jsolman jsolman changed the title Restore MemoryPool transactions from restored consensus context. Write consensus context synchronously. Restore MemoryPool transactions from saved consensus context. Feb 19, 2019
neo/Persistence/Store.cs Outdated Show resolved Hide resolved
@jsolman
Copy link
Contributor Author

jsolman commented Feb 20, 2019

This should be ready now. I’ve tested these changes with the change from #596

neo/NeoSystem.cs Outdated Show resolved Hide resolved
erikzhang added a commit that referenced this pull request Feb 21, 2019
@jsolman
Copy link
Contributor Author

jsolman commented Feb 21, 2019

I’ll update the summary again since commits for synchronously writing the state were picked out directly from #575 into #547

@jsolman jsolman changed the title Write consensus context synchronously. Restore MemoryPool transactions from saved consensus context. Restore MemoryPool transactions from saved consensus context. Feb 21, 2019
shargon
shargon previously approved these changes Feb 21, 2019
@erikzhang erikzhang dismissed shargon’s stale review February 21, 2019 10:38

We are going to implement #598

@jsolman
Copy link
Contributor Author

jsolman commented Feb 21, 2019

Closing in favor of #598

@jsolman jsolman closed this Feb 21, 2019
@shargon shargon deleted the consensus/recoveryLog2 branch February 22, 2019 12:29
erikzhang pushed a commit that referenced this pull request Mar 3, 2019
* 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)
Thacryba pushed a commit to simplitech/neo that referenced this pull request Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Type - Changes that may affect performance, usability or add new features to existing modules.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants