Overview The post explores PQ-Verkle—a variant of Verkle trees potentially adapted for post-quantum (PQ) security—and its role in addressing Ethereum’s ever-growing state size. It frames the discussion by asking: What problems does Verkle solve, what are its key advantages, what do critics say, and can we “harden” it for a post-quantum world? The Problem: Ethereum’s Growing State State Bloat and Hardware Demands:Ethereum’s state is continuously expanding, which increases storage and I/O requirements for nodes. This rise forces full-nodes to manage large witness sizes (proofs of state), making it costly in terms of disk access and bandwidth. Statelessness as a Goal:The ideal is to enable nodes to verify blocks without storing the entire state locally. Verkle trees aim to reduce the witness size dramatically, lowering the barrier for participation and improving network efficiency. What Makes Verkle Trees Attractive? Efficient Storage Proofs:Reduced Data Needs:Verkle trees use vector commitments (VCs) that compress proofs. Instead of including multiple sibling nodes (as in Merkle trees), only one commitment per tree level is needed. Scaling with Arity:A higher arity leads to a shallower tree, resulting in fewer VC openings per proof. This efficiency becomes more pronounced as more leaves (state entries) are proven simultaneously.

While revisiting EIP6800 (Unified Verkle Tree as ethereum's state structure) I asked myself the following questions: What problem are we actually addressing? What properties did we actually like from Verkle? Would Verkle be the best solution in a non-PQ-existant world? What do researchers dislike about Verkle? Can we actually harden Verkle? The overall goal of this post will be to answer these questions and try to share all the knowledge obtained within the process.

Imagine being able to do the following: You want to perform a search in your browser. But you don't want the browser itself to know anything about your query (essentially, what you're looking for). And you still want the browser to be able to return you an encrypted list of pages that only you can decrypt. To later visit without anyone knowing you even searched for them. This is the core idea and motivation behind this post. Fully_Private_Browser_Search_Symbolic :::warning This idea was given to me by Matan Prasma when discussing about FHE usecases. He told me that he explained that to his alumni sometimes. And I thought the proposal was really interesting. Hence, all the contents of this doc are simply an elaboration and extension of the main idea that Matan gave me/told me about. :::

I assume that people might not have the time to watch this. But this is a talk from Carisa Veliz. And it's pure gold on understanding why Privacy matters. Much more that you could even anticipate. Carissa Véliz is an associate professor in philosophy at the Institute for Ethics in AI, and a fellow at Hertford College at the University of Oxford. She works on privacy, technology, moral and political philosophy, and public policy. Véliz has published articles in media such as the Guardian, the New York Times, New Statesman, and the Independent. Her academic work has been published in The Harvard Business Review, Nature Electronics, Nature Energy, and The American Journal of Bioethics among other journals. She is the author of Privacy Is Power (Bantam Press) and the editor of the forthcoming Oxford Handbook of Digital Ethics. This talk essentially ilustrates the dangers to which society is quietly being exposed and overthrown to. By evil companies, careless governments, uninformed parents, data brokers etc.. in whose interest your privacy or life doesn't have any place or relevance. The problem While I understand is not our task to educate people on why privacy matters directly, I also feel a lot of times that if we don't do it, who is going to?

Please, try to refer to sections or pages of the paper that are related to the question topic you're writing about. CCS Is the mermaid diagram acurate? Is it missing anything? Does it relate/map 1:1 to this section? HyperNova Multifolding

++Table of contents++ Credits This document has been possible thanks to the reviews of @asn-d6 and @oskarth as well as the immense help from @arnaucube and Edu(from PSE) who almost completely derived R1CS&Plonkish -> CCS. Also thanks to Srinath Setty for his help on any question we've had while reading his paper as well as while elaborating this doc. CCS and R1CS (an intro) Due to NP-completeness equivalence, we can easily translate any R1CS statement and translate it into a CCS statement which is completelly equivalent. To do so, it contais certain information as:

++Table of contents++ This document outlines the design of an FHE-based crypto-frog arena. The idea is that we can use the POD-ed version of FrogCrypto to actually use the frogs to battle against eachother! :::success YOU CAN TEST THE ARENA HERE: https://github.com/CPerezz/phantom-zone/blob/frogcrypto_arena_example/examples/frog_arena.rs To run: $ cargo run --release --example frog_arena --features "non_interactive_mp"

++Table of contents++ Ideas from routing Use Dijkstra's algorithm to examine the reputation towards a peer Dijkstra's algorithm allows to compute the shortest path between two points of a graph. It's widely using by most of today's routing algorithms. On key feature of the algorithm is that it doesn't only provide the user with the shortest path to a point in the graph. But also is able to provide with the paths $\geq{X}$ steps compared to the shortest one. With that, seems a bit easier to not only provide 1st level trust paths to a peer but rather also 2nd and 3rd.

