# Gaps in the DeltaQ report and CIP-0164 ## Preamble This document surfaces gaps in the Leios ΔQ report ([`ouroboros-leios/analysis/deltaq/improved-leios/report.md`](../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`](leios-overlap.md) — the branch's two-frame framing (validation vs adaptive). - [`leios-testnet.md`](leios-testnet.md) — operational shape of a measurement campaign. - [`leios-main-vs-branch.md`](leios-main-vs-branch.md) — what changes if remediation is attempted from `main` vs from the branch. --- ## Report gaps (analysis-side) ### 1. Runtime-adaptive protocol behaviour is not a design lever 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). ### 2. Cross-node correlation of failure modes is silently assumed lockstep 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`](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. ### 3. Path-length distribution assumed as regular random graph 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-mainnet` topology at [`data/simulation/pseudo-mainnet`](../../ouroboros-leios/data/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.ipynb` for the synthesized mesh, `post-cip/peer-topology/mpe.ipynb` for the mempool-measurements real testnet). A preliminary read ([`topology-v1.md`](../../ouroboros-leios/data/simulation/pseudo-mainnet/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. Extending `cfd.ipynb` with `igraph`-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"](leios-testnet.md#what-requires-cross-node-correlation), with the path-length-skew role in [item 6 of "Dynamics the report doesn't model"](leios-testnet.md#dynamics-the-report-doesnt-model-but-deltaq-traces-expose). 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](leios-testnet.md#what-only-needs-a-topology-snapshot-cheaper-than-correlation) 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`](leios-conditional-diffusion.md)) consumes $G(t)$ = `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 $F_{\text{full}\mid C}$ formula. ### 4. Round-to-round feedback and recovery dynamics 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"](leios-testnet.md#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. ### 5. Per-node interface contention across concurrent connections is not modelled 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). ### 6. OS / TCP heterogeneity across the SPO fleet 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. ### 7. Cost of the measurement infrastructure is not addressed 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. ### 8. Explicit uncertainty envelope is missing 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. ### 9. Adversarial-model coverage of the network layer 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. --- ## CIP-0164 gaps (specification-side) ### 10. Governance of adaptive behaviour is unspecified 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). ### 11. Instrumentation requirements are not part of the spec 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. ### 12. Pre-diffusion failure has no specified response 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. ### 13. Multi-implementation consistency 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. ### 14. Fallback behaviour when adaptive machinery is unavailable 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. --- ## Cross-cutting / meta gaps ### 15. The measurement plan itself 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). ### 16. The "operational" vs "in-CIP" boundary 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. --- ### 17. Praos-over-Leios prioritization and intra-connection head-of-line blocking *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"](leios-testnet.md#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](leios-testnet.md#connection-separation-for-latency-critical-traffic). The gap is that the requirement is specified while the mechanism is neither specified (CIP) nor shipped (implementation), and the contention is unmodelled (report). ### 18. Round concurrency is the norm, and wasted diffusion is unaccounted `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, $P(\text{gap} < 14\,\text{s}) \approx 1 - e^{-14/20} \approx 0.50$: about half of all EB pipelines overlap the next one, and ~50% of produced EBs are structurally discarded — this *is* the $P_\text{interrupted} \approx 0.503$ that caps $P_\text{cert}$ at 0.497. Round concurrency and per-round waste are baseline behaviour, not corner cases. **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`](leios-testnet.md#cascade-to-livelock-bounding-sustained-overload-failure). ### 19. Egress economics and serving incentives are unmodelled 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`](leios-conditional-diffusion.md#adversarial-diffusion-and-the-g-adv-counterpart)). **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. ### 20. Catch-up and laggard sync under sustained throughput 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. ### 21. Ingress-queue sizing under 12 MB replies 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. --- ## Priority ranking Ranked by leverage — which gap being named would most change how the report and CIP evolve: 1. **The runtime-adaptive lever is unnamed** — gaps 1 + 10. The biggest missing frame. 2. **Pre-diffusion enforcement is a runtime property with no spec status** — gaps 12 + 15. Rec 3 has no teeth. 3. **Cross-node correlation silently assumed lockstep** — gap 2. Changes what `P_cert ≈ 0.497` means under stress. 4. **Instrumentation requirements and their cost** — gaps 7 + 11. If Frame 2 exists it must be affordable and required. 5. **The operational-vs-spec boundary** — gap 16. Too much protocol correctness currently lives outside the spec. 6. **Path-length distribution** — gap 3. First-order load-bearing modelling input; pseudo-mainnet already shows the regular-random-graph baseline is empirically divergent. 7. **Round-to-round feedback and recovery dynamics** — gap 4. Real stability question. 8. **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. 9. **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. 10. **Per-node interface contention** — gap 5. A real modelling gap. 11. **Egress economics and serving incentives** — gap 19. Uncompensated egress is an incentive-compatibility pressure on mesh topology. 12. **Catch-up / laggard sync** — gap 20. 52 GB/day growth vs FFD starvation; possible per-node liveness failure. 13. **Ingress-queue sizing under 12 MB replies** — gap 21. Sizing oversight → correlated teardown storms. 14. **Multi-implementation consistency** — gap 13. Future-proofing. 15. **OS heterogeneity** — gap 6. Fleet reality. 16. **Explicit uncertainty envelope** — gap 8. Reader-guidance. 17. **Adversarial-model coverage of network layer** — gap 9. Needed only if Frame 2 is adopted, then critical. 18. **Fallback behaviour when machinery unavailable** — gap 14. Follow-on from gaps 10–13. --- ## What could close each gap (summary) | # | 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 | --- ## Not on this list 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 (see [`leios-testnet.md`'s cascade section](leios-testnet.md#cascade-to-livelock-bounding-sustained-overload-failure)), 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 in `apply-reapply` measurements. - **The Praos-cap ceiling** (`P_cert ≈ 0.497`). A schedule property of the leader election; not a gap. ## Where the gaps interact 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.