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

Allow skip to future round from QUALITY #278

Closed
masih opened this issue May 28, 2024 · 1 comment · Fixed by #279
Closed

Allow skip to future round from QUALITY #278

masih opened this issue May 28, 2024 · 1 comment · Fixed by #279
Assignees

Comments

@masih
Copy link
Member

masih commented May 28, 2024

Initially, re-boradcast protocol improvements required full execution of both QUALITY and DECIDE phases. Skipping ahead from QUALITY phase does not violate the correctness proof of gPBFT. The fact that QUALITY always terminates for a participant means the participant will eventually jump, but it may do it earlier.

If a node skips to future rounds without executing the QUALITY messages it has recieved it will only help reaching consensus for bottom. Therefore, allow jumping rounds from QUALITY phase, but process locally available messages first.

Relates to:

@masih masih self-assigned this May 28, 2024
@masih masih added this to F3 May 28, 2024
@masih masih moved this to Todo in F3 May 28, 2024
@masih masih moved this from Todo to In progress in F3 May 28, 2024
masih added a commit that referenced this issue May 28, 2024
Update the core protocol implementation to allow skipping to future
rounds from QUALITY phase. This reduces the conditions to requiring an
instance to only fully execute DECIDE phase. Otherwise, the instance may
jump ahead as long as all queued messages are processed.

As a result, the implementation no longer needs to check for QUALITY
phase transition on receiving alarms.

Fixes #278
@masih masih moved this from In progress to In review in F3 May 28, 2024
masih added a commit that referenced this issue May 28, 2024
Update the core protocol implementation to allow skipping to future
rounds from QUALITY phase. This reduces the conditions to requiring an
instance to only fully execute DECIDE phase. Otherwise, the instance may
jump ahead as long as all queued messages are processed.

As a result, the implementation no longer needs to check for QUALITY
phase transition on receiving alarms.

Fixes #278
masih added a commit that referenced this issue May 28, 2024
Update the core protocol implementation to allow skipping to future
rounds from QUALITY phase. This reduces the conditions to requiring an
instance to only fully execute DECIDE phase. Otherwise, the instance may
jump ahead as long as all queued messages are processed.

As a result, the implementation no longer needs to check for QUALITY
phase transition on receiving alarms.

Fixes #278
masih added a commit that referenced this issue May 28, 2024
Update the core protocol implementation to allow skipping to future
rounds from QUALITY phase. This reduces the conditions to requiring an
instance to only fully execute DECIDE phase. Otherwise, the instance may
jump ahead as long as all queued messages are processed.

As a result, the implementation no longer needs to check for QUALITY
phase transition on receiving alarms.

Fixes #278
@anorth
Copy link
Member

anorth commented May 28, 2024

The "process locally available messages first" part is captured in #151. This issue can be scoped to not disallowing QUALITY.

github-merge-queue bot pushed a commit that referenced this issue May 28, 2024
Update the core protocol implementation to allow skipping to future
rounds from QUALITY phase. This reduces the conditions to requiring an
instance to only fully execute DECIDE phase. Otherwise, the instance may
jump ahead as long as all queued messages are processed.

As a result, the implementation no longer needs to check for QUALITY
phase transition on receiving alarms.

Fixes #278
@github-project-automation github-project-automation bot moved this from In review to Done in F3 May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants