Ethereum lessons from a live end-to-end PQ proof-native protocol
Ethereum lessons from a live end-to-end PQ proof-native protocol
ignotusnemo August 16, 2026, 9:06am 1
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.
gui1196×792 201 KBParano1d 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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61917-what-proof-native-means-here-1)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61917-the-proof-stack-2)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61917-the-security-claim-precisely-3)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61917-what-may-be-useful-for-ethereum-4)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.
2 Likes
TMerlini August 16, 2026, 12:29pm 2
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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61920-what-reproduced-1)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:
Eight for eight, checked by string-matching the README against the program output rather than by eye.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61920-what-happened-when-i-tried-to-break-it-2)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61920-the-false-finding-i-nearly-posted-about-your-work-3)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61920-the-part-i-actually-want-to-praise-since-it-is-rare-4)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61920-what-i-can-offer-and-what-i-cannot-5)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.
1 Like
ignotusnemo August 16, 2026, 1:41pm 3
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.
1 Like
TMerlini August 16, 2026, 2:19pm 4
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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61922-your-h132-profile-reproduces-on-the-standalone-1)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 PASSFive 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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61922-the-standalone-guards-its-published-conclusions-too-2)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 failedYour release regression suite failed seven; this one fails eight. Different suites, same refusal.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61922-the-eighth-one-fails-for-a-different-reason-and-i-think-you-will-want-to-know-3)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.
[](https://ethresear.ch/t/ethereum-lessons-from-a-live-end-to-end-pq-proof-native-protocol/25730#p-61922-what-this-establishes-and-what-it-does-not-4)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.)
1 Like
71104 August 17, 2026, 10:31pm 5
Justin Drake tweeted and every other crypto bro be like: “rewrite Ethereum with Binius make no mistake”. Strong AI game right there, bro. 
ignotusnemo August 21, 2026, 6:23am 6
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 
1 Like
ignotusnemo September 27, 2026, 11:07pm 7
A source update, since I can no longer edit the opening post: its old GitHub links no longer resolve.
GitLab mirror: ignotus nemo / parano1d · GitLab
Since that post, Parano1d has launched on mainnet https://parano1d.org. The latest upgrade extends recursively authenticated live State to programmable rights: a live output commits to a bounded program, policy and persistent counters, and each authorized transition is checked in the recursive block proof. The upgrade also changes block capacity and updates the end-to-end soundness accounting. Its new rules are published but have not yet activated on mainnet.
Current release: Parano1d v2.0.0 - ignotusnemo/parano1d - Parano1d Git
Security model: parano1d/docs/protocol/security-model.md at main - ignotusnemo/parano1d - Parano1d Git
---
Vitalik’s new essay now describes recursive proofs, quantum-safe cryptography and moving beyond the familiar blockchain model as central to Ethereum’s future:
The title of this thread is aging rather well. 