Unleashing ZK: a new era of performance, privacy, and interoperability

At ETHDenver’s Modular & L2 Day, Sylve was part of a panel on Unleashing ZK: a new era of performance, privacy, and interoperability. You can read Sylve’s highlights below! And if you’d prefer, here’s the whole panel with Sylve, Pradeep Singh from Gateway.fm, Rebeca Vacaru from Routescan and Mark Smargon from Fuse, moderated by Risc Zero’s Shiv Shankar.

On the adoption of ZK

zkVMs have been a massive unlock technically, but not mentally yet − people don’t go around thinking, «oh, now I can do ZK».

The app builders we work with often have a privacy requirement. They want to build privacy-preserving applications. For these, you quickly run into an issue: zkVMs are easy to use, but they’re memory-hungry and can’t run in a browser.

We actually had a builder who ran a benchmark of how to prove a simple P256 signature client-side on Safari for mobile. He went through everything he could find, and the only option that worked for this was Noir.

So we’re in a position where we have great server-side proving and Layer 2s and so on, but it’s lagging in terms of adoption, and I think that’s because it doesn’t exactly fill the needs of builders.

What’s the next step for ZK?

We've mostly been examining ZK from the privacy and scaling perspectives. Accessibility will help us break that glass ceiling.

ZK is a way to extend a signature, for example. You have your passport, which means that you can actually reach users where they are, without a need to onboard.

It is possible to build an application that allows you to airdrop an entire country because you can geofence based on passports. You can send money to someone's email address using zkEmail. And I think that's the one thing where we haven't seen a lot of innovation, with zkEmail, Cursive, the open passport teams… We need to see even more.

This might be a hot take, but TEEs are great because they allow you, as an application developer, to give your users a taste of what real-time proving will look like client-side in a few months or years.

People do therapy with Claude and ChatGPT, so I think we should take off our blockchain tinfoil hats. We don’t need perfection; we need TEEs and ZK to make things more trustworthy.

Making ZK worth learning

People consider the ZK community very highbrow, and it's still moon math.

Even though we were able to prove the op stack before we got fraud proofs, it's still moon math.

The poster child for ZK right now is zkTLS − and it’s arguably barely ZK itself. zkTLS takes the highbrow image and turns it into something that looks interesting and has actual use cases.

Another approach to education is to tell people they’re going to have to learn a lot of difficult concepts. But the angle is that you're able to port data onchain, for example. And that's really cool because then you get into it and realize you can now build an on-chain credit graph or under-collateralized loans if you can prove that I'm in the top 1% earner of a particular country or something like that.

If you give people an incentive to use a particular piece of technology, they will learn everything they need to learn − including « moon math ».

It’s time for a revolution

In blockchain, we try to be reformists. We’re in a very weird industry, where outside of more theoretical research, everything is very still; you’ve got stablecoins and a few specific use cases, but almost everything else is just an idea.

It’s difficult to point to something and say, «That’s what the tech is for.» So we try to reuse technology that already exists: we build L1s on Cosmos, on Substrate…

At Hylé, we tried using that, and the result was horrendous. Afterward, we rebuilt everything from the ground up.

Now that we have ZK, I think it’s the perfect time to make a bold bet and redesign everything we have done so far. Let’s stop using Solidity − or rather, let’s make zkVMs work with everything: Solidity, Rust, and everything else down to COBOL!