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

Improve consensus timings #3430

Open
6 tasks
pinebit opened this issue Dec 19, 2024 · 1 comment
Open
6 tasks

Improve consensus timings #3430

pinebit opened this issue Dec 19, 2024 · 1 comment
Assignees
Labels
protocol Protocol Team tickets
Milestone

Comments

@pinebit
Copy link
Collaborator

pinebit commented Dec 19, 2024

🎯 Problem to be solved

To prevent missing proposals we shall revisit the timings used by consensus layer.
Once the final values confirmed, we need to introduce a new timer type and a new version of QBFT protocol (see Consensus Abstraction design) that is using this new timer.

🛠️ Proposed solution

  • Review the statistics on timings reported by Data.
  • Implement new timer type and configure the new QBFT protocol version, say qbft/v2.1.0.
  • Possibly change --consensus-protocol flag behavior to allow fully qualified protocol strings (so we can override with the precise qbft version).

🧪 Tests

  • Tested by new automated unit/integration/smoke tests
  • Manually tested on core team/canary/test clusters
  • Manually tested on local compose simnet
@pinebit pinebit added the protocol Protocol Team tickets label Dec 19, 2024
@pinebit pinebit added this to the v1.3.0 milestone Dec 19, 2024
obol-bulldozer bot pushed a commit that referenced this issue Jan 14, 2025
Add a third consensus round timer which implements the following behavior:
- First consensus round has 1 second to complete
- Subsequent rounds have exponentially more time starting at 200ms (400ms, 800ms, 1.6s, etc...)

category: feature
ticket: #3430
feature_flag: exponential
DiogoSantoss added a commit that referenced this issue Jan 15, 2025
Add a third consensus round timer which implements the following behavior:
- First consensus round has 1 second to complete
- Subsequent rounds have exponentially more time starting at 200ms (400ms, 800ms, 1.6s, etc...)

category: feature
ticket: #3430
feature_flag: exponential
obol-bulldozer bot pushed a commit that referenced this issue Jan 20, 2025
Change exponential timer (implemented in #3440) for linear timer.

- First consensus round has 1 second to complete
- Subsequent rounds have linearly more time starting at 400ms (600ms, 800ms, 1s, etc...)

category: refactor
ticket: #3430 
feature_flag: linear
@DiogoSantoss DiogoSantoss self-assigned this Jan 21, 2025
@KaloyanTanev KaloyanTanev removed this from the v1.3.0 milestone Mar 5, 2025
@KaloyanTanev
Copy link
Collaborator

KaloyanTanev commented Mar 6, 2025

If we get this PR merged in v1.3.0, I believe we will need data from at least a month from couple of clusters, in order be able to advance with this request. That said, v1.5.0 seems like a reasonable milestone for this one.

@KaloyanTanev KaloyanTanev added this to the v1.5.0 milestone Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocol Protocol Team tickets
Projects
None yet
Development

No branches or pull requests

3 participants