-
Notifications
You must be signed in to change notification settings - Fork 104
leios report gaps
This document surfaces gaps in the Leios ΔQ report
(ouroboros-leios/analysis/deltaq/improved-leios/report.md)
and in CIP-0164 that emerge when the goal is stated as "Leios reacting
optimally to observed conditions" — i.e., when static-analytical design
is treated as the starting point, not the finished product.
The gaps fall into three families:
- Report gaps — omissions or simplifications in the ΔQ analysis itself.
- CIP gaps — provisions the specification should probably contain but doesn't.
- Cross-cutting / meta gaps — issues that span both, or that concern how the design work is being conducted rather than its content.
The framing here is deliberately not centred on any particular implementation branch. Where the mux RTT/DeltaQ work on this branch is relevant to closing a gap, it's noted, but the gaps stand on their own — they need addressing regardless of which network stack is in use, and several would remain even if the branch's telemetry were fully adopted.
Companion documents that discuss remediation from a specific implementation perspective:
-
leios-overlap.md— the branch's two-frame framing (validation vs adaptive). -
leios-testnet.md— operational shape of a measurement campaign. -
leios-main-vs-branch.md— what changes if remediation is attempted frommainvs from the branch.
The report is entirely static-analytical: pick assumed network
conditions, solve for parameters, freeze them. It never asks "should
Leios adapt at runtime to observed conditions?" — that whole class of
levers (voter self-throttle, adaptive S_EB_tx, FFD from a real
"am I going to make my deadline" signal, runtime enforcement of
Recommendation 3) sits outside the model.
Why it matters. Static parameters chosen against assumed conditions degrade catastrophically when reality diverges from those assumptions. Recommendation 3 ("ensure effective tx-submission pre-diffusion") is already unactionable at design time because pre-diffusion is a runtime property. Similar dynamics apply to peer health, cwnd, and mempool freshness. A design that has adaptive behaviour available in principle but declines to specify it forfeits a lever explicitly needed for some of the report's own recommendations.
What could close it. Extend the report with an adaptive-lever chapter treating runtime observation as a first-class design axis; add CIP-0164 provisions on when nodes may/must adapt (see gap #10).
Both π₁ (mempool-miss rate) and α (the "pre-diffusion working"
scenario probability) are treated as system-wide scalars. In reality
they're per-node observations, and whether they correlate across nodes
(all fail together vs fail at different times) is the difference
between global P_cert collapse and graceful mesh degradation. The
report's single-scalar treatment silently assumes maximum correlation
— the worst case — without acknowledging the assumption.
Why it matters. The 12 MB feasibility conclusion depends on
P_cert ≈ 0.497. Under stress, whether that number holds or crashes
depends on failure correlation. If failures are independent, quorum
still meets from healthier nodes; if lockstep, no quorum. The report's
model can't distinguish the two.
What could close it. Empirical measurement of π₁ and α as
time-series across multiple nodes simultaneously (the
mempool-measurements dataset already provides the per-node data for
π₁; α needs per-node computation from EB arrivals cross-referenced
with mempool state). Report the joint distribution, not just the mean.
Downstream consumer. Yves Hauser's §5.6 conditional-CDF analysis
(leios-conditional-diffusion.md)
lists an i.i.d.-arrivals assumption as its caveat 1, which is exactly
this gap. Fixing gap 2 directly quantifies how pessimistic that
caveat is.
The blended-diffusion CDF (report.md:359-436) convolves per-hop
transfer times with a path-length distribution taken from a regular
random graph (2500 nodes, degree 10). Real SPO topology has clustering,
hub nodes, and degree variance that would shift the distribution.
Why it matters. The 14 s blended-diffusion tail probability (14% under Mathis, 99% under CUBIC at 12 MB) is sensitive to path-length skew. If typical paths are 4.5 hops instead of the assumed ~3.6, the whole convolution shifts.
What could close it. Two complementary approaches, both worth doing — and one of them is already substantially built:
-
Direct topology survey. Query each node's peer-selection state (or
use an already-synthesized topology) to derive the graph structure
directly. This artefact exists. The Leios repo carries a
pseudo-mainnettopology atdata/simulation/pseudo-mainnet— 10,000 nodes calibrated against RIPE Atlas latencies, Cardano Foundation connectivity/geography measurements, and real mainnet stake — plus analysis notebooks (post-cip/peer-topology/cfd.ipynbfor the synthesized mesh,post-cip/peer-topology/mpe.ipynbfor the mempool-measurements real testnet). A preliminary read (topology-v1.md) already shows the pseudo-mainnet has degree ~30 and diameter 6 hops — the report's degree-10 regular-random-graph baseline is first-order divergent from the calibrated mesh. Extendingcfd.ipynbwithigraph-based shortest-path calculation would produce the empirical path-length distribution directly. -
Reconstruction from live diffusion. Tag every EB with a stable ID,
log per-node arrival/forward events, join with the peer graph to
reconstruct actual multi-hop trajectories. Detailed operational
shape in
leios-testnet.md's "What requires cross-node correlation", with the path-length-skew role in item 6 of "Dynamics the report doesn't model". Answers: what path-length distribution actually manifests during EB diffusion, which may diverge from shortest-graph-paths due to peer-selection preferences?
The two are complementary: topology survey establishes the structural
ceiling on path lengths (shortest-graph paths through the mesh);
reconstruction reveals whether peer-selection behaviour biases
diffusion onto longer paths than the topology alone would predict. The
four possible outcomes of comparing them — matched-baseline,
peer-selection-adds-hops, structure-is-worse-than-assumed, and
peer-selection-hides-longer-structure — each imply different follow-up
work. See
leios-testnet.md's topology snapshot section
for the outcome table and recommended ordering
(topology-first, reconstruction-second).
Credibility caveat on pseudo-mainnet. The dataset is synthetic but empirically calibrated — marginal distributions match Cardano Foundation and RIPE Atlas measurements, but individual edges are not observed live-mainnet peer relationships (which are not publicly available). Appropriate for aggregate topology questions (path-length, degree, clustering, geography); inappropriate for predictions about specific edges. The ReadMe explicitly warns of imperfections from source-data smoothing.
Downstream consumer. Yves Hauser's §5.6 conditional-CDF analysis
(leios-conditional-diffusion.md)
consumes cdf_blended_delay(s_eb_body_kb), whose
convolution is parameterised by exactly this path-length
distribution. Fixing gap 3 directly improves the analytical input to
Yves's
Rounds are treated as independent Bernoulli trials in P_cert.
Reality has autocorrelation: a heavy round consumes mesh bandwidth
that would otherwise carry tx-submission, raising π₁ for the next
round, which raises blended-diffusion load again — a cascade the
model doesn't capture. Similarly, after any failure, whether the mesh
recovers monotonically or oscillates is unaddressed.
Why it matters. Consecutive-round-failure tail probability is worse than the Bernoulli model implies if positive-feedback autocorrelation exists. Oscillatory recovery indicates latent instability that a static analysis cannot detect.
What could close it. Multi-round measurement or simulation of the
mesh under sustained load; recovery-trace analysis after induced
failures. See
leios-testnet.md's "Cascade to livelock: bounding sustained-overload failure"
for the specific pathological outcome (livelock under sustained
overload), TxCache's role as a partial mitigation, adaptive body
sizing as the actual stabilizing lever, and the measurement
recipes that bound the problem empirically.
The mux itself is fair at the SDU level — round-robin between active mini-protocols on a connection means concurrent tx-submission, chain-sync etc. all get their share during a heavy block-fetch transfer on the same connection. Intra-connection contention is not the gap.
The gap is inter-connection contention on a busy relay's network interface. A relay with 500 concurrent connections shares one NIC's bandwidth across all of them; TCP flows compete at the interface level, and TCP fairness is bytes-in-flight, not per-connection. The report models per-hop transfer time as if each connection has independent access to the wire, which isn't accurate on a busy relay.
Why it matters. Effective per-connection throughput on a busy
relay is interface_bandwidth / active_flows, potentially much less
than a single-flow model predicts. During diffusion events involving
many simultaneous transfers (multiple EBs, or an EB plus catch-up
block-fetch), the per-connection budget can dip below what the report
assumes even at moderate loss rates.
What could close it. Add an interface-contention term to the per-hop transfer model, parameterised by concurrent-flow count. Or validate empirically that busy relays don't hit interface saturation under the test load (aggregate per-connection throughput measurement).
The Mathis-vs-CUBIC discussion is framed as "which model is right for the system", but real SPOs run different kernels: modern Linux CUBIC, older Linux Reno, BSD variants, potentially Windows. The right question is "what's the distribution of effective TCP behaviours across the fleet", not "which mean fits".
Why it matters. A mesh with mixed cwnd growth laws behaves differently than one with uniform behaviour. Adversarial or unlucky nodes on the slow tail of the distribution could disproportionately influence quorum outcomes.
What could close it. SPO fleet OS/kernel survey; per-implementation TCP behaviour characterisation.
The report's Recommendation 5 asks for empirical SPO-path
measurements. It does not address whether the required instrumentation
can run at production scale. If measuring the mesh requires machinery
that itself costs an estimated 5–15% of a CPU core per relay
(unbenchmarked — flagged for measurement in leios-testnet.md), the
"just measure it" prescription is understated.
Why it matters. Frame 2 (runtime-adaptive) depends on production nodes running the same telemetry Frame 1 uses on measurement nodes. If that telemetry is infeasible in production, the adaptive lever can't exist there, regardless of whether the analytical work says it should.
What could close it. Cost analysis of the required instrumentation, mitigation strategies (statistical sampling, protocol-scoping, probe sampling), feasibility gate on recommendations.
Different numbers in the report have very different provenance.
µ_apply and µ_reapply are empirical (from apply-reapply
measurements). p = 10⁻⁴ is an admitted guess. π₁ = 1/6 was hand-tuned
in prior work and updated to 0.06 empirically. Independence
assumptions between hops are stated but not tested. Yet all these
numbers appear in the report at the same rhetorical level of authority.
Why it matters. Decision-makers can't calibrate their confidence in each conclusion without knowing which inputs are measured vs guessed. The 12 MB feasibility conclusion is only as strong as the weakest input in its dependency chain.
What could close it. Uncertainty summary table in the report: per-input classification as measured / hand-tuned / assumed / speculative, with confidence intervals where available.
Adversarial withholding is briefly mentioned (§7 limitation 5), but network-layer adversarial models are not systematically explored. If Frame-2 adaptive behaviours are added, new attack surfaces open (inflating our observed RTT to push us out of the committee, selective ACK delays, targeted mempool poisoning). The current model doesn't cover them.
Why it matters. A protocol that adapts based on local observation is vulnerable to observations being manipulated. Any adaptive lever needs adversarial-robustness analysis before deployment.
What could close it. Explicit adversarial-model chapter covering network-layer attacks against observation-based decisions.
If a voter observes that its local mesh health has fallen below what CIP-0164 assumed, is it allowed to refuse to vote? Required to? Forbidden from? The CIP is silent. This is the largest CIP-shaped hole: Frame 2 exists as a possibility (technically feasible in principle, exposable via reader-view machinery) but has no spec status.
Why it matters. Without CIP guidance, adaptive behaviour becomes a per-implementation choice. Some implementations will adapt, others won't. The effective protocol on the mesh drifts based on implementation-defined behaviour, which is exactly what a spec is supposed to prevent.
What could close it. Add CIP-0164 provisions defining what a voter MAY, MUST, or MUST NOT do based on local network observations. Distinguish advisory adaptations (nodes may) from mandatory ones (nodes must).
If a voter's adaptive decision depends on observed PeerRTT or
observed π₁, does CIP-0164 require nodes to have those observation
capabilities? Currently no. Which means voters that lack the
capability can't (or can't be required to) adapt — and if that's the
majority of the fleet, adaptive behaviour that the CIP allows won't
actually happen.
Why it matters. Enforceability. A spec-allowed behaviour that depends on optional instrumentation is soft — actual protocol behaviour depends on which optional bits happen to be enabled.
What could close it. Specify minimum trace/observation capabilities in CIP-0164. Version the spec by capability tier if uniform requirement isn't feasible.
Recommendation 3 says "ensure effective tx-submission pre-diffusion" but doesn't specify:
- Who ensures it?
- What's the observable failure signal?
- What should a node do when the failure signal fires?
- What's the recovery procedure?
Why it matters. Rec 3 is currently a wish, not a spec provision. If pre-diffusion fails at runtime (as it will occasionally under any realistic adversarial or heavy-load condition), the CIP gives no guidance on protocol response.
What could close it. Convert Rec 3 into a set of CIP provisions: observable-signal definition, response taxonomy (throttle, alert, refuse-to-vote), recovery criteria. Corresponds naturally to the transport-vs-outcome diagnostic framework, but the CIP is the place to define the observable and the response.
As Cardano moves toward multiple node implementations (Amaru, others), the network-layer signals CIP-0164 might depend on may or may not exist uniformly across implementations. If Frame-2 adaptive behaviours are advisory-based-on-local-observation, and observation capability differs per implementation, the effective protocol differs per implementation.
Why it matters. Multi-implementation is a stated goal of Cardano; CIP-0164 needs to be implementable identically across independent codebases. Currently it can't guarantee that where adaptive behaviour is concerned, because the required signals aren't specified.
What could close it. CIP-0164 explicitly enumerates required observations (e.g., "implementations MUST expose per-peer RTT quantiles at 10 s cadence"). This overlaps heavily with gap #11.
For nodes without adaptive-observation machinery (compile flag off, non-Linux OS lacking TCPInfo, alternative implementation without the signals), what does the node do? Fall back to static CIP-0164 values — including at operating points where the static values were chosen without empirical support? The CIP doesn't specify.
Why it matters. Silent fallback to guessed static values in adverse conditions is precisely the failure mode Frame 2 was meant to address. If Frame 2 isn't uniformly available, the fallback needs explicit definition.
What could close it. CIP-0164 states explicitly what non-adaptive nodes do: use static values with a documented safety margin, or refuse to participate in rounds where the safety margin isn't met. Both are legitimate; the CIP has to pick.
The report's Recommendation 5 asks for measurements without saying who runs them, on what topology, over what duration, with what analysis. The report is a plan for analysis; there's no plan for validation of the analysis's inputs.
Why it matters. All the analytical gaps above depend on this meta-gap being closed. Without a validation plan, the report's inputs remain unvalidated, and its outputs remain speculative.
What could close it. Named owners for a measurement campaign
(IOG benchmarking cluster? community SPO participants?
mempool-measurements team?), topology (region coverage, adversarial
edge nodes), duration (weeks not days, for tail-event coverage),
analysis (specific outputs feeding specific CIP-0164 provisions or
report.md sections).
Multiple things the report defers to "operational deployment" actually affect protocol correctness:
- Effective tx-submission pre-diffusion (Rec 3)
- Kernel TCP variant choice
- IW10 / rwnd autotuning defaults
- Instrumentation enablement
- OS choice on the SPO fleet
Each time the report writes "this is operational", it's saying "not
our problem". But if operational failure collapses P_cert to zero,
it is the CIP's problem. Where the spec-vs-ops boundary sits needs
an explicit answer.
Why it matters. Silent operational dependencies are unenforceable. A spec that depends on operational conditions it doesn't require or verify is soft — actual protocol behaviour depends on operators' choices with no verification.
What could close it. Explicit boundary statement in CIP-0164: a list of what the protocol requires operators to provide, with observability requirements attached. Everything not on that list is genuinely operator-optional; everything on it is protocol-critical.
Numbered last, outside the analysis / CIP / meta grouping above, because it spans all three families (report / CIP / implementation).
CIP-0164 requires that the node implementation "prioritize Praos over Leios" (CIP:1187-1209), tolerantly ("does not need to be perfectly strict"). Three problems sit under that one-line requirement:
- The report models no contention. Each fetch is an isolated TCP flow on an otherwise-idle 1 Gbit/s link; Leios bulk competing with Praos RB/header diffusion (and with votes) on shared connections and a shared interface is simply absent from the model.
- The CIP specifies the requirement but not the mechanism, and explicitly flags the hard parts as unsolved: server-side reply reordering, and small-reply/large-reply head-of-line blocking inside LeiosFetch (CIP:1414-1443).
- The mux has no priority classes — egress is fair round-robin at SDU level, with no notion of one connection or protocol outranking another.
"The mux is fair" does not close this: SDU round-robin governs only
scheduling into the bearer. Four couplings still head-of-line block
latency-critical traffic (votes on the 7 s deadline, Praos headers)
behind a 12 MB closure on a shared connection — egress batching, the
FIFO kernel send buffer, TCP loss-recovery (in-order delivery stalls
all mini-protocols on the connection), and typed-protocol reply
ordering (the one the CIP flags). Full mechanism and measurement recipe
in
leios-testnet.md's "Vote diffusion, head-of-line blocking, and Praos priority".
Why it matters. These couplings are how a throughput upgrade becomes a Praos-timeliness regression — the failure mode that would turn Leios from a win into a consensus problem. The certified-EB urgency inversion (a certified EB becomes as urgent as the RB it blocks, CIP:1193-1198) makes the required priority dynamic, not a static weight.
What could close it. A scheduling stack, most pieces in flight but
none merged to main:
-
WFQ + bursting in the mux —
origin/mw/mux-single-peer-performance(merged PR #5351) adds weighted-fair-queuing egress plus a per-protocol burst token bucket; WFQ weights map onto the CIP's tolerant (non-strict) priority. The right primitive; open question is runtime-adjustable weights for the urgency-inversion case. - Reply ordering — the CIP's two-instance LeiosFetch, or the experimental server-side reordering in typed-protocols.
-
Kernel buffer —
TCP_NOTSENT_LOWAT(Linux/Darwin) for the send-buffer coupling. -
Connection separation — the only escape from the TCP loss-recovery
coupling for the most latency-critical traffic; the options (second
TCP bearer / raw UDP / QUIC) and their tradeoffs are fleshed out in
leios-testnet.md's connection-separation section.
The gap is that the requirement is specified while the mechanism is neither specified (CIP) nor shipped (implementation), and the contention is unmodelled (report).
P_cert treats rounds as independent Bernoulli trials, and the report
discusses multi-EB windows only as an edge case. But with exponential
block gaps (mean 20 s) against a 14 s pipeline,
Why it matters. (a) Concurrent EB pipelines share the mesh, so the per-hop-independent-flow assumption (gap 5) and the HOL couplings (gap 17) apply between overlapping rounds, not just within one. (b) On a discarded EB the wasted bytes are specifically its EB-body diffusion and vote traffic — both carry no persistent value once the EB is dropped. The closure transactions are not wasted: any fetched to fill a cache-miss land in the TxCache and are reused by later EBs that reference the same txs. Neither the report nor the CIP quantifies this body-plus-vote overhead, yet at ~50% discard it is a large constant multiplier on EB-body and vote load specifically — and the report models no vote traffic as network load at all.
What could close it. A multi-round load model (concurrent-pipeline
bandwidth sharing) plus wasted-diffusion accounting: bytes per round
split into persistent (closure → TxCache) vs transient (discarded EB
body + votes). Both are directly measurable — see the round-outcome
autocorrelation and cascade recipes in
leios-testnet.md.
The CIP defines a q_egress metric and warns that "at throughput much
higher than 200 kB/s, network egress can become a significant cost"
(CIP:2173-2174), yet Leios "does not require any changes to incentives"
(CIP:1445-1459) — rewards stay block-count-based, with no per-byte
serving compensation. Baseline per-node egress is ~12 MB / 20 s ≈
5 Mbps ≈ ~1.6 TB/month (order ~$100+/month at commodity cloud rates);
big-ledger seed nodes carry a 5–20× multiple (the seed-egress
corollary in
leios-conditional-diffusion.md).
Why it matters. With no serving incentive, a rational SPO can
under-serve (rate-limit Leios egress, decline to be a good seed) or
migrate to cheap-egress providers — both reshape topology
geographically and feed the churn-concentration tendency
(leios-fetch-scheme.md Improvement #8). Egress cost is therefore not
just an operational line item; it is an incentive-compatibility
pressure on the very mesh structure the safety analysis assumes.
What could close it. A per-node egress cost/budget model as an explicit input; a CIP position on whether serving is incentivised, mandated, or best-effort. Directly measurable as per-connection outbound bytes.
At 12 MB / 20 s, chain growth is ~52 GB/day. A node a day behind must
move ~52 GB from its upstream peers while live rounds keep consuming
the same links — sustained inter-connection contention the per-hop
model (gap 5) never covers. Freshest-first delivery, prioritising the
newest EB, structurally starves a laggard's older requests; the
recovery path is MsgLeiosBlockRangeRequest (CIP:1322).
Why it matters. If syncing consumes a large fraction of mesh capacity it competes with live diffusion and can push otherwise-healthy nodes into the tail; a node whose sync rate never exceeds growth-rate-plus-FFD-starvation is a per-node liveness failure. Whether Mithril-class snapshots become protocol-critical (not merely convenient) at Leios throughput is open.
What could close it. A sync-vs-live capacity model; measurement of the sustained mesh-capacity fraction a catching-up node consumes; a CIP position on bootstrap/snapshot expectations at Leios throughput.
Overflowing a per-mini-protocol ingress queue is a protocol violation
that tears down the whole bearer (network-mux's Ingress.hs).
Ingress limits sized for the Praos era (small blocks, headers, tx
batches) may not accommodate 12 MB LeiosFetch replies; if they don't,
heavy rounds produce correlated connection-death storms, and the
reconnect-plus-re-fetch amplifies load exactly when the mesh is
already stressed — a positive-feedback path adjacent to the livelock
cascade.
Why it matters. A sizing oversight here turns a load spike into a connectivity collapse. It is a concrete implementation checklist item specified nowhere today.
What could close it. Size LeiosFetch ingress limits for the maximum closure/EB reply; test teardown behaviour under heavy-round load on the testnet.
Ranked by leverage — which gap being named would most change how the report and CIP evolve:
- The runtime-adaptive lever is unnamed — gaps 1 + 10. The biggest missing frame.
- Pre-diffusion enforcement is a runtime property with no spec status — gaps 12 + 15. Rec 3 has no teeth.
-
Cross-node correlation silently assumed lockstep — gap 2.
Changes what
P_cert ≈ 0.497means under stress. - Instrumentation requirements and their cost — gaps 7 + 11. If Frame 2 exists it must be affordable and required.
- The operational-vs-spec boundary — gap 16. Too much protocol correctness currently lives outside the spec.
- Path-length distribution — gap 3. First-order load-bearing modelling input; pseudo-mainnet already shows the regular-random-graph baseline is empirically divergent.
- Round-to-round feedback and recovery dynamics — gap 4. Real stability question.
- Round concurrency is the norm; wasted diffusion unaccounted — gap 18. ~50% of pipelines overlap and ~50% of EBs are discarded; baseline load, not an edge case.
- Praos priority & intra-connection head-of-line blocking — gap 17. A consensus-regression risk: the CIP requires Praos priority but specifies no mechanism, the report models no contention, and the mux has no priority classes.
- Per-node interface contention — gap 5. A real modelling gap.
- Egress economics and serving incentives — gap 19. Uncompensated egress is an incentive-compatibility pressure on mesh topology.
- Catch-up / laggard sync — gap 20. 52 GB/day growth vs FFD starvation; possible per-node liveness failure.
- Ingress-queue sizing under 12 MB replies — gap 21. Sizing oversight → correlated teardown storms.
- Multi-implementation consistency — gap 13. Future-proofing.
- OS heterogeneity — gap 6. Fleet reality.
- Explicit uncertainty envelope — gap 8. Reader-guidance.
- Adversarial-model coverage of network layer — gap 9. Needed only if Frame 2 is adopted, then critical.
- Fallback behaviour when machinery unavailable — gap 14. Follow-on from gaps 10–13.
| # | Gap | Remediation type |
|---|---|---|
| 1 | Runtime-adaptive lever | Report extension + CIP provisions |
| 2 | Cross-node correlation | Measurement campaign |
| 3 | Path-length distribution | Topology survey (pseudo-mainnet + reconstruction) |
| 4 | Round-to-round feedback | Simulation + measurement |
| 5 | Interface contention | Model extension + measurement |
| 6 | OS heterogeneity | Fleet survey |
| 7 | Cost of measurement | Cost analysis + mitigation design |
| 8 | Uncertainty envelope | Report table addition |
| 9 | Network adversarial model | Report chapter addition |
| 10 | Governance of adaptation | CIP provisions |
| 11 | Instrumentation requirements | CIP provisions |
| 12 | Pre-diffusion failure response | CIP provisions |
| 13 | Multi-implementation consistency | CIP + observation-spec |
| 14 | Fallback behaviour | CIP provisions |
| 15 | Measurement plan | Named owners + campaign spec |
| 16 | Operational/spec boundary | CIP boundary statement |
| 17 | Praos priority & intra-connection HOL | Report contention model + CIP mechanism spec + mux WFQ / reply-ordering / connection-separation (in-flight) |
| 18 | Round concurrency + wasted diffusion | Multi-round load model + wasted-byte accounting (measurable) |
| 19 | Egress economics & incentives | Egress cost model + CIP incentive/serving position |
| 20 | Catch-up / laggard sync | Sync-vs-live capacity model + snapshot position |
| 21 | Ingress-queue sizing | Size limits for max reply + teardown test |
Some concerns the branch or the ecosystem has raised are not gaps in the report/CIP:
- Mux SDU-scheduling fairness between mini-protocols. The round-robin scheduling of SDUs into the bearer is well-understood and is not a gap. (Head-of-line blocking below the mux — egress batching, the FIFO kernel send buffer, TCP loss-recovery, and typed-protocol reply ordering — is a distinct concern and a real gap, tracked as gap 17.)
-
π₁ central estimate from
mempool-measurements. The ~0.06 central value is empirically grounded and the report uses it appropriately — but the grounding is a thin sample (3 AWS nodes, BAU-only, values read off rendered SVGs with no confidence intervals), and it is the central value that is well-founded, not the tail. The dataset's own us-east-2 outlier (π₁ ≈ 0.44 at >85% utilisation) is exactly the load→π₁ coupling the livelock cascade hypothesises (seeleios-testnet.md's cascade section), and is under-explored. So: not a modelling gap in the central case, but the load-dependent tail of π₁ is not closed either. -
CPU-side inputs (
µ_apply,µ_reapply). Grounded inapply-reapplymeasurements. -
The Praos-cap ceiling (
P_cert ≈ 0.497). A schedule property of the leader election; not a gap.
Several gaps are load-bearing on others:
- Gap 15 (measurement plan) is a prerequisite for gaps 2–8 — none of the empirical gaps can be closed without a validation campaign.
- Gaps 10 (governance) and 11 (instrumentation requirements) are interdependent — governance of adaptive behaviour requires specifying the observations it depends on.
- Gap 16 (operational/spec boundary) frames how gaps 10–14 should land: which are protocol-mandatory vs operator-discretionary.
Closing the top-3-ranked gaps (adaptive lever, pre-diffusion enforcement, cross-node correlation) would move most of the report's current speculative content into either measured territory or explicit design decisions. The rest are lower-order refinements.