PaperlayerView exact revision on arXiv

Source-linked AI summary

Steelhead: Interleaving Partially Synchronous and Asynchronous Commit Rules on a Shared DAG

George Danezis, Zeno De Angeli, Philipp Jovanovic, Lefteris Kokoris-Kogias, Markus Legner, Alberto Sonnino

arXiv:2609.30163v1cs.DCcs.CR

TL;DR

Partially synchronous consensus is fast but loses liveness under asynchrony, while asynchronous consensus remains live at the cost of extra delays and a common coin. Steelhead interleaves both commit rules on one DAG and adapts their period from committed data. Simulations report that it tracks the partially synchronous protocol in healthy conditions and stays near the asynchronous protocol when the former stalls.

  • Problem

    Partially synchronous BFT is fast but loses liveness under asynchrony or targeted leader attack, whereas asynchronous BFT stays live but pays extra message delays and a common coin.

    Source: §1 · p. 1

  • Method

    Steelhead assigns every k-th slot to an asynchronous rule and the other slots to a partially synchronous rule on the same DAG, using anchors to complete pending decisions.

    Source: §1 · p. 2

  • Results

    313 vs 301 ms in degraded-network condition (ii), Steelhead versus Mahi-Mahi; simulations also report Steelhead matching the faster variant in several BlueBottle conditions.

    Source: §6.4 · p. 13, §6.5 · p. 14

  • Takeaways & Limitations

    The simulations report that Steelhead can remain near the asynchronous variant when the partially synchronous protocol stalls, while tracking the partially synchronous protocol in healthy conditions.

    Source: §6.4 · p. 13, §6.5 · p. 14

    Steelhead requires both rules to share a committee and blocks and to meet its wavelength-based decision and evidence-persistence properties.

    Source: §2 · p. 4

Abstract

from arXiv · show

Dual-mode consensus protocols are fast when the network is partially synchronous and remain live under asynchrony. We introduce Steelhead, a dual-mode mechanism that composes a partially synchronous and an asynchronous commit rule over one DAG: every k-th round is decided by the asynchronous rule, whose leader a common coin reveals after the votes, and all other rounds by the partially synchronous rule. Every interval, validators replay the committed DAG under each candidate period, adopt the one with the fewest expected message delays, and fall back to k = 1 when the output stalls; the asynchronous rule applied to the coin rounds alone keeps the protocol live. Steelhead sends no message beyond the DAG's blocks, not even to agree on the period, and opens a coin only on the rounds that need a hidden leader. It is generic over pairs of DAG commit rules that share a committee; we instantiate it with Mysticeti and Mahi-Mahi at n >= 3f+1 and with the two variants of BlueBottle at n >= 5f+1. We prove it safe and live, and provide mechanized proofs in Lean 4. In simulation, Steelhead matches the partially synchronous protocol in a healthy network, stays close to the asynchronous one when network conditions stall the partially synchronous one, and adapts quickly in both directions.

1 Introduction

Steelhead interleaves partially synchronous and asynchronous commit rules over one DAG, with the round number assigning each slot to a rule. Validators adapt the period from committed data, while anchors let the rules complete one another’s pending decisions.

1 Introduction

  • Every k-th slot uses the asynchronous rule and the others the partially synchronous rule, with k ranging from fully asynchronous at 1 to partially synchronous at infinity.Both rules read the same DAG; the round number selects the deciding rule without a mode vote, path switch, or extra message.Source: §1 · p. 2
  • An undecided slot is completed by the first committed slot at least one wavelength above it, whose causal history carries the evidence needed for the decision.This handover lets Steelhead avoid reconciling where a previous rule stopped.Source: §1 · p. 2
  • Under asynchrony, known-leader slots can stall output, so validators replay the coin-carrying slots with the asynchronous rule to derive shared period data.The control reading commits no output; it yields a common committed block for computing the period.Source: §1 · p. 2
  • Validators replay committed data under candidate periods and choose the one with the lowest expected latency, averaging over possible leaders as a uniform coin would.The replay ranks rules but commits nothing, and the asynchronous rule certifies a fixed fraction of blocks under any message schedule.Source: §1 · pp. 2–3
  • The paper reports proofs of safety and liveness, mechanized in Lean 4, implementations over two protocol pairs, and simulations in various network conditions.The pairs are Mysticeti with Mahi-Mahi at n ≥3f + 1 and the two BlueBottle variants at n ≥5f + 1.Source: §1 · p. 3

