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.0.1 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.0.1
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.