In this fireside chat, we invited Tamir Hemo, Head of Cryptography at Succinct Labs, to discuss the architecture, roadmap, and security of SP1 — Succinct’s zero-knowledge proving system.

Tamir discusses his work on scaling SP1 for production-grade ZK compute, the cryptographic design choices behind the system, Ethereum Foundation’s Ethproofs initiative, and what’s coming next for the ZK-VM infrastructure.

The conversation was hosted by Ben Sepanski, CSO at Veridise, and filmed on 17th November 2025 in Buenos Aires.

See the full timestamps and text summary below.

Timestamps

00:00 – What is SP1, and how does it fit Succinct’s mission?
02:31 – How is a ZK-VM more general than bespoke ZK circuits?
03:30 – Was Hypercube the first EthProofs ZK-VM with real-time proving?
04:30 – Which design decisions enabled SP1’s current performance gains?
07:36 – How to balance theoretical designs vs arithmetic optimizations?
10:19 – What SP1 attack surfaces concern you? How do you mitigate them?
14:04 – How is working with interactive theorem provers different from SMT-solver–backed tools like Picus?
15:36 – How does integrating more tools affect system design, and what tools do you still wish existed?
18:18 – When add a precompile, and how does it affect security?
20:24 – Is “compile-to-circuit” a useful dual to the ZK-VM model?
21:12 – What guarantees should the prover offer, where should it run, and what are the privacy risks?
24:04 – Could incremental proving (small local proof + larger server proofs) be a possibility?
26:14 – With evolving cryptography (e.g., proximity gaps), how do you prioritize threats and balance proofs vs. conjectures?
29:23 – What new cryptography or future SP1 work excites you?
32:01 – What SP1 applications excite you most?
34:45 – What does the new prover network enable vs. the earlier private proving service?
36:55 – Any timeline for achieving a at-home proofs for 99% of blocks?
39:34 – What bottlenecks keep the last 1% of blocks from fitting <12s? 42:08 – Are adversarial blocks an attack vector against the prover? Which EVM opcodes are the biggest “prover killers”?
43:18 – Beyond Ethereum, what other computations is SP1 targeting?
45:16 – What’s next for SP1 that you’re most excited about?
47:15 – Closing remarks

Summary of the fireside chat

What is SP1?

Succinct is building verifiable compute using zero-knowledge (ZK) proofs, a technology whose name is inspired by the succinctness property—the idea that verifying a proof requires much less effort than re-executing the original, large computation. Tamir Hemo sees this as a crucial gain, especially in the context of blockchains where all nodes currently need to re-execute the entire state transition function.

SP1 is the embodiment of these efforts. Hemo explained that Succinct started by writing bespoke ZK circuits for projects like an Ethereum bridge. However, he found the developer experience of writing customized circuits not sustainable, particularly recalling the difficulty of having to re-implement all of Tendermint within a Plonky2 base circuit, which he described as really hard. This frustration spurred the decision to build SP1 as a more general purpose ZK-VM.

Hemo emphasized having a strong opinion about the architecture: SP1 had to be pre-compile-centric. This design allows specific, known computations to be handled by highly optimized circuits, while the bulk of the logic can be run by importing, compiling, and executing a standard program. Hemo captures the essence of this design by calling it the magic of like the ZK-VM and the magic of SP-1. Ultimately, the goal is not to prove that every single RISC-V cycle (the modern instruction set SP1 uses) was executed correctly, but to prove that the compiled program does what it what it promised to do safely and quickly.

What has SP1 been working on lately?

The team has been intensely focused on performance, leading to the development of Hypercube, the ZK-VM’s latest iteration. Hemo noted that in May 2025, Hypercube demonstrated real-time proofing by successfully proving 93% of a large sample of blocks in under 12 seconds. Since then, resource consumption has been dramatically optimized, allowing the system to prove around 99.7% of blocks with like just 16 GPUs. Hemo framed this jump in capability as aligning with the dream of of using ZK to scale the L1. Furthermore, he highlighted that 16 GPUs are special because they fall under the 10,000-watt (ten kilowatts) threshold, meaning the proving can be done with consumer hardware that people might use for an electric vehicle charger at home.

Tamir Hemo’s Relief: Breaking the tension

This immense scaling required Hemo and the team to abandon the limitations of the previous architecture, SP1 Turbo, which used univariate polynomials. Hemo felt there was a weird tension in the old design: if they optimized the circuit (arithmetization), the cost of recursion would increase. Recursion is necessary to aggregate proof segments, but it introduces a serial step that drastically increases latency.

