Pipelined proving and practical ZK proofs for provable apps

At DevCon 2024’s ZK Hub, Lancelot spoke about pipelined proving and practical ZK proofs for provable applications. Watch the video or read the highlights below!

We’re going to talk about the fact that rollups are good… but we can do better.

Rollups are good.

Let’s quickly go over what a rollup does − or at least our definition of a rollup because this is the kind of word that everyone defines differently.

A rollup maintains state commitments on the Layer 1.

In the case of a ZK rollup, state transitions are validated by zero-knowledge proofs, which allows for the avoidance of fraud, invalid transitions, and the like.

Usually, only the L2 sequencer can post validity proofs to change the centralized state commitments. The exception is cases where you have trustless indexation and escape hatches, which, to my knowledge, are not in prod on any general-purpose ZK rollup at this time.

So, in short, a rollup is an iceberg: a tiny bit is visible on Layer 1, the state commitment, and the whole database on Layer 2.

And when you think about it, transactions are just proofs of state transitions. So you start from a commitment, and then you have a ZK proof that takes you to another commitment, and so on.

With most ZK rollups, these are actually batches of many transactions, batches of blocks, even. For efficiency, you need a lot of recursion, so there are several hours between each of these state transitions. Once you’ve waited all that time and things have been proven, you’ll need an indexer to read information.

For that, you generally use the rollup’s infrastructure if they have an indexer: StarkNet does that, for example. You could also, in theory, do it on your own with user indexation.

Accessing the Layer 2 state, what’s under the surface of the water, remains permissionless, but someone needs to do it actively. It’s not as automatic as on Ethereum.

If you don’t do it with batches of blocks but with individual transactions, you end up with something that looks a lot like what I call a based ZK rollup: each transaction is just a ZK proof of a state transition. On the Layer 1, you maintain the state commitment for your application. That’s precisely how rollups work, and you could do a regular app that works like that… but you’ll have some issues.

Currently, all rollups are bridged to the Layer 1: they’re technically interoperable, but you have to rely on bridges every time.

If you want to be efficient, you’ll run into issues:

• it’s difficult to compose contract calls
• you have long proving times, as I explained above, since you need to batch blocks
• you get high latency, making parallelization very hard to achieve

Because Layer 2s are centralized with only one person posting proofs, they can’t have parallelization. You’ll run into many issues if you try to engage many users at the same time. 

Rollups are good… but they can be better. Let’s talk about how.

Composable contract calls

If you want to do composition right now with ZK proofs, you're in the situation on the left.

Let's say you want to make a Tetris game, but you want people to have a CryptoPunk to be able to play Tetris.

You need to verify the CryptoPunk contract's code inside the code of your Tetris game. This is annoying! If you want to change the identity verification, you need to change the code of your application.

You're basically putting boxes inside other boxes. If you want to change the innermost box, you have to open every single box to swap it out.

With proper composability, which is what Hylé gives you, you can do the same independently.

You have the CryptoPunk proof that's standing on its own.

You have your own Tetris proof.

You add a little bit of information inside your proof as metadata, saying that you expect there to be proof of a CryptoPunk. If you want to verify something else, you can change that little bit of metadata. You don't need to change anything else to support any kind of identity.

You can even abstract it away and change the code of your application without redeploying it. If the CryptoPunks contract is updated, you don't need to update your application − not that this specific contract would be likely to update.

So that’s the solution to the first problem.

Solving proving time and latency with pipelined proving

The second problem, which is much more annoying, is proving time and latency.

Let’s use the example of an auction.

Let's take another, slightly more realistic example: you have an auction. The auction ends at the red bar on the timeline below.

The timeline of the auction and why proving latency is a problem.

You see the auction. You want to bid, but by the time you generate your proof, the auction has ended because… let's say, it was terribly written, and it took several hours to generate the proof.

Of course, you're sad because you couldn't bid.

Or, and this is an even worse problem, maybe you saw the auction, and someone else saw it at the same time. At this point, you both see the initial state commitment of the auction contract, which is the green state below. You both craft your transaction.

The problem of parallelization in an auction.

1. They're both state transitions from this initial start state.
2. The person on the upper timeline is faster than you because they've got a better computer or whatever. They send their transaction first, and at this point, your transaction will bounce: the proof of state transition no longer applies.

The program doesn't know if it can go from blue to red, so it rejects your transaction. Again, you are sad.

The solution to this is… pipelined proving. Yes, that’s the title of this presentation. We’re finally getting there.

Pipelined proving

We split the sequencing of transactions from the actual settlement; only the latter relies on zero-knowledge proofs.

Sequencing means that both of you in the auction send the information about your bid onchain. You say how much you’re willing to bid − depending on the use case, you might want to send your ZK proof directly and keep the exact number secret, but let’s not add complexity right now.

You both tell the chain how much you’re willing to pay. There’s no latency because you’re not generating a proof: we receive your message immediately, and we sequence it. We’ll remember in what order your bids arrived. From then on, that is determined and fixed: there’s no guesswork and no place for change.

Starting then, you can work on generating ZK proofs that you will use for your bid to become legitimate: proving that your balance is sufficient, for instance, or that you are authorized to bid on this auction. You can generate these proofs, and we’ll settle them later. This could happen once the auction has ended; that’s fine because only the initial sequencing matters. The chain will only reflect the final state once the proofs are settled, but things are etched in stone from the beginning. It’s just like time travel!

A lean blockchain

This leads us to what Hylé is: a lean blockchain.

Essentially, we view blockchains as custodians of data integrity through zero-knowledge proofs. They only need to do sequencing, a little bit of data availability, and settlement. With pipelined proving and native proof composability, you can achieve really high performance.

In theory, because it's asynchronous, it’s infinite. In practice, it's not going to be truly limitless, but it still could go really high if you do enough recursion during the gap between sequencing and verification.

This is great. In the previous situation, everybody was talking through bridges to a Layer 1. Now, everybody is on the Layer 1, and at the same time, they work like a rollup. So you can write Rust code and run it on SP1 or Risc0 or anything else, and you're already interconnected via native proof composability.

It’s like ZK rails! (Yes, we like trains.) This gives a lot more flexibility than in current blockchain ecosystems. 

If ZK is a railway, then Hylé is the train station connecting all the lines. In this example, we’ve included:

• a permissionless onramp via zkEmail, like zkP2P, which is fully decentralized and proved client-side
• DeFi pooling with permissionless private strategies, with a centralized backend and validity proofs that allow it to remain manageable and trustless
• a fully onchain game running on everyone’s computers

This is Hylé, and this is what we are building right now.