2 Background and Model

Steelhead composes partially synchronous and asynchronous DAG commit rules to target the latency of the former during synchrony and the liveness of the latter under asynchrony. Its model specifies the shared committee, DAG, timing, and rule properties required for this composition.

2 Background and Model

  • The system has n validators, at most f Byzantine, and quorums of size n−f; instantiations use resilience thresholds n ≥3f + 1 or n ≥5f + 1.Steelhead adds no cryptography or messages beyond the DAG substrate’s signed blocks and hash-based causal references.Source: §2 · p. 3
  • The common coin must agree, remain unpredictable until n−f authorities contribute, and be uniform conditional on the adversary’s prior view.The coin’s value maps to a uniformly selected leader among the n authorities.Source: §2 · p. 3
  • In the DAG model, each slot is decided from its rule’s wavelength of rounds, while an undecided slot is resolved indirectly through a later anchor’s causal history.Output follows slot order, so an undecided slot holds back higher slots.Source: §2 · p. 4
  • The two rules must share a committee and blocks and satisfy five interface properties, including wavelength-based decisions and evidence persistence; each instantiated pair discharges the required clauses.The wave family supplies clauses A1–A3, while each rule pair must additionally satisfy A4 and A5.Source: §2 · pp. 4–5
  • The stated goal is to combine the latency of a partially synchronous rule during synchrony with the liveness of an asynchronous rule under asynchrony.Both rules operate through a shared interface, and Steelhead implements atomic broadcast.Source: §2 · p. 5

3 Interleaving Two Commit Rules

Steelhead assigns each slot to one of two commit rules by round number, then uses anchor-based decisions to hand over pending slots. A fixed period cannot provide both healthy-network speed and asynchronous liveness, motivating interval-based adaptation.

3.1 Slots by Round Number

  • The round number selects the wavelength: rounds divisible by k use the asynchronous rule, while other rounds use the partially synchronous rule.Blocks remain identical apart from a coin share, and only rounds needing a hidden leader carry a coin.Source: §3.1 · p. 5

3.2 Deciding Slots: the Anchor Floor

  • An undecided slot’s anchor search starts at r + w(r), so the anchor’s causal history can contain direct-commit evidence; this handover lets one rule decide slots left pending by the other.In Fig. 2, the asynchronous slot at round 4 is decided by the synchronous slot at round 9.Source: §3.2 · p. 6, Figure 2 · p. 6

3 Interleaving Two Commit Rules

  • At each interval, validators use a control-reading pivot and its causal history to replay candidate periods, choosing the lowest expected output delay or setting k = 1 if the ledger stalled.The selected period applies to the next interval; the abstract loop includes hysteresis before changing periods.Source: §3.2 · p. 7

3.3 What a Fixed Period Cannot Do

  • In a healthy network, asynchronous slots add wavelength-related delays that do not compound, but under asynchrony synchronous slots may remain undecided and block output for every fixed k > 1.Thus k = 1 is live under asynchrony but slow when the network is healthy, so the period must adjust dynamically.Source: §3.3 · p. 7

4 Adapting the Period

Steelhead adapts its period by replaying a shared DAG under candidate rules, using a control reading to keep period evidence available even when the output reading stalls. Validators derive the next period deterministically from the pivot’s window, with a failover to k = 1 if that window produced no output.

4.1 The Adaptation Loop

  • The next period is the candidate whose replay scores best on the pivot’s window; if the output committed nothing there, Steelhead sets the next period to 1.Periods apply to the next interval, and every honest validator computes the same sequence without a period vote.Source: §4.1 · p. 8

