Ethereum lessons from a live end-to-end PQ proof-native protocol

[ignotusnemo]

There is a lot of discussion here about what an end-to-end post-quantum blockchain stack should eventually look like.

I took the clean-slate route, built one and launched it as a public testnet. A full node can independently verify the network and produce blocks… on my old laptop.

Parano1d protocol is a proof-native L1 ordered by proof of work. Wallet authorization, state transitions and recursive validity from genesis are all carried by a single post-quantum proof stack. Under the explicit premises described below, its security theorem establishes end-to-end pq soundness from genesis against the NIST PQC Category 1 resource envelope.

The source is public, and the current v2.1.0 release includes GUI and Core binaries for Linux, Windows and macOS.

What “proof-native” means here

A Parano1d block is not an execution request that every full node must replay.

The wallet produces a freshly randomized zero-knowledge proof that it knows the 256-bit preimage of the input owner address, bound to the complete logical transaction. The proof reveals no spending secret and contains no public key, digital signature or state path.

The miner then proves the public part: every input exists, every output slot is empty, values and fees balance, and the new state root is the exact result. The resulting recursive proof also verifies the proof carried by the previous block, extending the proven chain of valid state transitions from genesis to the new block.

A node verifies the proof and materializes the proven slot writes. It does not independently re-execute the transaction logic to discover the same transition.

Once a block leaves the recent 18-block reorganization window, the node prunes its full body because active consensus no longer requires it. Permanent compact headers retain the transaction root. A saved payment receipt contains the transaction summary and its Merkle path to that root, so the payment’s inclusion in the canonical chain remains independently verifiable long after the original block body has been removed.

A new node can therefore authenticate a finalized state with its recursive terminal and verify one later terminal at the selected live tip. It does not need to replay transaction execution from genesis or trust a checkpoint.

This is O(1) in chain height for state-validity verification, not O(1) total bootstrap data. State transfer still scales with the live UTXO set, and permanent compact headers remain necessary for cumulative-work fork choice.

The proof stack

The committed trace arithmetic uses GF(2^128), while Fiat–Shamir challenges and recursive authentication use GF(2^256). Poseidon2b is the common permutation for addresses, transactions, Merkle trees, State commitments, transcripts, block identifiers and PoW.

The production permutation is width 4, x^7, 8 full rounds and 58 partial rounds.

The proving pipeline combines GKR, batched sumcheck, zerocheck, lincheck and FRI-Binius/BaseFold without a trusted setup. I developed a global-trace reduction called FROST-GKR for the Poseidon2b and Merkle workload.

In a pinned like-for-like benchmark covering 59 width-four Poseidon2b permutations, FROST-GKR reduced median prover time by 10.69×, protocol-verifier time by 14.80× and raw algebraic proof bytes by 51.67×. The benchmark, reference implementation and measurement record are published here.

Binary fields turned out to fit commodity CPUs well because x86 PCLMUL/VPCLMUL and ARM PMULL directly accelerate carryless multiplication. The released binaries select the appropriate backend at runtime.

These are the current isolated production measurements:

Host	Class	HistoryStep construction	Terminal
Low-cost AVX2 laptop, 12 threads	B25	10.734 s	971,732 B
AVX-512 PC, 24 threads	B25	6.905 s	971,732 B
Low-cost AVX2 laptop, 12 threads	B255	34.938 s	1,081,108 B
AVX-512 PC, 24 threads	B255	21.053 s	1,081,108 B

The public testnet targets a complete 20-second block interval, including proof construction, nonce search and propagation. B25 is the laptop-class production floor; B255 is selected only when the host can sustain it. Full benchmark methodology is documented here.

The security claim, precisely

The production profile has 127 bits of provable Block–Tiwari FS-FRI security and 127 bits under their conjectured RBR premise. The end-to-end security game asks whether one stateful quantum adversary can make the verifier accept an invalid terminal state whose recursive ancestry begins at genesis.

The reduction covers wallet authorization, block relations, parent links, exact state transitions and recursive verification under one adversarial resource budget.

The resulting Category 1 statement is conditional on the explicitly stated fixed-Poseidon2b delta and coherent response-cost premises. It is not a claim of NIST certification or external audit. The complete theorem, finite terms and executable exact-arithmetic certificate are in noid_soundness.

