Require timeout certificates to leave all non-Fast rounds#6605
Draft
afck wants to merge 1 commit into
Draft
Conversation
Multi-leader rounds could previously be skipped by any valid proposal in a later round. Supporting that required tracking the highest signed proposal (`signed_proposal`), a recovery path that advanced the round on rejected proposals, and special round-comparison rules — logic that complicated the protocol. Now every non-Fast round ends only via a timeout certificate for that round (or a locking block from a higher round, which proves a quorum already reached it). Proposals must match the current round exactly. `Fast` proposals remain exempt: they can no longer advance the round, and the existing vote and locking-block checks prevent them from conflicting with later-round blocks. - Add `TimeoutConfig::multi_leader_round_duration` (default 1 second): multi-leader rounds are meant to be cooperative, so contention should be rare, and a short round keeps retry latency low. Single-leader rounds keep `base_timeout` plus `timeout_increment`. - The fast round times out iff `fast_round_duration` is configured, regardless of whether there are regular owners. A chain with only super owners and no fast-round duration relies on them for progress. - Remove the `signed_proposal` register, its recovery path, and `requested_signed_proposal` from `ChainManagerInfo`; `Worker::handle_block_proposal` returns `Result` again since a rejected proposal can no longer produce notifications. - Expose the new duration as `--multi-leader-round-ms` in the CLI and `multiLeaderRoundMs` in GraphQL, and fix the `base_timeout` docs. - Add the new field to the EVM `LineraTypes.yaml` registry, the regenerated `LineraTypes.sol`, and the `Linera.sol` wrapper, so that EVM contracts can deserialize the `chain_ownership()` result. This changes the serialization of `TimeoutConfig` and therefore chain IDs and the network protocol; it is not compatible with existing deployments.
afck
force-pushed
the
timeout-only-rounds
branch
from
bd0cc82 to
172ff64
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Multi-leader rounds can be skipped by any valid proposal in a later round. Supporting that requires tracking the highest signed proposal (
signed_proposal), a recovery path that advances the round on rejected proposals, and special round-comparison rules — logic that complicates the protocol.Proposal
Now every non-
Fastround ends only via a timeout certificate for that round (or a locking block from a higher round, which proves a quorum already reached it). Proposals must match the current round exactly.Fastproposals remain exempt: the existing vote and locking-block checks prevent them from conflicting with later-round blocks.TimeoutConfig::multi_leader_round_duration(default 1 second): multi-leader rounds are meant to be cooperative, so contention should be rare, and a short round keeps retry latency low. Single-leader rounds keepbase_timeoutplustimeout_increment.fast_round_durationis configured, regardless of whether there are regular owners. A chain with only super owners and no fast-round duration relies on them for progress.signed_proposalregister, its recovery path, andrequested_signed_proposalfromChainManagerInfo;Worker::handle_block_proposalreturnsResultagain since a rejected proposal can no longer produce notifications.--multi-leader-round-msin the CLI andmultiLeaderRoundMsin GraphQL, and fix thebase_timeoutdocs.Test Plan
Tests were updated and extended.
Release Plan
Links