The future of accelerated proving
At DevCon 2024’s Proof Summit, Sylve took part in a panel about the future of accelerated proving systems alongside Jens Groth at Nexus and François Garillot at Argument, moderated by Lagrange’s Ismael Hishon-Rezaizadeh. You can watch the video or read Sylve’s highlights below!
What do you look forward to the most in terms of ZK innovation?
What I’m most interested in is the ecological conditions that allow for this Cambrian explosion of research and innovation and why a single PhD student is able to revolutionize the field. STARKs have been around for a while now − and it’s a bit like the history of the steam engine.
The first time we used the steam engine was not in steamboats or for the textile industry; it was to pump water out of coal mines. That engine was so inefficient and janky that the only place it could be used was right next to the energy source. Because we had a use case for it, the engines got better, and we applied them to different things.
I like to think of blockchains as coal mines. ZK started improving them by bringing privacy and scalability for rollups. That’s where the ecological conditions united to create the Cambrian explosion, and I’m interested in what comes next: provable applications, trust infrastructure, and the like.
What’s your choice of proof system at Hylé?
When we looked at how proofs are used in blockchain, we realized that the most significant contribution to ZK is what is limiting it right now: everything has to fall back onto the upper limit of 300k gas to verify a groth16 proof.
That means we have fancy proving systems that use STARKs, recursion, and so on… and then you have to add massive latency to cram all of this into a tiny proof to send onchain.
You might want to use a specific proving backend for particular cases, such as Noir, which is perfect for privacy and client-side proving. Or maybe you want to use a multi-purpose zkVM like Nexus for other things; it’s actually what one of our builders has done. They used Circom for zkEmail and Risc0 for the proving backend for their ZK game.
We decided to be the Switzerland of proving systems. All proving systems are equally beautiful, and we want to support all of them. This is non-negotiable for us; we won’t go for trade-offs.
Hardware acceleration
Hylé will aggregate a lot of demand for proving services.
We're going to have a lot of applications posting provable blobs that eventually need to be proven and settled on Hylé. These particular things are probably going to be built on public input. So, proving services that want to settle on Hylé massively benefit from hardware acceleration. It's basically like mining!
On the other hand, let's say you want more privacy-preserving applications. They have entirely different ecological conditions: you cannot assume people will have an ASIC on their smartphone. So, you're going to need to use a specific proof system that is appropriate for your ecological conditions.
On our end, there will be a lot of back-and-forth between the app developers and us to really steer them in the best direction. « If you really want to use Noir on a client-side type of thing, maybe you want to use it more for this thing. »
You may need a huge computation or want to create a ZK proof that an image was edited and signed; these operations can be folded because they're really repetitive. And then maybe you’ll benefit from other accelerations.
How do you use ZK for Hylé?
When you think of zkL1s, you might think of Mina and Aleo first.
The first thing that truly differentiates us from Mina is that we don’t have vendor lock-in. We don’t require you to use o1js. We very much think that all programming languages, all zkDSLs and zkVMs… are beautiful. You should use the right tool for the job. We want you to have the flexibility to choose any language that you want.
The second is that recursion or aggregation is really good, but there may be better solutions. It's great for security but not for composition. If you are on Ethereum, composable smart contract calls are compelling, but to make two zkApps interact on Ethereum, you’ll have a hard time. So, what we do is proof composition.
We’ve talked about proof composition in more detail in a recent blog post:
Tech team
The third and final main difference between Hylé and traditional zkL1s is that we separate sequencing from settlement.
We do that with pipelined proving, something we’ve also discussed in detail:
Tech team
All in all, we're trying to remove the ZK from zkApps. We want people to build applications without even thinking about what's underneath. We want them to use the affordances that ZK gives, which are privacy, scaling, and flexibility, without hassle.