Equilibrium Infra Bulletin #10: Proof System Diversification, powdr zkVM Toolkit, and Overview of ZK Tooling & Proof Systems
Equilibrium Labs builds the state-of-the-art in decentralised infrastructure. We are a global team of ~30 people who tackle challenges around security, privacy and scaling.
This newsletter allows us to share more about what we read, what excites us and what we think is relevant to the space. In addition, you will get a glimpse into the organisation and our culture. We are now also on Telegram.
Research, Articles and Industry News:
📚 Why Multi-Prover Matters (Taiko) - Recommended by Joakim:
ZK-Rollups, circuits, and SNARKs are complex and the technology is still quite immature. Using a multi-prover approach can hedge the risk of bugs and vulnerabilities in proving systems, architectures, and implementations. Taking a multi-prover approach can include:
Different proof types: Fraud proofs (optimistic rollups), validity proofs (zk/validity rollups), SGX, etc. These all rely on different assumptions and have different security guarantees, which adds diversity.
Different proving systems: In the case of validity rollups, for example, one could utilise both SNARKs and STARKs.
Different implementations by different teams: reduces the risk of having the same bug across all implementations, if they are built by different teams and potentially even in different languages.
One unresolved question is how these different proof systems would interact. One option is to have one proof system as the leading one, with the rest acting as backups if the main one fails. Another solution would be to have an N-out-of-M solution, where for example 2/3 proofs need to be valid for the overall block to be valid. With two proof systems, Taiko proposes that multi-sig governance could be used to resolve an emergency situation where one or more proof systems have completeness issues. However, all of these are still up for debate and require further testing to find the optimal solution.
Key Takeaway: Proof systems are a crucial safety component on L2s, but the technology is still quite immature. Having multiple proof systems can hedge the risk of bugs and vulnerabilities in proving systems, architectures, and implementations. A useful mental model is to compare multi-proof on L2s to client diversity on L1s. Several teams, including Optimism and Taiko, are actively exploring this topic.
📚 Powdr - A zkVM toolkit - Recommended by Teemu:
Powdr is a zkVM language & compiler toolkit (rather than a specific zkVM implementation) that makes it easy to build zkVMs by abstracting away low-level constraints and prover complexity. While custom zkVMs have some performance-related benefits (more fine-tuned and optimized), they are also difficult to audit, inflexible, and often prover/proof system-specific. Powdr aims to change this.
The high-level 𝑝𝑜𝑤𝑑𝑟-𝑎𝑠𝑚 language can be used to define VMs and programs, and these programs are later compiled into a low-level constraint language. There are two stages to the process:
The compiler reduces a program made of virtual and constrained machines to a set of AIRs (Algebraic Intermediate Representation).
The linker is used to turn an AIR tree into a single PIL (Polynomial Identity Language) file.
Source: Powdr
One of the benefits of powdr is that it’s flexible to both the frontend language and backend target (inspired by existing and established compilers, such as LLVM). On the frontend, besides programs written for custom VMs, powdr can take RISCV and LLVM programs and create ZK proofs of execution. Integrating other VMs such as WASM happens seamlessly at the language level, which means that the same compiler middleware could be used to generate ZKPs for programs written in Rust, C++, Solidity, AirScript, etc. The powdr-PIL can be used to generate proofs using multiple backends, such as Halo2, eSTARKs, and Nova (integration in progress).
Key Takeaway: Powdr is a toolkit to build VMs, rather than a specific zkVM implementation. The flexibility of powdr is demonstrated through its support of multiple frontends and backends (provers). As an example, you can write code in (no-std) Rust, which is compiled to RISC-V, then to powdr-asm, and finally to PIL.
📚 An Opinionated Overview of ZK Tooling and Proof Systems Right Now - recommended by Hannes:
It’s easy to be overwhelmed when first entering the ZK space. Not only are there several different proving standards and a constant stream of new papers being released, but the content is also often quite technical and scattered around. This blog gives an introduction to the different components, the tradeoffs between them, and links for further reading.
Some summaries from the post include:
Circom is useful for client-side proofs in the browser that are very small (i.e. hashing), or server-side proofs you want to prove on-chain, where privacy is less critical.
plonky2 can bring fast server-side proofs (compromises on privacy with outsourcing) but is less proven than some of the other options. Well suited for zk/validity rollups which use ZKPs for scaling (zkEVMs)
Nova-based folding schemes are useful for ultra-fast client-side proofs if you only have one repeated operation in the circuit, like many rounds of hashing.
Key Takeaway: ZKPs are hard, and a lot more work is needed to bridge the gap between very technical and very introductory content. While this post is not fully comprehensive, it serves as a good introduction to existing solutions and offers links for further reading for those who are interested in going deeper.
Personal recommendations from our team:
📚Reading: In Order to Live - Yeonmi Park: The story of human rights activist Park and her road to freedom after fleeing North Korea at age 13 with her mother.
🎧Listening: LEJ - Summer 2023: While autumn is slowly taking over (at least here in Europe), this medley serves as a welcomed throwback to summer.
💡Other: Blockchain Payments: It only took 15 years, but the payments use case of blockchains is finally starting to see real-world adoption🔥