Hemo expressed his relief that the adoption of multilinear polynomials, spurred by Ron Rothblum joining as Head of Research, broke this limitation. Rothblum showed us the beauty of multilinears. Hemo finds multilinear polynomials structurally advantageous because they allow operations, such as permuting polynomials, to be done for free by the verifier, rather than requiring additional convincing. This led to the Juggernaut Polynomial Commitment Scheme (PCS). The underlying motivation was to ensure the arithmetization layer had maximal freedom to minimize the trace area (the size of the ZK circuit), without the recursion cost increasing. Hemo shared he didn’t like this tension.

Surprises and Bottlenecks

Hemo was genuinely surprised by unexpected performance gains achieved from external teams. The Zilkworm team, adapting the client based on EVMone, optimized code paths to generate fewer RISC-V cycles, leading to a 2x performance improvement from the program side. Hemo admitted, he didn’t expect to get so much gain for free.

The remaining challenge to achieve 100% proving within the 12-second slot time is ensuring predictable proof costs. The current gas model doesn’t exactly match the proving cost, leading to adversarial blocks that exploit mispriced op codes. These prover killers, such as MODEXP (Modular Exponentiation), are the biggest source of outliers, though Hemo noted the Ethereum Foundation is working on EIPs to address repricing them.

How is Veridise working with Succinct and SP1?

The security of ZK-VMs is Hemo’s paramount concern, particularly the risk of an underconstrained circuit—a scenario where the circuit fails to specify a necessary check, allowing a false proof to be generated. Beyond traditional security audits and bug bounties, Hemo pursued mathematical guarantees through formal verification.

Succinct’s collaboration with Veridise focused heavily on verifying that the circuits were not underconstrained using the tool Picus. Hemo praised the tool, calling the integration a major win, as it helps the team catch bugs early on in the development. He noted that Picus is easy for the team to use, requiring only small annotations for non-deterministic parts of the code, after which it automatically scans the entire error space.

Hemo also invested in verifying the semantics of the constraints using the interactive theorem prover, Lean. This intense effort verified that the constraints match the official RISC-V specification. Hemo was surprised at how quickly this complex process was achieved (a few months), thanks to the domain expertise involved.

What’s up next?

Compiler Infrastructure and Pre-compile Automation

Hemo lamented that ZK circuit development is still quite manual and wishes for better compiler infrastructure, similar to what exists for normal code where the type checker is almost always going to help you. He believes a more semantic way to like introduce the constraint is needed. This would allow translation into verification languages and enable the verification of simpler versions of the circuit before optimization. He is excited to see what comes in this area, such as Veridise’s promising LLZK project. Ben Sepanski shared that LLZK is an intermediate representation intended to be both analyzable by tools like Picus and easy to express. The ZK tools in AuditHub, a blockchain security platform developed by Veridise and utilized by Succinct, run on LLZK.

Regarding pre-compiles, Hemo treats them as equivalent to writing a new circuit, requiring the same extensive security due diligence, including running Picus. The future, however, lies in automating this pre-compiled process. Instead of manually writing circuits, Hemo is excited by the idea of automatically translating code blocks into a more efficient representation and then formally verifying that automatic process.

Decentralization and personal privacy concerns

Succinct has moved from a private proving service (using TEEs for input privacy) to a decentralized prover network. Hemo finds the success of the decentralized network really cool to see. He noted that customers benefit from better prices and fulfill their desire not to have Succinct to be a single point of failure in their protocol, which makes a lot of sense.

Hemo harbors profound personal feelings about current data custody: He doesn’t like that sensitive data is currently stored in leakable databases. He said he would send his driver’s license to a prover to get a one proof rather than uploading it to 500 websites, and desires a future where highly sensitive data is not kept anywhere. He sees ZK proving as a mechanism for this, as the prover only ingests the data for the proof and can delete it immediately. That’s already a better future in my mind.

Cryptographic direction and verifiable future

Hemo confirmed that Succinct is shifting Hypercube away from relying on conjectures (like those related to proximity gaps common in STARK-based systems) and plans to rely on the provable results.

Ongoing cryptographic work includes an upgrade to the Juggernaut PCS to ensure the verifier only needs a digest of the constraint[s] rather than the constraints themselves. Hemo also highlighted research on the Fiat-Shamir transformation, noting that work by Ron Rothblum and co-authors showed that the vulnerability is more than just contrived and exists in plausible circuit settings, emphasizing that with Fiat-Shamir you have to be really really careful.

Hemo concluded by reflecting on the immense total value secured by SP1 (in the billions), calling the sum quite insane and acknowledging the accompanying responsibility. Beyond blockchain scaling, Hemo is driven by the broader vision of ZK providing verifiable technology. He expressed a deep concern about the growth of AI-generated content, asking: Do we want to live in a world where we can’t tell anything that’s real? He sees ZK-VMs enabling off-chain financial applications and privacy features that would be impossible otherwise.