An introduction to Delayed 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 delayed proving ?
We introduced delayed proving to overcome a fundamental problem that off-chain execution with onchain verification creates. But before deep-diving into delayed 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.
In order to make Bob’s transaction valid, he’ll have to prove that the state transition from rootHash to rootHash’ is legit.
So 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 make sure Bob can send his transaction in time even with slow proof generation ?
- Timekeeping: How do we ensure that the proof contains accurate time information? Users can’t systematically be trusted, 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 ! 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 in two. 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.
The Sequencing is done when the blob-transaction is received and included in a block; and the Settlement is done when the proof-transaction is verified and added in a block.
In our exemple, Bob first broadcasts the blob-transaction, that is then sequenced and added to the chain, among multiple other transactions. This offers a well-defined global order, well-defined timestamps, etc. over all transactions. By fetching and executing all unproved blob-transactions linked to 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 easily determine what virtual state needs to be used at the proving step.
After verification, Hylé simply settles by updating the contract’s state commitment 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 were provers receive an incentive for proving pending blob-transaction. Users would then never have to bother about anything else than just 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 the general case, 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 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.
But 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 you should care ?
Delayed proving annihilates ZK’s current intrinsic slowness problem as proof can be broadcasted asynchronously.
Furthermore delayed proving lightens the burden for 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 on 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 that high as blob-transactions are not processed by nodes. To them, blobs are just a bunch of meaningless bytes. They can never be rejected. Adding them in a block is “effortless”, making 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. 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 +5min to prove that they were actually vibing.
Thanks to soft-finality, users do the entire VibeCheck flow without having to prove anything. They are then given the choice to prove their transaction in their own browser offering them full privacy, or to delegate that task to an external prover which is cheaper and faster.
From a user point of view, the flow is smooth and responsive 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.