Building the future of ETH now
During ETHDenver 2025, our co-founder and CTO Lancelot was invited to speak at ZK Hub about building the future of Ethereum right now with Hylé. Watch his talk or read the formatted transcript below!
The world tomorrow
How do you scale Ethereum? You rethink everything from a blank slate.
Zero-knowledge is the endgame
Zero-knowledge is the endgame, and zero-knowledge technology is evolving quickly.
We’ve gone from writing very arcane Circom circuits to using zkVMs and writing Rust contracts. A lot of progress is being made towards real-time proving; in just a few years, we can expect near-instant proving on smartphones. The tooling around it is also vastly improving.
In short, ZK is becoming usable and, better yet, commonplace.
Digital signatures are becoming the norm
The second trend is that we're moving towards a signature-by-default world for many different reasons.
One of the big ones is that you have to counter AI slop. One of the only ways to do that is with signatures. And if you think about it, ZK is just programmable signatures.
The whole field of programmable cryptography and signatures follows the same curve as ZK. Emails and passports have been signed for a few years already.
Now, we're sending invoices and contracts. Noir works for open banking. We're going to sign photos, health data, voice notes, IOT… everything, really.
What happens in a world in which ZK proofs are generated in real time, and signatures are commonplace?
The answer is that signed information can be trustlessly brought onchain with zk. You can bring this whole new class of real-world assets onchain. You can now trustlessly operate with it.
That enables new kinds of applications… but you can't do this on existing blockchains. Blockchains have poor performance, the UX remains unintuitive, and fragmentation is a problem. You’re not learning anything new here.
Building the network that enables a golden age
The three problems of current blockchains
Currently, there are three barriers to building a network that enables a golden age of onchain data.
Applications are limited in code size and storage size. The solution to this is to stop storing data onchain.
The second obstacle is that if you want to use a blockchain, even benefitting from account abstraction, you’ll need a 24-word seed phrase and a browser extension or a hardware wallet… it’s too much. The solution to that second problem is identity abstraction.
The third problem is slow throughput. Our solution to that is simply not to do execution.
No storage
Removing storage is relatively straightforward. Ethereum has known how to do this for a couple of years already. The solution is to turn everything into a rollup.
In rollups, the only thing that’s being stored onchain in the longer term is state commitments. 99.99% of the actual state of the applications is stored elsewhere, hence the recurring iceberg metaphor.
This makes the Layer 1 chain much leaner. It also allows applications to be larger: you’re no longer limited by how many variables you can store.
No wallet
The solution here leverages the first point.
Let’s think of what a wallet is philosophically. A wallet is a secret: something you know, and a nonce, the number of times you’ve used it.
The role of the secret is to protect your identity. With ZK, you can use many other tools to do that − you don’t need to rely on private ECDSA keys. You could use email, one-time passwords, or just regular passwords. You could use Passkey and WebAuthn. You could use biometrics like World has been doing.
As for nonces, they’re a hassle. They’re stateful, and they are basically a planet-scale global state. You have immediate parallelization problems. Solutions here involve leveraging more states, which only works if you don’t have your state onchain: then, you unlock multidimensional nonces or transaction-level UUIDs and bloom filters. All of this is possible… if you don’t have storage.
No execution
The final item on the roadmap is the hard one: removing the execution.
Once again, the solution is on the Ethereum roadmap.
A blockchain needs only sequencing. Sequencing is enough to achieve deterministic states unless we’re talking about intents.
If you start from a known state and process transactions in a certain order, no matter how the execution is done, you’ll end up with the same result.
Sequencing is enough for a deterministic state, and a deterministic state is what you want in a blockchain. But you also want to keep the base layer’s security, and that’s the main problem with rollups today.
Let’s compare them.
The reading key is easy: anything with a clown on it doesn’t inherit the security of the L1.
Rollups have sequencing outside of L1, usually with a centralized L2 sequencer. Their execution is also not on L1, but since you can’t really cheat with proofs, we’ve given the clown cool sunglasses. It’s not on L1, but it is still fairly secure. The price is high, though: you’ll get increased latency and potential censorship issues.
And then, you have the DA problem. Some rollups send the DA of their chain to Ethereum; some don’t. That’s awkward!
After ZK and optimistic rollups, we started seeing based rollups where sequencing is ultimately done by the Layer 1. Execution happens off-chain, but you can easily prove it with ZK or optimistic fraud proofs, and the DA is also provided by the Layer 1.
The solution is Hylé
Now, I’d like to introduce a secret new thing: Hylé.
On Hylé, all of these things happen trustlessly on the base layer. We believe that ZK proofs are the best execution layer: with ZK proofs, you can do state transitions. You only need to change the state commitment every time something happens, and you will get infinite scalability and extraordinary flexibility in the kind of applications you can write. I won’t be talking about privacy today, but if you want a fully private app, you can do that using ZK proofs.
Do you think it’s too good to be true? You’re right: there are three problems with this kind of solution.
The first is composition: it’s quite difficult to call other contracts with ZK. In existing solutions, you’ll need bridges or shared sequencing − which is still flimsy and hard to understand.
The second problem is that generating proofs takes time. If you have to wait for the proof to be sequenced, you’ll have a lot of latency.
And finally, there’s parallelization: ZK isn’t commutative.
How Hylé solves the three issues of ZK proofs
Composition: base layer
In ZK, you usually rely on recursion in some way if you want to do proof composition. If you want to create a Tetris game that’s only for people who own a Cryptopunk (because somehow NFTs are cool again), you’re going to have to verify proof that one owns a Cryptopunk inside your Tetris game.
So, if you want to change your Tetris logic or if someone wants to change the Cryptopunk verification model, both will have to be changed at the same time. That’s not flexible and is hard to scale.
Proper composability is what happens if you have shared sequencing at the Layer 1 level. In that case, you can have each contract doing its own thing without the need for recursive verification.
This also allows you to use different proof systems for each of these things. It’s very interesting because there are different trade-offs for zkVMs and zkDSLs, and you can now leverage those using the best model for each proof. It’s better than writing a verifier for Noir in Circom!
Proving time and parallelization: pipelined proving
The second problem I mentioned is proving times and latency.
Let’s take a very simple example: there’s an auction, you want to bid, and the auction ends in 10 seconds. You could send a transaction, but by the time your proof is generated, the auction will have ended. Sad times!
This goes hand-in-hand with parallelization: check out Mina or Miden’s documentation or any other protocol. Everyone struggles with this. In short, if you do ZK proofs of state transitions, you have to start with an initial state commitment.
If two people see the same initial state and each sends a proof, whoever sends their proof first will deny the ability to process the other proof: the initial state will have changed.
The solution: pipelined proving
Our solution is pipelined proving. If you are familiar with Monad’s deferred execution, imagine that applied to ZK.
The steps go as follows:
- Sequencing: send a blob transaction to the L1 that states your commitment. For example, if it’s an auction, « I’m going to bid 10 USDC on this NFT.»
- Once the transaction has been sequenced, generate and send the proofs.
This allows you to send proofs based on a known initial state. If you’re trying to prove the second bid of the auction example above, you’ll see that the first bid is sequenced before yours, and you’ll be able to base your transaction on that virtual initial state rather than the original one.
This also fixes latency issues! Sequencing is enough for deterministic states, we’ve talked about it earlier. So, as long as you’re confident that your proof will be sent and verified, you know that your transaction will be settled. If you feel like it, you can wait three days before generating your proof! (Conceptually, at least, as we implement timeouts that won’t be several days long.)
Unchain your applications
This enables what we call unchained applications. They are no longer limited by chains or restricted to what blockchain can do. You can do anything you want and ZK-ify it to send it to the base layer.
You could do permissionless P2P onramp with zkEmail. Really, you could do it right now with Noir and implement it in real time at Hylé! You could have a fully onchain game where the state is decentralized between players of the game. You could do DeFi pooling with permissionless private strategies: with ZK, you can have a centralized backend and trustless composability with your private data.
You can build trustless escape hatches. You can create variants of WorldCoin. You can airdrop a whole country because since the state isn’t onchain, you don’t need to know who the people are. You just need to verify a proof of passport from a given country.
Hylé opens up a whole new world of possibilities that can’t be done on existing chains. And for what can already be done onchain with a more specific rollup, we have one thing to say: if the solution to your problem is to add more blockchains to a blockchain, you’re not fixing your problem. Hylé does.