4.2 Seeing Both Rules: Two-Way Probes

  • Canaries probe the partially synchronous rule while coin-carrying slots probe the asynchronous rule, keeping evidence of both rules available for switching regimes.The canary interval is odd and coprime to every candidate period, so every candidate is probed; a canary certificate indicates the partially synchronous rule could work again.Source: §4.2 · pp. 8–9

4.3 Agreeing on the Evidence: the Control Reading

  • A second, control reading applies the asynchronous rule only to coin-carrying slots and uses its first commit as the pivot, so period computation can proceed despite a stalled output reading.Its slots are fixed by the rule, including multiples of maxPeriod above the interval, and direct verdicts match those of the output reading.Source: §4.3 · pp. 9–10

4.4 Scoring Without a Coin: Counterfactual Replay

  • Counterfactual replay scores each candidate by expected block-output delay, averaging over possible leaders for the asynchronous rule and using canary success as evidence for the partially synchronous rule.The replay includes head-of-line blocking; the asynchronous score has a scheduling-independent floor because a fixed fraction of each round’s blocks are certified under any schedule.Source: §4.4 · p. 10
  • Replay approximates candidate decisions using certificates anywhere in the pivot’s window and treats slots not committed within the window as committing at its top round.The computation costs O(|K| · |W|) for |K| candidates over a window of |W| blocks.Source: §4.4 · p. 10

5 Correctness

Steelhead’s correctness argument combines a cross-rule safety argument with liveness in both synchronous and asynchronous settings. Period agreement follows from deterministic updates to an agreed pivot window.

Safety

  • A direct commit leaves a certificate for the anchor search, aligning indirect decisions across rules; two indirect decisions agree because validators find the same anchor.This is the cross-rule safety argument; the remaining safety properties are inherited from the base protocols.Source: §5 · p. 11

Liveness

  • After GST, synchronous slots with an honest leader and a leader wait commit directly; under asynchrony, control-reading progress and failover to k = 1 restore output liveness.At k = 1, a run of wa direct commits decides every slot below it, and the counting property makes such a run occur with probability 1.Source: §5 · p. 11

Agreement on the period

  • The agreed pivot window makes period updates identical across honest validators for any deterministic update rule; at k = 1 and k = ∞, verdicts match Mahi-Mahi and Mysticeti, respectively.Source: §5 · p. 11

6 Implementation and Evaluation

Steelhead is evaluated in simulation against the two pure protocols in each of two protocol pairs. It tracks the partially synchronous protocol in healthy conditions, the faster protocol when conditions degrade, and adapts when conditions change.

6 Implementation and Evaluation

  • Across both protocol pairs, Steelhead matches the partially synchronous protocol in healthy conditions, stays close to the asynchronous protocol when the former stalls, and adapts in both directions.The evaluation reports these outcomes for pairs at n ≥3f + 1 and n ≥5f + 1.Source: §6 · p. 11

6.1 Implementation

  • Steelhead adds a per-round wavelength schedule, restricts leader waits to synchronous slots and canary rounds, and updates its period by counterfactual replay.The block format remains unchanged, and the implementation adds no protocol messages or storage access.Source: §6.1 · p. 12

6.2 Experimental Setup

  • The evaluation uses seeded discrete-event simulation with real consensus code, 50-validator full-mesh committees, and six scripted network conditions.Conditions run from 30 to 150 seconds; latency is measured from submission to commit as five-second-window means and medians over seven seeded runs.Source: §6.2 · p. 12

6.3 Healthy Network

  • 215 ms for Steelhead versus 213 ms for Mysticeti and 294 ms for Mahi-Mahi in healthy windows; Steelhead stays at period 64.Steelhead is within 1% of Mysticeti and 27% below Mahi-Mahi; Fig. 4 plots latency over time for the 3f + 1 pair.Source: Figure 4 · p. 13, §6.3 · p. 13