The recent algebraic attacks in ePrint 2026/306 are included in the analysis. The wide tensor-matrix attacks do not apply to the width-four production instance. The applicable Appendix A feed-forward compression case is instantiated directly. What the paper does not establish, the fixed-permutation quantum delta remains an explicit premise rather than being hidden behind “128-bit” shorthand.

I would particularly welcome independent review of this boundary.

What may be useful for Ethereum

Ethereum is already doing serious implementation work on leanXMSS, leanVM, recursive aggregation and post-quantum devnets. The validator registry design also makes clear how tightly hash choice, aggregation and network bandwidth interact.

Parano1d protocol suggests several broader conclusions:

First, post-quantum security is an end-to-end systems property, not a signature replacement. Wallet authorization, recursive proofs, commitments, fork choice and migration assumptions must be evaluated as one path.

Second, the hash function is an architectural decision. It determines trace geometry, recursion cost, Merkle performance, proof size and network behavior. Cryptanalysis cannot be separated from performance engineering.

Third, recursive validity changes the relationship between state and history. Once the accepted state carries a proof of its path from genesis, historical execution stops being part of every new node’s hardware requirement.

Parano1d protocol is not an EVM replacement, it uses a deliberately constrained UTXO model. But it is a complete running artifact rather than a proposed stack.

Source: https://github.com/ignotusnemo/parano1d
Release: https://github.com/ignotusnemo/parano1d/releases/tag/v2.1.0
Documentation: https://docs.parano1d.org
Research: https://lab.parano1d.org

I am interested in technical criticism, especially around the from-genesis security reduction, the fixed Poseidon2b boundary, FROST-GKR and the networking consequences of recursive proof propagation.

[TMerlini]

You invited independent review of the fixed-permutation boundary and shipped an executable certificate, so I did the smallest useful thing: I ran it. Not a review of the soundness argument, I am not the right person for that, but a reproduction, on hardware you have never seen, plus an attempt to make it lie.

What reproduced

parano1d-soundness at cd56eaa, pinned Rust 1.96.0, macOS/aarch64, clean build.

• 26 tests pass.

• Deterministic — two runs byte-identical.

• Every published figure in the README results table reproduces exactly, to the last digit:
  target 128, provable 127, conjectured 127, the sequential ideal-QROM boundary
  64.707407428576, the gate-depth floor 173.273866314232, the margin 3.273866314232, and
  the complete ideal envelope 0.053364140323608411.

Eight for eight, checked by string-matching the README against the program output rather than by eye.

What happened when I tried to break it

I mutated the pinned snapshot and rebuilt. It fails closed, which is the behaviour I was hoping for and did not assume:

queries 65 -> 20     exit 1   "wallet ledger and geometry query count ..."
queries 65 -> 400    exit 1   rejected even though STRONGER
digest 256 -> 64     exit 1   "Poseidon2b digest width is not a whole ..."
entropy 255 -> 8     exit 1   "wallet and C1 challenge supports diverge ..."

The second one is the interesting result. Raising the query count is not accepted, the check is a cross-component consistency invariant rather than a security floor, so an inconsistent snapshot cannot buy itself a better number. And in every case it refuses to emit a security
figure at all rather than emitting a wrong one. Given the subject, that is the right failure direction.

The false finding I nearly posted about your work

Worth including, because it is the honest version of “I checked”.

My first tamper run showed every mutation producing an unchanged PASS / 127 bits. That reads as the snapshot validation is decorative, and I was a paragraph from saying so here.

It was wrong. src/parameters.rs:11 does include_str!("../model/production.toml") , the snapshot is compiled in, so editing the file without rebuilding mutates something the running binary never reads. My mutation changed zero effective bytes and I nearly published the null
result as a finding, against someone else’s security work, in public.

Which is a small instance of your own first lesson pointed at a reviewer instead of a protocol: the thing that failed was not the check, it was my belief about what my check had touched.

The part I actually want to praise, since it is rare

You put provable 127 and conjectured 127 in the same table rather than collapsing both into “128-bit security”, state plainly that this “is not a claim of NIST certification or external audit”, and keep the fixed-permutation quantum delta as an explicit premise instead of hiding it behind shorthand. The certificate even prints the exact condition the conclusion rests on, Delta < 0.446635859676391589.

