Introduction

Zero knowledge proofs are the secret key for user privacy and verifying transactions in blockchains today. They can compress computations, making it faster and cheaper to verify just one proof than having to verify each transaction individually. Everything can be zk’d, including rollups, bridges, and VMs. However, generating these proofs can be slow, computationally intense and expensive, particularly on Ethereum. 

This can limit the deployment of innovative applications due to high proving times and gas costs. Zk rollups, which use provers for zk proofs, are a solution but can be resource-heavy. Due to these resource requirements they are usually centralized, which comes with tradeoffs such as being prone to censorship and higher settlement costs. In recent times, alternatives have emerged to solve this problem:

• proof aggregation techniques to amortize the verification cost, and 
• prover marketplaces, to offer greater liveness/censorship resistance and to provide users with a competitive market proof price.

zk Rollup Model

Let’s walk through a simple overflow of how transaction execution works on a zk rollup. At a high level, a zk rollup has I. users, which submit transactions, II. a sequencer, who orders transactions and builds L2 blocks, and III. prover(s), who generates and submits validity proofs for correctness of state transition. The L1 smart contract verifies validity proofs and updates the state root, finalizing the execution of user transactions.

• Submission. A user submits its transaction to the sequencer which includes a fee
• Batching. The sequencer orders user’s transactions into L2 blocks and submits batches of L2 blocks to L1 to amortize the proof cost. Validity proofs are not necessarily submitted along with batches, usually the latency is greater than submission times.
• Proving. For each batch of transactions, the (usually) centralized prover generates and submits a zk proof to prove the correct L2 execution state transition. Once the transactions and blocks are proved on L1, they’re considered final.

Once an L1 batch is submitted to the rollup smart contract on L1, the witness can prove that the execution computed on the L1 batch is correct.

Proof Supply Chain

While recent developments in shared sequencer layers may seem to provide a straightforward approach to cross-domain atomicity, it’s not quite that simple. Shared sequencing layers are primarily designed to do just that: to sequence transactions over multiple rollups while offering high throughput. However, they don’t actually prove anything. In the modular thesis, they would need to plug into a shared prover network to delegate this task.

The proof supply chain was first introduced by trace in this post. We will not get into theoretical proof aggregation MEV, but he makes the case for some MEV instances that could arise from provers ordering proofs later or earlier than others. I highly recommend reading it.

Shared provers could be a new layer that surges to fill the gap between applications wanting to support zk proofs for whatever purpose (privacy, scalability, identity..) but without the bandwidth to deal with the overhead of building zkVM or circuits in-house.  

As seen in the current landscape, crypto is highly fragmented. Not just with respect to liquidity, but the layers that combine to build the modular stack such as sequencers, block builders, provers, proposers, and relayers.

Today, rollups submit zk proofs individually by a (usually) centralized or whitelisted set of provers. A problem arises when multiple rollups try to submit zk proofs to L1at the same time as they incur high gas costs. Can they do better, you ask? Prover networks surged to unify zk proofs to allow zk applications (e.g. oracles, identity networks, privacy, not just rollups) to outsource proof generation to a network of specialized hardware providers for better cost and time efficiency

Assuming different kind of rollups connected to the network, the transaction life cycle works as follow:

1. Rollups submit proof request to the prover network 
2. A matchmaking mechanism to choose the next prover is used
3. Provers fulfill proof requests
4. There’s also an optional proof aggregation step where these fulfilled proofs get aggregated into one bigger proof
5. Finally the provers submit proofs to L1 to be verified on-chain

The proof supply chain has two actors: proof requester (zk applications) and proof generator (provers)

Each rollup can either choose an external proof provider, which could be a SaaS, or opt to build it in-house. The proof provider will then be responsible for generating the proof and posting it on-chain. Usually, prover networks accept different kinds of zkVMs/circuits, such as =nil or Marlin’s Kalypso

The great thing about zk proofs is that they are self-verifying. This means that applications don’t need to rely on the honesty of the proof provider. The proof is verified on-chain and is inherently correct due to the nature of zk proofs.

Proof Singularity

There are different types of proof singularity, and while they all share the common goal to amortize proof costs by just verifying one single proof, they do it differently.  

Let’s say that for example the cost to verify a SNARK on-chain is 200k gas. 

• If the proof represents just one proof, it’ll cost 200k gas. 
• If the proof represents 100 other proofs altogether, it’ll also cost 200k gas. It’s fixed cost. 

Aggregation

Proof Aggregation is a technique that condenses multiple valid proofs into one sing