6.4 Degraded Network and Recovery

  • Under degraded conditions, Steelhead drops to period 1 and approaches Mahi-Mahi’s latency when Mysticeti stalls, then returns to period 64 within 10 seconds after conditions lift.Under jitter, its plateau is 1473 ms versus Mahi-Mahi’s 1300 ms; with f crashed validators, Steelhead records 363 ms versus Mysticeti’s 356 ms. Fig. 4 shows the latency traces.Source: §6.4 · pp. 13–14, Figure 4 · p. 13

6.5 The 5f + 1 Pair

  • In healthy conditions, Steelhead commits in 169 ms versus 168 ms for BlueBottle-PS and 212 ms for BlueBottle-Async; under network-wide delays, Steelhead follows the faster variant within 1%.At n = 50, BlueBottle-PS survives network-wide conditions (iv) to (vi) but runs 48%, 41%, and 9% slower than its asynchronous variant.Source: §6.5 · p. 14

7 Related Work

Existing dual-mode designs pay for switching paths or running them concurrently. Steelhead instead uses round-number scheduling and adapts its period from the committed DAG.

7 Related Work

  • Timeout-based designs risk switching too early or too late, while Steelhead uses the round number to select the rule and adapts k from the committed DAG.Ditto and Bolt-Dumbo Transformer also put agreement on the critical path at every switch; Steelhead opens a coin only once every k rounds.Source: §7 · pp. 14–15
  • Concurrent-path designs pay for a second protocol, including quadratic messages in healthy conditions for some asynchronous paths.Abraxas pays O(n^2B) bits per block, while ParBFT1’s pessimistic path uses a validated asynchronous agreement on every slot.Source: §7 · p. 15
  • Icarus avoids a second path but requires Byzantine agreement at each switch to align parties that may observe different backlogs.Steelhead runs no second path and wastes no block; one slot in k pays wa − ws extra rounds.Source: §7 · p. 16

A Variant Without Asynchronous Slots in the Ledger

The proposed variant omits asynchronous slots from the output ledger while retaining a control reading for liveness and period updates. The authors keep the original design to avoid proof complexity for a small latency saving.

A Variant Without Asynchronous Slots in the Ledger

  • A control reading that applies the asynchronous rule to coin-carrying slots alone still supports liveness and period updates, while output uses the partially synchronous rule when k > 1.At k = 1, output uses the asynchronous rule on every round.Source: A Variant Without Asynchronous Slots… · p. 18
  • The variant would save the extra rounds of an asynchronous slot and its successor’s causal wait, about 1% of latency at k = 64.Source: A Variant Without Asynchronous Slots… · p. 18
  • The authors retain the original design because the variant complicates the safety proof and saves no additional cost beyond that latency, since the control reading still opens the coin.Source: A Variant Without Asynchronous Slots… · p. 18

B Full Proofs

This section establishes Steelhead’s agreement, liveness, and atomic-broadcast properties under stated rule conditions, including schedule adaptation, and details the interface, handover, and period-agreement foundations of the proofs. It also describes the Lean 4 formalization, its model, and the hypotheses on which its results depend.