A number that was proven and a number that was assumed look identical once they are both printed
as “128”. Refusing to let them look identical is most of what honest security reporting is, and
almost nobody does it in the same sentence as the headline.

What I can offer, and what I cannot

I cannot review a FRI soundness theorem and will not pretend otherwise.

What I can do is what I just did, at greater depth and on a schedule: independent reproduction of executable certificates, with mutation testing to establish that the checks discriminate, and the results published so a third party can re-derive them rather than trust either of us. That is the lane I work in, recompute-kit, and a live cross-verification console where several independently implemented nodes recompute each other’s claims.

If a second machine and an adversarial reproduction are useful to you as this moves toward review, I am glad to keep doing it and to publish the negative results with the same prominence
as the positive ones.

One question, in your own spirit rather than as a challenge: has the snapshot validation ever
been observed to reject a change that a reasonable operator would plausibly make, as opposed to the deliberate corruptions I threw at it? A check that only fires on obvious sabotage is
weaker than it looks, and you are better placed than I am to know which realistic edit it would
catch.

[ignotusnemo]

Thank you. This is exactly the kind of independent reproduction I hoped the executable certificate would make possible. I also appreciate that you included your false start. Confirming what an experiment actually changed matters here as much as the final result.

Your interpretation of 65 to 400 is correct. This is not simply a stronger security value. It binds two components to the same production transcript. A larger but inconsistent value describes a different system and must be rejected.

There are two forms of the artifact. The post links to the noid_soundness crate inside the main Parano1d workspace. You ran the standalone parano1d-soundness repository at cd56eaa. The standalone repository embeds a snapshot pinned to a specific Parano1d revision so that the calculation can be reproduced without building the entire project.

The integrated certificate does not use production.toml. It imports the wallet geometry, HistoryStep and BaseFold query counts, History classes, challenge support and Poseidon2b parameters directly from the production prover and verifier crates.

Your final question was the important one. These are not operator settings, so there is no normal operator edit to test. The realistic failure is a coherent but unintended protocol change made during development. I did not have a preserved accidental case, so I tested that case before replying.

In an isolated worktree, I changed the central production BaseFold query count from 133 to 132. HistoryStep obtains its value from the same production constant, so both components remained consistent. I did not modify the certificate or any embedded snapshot.

The certificate accepted the correspondence and recalculated the complete model for profile H132. The sequential ideal QROM boundary changed from 64.707407428576 to 64.207422567298. The Category 1 margin changed from 3.273866314232 to 2.140116311612. The complete ideal envelope changed from 0.053364140323608411 to 0.115101139010768806. The limiting event changed from wallet.query to history.query.

The modified profile still satisfied the stated premises, so the executable correctly reported PASS for that new profile. It did not blindly reject every change.

The release regression suite did reject it. Seven tests failed because the published H133 profile, optimizer boundaries, QROM result, response cost, limiting event and exact numerical conclusions had changed.

That is the important boundary. A coherent production change is allowed to produce a new certificate, but it cannot silently retain the previously published one. The actual production parameters flow through the complete calculation, and any change to the published conclusions requires an explicit review and update.

Your reproduction establishes that the standalone artifact is deterministic and fails closed when its embedded model becomes inconsistent. It does not review the theorem itself, as you clearly stated, but it is still useful independent evidence.

[TMerlini]

You ran the experiment rather than answering from memory, so the useful reply is not thanks, it is the same experiment on the other artifact.

Your H132 profile reproduces on the standalone

I made the equivalent consistent change in the embedded snapshot profile.history.queries,history_step_queries and basefold_queries all 133 → 132, so the correspondence stays coherent, and rebuilt, since include_str! means an unrebuilt binary reads the old snapshot.

Every figure you reported comes back identical, string-matched rather than eyeballed:

sequential ideal QROM boundary   64.207422567298
Category 1 margin                2.140116311612
complete ideal envelope          0.115101139010768806
limiting typed event             history.query          (was wallet.query)
assessment                       PASS

Five for five, and I think this is worth more than the original reproduction was.

Agreement on the published profile is weak evidence: both artifacts could be echoing the same table, and I could not have told the difference. Agreement on a profile neither of us had published, where there was nothing to copy from, is a different kind of check. Your integrated certificate imports its constants from the production prover and verifier crates; the standalone reads a pinned snapshot. Two independently built paths, one previously unseen input, same twelve significant figures.

