Quantum Transition Labs · QTL
Research ↗

SILMARILS on Permissioned Ledgers

Compare 160-byte information-theoretic TDV authentication against NIST post-quantum signatures — with live crypto, bandwidth models, and TPS impact.

160 BSILMARILS signature
15×smaller vs Dilithium-2
93%auth bandwidth saved
—hybrid vs full PQ retrofit
Not a Dilithium replacement. SILMARILS is designated-verifier (TDV): validators verify locally; public audit is receipt-controlled.

Live authentication flow

P1 signer → P2 mempool → P3 validator (designated verifier)

What this simulation does
  • Runs a real two-party SILMARILS sign/verify cycle in your browser (Web Crypto + BigInt field arithmetic).
  • Sign & verify — P1 signs the JSON payload; P3 (designated verifier) checks the real signature.
  • Simulate as DV — P3 verifies a simulated receipt (same size, different randomness) to show TDV behavior without re-signing.
  • Timings are local micro-benchmarks only — not network latency or batch verification.

Formulas

σ ← Sign(k_sig, m)                 // P1 produces 160-byte receipt
valid ← Verify(k_sig, m, σ) ∈ {0,1} // P3 designated verifier
|σ| = 160 B                          // fixed TDV receipt size
t_sign, t_verify = local wall-clock (µs)
P1
Signer
tx + σ
P2
Holder
relay
P3
Validator / DV
Real verify—
Simulated verify—
Signature size—
Sign / verify—

TPS impact calculator

CPU and bandwidth bottlenecks on the transaction hot path.

How TPS is modeled
  • CPU-limited TPS — compares total sign+verify CPU per block to the block interval (blocks/min). If auth CPU exceeds block time, TPS drops proportionally.
  • Bandwidth-limited TPS — the tighter of two caps:
    • Block auth cap — max authentication bytes allowed per block (consensus payload limit).
    • Network link — sustained auth throughput vs validator link speed (Mbps).
  • Combined (bottleneck) — min(CPU TPS, bandwidth TPS). This is the effective TPS shown on the cards and the rightmost bar group.
  • SILMARILS Hybrid — fixed ~2% CPU overhead (session-layer SLH-DSA + SILMARILS on hot path); bandwidth uses SILMARILS auth bytes.
  • Full PQ retrofit — separate industry benchmark (~87% loss); not derived from the same CPU/bandwidth formulas.

Formulas

T_block = 60 000 / (blocks/min)                     // block interval (ms)

CPU_loss% = min(95, 100 × CPU_auth / T_block)
CPU_auth = (N_sign × t_sign + N_verify × t_verify) / 1000   // ms per block

BlockCap_loss% = min(95, 100 × (1 − B_cap / B_auth))   if B_auth > B_cap, else 0
Net_loss%      = min(95, 100 × (1 − C_link / R_auth))  if R_auth > C_link, else 0
  R_auth = B_auth × (blocks/min) / 60                  // auth bytes/sec
  C_link = (Mbps × 10⁶) / 8                            // link bytes/sec

BW_loss% = max(BlockCap_loss%, Net_loss%)
TPS_CPU  = TPS_base × (1 − CPU_loss% / 100)
TPS_BW   = TPS_base × (1 − BW_loss% / 100)
TPS_eff  = min(TPS_CPU, TPS_BW)                      // combined bottleneck

Hybrid: CPU_loss% = 2% (fixed architecture estimate)
Retrofit: TPS_eff = TPS_base × 0.13                  // ~87% industry loss
SILMARILS Hybrid — —
SILMARILS (full hot path) — —
Dilithium-2 (full hot path) — —
Full PQ retrofit benchmark — —

Effective TPS: CPU vs bandwidth vs combined

Grouped bars per scheme — blue/gold = CPU/bandwidth limits; accent/red = combined bottleneck TPS.

Chart formula 
For each scheme s:
  bar₁ = TPS_CPU(s)    = TPS_base × (1 − CPU_loss%(s) / 100)
  bar₂ = TPS_BW(s)     = TPS_base × (1 − BW_loss%(s) / 100)
  bar₃ = TPS_eff(s)    = min(bar₁, bar₂)
Scheme CPU TPS CPU loss BW TPS BW loss Combined Bottleneck

Hybrid: SILMARILS on consensus + user auth, SLH-DSA at session layer (~2% CPU). Full retrofit: industry 84–90% TPS loss range (whole-chain PQ migration).

Ledger workload model

Authentication bandwidth and CPU by scheme.

What the ledger model counts
  • Each block includes user transactions (85% of txs/block) and consensus messages (validators × (validators−1) × 3 rounds).
  • Every message carries one signature → auth bytes/block = sig size × (user txs + consensus msgs).
  • Verify CPU assumes each validator verifies user txs once and incoming consensus msgs from peers.
  • Charts compare raw signature size and total auth payload — this is where SILMARILS’s 160 B vs Dilithium’s 2.4 KiB shows up most clearly.

Workload formulas

N_user  = ⌊txPerBlock × 0.85⌋
N_cons  = V × (V − 1) × R              // V validators, R consensus rounds
B_auth  = |σ| × (N_user + N_cons)     // auth bytes per block
MiB/min = B_auth × (blocks/min) / (1024²)
CPU_verify (ms) = (N_user + N_cons × (V−1)) × t_verify / 1000

Signature sizes (log scale)

Chart formula 
Y-axis (log₁₀): |σ| in bytes
X-axis: scheme name
Source: catalog sigBytes per PQC primitive

Auth bytes per block

Chart formula 
Y-axis: B_auth = |σ| × (N_user + N_cons)
Uses slider values: V (validators), txPerBlock, blocks/min
Scheme Sig Verifier Auth / block Auth / min Verify CPU

Hybrid deployment stack

Why hybrid, not full replacement
  • Public bridges and governance need public verifiability (ML-DSA / SLH-DSA).
  • High-frequency consensus and user auth use SILMARILS TDV — 160 B receipts between known validators.
  • Transport stays on TLS 1.3 with pairwise ksig keys; PQ migration is layered, not a single swap.
  • Governance / bridge ML-DSA / SLH-DSA (public verifier)
  • Consensus + user auth SILMARILS TDV receipts
  • Transport TLS 1.3 → pairwise ksig

References