++Table of contents++ Credits This document is a conjunt work between CPerezz, arnaucube and dmpierre. (hyperlinks to be added). Project description Folding-schemes team is a project within PSE that aims to do 2 major things: Perform research, implement and optimize the most significant Folding Schemes published so far. Implement use cases that showcase the power and leaverage that you can get while using folding schemes.

++Table of contents++ Abstract The paper introduces BitSNARK and Grail, systems designed to optimize Bitcoin Rollup Bridges. BitSNARK is an improvement over BitVM, providing better efficiency and reduced complexity for verifying SNARK proofs on the Bitcoin blockchain. Grail implements BitSNARK, enabling practical and scalable Bitcoin Rollup Bridges. Introduction The paper discusses the historical challenges of scaling Bitcoin while maintaining decentralization and computational expressivity. Gregory Maxwell's introduction of SNARKs as a potential solution remained theoretical due to perceived implementation barriers. Robin Linus's BitVM in 2023 demonstrated the potential for Turing-complete smart contracts on Bitcoin, but practical limitations persisted. BitSNARK aims to overcome these limitations, optimizing for SNARK verification and reducing complexity. BitSNARK BitSNARK is a software library for verifying SNARK proofs on Bitcoin. It focuses on zkSNARK verification, offering a faster and less costly solution than general-purpose systems. The BitSNARK VM uses a simplified register-based processor with three instructions (addmod, andbit, equal), making the verification protocol more efficient and secure.

Goal: See if GKR can be the next big thing and whether it will only be useful to make some protocols better or can actually mean a change in paradigm in the ecosystem. The expected outcome of the stay would be to have answers to the questions & topics below: Things to explore: GKR aggregation perf/complexityLev Soowon(GKR full recursion impl using circom / observed that proof size linear to the recursions)I think it is because of an overhead of compilation of circom circuit (R1CS) to layered arithmetic circuit. So it can be improved by implementation of native layered arithmetic circuit - Soowon GKR verification inside of a KZG Proof

++Table of contents++ :::danger Fix the offsets at which the randomness start. Check Chiesa's talk to widen the explanations: https://www.youtube.com/watch?v=N1-67VPrsbA ::: The Sum-Check protocol First formalized by Lund, Fortnow, Karloff and Nisan [LFKN92].

Nova-based ZKVM spec Abstract We propose a ZKVM based on Nova/SuperNova. Nova allows us execute repetitive blocks of code more efficiently using Incrementally Verifiable Computation (IVC) and a so called folding scheme. SuperNova generalizes this to work on different blocks of code using Non-uniform IVC (NIVC). This fits well with the instruction set in a VM. Both Nova and Supernova allows us to parallelize significant parts of the computation and also doesn't require FFTs. Taken together, this suggests there should be significantly faster proving time, and lower memory usage. By mapping Intermediate Representation (IR) and its opcodes to individual IVC steps, we can prove execution of small blocks of repetitive code more efficiently. This leverages existing compiler infrastructure and hot-path optimizations. We propose a design that deals with VM state updates using vector commitments. Each computation step can be folded up in a binary tree that is amendable to be parallelization. The final fold ensures the integrity of the entire computation, and is wrapped up in a SNARK at the very end to achieve succinctness. This work can be applied to both to proving ZK-WASM and ZK-LLVM execution and we sketch out what this looks like, as well as give an example of a toy VM. The proposed architecture is especially interesting for unbounded computation execution proving (unlike the EVM with gas) due to not having the same limits around roots of unity and memory consumption, such as in Halo2.

As done by Polygon with Fri/Starks and Groth-16, would be nice to know how worth would it be to use IPA for complex and ammortization friendly situations, projects or schemes, and verify the final proof (Decider) with a KZG-based proving system such as TurboPlonk or similar. Enabling then succint constant and sub-linear verification times. This is particularly useful for projects like the ZKEVMs, rollups, Proof of Validity of a chain etc.. Where we might have no constraints or limitations for the prover but we have a restricted envoiroment where we must verify the proofs (like the EVM). How we got here? Well, the first impression that we had was that why not using Pluto-Eris curves which have a cycle (so we can recurse with them) and where Pluto in particular has a Pairing too? The curves have a larger field-size than Bls12-381. (446 bits to be exact). This will imply slower operations for all algorithms such as: ECDSA, ECDH... Proof sizes will become bigger. Same with SRSs, key pairs etc.. Prover requirements in terms of computation and memory will also increase accordingly.

2023-01-03 Done/To-Do OnurSSHPlonk improvements review. Brecht/MSM improvements and how to apply to MSM circuits. Fixed-base MSM impl. Understand hyperplonk (Han's code). Review https://github.com/privacy-scaling-explorations/halo2/pull/114 Ask @ed255 about Inputs to ECC chip. Han