That is the thing your correction made testable. Before it, “I ran the standalone” was a caveat on my result. Now it is a claim about the standalone being a faithful proxy for the integrated path, and it has been checked rather than assumed.

The standalone guards its published conclusions too

You described the boundary precisely, a coherent change may produce a new certificate but may
not silently retain the old published one. The standalone behaves the same way:

unmodified snapshot   26 passed  0 failed
H132 snapshot         18 passed  8 failed

Your release regression suite failed seven; this one fails eight. Different suites, same
refusal.

The eighth one fails for a different reason, and I think you will want to know

Seven of the eight are what you described: production_profile_is_w65_h133,
current_profile_exceeds_64_sequential_ideal_qrom_bits,
category_one_resource_floor_exceeds_two_to_170, the optimizer boundaries, and so on. Those fail because a published conclusion moved. Correct, and exactly the intended signal.

The eighth is parameters::tests::correspondence_mismatch_is_rejected, and it fails for an
unrelated reason:

let diverged = PRODUCTION_SNAPSHOT.replace("basefold_queries = 133", "basefold_queries = 132");
assert!(load_snapshot(&diverged).is_err());

Under H132 that replace matches nothing. diverged is byte-identical to a valid snapshot, load_snapshot succeeds, and the assertion fails. The test is not reporting that the correspondence check broke. It is reporting that its own tamper anchor went stale and mutated zero bytes.

Two things about that, and the first is praise.

It fails closed, which is the rare and correct behaviour. A no-op mutation produces a red test rather than a green one. The same test written as “corrupt it and check we cope” with the assertion pointing the other way, would have gone green forever while tampering with nothing. I have made precisely that mistake twice this week, once in CI where the mutation step recompiled the artifact and silently undid its own edit. Yours does not have that failure mode.

But it is a different signal wearing the same colour. Seven reds mean “a published number changed, review and republish”. This red means “this test no longer tests anything”. Both end in “update the test”, so in a batch of eight they are easy to conflate — and the second is the one that, left alone, quietly stops discriminating. If it read .replace(&format!("basefold_queries = {}", PROFILE.basefold_queries), ...), or asserted the replace changed something before trusting the result, the two would stay distinguishable.

Small point on a suite that is clearly carefully built. I raise it only because it is the exact class of defect your own first lesson is about: the thing that failed was not the check, it was a belief about what the check had touched.

What this establishes and what it does not

Still not a review of the soundness theorem, that has not changed and I am still not the right person for it.

What is now established, by two independently built artifacts on an input neither had seen: the model is deterministic, it recalculates faithfully under a coherent parameter change, it names a different limiting event when the limiting event genuinely changes, and both artifacts refuse to carry a published conclusion across a change that invalidates it.

Everything above is published so it can be re-derived rather than trusted:

https://github.com/Echo-Merlini/parano1d-h132-reproduction

It contains the full transcript, environment, the control run on the unmodified snapshot, the snapshot diff, the rebuild, the five string comparisons and both test runs, together with the script that regenerates every line of it. The transcript is a capture, not a write-up: each figure in it came out of a command printed directly above it.

Conditions: standalone parano1d-soundness at cd56eaa, rust-toolchain.toml pinning 1.96.0, macOS/aarch64, the three-site consistent snapshot edit shown above, cargo build --release before running.

Two notes for anyone re-running it. Query rustc --version from inside the repository, elsewhere rustup reports the system default, and I had 1.97.0 in a draft of this post for exactly that reason. And rebuild before drawing conclusions, for the include_str! reason in my previous post; I wrote a transcript generator that got this right and still managed three other self-inflicted errors before it was fit to publish, all of the same shape, a step that reported success while doing nothing.

(The repository is under Echo-Merlini, an account I use for tooling and automation. Same person.)

[71104]

Justin Drake tweeted and every other crypto bro be like: “rewrite Ethereum with Binius make no mistake”. Strong AI game right there, bro.

[ignotusnemo]

Justin Drake has a time machine? I started this work in March and Binius has been in the public Parano1d repo since May 1, long before that tweet. Strong chronology game, bro