B Full Proofs

  • The proofs apply to rules sharing the stated committee and interface assumptions, while Theorem 1 generalizes beyond the wave family; the Lean 4 development machine-checks the arguments.The appendix says arguments needing neither A4 nor A5 hold for any pair of wave-family rules and wavelength function.Source: B Full Proofs · p. 18
  • Support uniqueness and quorum intersection ensure that a candidate with n −f supporters excludes rivals, and every sufficiently high block’s causal history reaches the slot’s indirect threshold.For BlueBottle, a direct skip or a candidate’s n −f supporters leave each candidate or rival below n −3f supporters; for the 3f + 1 pair, at most one candidate is certified.Source: B Full Proofs · p. 19
  • Honest validators agree on every slot’s verdict, including under independently derived adaptive schedules once they have derived periods through the highest round in their shared block universe.The proof covers direct and indirect verdicts and applies when the validators’ derived interval periods agree.Source: B Full Proofs · pp. 20–21
  • A direct commit is handed over to validators with committed anchors, and the resulting output preserves slot order and outputs each block at most once.Agreement rules out a conflicting skip; indirect commits output blocks only through the first committed leader whose causal history contains them.Source: B Full Proofs · pp. 21–22
  • The anchor search must begin at round r + w(r), the slot’s own wavelength floor, so an indirect verdict cannot skip a slot another rule directly committed.The proof identifies this cross-rule direct/indirect case as the only interaction between the rules.Source: B Full Proofs · p. 21, Figure 6 · p. 22
  • Under partial synchrony, honestly led synchronous slots with a successor leader wait commit directly within ws rounds, while asynchronous slots with honest or crashed leaders decide directly within wa rounds.Partial dissemination alone does not defer an asynchronous decision; slots left undecided directly are eventually resolved through committed anchors once the intervening slots are decided.Source: B Full Proofs · pp. 22–23
  • Under asynchrony, if maxPeriod ≤ interval, wa ≤ interval, ws ≤ wa, every round above 2 interval is populated (A1), and A5’s counting bound holds at every round with p > 0, every slot is eventually decided with probability 1.Source: B Full Proofs · p. 24
  • Any deterministic period-update rule gives honest validators the same derived period for an interval, because their control slots, control verdicts, and resulting pivot agree.The control reading applies the asynchronous rule at fixed wavelength wa, where Theorem 1 establishes verdict agreement.Source: B Full Proofs · pp. 25–26
  • At k = 1 Steelhead exactly matches Ra, while at k = ∞ it matches Rs; the replay’s direct-commit share is at least (n −f −b)/n for Mahi-Mahi at wa = 5 under any scheduling.The counting floors are p ≥ (n −f −b)/n (at least 1/3) for Mahi-Mahi at wa = 5, p ≥ 1/n at wa = 4, and p ≥ (n −3f)/n for BlueBottle’s asynchronous variant at wa = 3.Source: B Full Proofs · pp. 26, 29
  • Steelhead implements atomic broadcast for any rule pair satisfying clauses A1–A5, with honest validators agreeing on settled slots and eventually delivering valid blocks.Agreement follows from deterministic output over the same causal history; validity relies on the reference rule and eventual slot decisions.Source: B Full Proofs · pp. 26–27
  • The period scan replays candidate rules on a pivot’s causal history, scores expected output delay, and switches to k = 1 when output stalls.Replay estimates unprobed synchronous slots from canary success rates and averages over candidate leaders for asynchronous slots; the authors note that this rate does not guarantee selection of the fastest period, motivating failover.Source: B Full Proofs · pp. 28–29

C Lean Formalization

  • Every Appendix B statement is machine-checked in Lean 4, with no sorry and no axioms beyond Lean’s three standard ones.The development spans about 21k lines, including executable witnesses that test definitions on concrete DAGs and expose counterexamples to incorrect claims.Source: C Lean Formalization · p. 30

C.1 The Model and the Rule

  • The formal model composes anchored rules across slot kinds and proves period agreement for deterministic updates, while introducing a per-slot wavelength and anchor-floor rule.The formalization reuses the DAG core, fixed-wavelength decision rule, coin effect, and counting lemma; new results include agreement across derived schedules and liveness for lawful rule pairs.Source: §C.1 · pp. 31–32

C.2 What the Model Assumes

  • The model treats block production, delivery, post-GST reference behavior, fair leaders, coin uniformity, and the counting floor as hypotheses rather than deriving execution behavior.Under these hypotheses it checks expected waits, including 1/pwa blocks of wa coin rounds at k = 1, and establishes almost-sure progress through vanishing tail bounds over successive records.Source: §C.2 · pp. 32–33

C.3 Results

Appendix C.3 reports machine-checked Lean results while identifying remaining proof and model boundaries. Under a mistimed leader timeout, BlueBottle-PS continues committing with constant probability, whereas Mysticeti stalls because its rule requires two evidence layers.

