Skip to content
This repository was archived by the owner on Nov 10, 2025. It is now read-only.
This repository was archived by the owner on Nov 10, 2025. It is now read-only.

Do not InitializeConsensus(0) if crashed and recovered #778

Closed
#779
Closed
Do not InitializeConsensus(0) if crashed and recovered#778
#779
Assignees
shargonerikzhangZhangTao1596superboyiii
@vncoelho

Description

@vncoelho
vncoelho
opened on Dec 16, 2022

Describe the bug
While testing dbft 3.0 we noticed a case that a CN helped others to change view and suddenly crashed, it may restart and come back to view 0.
However, it looks like the scenario could also happen nowadays.

neo-modules/src/DBFTPlugin/Consensus/ConsensusService.cs

Lines 144 to 159 in c187c26

if (!dbftSettings.IgnoreRecoveryLogs && context.Load())
{
if (context.Transactions != null)
{
blockchain.Ask<Blockchain.FillCompleted>(new Blockchain.FillMemoryPool
{
Transactions = context.Transactions.Values
}).Wait();
}
if (context.CommitSent)
{
CheckPreparations();
return;
}
}
InitializeConsensus(0);

That could lead to an honest node becoming byzantine, i.e. a node would help change view but later stay committed a lower view.

Perhaps, we just need to verify view number and fix the InitializeConsensus.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions