0xLoopTheory

1/12 I’ve been working on a paper about the post-quantum security of modern zero-knowledge proof systems. Progress on the full paper will slow for a while as I focus on the CISSP, but I didn’t want the core ideas to disappear into private notes.

PLONKish arithmetization is the constraint framework used in the PLONK polynomial IOP. It's the approach used to turn computations into polynomial constraints that a proof system can verify. Heard the term before but never really understood what "PLONKish arithmetization" actually means? In Episode 5 of my series 🎬 I break it down step-by-step. Check it out here: youtube.com/watch?v=9CWS1H…

Got it—then I’d frame it as a proof-system agnostic architecture in principle, but not yet a PQ-plausible instantiation in practice. Groth16 on BN254 is still a structural-break backend in my framework. What concrete successor backend do you see as the serious deployment target, and what tradeoffs (in proof size or verification gas) do you expect when moving from this Groth16 prototype to a truly quantum-resistant one?

@0xLoopTheory but the architect is proof-system agnostic, I'm using groth16 for simplicity

1/12 I’ve been working on a paper about the post-quantum security of modern zero-knowledge proof systems. Progress on the full paper will slow for a while as I focus on the CISSP, but I didn’t want the core ideas to disappear into private notes.

Thank you very much for sharing—I read the ZK-ACE preprint. The shift from transaction-carried PQ signatures to commitment + ZK authorization is an interesting design direction, and it connects to the architectural thesis I’m developing. The key question from my framework is: what’s the proof backend? If the intended deployment is the Groth16-style instantiation reflected in the benchmark numbers, then in my taxonomy that backend remains a structural break: the authorization layer is elegant, but the live verifier is still Shor-vulnerable. Groth16 is exactly the kind of system I classify that way. If the construction instead migrates to a transparent hash-based backend, the picture changes significantly. In that case, I’d be curious about the concrete deployment target and, for any Fiat–Shamir-based instantiation, what the QROM story looks like. My paper treats L2 as the main hinge and L4 as an independent proof obligation for FS-based systems.

Hi, I think this paper can solve some of your concerns: x.com/0xjasonw/statu… (arXiv:2603.07974v2) Instead of stuffing 2.4KB ML-DSA signatures into every transaction (or bloating ZK circuits with heavy lattice arithmetic), ZK-ACE replaces signatures entirely with identity-centric zero-knowledge authorization. ✅ Chain only stores one compact identity commitment (IDcom). ✅ Provers submit tiny ZK proofs proving “this TxHash was authorized by my committed identity” — no signatures, no lattice math, no post-quantum verification on-chain. Key performance numbers (reference implementation, Apple M3 Pro single-threaded): • Circuit size: 4,024 R1CS constraints (Poseidon) • Groth16 proving time: 63 ms median • Verification time: 0.65 ms (651 µs) • On-chain authorization data: 10–20× smaller (320–448 bytes vs several KB) Supports nonce-registry & nullifier-set replay protection, batch aggregation, recursion, account abstraction, and rollup deployment. Proof-system agnostic and fully migratable. This feels like the right shift for true post-quantum readiness. With this new solution integrated with some other breakthroughs, I’ve implemented a new chain (still in my private repo). Algorithm analyzing shows it can achieve significantly higher TPS than Solana while keeping per-transaction costs much lower. Best of all — node verification is extremely lightweight and no GPUs are needed. You can get some ideas from my thread I mentioned above. Would like to hear more from you. #ZK #PostQuantum #Blockchain #AccountAbstraction #Rollups

Is Post-Quantum ZK an Architecture Problem? Here are the notes from an unfinished paper on this subject.

12/12 Particularly interested in feedback from people thinking about ZK system design, deployment constraints, recursion, FRI / Fiat–Shamir / QROM, and real migration paths. encryptorium.medium.com/post-quantum-z…

11/12 I’m not claiming the story is finished. I am claiming that post-quantum ZK should be discussed in a more architectural and deployment-aware way than it usually is. If you think this framing is wrong, incomplete, too neat, or missing important literature, I genuinely want the pushback.

@0xv1bh4 Good luck on your journey! Also important to keep the big picture in mind :)

