Skip to content

Require timeouts for all rounds.#6412

Draft
afck wants to merge 9 commits into
linera-io:mainfrom
afck:sketch-timeout-only-rounds
Draft

Require timeouts for all rounds.#6412
afck wants to merge 9 commits into
linera-io:mainfrom
afck:sketch-timeout-only-rounds

Conversation

@afck

@afck afck commented May 28, 2026

Copy link
Copy Markdown
Contributor

Motivation

The logic for multi-leader rounds, allowing proposals in higher rounds at any time, complicates the consensus protocol a lot.

Proposal

Make multi-leader rounds time out, too.

Test Plan

CI

Release Plan

  • Nothing to do / These changes follow the usual release cycle.

Links

afck added 9 commits May 25, 2026 08:29
Previously, a signed proposal in a higher `MultiLeader(n)` round could
advance `current_round` without a timeout certificate. That asymmetry
required a separate `signed_proposal` field on the chain manager, a
parallel `update_signed_proposal` path on rejection, and an extra
locking-block back-propagation rule, and was the source of the bugs
fixed in linera-io#6343 / linera-io#6360.

Now `MultiLeader` follows the same rule as `SingleLeader`: only a
timeout certificate (or a higher-round locking block) advances the
round. `TimeoutConfig` gains a dedicated `multi_leader_round_duration`
so chains expecting multi-leader contention can keep retry latency
short without affecting single-leader timeouts.

Net change is -52 lines of production code (the manager loses ~110
lines and the chain worker's error-recovery wrapper disappears), plus
the structural removal of `signed_proposal` from `ChainManagerInfo`,
the gRPC/simple servers, the updater, and the chain client.

Tests that exercised the legacy "skip a multi-leader round for free"
behavior are updated to either advance the test clock through the new
short timeout (via a new `run_through_timeouts` helper in `test_utils`)
or to directly assert the `WaitForTimeout` outcome that's now surfaced.
…ounds

# Conflicts:
#	linera-base/src/identifiers.rs
With BlobOrigin::Genesis now in main, the pending burn-3 block can be
finalized through the multi-leader timeout, so we can again assert that
client.burn(1) returns Conflict and leaves balance = 7.
Drop the super-owner break-out carve-out in `check_proposed_block` and the
matching skip-Fast branch in the chain client's `round_for_new_proposal`.
Every non-Fast round transition now flows through the same rule: timeout
certificate (or higher-round locking block) only.

`ChainOwnership::round_timeout` also stops zeroing out `fast_round_duration`
for super-owner-only chains. If you set the duration, the round times out;
if you don't, the chain stays in Fast forever — which is the natural mode
for a super-owner chain and matches the previous default behavior.

Three tests configured `fast_round_duration: None` plus a super owner and
relied on free Fast skipping (for oracle reads, for the explicit
`allow_fast_blocks: false` option, or after `transfer_ownership`); they
now either opt into Fast blocks or configure a Fast-round timeout and
wait it out via `run_through_timeouts`.
It is only used there, and being defined in `test_utils` (which is
compiled when downstream consumers enable the `test` feature) produced
a dead-code warning.
…d_by_original_owner`.

The test stages a multi-leader-round proposal that initially fails to
commit; advancing requires a timeout certificate. Drive the clock past
the round timeout while retrying `process_pending_block`.
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.

1 participant