ParanO(1)d soundness under industry metrics

Four recurring terms are used in the comparison. FRI is the low-degree proof family underlying the listed code-based systems. An interactive oracle proof (IOP) lets a verifier query committed oracle data instead of reading an entire proof table. The Toy Problem score is an industry parameter heuristic based on code rate, query count and a field-size cap. Round-by-round knowledge soundness (RBR) instead bounds the extractor's failure at each verifier move; the related $t/e(t)$ convention divides attack work $t$ by its success probability $e(t)$. The table compares scalar scores only within the metric named in each row; it does not treat the underlying protocols as identical objects.

The ParanO(1)d values are derived from pinned production inputs, implemented as executable formulas and fixed by regression tests. Each value retains the scope of the metric that produced it: conjectured parameter score, generalized-RBR knowledge bound or finite work-accounted composition.

Scope and method

Security numbers are easy to compare after their definitions have been removed. That is also when the comparison stops meaning anything. “100 bits,” “96 bits” and “128 bits” may refer to a conjectured query score, a proved interactive soundness error, a relaxed work-per-success definition, a hash primitive or a composed application. The integer is the last step. The attack game and the reduction come first.

This study asks one reproducible question: what does the committed ParanO(1)d proof geometry score under the same classical conventions published by established proof-system projects? Four objects are evaluated separately:

1. the literal Plonky2/Toy-Problem parameter score;
2. a query-work score using the actual production acceptance radius and mandatory pre-query grind;
3. a theorem-backed generalized RBR knowledge bound for the wallet base IOP;
4. finite accepting-path error sums, with grind treatment made explicit.

The results are not averaged or collapsed into one number because they answer different questions. The public repository preserves them as different types and different output sections.

Production inputs, not illustrative parameters

The inputs are copied from ParanO(1)d commit 93b0252317208c20f8a769afb74681aa9389e286. That revision is recorded inside the workbench. A later protocol revision must deliberately update both the source pin and the expected results.

State is the authenticated set of current unspent outputs and consensus counters. HistoryStep is the recursive proof of a block's exact transition from its parent State to its child State. B64 and B255 are its two fixed proof-capacity classes, sized for blocks containing up to 64 and 255 user-transaction pages respectively; they enforce the same validity rules with different constraint-domain capacities.

The wallet geometry is fixed in zk_capsule.rs. The BaseFold query floor, grind and production ladder are fixed in basefold.rs. The independent workbench carries only the values required for the calculation:

pub const PRODUCTION: ProductionParameters = ProductionParameters {
    challenge_field_bits: 128,
    digest_bits: 256,
    wallet_query_count: 64,
    wallet_log_inverse_rate: 5,
    wallet_miss_numerator: 3,
    wallet_miss_denominator: 10,
    wallet_grind_bits: 16,
    max_authorizations_per_block: 255,
    history_query_count: 125,
    history_log_inverse_rate: 2,
    history_grind_bits: 16,
    history_log_message_columns: [18, 19],
};

This duplication is intentional and fail-closed. The production commit is the authority; the workbench is a review artifact. Its tests make a stale copy visible instead of letting a spreadsheet silently outlive the protocol it described.

Metric one: the literal Toy Problem score

Plonky2 implements the familiar rate/query expression and caps it by the field:

where $q$ is the number of queries, $\rho$ is the code rate, $g$ is the pre-query proof-of-work grind and $\lambda_F$ is the field cap. The implementation in the workbench is deliberately literal:

pub fn literal_toy_problem_score(
    query_count: u32,
    log_inverse_rate: u32,
    grind_bits: u32,
    field_bits: u32,
) -> (f64, f64) {
    let raw = (query_count * log_inverse_rate + grind_bits) as f64;
    (raw, raw.min(field_bits as f64))
}

For wallet authorization, 64 * 5 + 16 = 336. For either HistoryStep class, 125 * 2 + 16 = 266. Both are capped at 128 bits by GF(2¹²⁸); the 256-bit digest also has a 128-bit classical collision ceiling. The weakest displayed pipeline component is therefore 128 bits.