C.3 Results

  • Each Lean result has an audited statement file and a separate kernel-checked proof.Table 4 maps Appendix B statements to their machine-checked counterparts.Source: §C.3 · p. 33, Table 4 · p. 34
  • For BlueBottle’s pair, the checked results exclude agreement between output and control readings on direct verdicts and Appendix D’s certificate-layer issue.The replay model also excludes Section 6 evaluation and interpreting schedule-clock time as wall-clock time.Source: §C.3 · p. 33

D Partially Synchronous Protocols Under a Mistimed Leader Timeout

  • BlueBottle-PS keeps committing with constant probability when T < D, while Mysticeti stalls; configuring T ≥ D restores both rules.The authors characterize this as a latency collapse under a too-small timeout, not a liveness statement.Source: D Partially Synchronous Protocols… · p. 35

D.1 Observation 1: Minimum-Quorum References

  • A timeout T < D makes validators propose at the n−f-block threshold, so every block references exactly n−f previous-round blocks.The fixed-delay runs at n = 10 verified this behavior for both rules.Source: §D.1 · p. 35
  • At n = 10, BlueBottle-PS references the leader with probability 0.889, versus 0.667 for Mysticeti.The higher n−f threshold increases this chance because it also determines how long a validator waits before proposing.Source: §D.1 · p. 35

D.2 Observation 2: Layers of Evidence

The two-layer Mysticeti rule makes direct commits depend on forming certificates from vote-round blocks, creating an all-or-nothing filter. Under the stated independent-arrival model, this sharply reduces the commit probability and can leave slots waiting indefinitely at n = 50.

D.2 Observation 2: Layers of Evidence

  • The two-layer rule commits directly only when every vote-round block voted, making its direct-commit probability depend on the extreme tail Pr[V = n].A certificate requires n−f references, and with minimum-quorum references all of them must be votes.Source: §D.2 · p. 36
  • At n = 10, Pr[V = n] is 0.026 under independent arrival orders but measured at 0.10; at n = 50, the independent-order floor is 4 · 10−9.The independence assumption is optimistic: correlated arrivals produce a fatter tail, while P1’s measured Pr[V ≥ n−f] remains 0.652 versus 0.650 under independence.Source: §D.2 · p. 36
  • At n = 50, the next direct commit never arrives, so undecided slots have no anchor and progress stops.Each undecided slot waits for the next direct commit above it; expected waiting time is 1/P2 rounds.Source: §D.2 · p. 36

D.3 Experimental Validation

In fixed-delay simulations, BlueBottle-PS continues committing at both tested committee sizes while Mysticeti fails to commit at n = 50. Under random delays, BlueBottle-PS remains live while Mysticeti develops commit-free windows and stalls at n = 50 as delay increases.

D.3 Experimental Validation

  • At n = 50, Mysticeti decides nothing in any fixed-delay seed despite the DAG advancing about 210 rounds; BlueBottle-PS matches P1 within 3%.At n = 10, BlueBottle-PS commits at the predicted rate, while Mysticeti commits directly about once per round in ten and has mean latency of 16–90 s.Source: §D.3 · pp. 36–37, Table 5 · p. 37
  • Under random delays (100–150 ms past T = 100 ms with probability ϕ), at n = 10 BlueBottle-PS stays live and costs at most 5× healthy latency; Mysticeti commit-free windows dominate from ϕ = 0.40.At n = 50, Mysticeti latency rises to 2.7 s at ϕ = 0.2; beyond that, no slot is decided and runs cannot complete. Fig. 7 plots latency and the direct-commit rate.Source: §D.3 · p. 37
  • At n = 50, BlueBottle-PS saturates at 1.1 s with a direct-commit rate of 0.55–0.60, near its closed form P1 = 0.59.The closed forms describe only the minimum-quorum regime and do not predict where the stall begins.Source: §D.3 · p. 37

E Evaluation Details

