CIRISServer — benchmarks, interpreted

The CEWP crux use case — stream and store at massive scale — measured and interpreted. Receivers are charged open-only; every blended figure names its model. Raw criterion numbers at the bottom. Absolute µs are host-relative (this run's runner); the ratios and ceilings travel.

PQC group video is effectively free at steady state. the steady-state frame path runs at up to 2.2 GiB/s (AES-256-GCM — quantum-irrelevant at 256-bit); the post-quantum tax is ~83 µs once per peer-link, never per frame.

Video throughput — realtime A/V mesh (two-layer hybrid-PQC)

Per frame: inner AES-256-GCM (E2E epoch DEK) → wire codec → outer AES-256-GCM (per-Link transit key). seal is the sender's cost; open is the receiver's (it never re-seals).

A 50-person room costs ~0.5% of one core to receive

…under a stated model: 720p, 30 fps, GOP=30 (1×64 KiB keyframe + 29×16 KiB inter per second), receiver opens 49 streams. Range across motion: ~0.17% (low-motion 4 KiB) to ~0.45% (typical 16 KiB), receive-only. Publishing one stream to the room is ~0.24% of a core. Crypto is nowhere near the bottleneck — bandwidth and the network are.

Post-quantum overhead — the hybrid handshake (per peer-link, one-time)

The only place the post-quantum cost can live: bulk frames are AES-256-GCM (already quantum-fine), so the PQ cost is structurally confined to the KEM at session setup. Per-frame PQC cost is zero.

Mesh fan-out — sender cost per frame (16 KiB)

naive = N× full seal_av_chunk. shared_inner = v3.7.0's seal_av_inner once + seal_av_outer per Link (CIRISEdge#122) — wire-identical, inner AEAD done once.

Membership-change rekey — the churn path (projected)

Each join/leave rewraps the fresh epoch DEK to the member-set. flat = O(N) (the unicast-mesh baseline, #129). tree = O(log N) (the TreeKEM optimization, needs multicast, #66). The outer per-Link key is not re-KEX'd on churn (KEX is one-shot per session).

A 50-room paying the flat baseline spends ~3.41 ms per membership delta — ~10.2% of a single 33 ms frame, or ~0.34% of a core at one join/leave per second. Affordable even unoptimized; the tree (#66) removes it as a concern. Steady-state video is untouched by churn.

Replication speed — CEG-RC5 corpus ingest (the "store" spine)

What a node pays per replicated trace: Ed25519 verify → decompose → persist (5-tuple ON CONFLICT DO NOTHING dedup — not a content-hash lookup).

The finding: re-delivery saves only ~10.8% over a fresh insert — because verify runs before dedup, a duplicate still pays full Ed25519 verification. So a replay / gossip flood is bounded by verify throughput, not a cheap reject. This is deliberate (verify-before-mutation; reordering dedup ahead of verify is an AV-9 suppression oracle — the dedup key is attacker-controllable). The scale levers are the pre-verified relay path (VerifyMode::TrustPreVerified gated on an Edge verify_outcome) and batch verification (CIRISPersist#225) — not dedup-first.

Assumptions

• single thread, one core; real deployments fan out across cores
• frame sizes are representative codec outputs, not a live encoder; the GOP blend states its model inline
• receivers are charged OPEN-ONLY — a node never re-seals frames it receives
• 30 fps reference for all per-second / % -of-core figures
• membership-change rekey is PROJECTED from the real hybrid-KEM primitive — the substrate does not implement it yet (CIRISEdge#129); steady-state cost is unaffected
• crypto + wire-codec + persist spine (CIRISServer-owned); excludes the RNS network hop (bandwidth/RTT-bound) and codec encode/decode
• 100% hybrid PQC, hard cut — Ed25519+ML-DSA-65 sigs, X25519+ML-KEM-768 KEM, no classical-only path