The exact label is 128-bit literal Toy-Problem-style conjectured classical parameter score. The score imports a rate-based model; it does not enumerate finite exceptional sets.

Metric two: production-radius query work

The literal rate score does not include the acceptance radius used by the verifier. A second, still conjectured, work score therefore uses the actual miss probability and charges the mandatory 16-bit grind immediately before query sampling.

For wallet authorization, the selected list-decoding radius is $7/10$. A word outside that radius can agree on at most $3/10$ of the source positions. Sixty-four queries miss every discrepancy with probability at most $(3/10)^{64}$:

For HistoryStep, the calculation uses rate $\rho=1/4$, relative distance $\delta=3/4$, domain length $n$ and the production proximity radius

The corresponding score is

The weakest component and the additive composition both round to 100.757887 bits. This is reported as a 100.76-bit production-radius conjectured classical query-work score. It uses the deployed radius rather than the rate alone, while intentionally leaving the finite exceptional sets to the separate analysis below.

Metric three: a 96.047-bit generalized RBR knowledge bound

The wallet result is the theorem-backed part of this study. It uses generalized round-by-round knowledge in the sense of Block, Garreta, Tiwari and Zając. The protocol has 30 verifier moves. Each move receives an error bound $\varepsilon_i$, and the scalar generalized-RBR convention is their maximum:

This is not an accepting-path union. Summing all move bounds here would calculate a different object.

The exact Reed–Solomon geometry

The source affine code has length $n=65\,536$, message length $K=2\,048$, paper degree $k=K-1=2\,047$ and selected radius $\gamma=7/10$. Seven binary folds preserve rate 1/32 and produce eight codeword lengths from 65,536 down to 512.

The calculation applies Theorem 4.6 of Ben-Sasson, Carmon, Haböck, Kopparty and Saraf (BCHKS) with multiplicity $m=3$ and $h=m+1/2=7/2$:

The ceiling is not evaluated with binary floating point. With $S=2^{48}$ and

the workbench checks the integer certificate

Substitution into the positive denominators gives the conservative rational upper bound

so the BCHKS exceptional-set ceiling is $A_\gamma=4\,157\,831\,958$. The fixed main batching discrepancy is a nonzero affine polynomial in the same challenge and contributes at most one additional root:

Why the candidate list contributes no probability

The selected Sudan interpolation has weighted degree 19,660 and $Y$-degree three. Its four coefficient blocks contain 19,661, 17,614, 15,567 and 13,520 monomials: 66,362 unknowns against 65,536 homogeneous constraints, leaving a positive margin of 826. A nonzero interpolant exists, and at most three distinct factors $Y-p(X)$ can occur. The same integer dimension check remains positive on every folded layer.

The bank, companion and mid oracles are the three encoded tables observed at the source, companion-claim and intermediate-fold stages of the authorization protocol. The extractor completely decodes each table, re-encodes every candidate against the observed values, and checks the exact authorization and fold-chain relations. Each list has at most three elements, so at most $3^3=27$ candidate triples are examined. Those 27 checks are deterministic work. They are neither added to nor multiplied into the failure probability.

The 30-move ledger

Phase A is the eleven-round sumcheck that binds the transparent product-sum relation between the owner proof and the public authorization data. The code names in the table identify the exact Fiat–Shamir challenges; their protocol roles are stated first so the ledger can be read without consulting the implementation.

MainGamma is the maximum move. The resulting scalar is

The resulting figure is a 96.047-bit classical generalized RBR knowledge bound for the interactive wallet base IOP. The complete proof note gives the candidate-selector lemma, the doomed-set induction and every move individually.

let rbr = wallet_generalized_rbr_metrics();
assert_eq!(rbr.source_correlated_agreement_bad_coins, 4_157_831_958);
assert_eq!(rbr.gamma_affine_batch_bad_coins, 1);
assert_eq!(rbr.max_restoration_triples_checked, 27);
assert_eq!(rbr.bad_coin_numerator, 4_157_831_959);
close(rbr.generalized_rbr_bits, 96.046_815_693_930_09, 1e-12);

