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

Round change upon f+1 RC messages (experimental option) #7838

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

pullurib
Copy link
Contributor

@pullurib pullurib commented Oct 31, 2024

PR description

  • Added an experimental option to enable round change upon receiving f+1 valid round change messages from different validators for future rounds
  • move to least of the future rounds
  • If node is proposer for the new round, wait till the new round receives ceil(2*N/3) quorum of RC messages to propose the new block.

Plan going ahead

Next release

--Xqbft-enable-early-round-change = false

- No f+1 behaviour

--Xqbft-enable-early-round-change = true

- f+1 behaviour

Besu 25.6.0

Remove --Xqbft-enable-early-round-change (NOT make it --qbft-enable-early-round-change)

Fixed Issue(s)

#1822

Copy link
Contributor

@matthew1001 matthew1001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with some small comments

@jframe
Copy link
Contributor

jframe commented Dec 3, 2024

I forgot about this, just having a look now. Hopefully won't take me log to get through it.

Bhanu Pulluri added 3 commits December 3, 2024 15:43
doRoundChange(qbftRound.getRoundIdentifier().getRoundNumber() + 1);
}

private synchronized void doRoundChange(final int newRoundNumber) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this need to be synchronized?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is called by two threads one handling round timer expiry and the other handling RC payload (upon f+1 RC quorum) . So made it synchronized as there's no scope of IO blocking or no scope for deadlock without calls to other synchronized methods. Can finegrain it if needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants