An introduction to pipelined proving

Hylé aims to become a lean blockchain, focusing only on Sequencing and Settlement for provable applications. We leverage zero-knowledge proofs to offload execution and data storage off-chain.

As a reminder,

• Sequencing is all about establishing the transaction order within a block.
• Execution is about processing transactions to update the blockchain’s state.
• Settlement is about finalizing a transaction. Making it immutable, meaning it cannot be altered, deleted, or reversed.

What is the link between those and pipelined proving?

We introduced pipelined (or delayed) proving to overcome a fundamental problem that off-chain execution with onchain verification creates. But before deep-diving into pipelined proving and why you should care, let’s quickly explain what a smart contract is on Hylé.

Hylé’s smart contract: it’s all about state transition

For the sake of privacy and scalability, Hylé only verifies the state transitions of a smart contract. Let’s take an ERC20 token on Hylé as an example. Its state is a map linking accounts with their balance. It is merkelized to obtain the state commitment rootHash.

A state transition is going from rootHash to rootHash’ when Bob sends 2 $Token to Alice.

To make Bob’s transaction valid, he’ll have to prove that the state transition from rootHash to rootHash is legit.

In the end, a smart contract on Hylé is really just a mapping between a contract name and a state commitment—easy, right?

What does it imply?

There are, however, some problems with this approach. Let’s say we want Bob’s transaction to happen before midnight because it’s used for an onchain auction. On traditional chains, this is easy enough. With provable applications, three challenges arise:

• Proof generation latency: How do we ensure Bob can send his transaction on time, even with slow proof generation?
• Timekeeping: How do we ensure that the proof contains accurate time information? Users can’t be trusted systematically, nor can they accurately predict when their transaction will be sequenced. Adding tolerance to compensate opens the door to manipulation and creates censorship risks.
• Transaction parallelisation: Hylé is a state machine, and proofs must show valid state transitions. What happens if Bob and Alice both want to send a transaction at the same time? Two proofs created from the same state will conflict: the second proof should instead be based on the final state of the first proof… But this information is not available yet! The second transaction will have to be proved again. Painful!

The solution we brought to the table is to split Sequencing from Settlement entirely.

We called it delayed proving. 

What is delayed proving?

The previous transaction was conceptually composed of two things: a statement (Bob wants to send 2 $Token to Alice) and a proof (ZK proof that state-commitment went from rootHash to rootHash’ ). Delayed proving is about splitting this transaction into two parts. A blob-transaction (for the statement) and a proof-transaction (for the … proof).

Hylé doesn't care what's inside the blob-transaction (that is why it is a blob). Only the contract’s code knows how to process it.

The proof-transaction certifies the validity of the state transition induced by the blob-transaction.

Sequencing is done when the blob transaction is received and included in a block, and Settlement is done when the proof transaction is verified and added to a block.

In our example, Bob first broadcasts the blob transaction, which is then sequenced and added to the chain, among multiple other transactions. This offers a well-defined global order, well-defined timestamps, etc., for all transactions. By fetching and executing all unproved blob transactions linked to the token’s contract and sequenced before his own, Bob is able to recompute the virtual state that his proof transaction will use as the initial state.

This round of sequencing blob-transactions fixes the concurrency issues. One can quickly determine what virtual state needs to be used at the proving step.

After verification, Hylé simply settles by updating the contract’s state commitment, which is stored on-chain. In essence, Hylé maintains a separate “settlement cursor” for each contract, updated independently from sequencing.

Potential complications

I can sense your next question: what happens if Alice never proves her blob-transaction?
Bob won’t be able to generate a proof that is based on the correct initial state.

First of all, Bob knows the contract’s code. Hence, Bob can execute Alice’s blob-transaction. If Bob can execute the blob-transaction, then Bob can actually… prove that transaction. Nothing prevents Bob from proving for Alice.

Delayed proving actually opens up a demand-side prover market. One could imagine a side market where provers receive an incentive for proving pending blob-transactions. Users would then never have to bother about anything other than broadcasting their statements. 

No more proving, just blobs: benefits of ZK with normal blockchain affordances.

But wait a minute… What happens if Alice’s blob-transaction is not provable?

In general, we can’t guarantee that every proof will be generated or submitted on time. To address this, Hylé uses timeouts: transactions that are not proved within a set duration are rejected.  In other words, if Alice’s blob-transaction is unprovable, Bob will have to wait for a timeout in order to prove his own blob-transaction. From an objective point of view, Bob can just ignore Alice’s transaction while he’s building the virtual state he will base on. Alice’s transaction will timeout, and Bob won't have to reprove anything.

However, in order to prevent an increasing lag between blobs and proofs transactions, one solution is to batch blob-transactions together and prove consecutive state changes within one proof.

However, waiting for timeouts increases the backlog of unproved transactions, slowing finality. The good news is that with proper fee incentives and ZK recursion, we can catch up during favorable intervals.

Why should you care?

Delayed proving annihilates ZK's current intrinsic slowness problem as proofs can be broadcasted asynchronously. 

Furthermore, delayed proving lightens the burden on users to generate proofs. They can rely on other actors to generate proofs on their behalf. Likewise, a large class of existing applications could become provable apps and be integrated into Hylé with minimal changes. Our design allows developers and users to benefit from proving technology while abstracting the complexities of proving and verifying.

Last but not least, throughput can be high because nodes do not process blob-transactions. To them, blobs are just a bunch of meaningless bytes. They can never be rejected. Adding them in a block is “effortless”, making the Hylé chain’s soft-finality essentially as fast as the network will allow. 

How does it work in practice?

We recently created a PoC named VibeCheck. The pitch is dead simple: vibe-to-earn. This aims to be our first example of what a provable app could be capable of.

Delayed proving is very useful in VibeCheck’s case. ZK proving is heavily resource-consuming, and users might not want to wait +5 minutes to prove that they were actually vibing.

Thanks to soft finality, users can complete the entire VibeCheck flow without having to prove anything. They are then given the choice to prove their transaction in their browser, which offers them full privacy, or to delegate that task to an external prover, which is cheaper and faster.

The flow is smooth and responsive from a user's point of view, as illustrated in this video. Check it out for yourself!

Wrapping it all up

Off-chain execution with onchain verification comes with downsides that delayed proving harmoniously solves: robust soft-finality and flexible post-proving mixed with high throughput. With Hylé, users and applications will benefit from the scalability, privacy, and flexibility provided by provable applications without the hassle of working with a complicated ZK stack. All of the fun, none of the hassle. 

This post's main author is Maximilien, with support from Bertrand and Alex C.