Metric four: finite accepting-path ledgers

Generalized RBR and ordinary accepting-path soundness are not interchangeable. For the latter, the finite error terms are added first and only then converted with $-\log_2$. The initial calculation gives transcript grinding no automatic soundness credit.

For one wallet authorization:

which gives 95.049176 bits. For HistoryStep:

One fixed invalid block containing one false authorization and one false HistoryStep event has the conservative additive bound 84.756737 bits per forgery without grind credit.

Where the grind belongs

The 16-bit grind occurs immediately before query sampling. Applying it only to the later query term, rather than multiplying unrelated finite field exceptions, gives a fixed-invalid-block result of 95.021747 bits. This is the closest ParanO(1)d scalar in the workbench to the relaxed work-accounting convention used in the ethSTARK comparison.

A separate one-shot experiment lets one block contain up to 255 independently attackable wallet proof events:

That union gives 84.490657 bits without grind credit and 87.054734 bits when grind is applied only to the query term. It is not the per-forgery work headline. Under a $t/e(t)$ definition, generating 255 independent attempts also consumes their work; subtracting $\log_2(255)$ after charging all attempts can count the same multiplicity twice. A true multi-target Fiat–Shamir statement needs one global adversarial work or oracle-query budget.

fixed_invalid_block_finite_no_grind_bits:
    union_probability_bits(&[
        wallet.finite_no_grind_bits,
        limiting_history_finite_no_grind_bits,
    ]),

fixed_invalid_block_query_grind_only_bits:
    union_probability_bits(&[
        wallet.finite_query_grind_only_bits,
        limiting_history_finite_query_grind_only_bits,
    ]),

The executable record

The calculation is published as a small independent Rust repository rather than embedded in the node. It has no consensus role and changes no network parameter. Its purpose is to make the formulas inspectable, executable and sensitive to parameter drift.

git clone https://github.com/ignotusnemo/parano1d-soundness.git
cd parano1d-soundness

cargo run --release
cargo test --release
cargo clippy --all-targets --release -- -D warnings
RUSTDOCFLAGS='-D warnings' cargo doc --release --no-deps

The tests pin the production source revision, the literal Toy Problem values, both HistoryStep classes, the 2⁴⁸-scale square-root certificate, all eight BCHKS ceilings, the list-size-three interpolation certificate, the exact 30-move RBR ledger and each finite composition. In particular, one regression test states that the 27 candidate triples are deterministic extractor work and must never appear in the error numerator.

Interpretation of the results

The reported values are intended for like-for-like comparison within their named metrics:

• 128 bits is the literal Toy-Problem-style conjectured classical parameter score.
• 100.76 bits is the production-radius conjectured classical query-work score.
• 96.047 bits is the theorem-backed classical generalized-RBR knowledge bound for the interactive wallet base IOP.
• 95.022 bits is the fixed-invalid-block work-accounted finite composition under the stated grind convention.

These definitions match the comparison table at the beginning of the article and are preserved in the executable output. Each value is used only within its named metric.

Primary sources

• Ignotus Nemo, ParanO(1)d soundness.
• Wallet authorization: a 96.047-bit generalized RBR bound.
• Plonky2 security statement and its literal parameter calculation.
• RISC Zero soundness calculator.
• StarkWare, Safe and Sound: A Deep Dive into STARK Security.
• Block, Garreta, Tiwari and Zając, Fiat–Shamir Security of FRI and Related SNARKs.
• Block and Tiwari, On the Concrete Security of Non-interactive FRI.
• Block, Garreta, Tiwari and Zając, On Soundness Notions for Interactive Oracle Proofs.
• Ben-Sasson, Carmon, Haböck, Kopparty and Saraf, On Proximity Gaps for Reed–Solomon Codes.

Ignotus Nemo