The evaluation details specify simulator parameters, network conditions, and measurement conventions for the protocol comparisons. The setup also describes Steelhead’s replay interval, period selection parameters, and periodic canary probes.

E Evaluation Details

  • The evaluation details cover network conditions, figure-reading guidance, per-panel numbers for both protocol pairs at n = 10 and n = 50, and runs at n = 10.Tables 6 and 7 list the common simulator, load, Steelhead parameters, and six network conditions.Source: E Evaluation Details · p. 37, Table 6 · p. 38, Table 7 · p. 39

E.1 Setup

  • The interval sets Steelhead’s replay window and reaction horizon, while maxPeriod starts at one asynchronous slot in 64 and hysteresis sets the required improvement for adoption.The interval spans about 6 s at the healthy round rate.Source: §E.1 · pp. 37–38
  • A canary keeps the leader wait on every 31st asynchronous round, ensuring probes fall on synchronous slots for every candidate period.Network models add delay without dropping messages; the leader-delay adversary targets the current round-robin leader and is blind to the coin.Source: §E.1 · pp. 38–39
  • Latency is measured from transaction submission to block commit per replica in 5 s windows; figures show the median across seven seeds after a 3-tick rolling median.Windows without commits appear as gaps, and the period trace averages replicas across the committee; intermediate values indicate mid-transition.Source: §E.1 · p. 39

E.2 Per-Panel Results

The per-panel results define how degraded latency plateaus and period-transition times are measured, and describe transient period changes that carry localized latency costs.

E.2 Per-Panel Results

  • The degraded plateau is the median of 5 s windows from 70–330 s; “stalled” means fewer than one commit per ten windows.The table also records time to reach period 1 after onset and to return to 64 after the condition lifts.Source: §E.2 · p. 39
  • In crash panel (iii), the period alternates between 64 and {1, 2, 4, 8} every second or third interval, costing a 7% gap to Mysticeti.Identically across seeds, a probe landing on a crashed round-robin leader reads as a starved slot, and each dip costs a few windows of Mahi-Mahi latency.Source: §E.2 · p. 39
  • After recovery in panels (ii), (iv), and (v), the period briefly drops to 2, and one 5 s window commits at about 0.25 s.The drop occurs 20–70 s after the condition lifts.Source: §E.2 · p. 39
  • In panel (i), the period briefly drops to 1 or 2 once or twice during the condition, each time costing one window at about 0.3 s.Source: §E.2 · p. 39

E.3 Committee of 10

At n = 10, Steelhead stays close to the partially synchronous protocol in healthy phases and tracks the better protocol under degraded conditions, while adapting its period as conditions change.

E.3 Committee of 10

  • The n = 10 rerun uses 30 s healthy, applies each of six conditions through 330 s, then returns healthy to 450 s; Tables 8–9 give per-panel results.The tables report degraded-plateau latency and Steelhead’s times to reach period 1 and return to 64.Source: §E.3 · p. 39, Table 8 · p. 40, Table 9 · p. 40
  • In healthy phases, Steelhead stays within 1% of the partially synchronous protocol (208 vs 206 ms; 163 vs 162 ms) and 22–28% below the asynchronous one.Source: §E.3 · p. 40, Figure 8 · p. 41, Figure 9 · p. 41
  • Steelhead reaches period 1 within 10–25 s after onset where a protocol stalls and returns to 64 within 5–15 s after conditions lift.Source: §E.3 · p. 40
  • Under large leader delay it tracks the better protocol within 3%; under network-wide conditions, within 1% (684 vs 685 ms; 1122 vs 1121 ms; 1022 vs 1017 ms).Source: §E.3 · p. 40
  • At n = 10, crash dips cost 7% and 17% for the two pairs, versus 2% at n = 50; BlueBottle-PS ties its asynchronous variant under network-wide conditions.Mysticeti survives jitter at a 3.1 s plateau rather than 5.7 s.Source: §E.3 · p. 40
Loading 2609.30163v1…