Inspired by the @0xLoopTheory I’m committing to a 90-day challenge to test my discipline and consistency. Maybe on the other side of these 90 days, I’ll finally see what I’m truly capable of.

MoonMath Manual Study Group incoming - kicks off this thursday March 5 on our Discord server! Find link here->zkhack.dev If you are a beginner & have wanted to build up your knowledge of the foundations underpining zk and SNARKs, this may be ideal for you!

@__zkhack__ Absolutely. It's great to be a part of it. Thank you for everything you are doing! 😊😊😊

@0xLoopTheory Thanks for shoutout :) Happy our community could help on this journey

Some personal reflection today. Roughly 214 days ago, I started what I called the 1001-day challenge. The idea was simple: introduce deliberate consistency into my life and see whether sustained daily effort could meaningfully change my direction. At the time, cryptography and research still felt like something slightly “ahead” of me — something I wanted to grow into. So I began posting daily progress updates. Not for performance, but for accountability. To show up every day. To study mathematics again. To go deeper into cryptography and post-quantum topics. To actually build, write, and understand instead of just planning to. Looking back now after more than 200 days, I can honestly say: The experiment worked. The last months were intense — countless early mornings, late evenings, weekends spent studying, coding, reading papers, rewriting notes, failing, retrying, and slowly understanding things that once felt completely out of reach. And the effects went far beyond spare-time learning. My professional life changed. My understanding of cryptography deepened dramatically. Research moved from an abstract goal to something I actively do. Writing papers became normal. Rust development became part of my daily toolbox. Post-quantum cryptography and long-term security questions have increasingly become part of my day-to-day work. Somewhere along the way, the boundary between career, interest, and curiosity disappeared. I realized something unexpected: I am already at the point I originally hoped to reach after 1001 days. I genuinely enjoy what I’m doing — both in my job and outside of it. I wake up wanting to continue learning. I spend my time working on problems I care deeply about. And I can clearly see a long-term path forward. Because of that, the daily posting itself has started to feel repetitive. The purpose of the challenge was never counting days — it was building direction, discipline, and identity. And once those are established, the counter becomes less important than the work itself. So this is not an announcement that anything is stopping. Quite the opposite. I will continue: • studying mathematics and cryptography daily • working on research papers • publishing tools and experiments • writing technical blog posts • contributing to the ecosystem • exploring PQC and ZK systems • learning, building, and improving What will change is the format. I will stop the daily progress posts and instead share milestone updates from time to time — meaningful progress, publications, releases, insights, and research developments. The 1001-day challenge evolves from a public streak into a long-term roadmap for the next five years. Another thing that became very clear during these 200+ days: None of this happens alone. I owe enormous thanks to the people and communities that shaped this journey: @0xFlint_ — for the inspiration to post consistently and openly share progress. @LeastAuthority — for the MoonMath Manual, which became a constant companion throughout this journey. @Jeyffre — for inspiration, guidance, and showing what long-term dedication in this space can look like. @RareSkills_io — for the ZK book and outstanding educational resources. @RareCodeAI — your Rust course fundamentally changed my ability to build and experiment. @zeroknowledgefm and especially @AnnaRRose — for making complex ideas accessible and for countless hours of learning through conversations and podcasts. @__zkhack__ — for lowering the barrier to entry with incredible resources and community energy. @Zac_Aztec , @aztecnetwork , and @NoirLang — for pushing the ecosystem forward and making privacy-preserving technology tangible for builders. And honestly, many, many more people, researchers, builders, and community members who shared ideas, papers, feedback, encouragement, or simply conversations along the way. The last 200+ days were intense — many hours invested every single day — and it showed. It changed how I work, how I think, and where I’m heading. But this is not a finish line. If anything, it feels like the real journey is just beginning. The outlook from here is simple: write more, build more, publish more, collaborate more — and continue growing steadily within this field. Always open to collaboration, discussion, and shared research. Dedication compounds. Consistency works. And sometimes disciplined curiosity quietly reshapes your life faster than expected. Onward.

@FaithObafemiEsq Thank you 😊😊

@0xLoopTheory Your consistency and discipline is inspiring as I know it's not easy to do