Succinct Labs recently launched SP1, the first fully open-source, performant zkVM designed for production use. With SP1, developers can leverage zero-knowledge (ZK) technologies without any prior experience or knowledge in the field. In the past, working with ZK required learning advanced mathematics and writing in esoteric, developer-unfriendly languages (often lacking even basic print statements). Now, you can write in Rust—an ergonomic language with built-in safeguards that streamline the development of complex software while ensuring correctness.
SP1 eliminates the need for developers to master complex concepts like elliptic curves or arithmetic circuits. Our platform grants access to cutting-edge ZK technology's security and scalability benefits while allowing developers to build applications using familiar, human-readable languages. This approach significantly enhances maintainability, dramatically improves the development experience, and boosts overall productivity.
We founded Succinct with a vision of harnessing zero-knowledge (ZK) technology's power, though we weren't certain where its first applications would emerge. Our initial focus landed on ZK bridging—one of the most promising uses for this emerging technology. This work led us to develop several complex ZK circuits and systems, including a ZK Ethereum light client and a ZK implementation of Tendermint.
Both projects were long and challenging undertakings. We had to develop large, intricate circuits while collaborating directly with cryptographers to audit and optimize the implementations. Each project consumed three months of our team's time and required significant financial investment for thorough auditing.
By the end, we began to question the practicality of this approach. Building ZK apps required developers to custom-build circuits, grapple with elliptic curves, and work closely with cryptographers. That's when we started contemplating the creation of a zkVM. By this point, we had amassed the knowledge and tools to build a functional zkVM with relative ease. However, we recognized that creating a truly performant zkVM would pose a much greater challenge.
To better understand what we mean by "performant," let's consider a ZK rollup on Ethereum. In this scenario, a prover consolidates a batch of L2 transactions into a proof, which is then posted to a verifier contract on Ethereum mainnet. Once posted and verified, this proof simultaneously commits and verifies those blockchain transactions. Unlike optimistic rollups, which typically require a 7-day waiting period for finality, ZK rollup transactions are finalized as soon as the proof is submitted to Mainnet—showcasing the power of ZK technology. Here, the primary factor limiting transaction processing speed becomes the time required for proof generation.
Both ZK and optimistic rollups aim to reduce the data and execution load on Ethereum mainnet. In our scenario, this means our proof and verification logic should be compact. This shifts the burden of heavy computation onto the prover, which must create a small proof of a complex computation.
This is where SP1 shines. We've diligently optimized our logic and circuits, resulting in significant reductions in prover costs and latency. We've brought proving costs down to about 1 cent per transaction and anticipate 5-10x further gains by the end of this year, based on our roadmap plans.
From the outset of building SP1, we were committed to making it fully open-source. We believe that complete transparency is essential for achieving full trustlessness in a ZKP stack. Anticipating high demand for fully trustless ZKPs, we've ensured our zkVM has been open-source from day one.
Another key motivation for open-sourcing SP1 is to empower the community. By allowing developers to fork our repo and tailor it to their specific needs, we're fostering wider adoption. We believe more teams will embrace SP1 if they have the freedom to modify the code—even if they don't immediately need to. Furthermore, by enabling experimentation with and benchmarking of new proving systems and cryptographic algorithms, we aim to catalyze research and innovation throughout the ecosystem.
We briefly touched on optimistic and ZK rollups earlier. Let's revisit why we're building rollups in the first place—scaling Ethereum. This network, often called a "world computer," isn't actually designed for high computational throughput. Ethereum achieves 'trustlessness'—where no one needs to trust any single party—by having all participants independently verify every transaction. In terms of redundant work performed, this is about as inefficient as possible.
ZK-SNARKs sit at the opposite end of that spectrum. These complex mathematical constructions enable remarkably efficient proofs of computation, allowing verification where only one or a few parties need to perform the work. ZK-SNARKs make "verifiable computation" possible: I can perform a computation that takes hours, then give you the output along with a proof that I did it correctly. This proof is much shorter than the computation itself, and you can quickly verify it with a simple procedure.
This 'succinct proof of computation' is the idea behind ZK rollups. A batch of transactions is processed off-chain, where we confirm they produce a valid state transition. We then generate a proof that the state transition was done correctly and post that proof to the rollup's verifier contract on mainnet. The verifier contract checks the proof and updates its state root (a compressed representation of the rollup’s world state), effectively finalizing those transactions.
This represents a significant leap in efficiency—in zkEVMs, transactions can achieve finality within minutes, rather than the days required by optimistic rollups. Here, "trustlessness" is achieved through sophisticated mathematical constructions that enable us to provide a succinct proof validating a batch of transactions. Instead of relying on a centralized sequencer or a fraud litigation process, we place our trust in mathematics. Once a proof for a batch of transactions passes verification, we consider those transactions finalized and move forward.
Interestingly, in the context of ZK rollups, which rely heavily on ZK-SNARKs, it's not actually the "ZK" (zero-knowledge) that's most relevant—it's the "S" (succinctness). If the proofs aren't much shorter than the computation itself, the whole value for scaling is lost. However, if the proofs aren't strictly "zero-knowledge," it doesn't fundamentally alter the primary goal of scalability.
Until recently, building a real-world zkEVM was extremely challenging. Teams spent years developing circuit-based solutions, and even now, only a few have reached mainnet. Thanks to SP1, however, leveraging the efficiency of a zkEVM is now available to anyone with an OP Stack rollup—see our recent announcement of OP Succinct for more details.