talks

Sylve on the House of ZK podcast

Alex Sirac

Oct 30, 2024 • 18 min read

Sylve was invited to the House of ZK podcast, a podcast and media channel exploring everything ZK, from its fundamental principles to the latest advancements in the industry. There, he talked about Hylé and the future of lean blockchains!

Watch the video or read our highlights below!

What is preventing ZK from becoming mainstream?

Alice asked: Even though we have that mission of making ZK a tool that everyone can use, and even though our proving and verification costs have improved over the years, the demand for it has not necessarily increased at the same rate. What are your thoughts on what's preventing ZK from becoming more widely adopted, and maybe some next steps that we could take to address it?

Taking the steam engine outside of the coal mine

The comparison that I like to make for ZK is to compare it to the early steam engines.

The steam engine was used to power the industrial revolution, but it didn't start there. The first use of the steam engine was to pump water out of coal mines at the end of the 18th century.

Why didn't people just use it everywhere? It's such good technology! Just like ZK: why isn't everyone using ZK right now?

The early steam engines were so inefficient that the only place we could apply them was… literally right next to their power source, inside the coal mines. This was a great use case because it meant that we could mine more coal and, therefore, use more steam engines.

It's a very localized thing because it just so happened that in the UK, at the end of the 19th century, you had a massive demand for coal, and it was the hotbed of the textile industry. The whole sector was bottlenecked by a single movement, which was to spin a thread.

Someone realized that the steam engine, which was getting exponentially better as it was used more in coal mines, could be applied to the textile industry. So they did that.

And steam engines improved.

Then someone said, « Steam engines are better. How about miniaturizing them and putting them in a boat? » The process had started.

I talked about this example in more detail in my talk on Brave New Provable World.

Taking ZK outside of the coal mine

For ZK, we're talking about a technology that was first put on paper 30 years ago. It's still very early. A decade ago, it was taking hours or days to prove even negligible amounts of computation.

no
— Eli Ben-Sasson (@EliBenSasson) September 24, 2023

(ouch)

The first real use case for ZK was blockchain because it was the only area where such an inefficient technology could be applied and generate massive results.

The first use case was for scaling Ethereum. By doing this, we invented new proving systems, such as Binius, Plonk, and CircleSTARKs. We had new, usable tools.

StarkWare had a Head of Algebra, and Cairo started as an internal tool so that they didn't have to write the polynomials by hand.

The proving systems are getting better, and the tooling is getting better, to the point that we now have zkVMs. Eventually, you won't even need to think about what type of tool you're using. You’ll just write your code, and it will be proven.

So, how do we move from the coal mines to the textile industry? There will be provable applications.

They fundamentally lower the cost of trust.

They mean that I can produce a proof that I'm employed at Goldman Sachs − and therefore, someone can give me a loan on the blockchain.

It lowers the cost of KYC and reduces the cost of verifying… and not only in the computational sense. I don't need to pay a KYC company $200 to get your FICO score. I can just get a ZK proof from you, generated by another third party, that you're legit and you have good credit.

And I think that's going to be the Cambrian explosion for this actual usage of ZK. And I'm very excited about that.

I don't quite know what it will look like, but that's what we at Hylé want to help develop.

Use cases for ZK technology

ZK passports

I'm really excited about ZK passports in general and all the teams working on that front.

When I pitch ZK to people, they don't really get it. So I show them zkP assport, Open Passport, or Rarimo.

It's like, « Wait, you mean I can prove to you that I'm a French citizen without revealing my data? »

And that's a gigantic improvement over whatever solution we have right now.

There are many discussions right now in Europe around « should we gate certain contents to adults? » And it's going to be mayhem. We will require people to do KYC and have credit cards. These teams are following the debates very closely, and they see ZK mentioned. And I think that's a fantastic liftoff.

Trust Infrastructure

A group of people have banded around the idea that programmable cryptography can be used to build decentralized applications, using blockchain when it really matters and using the right tool where it works.

So part of that group − we call ourselves Trust Infrastructure − revolves around the people at Tonk.gg.

They have a tool called Speakeasy, which allows users to create private forums that they can only access with proof of qualification. And it's really cool!

The mental model on the blockchain is that everything should be trustless, and you're not trusting anyone. And so you're either:

in the Web2 world, where everything is centralized, and you fully trust the company that's operating it
in the blockchain world, where everything is trustless, and therefore nobody trusts each other.

But there's nothing in between. The trust infrastructure people are pushing for is: Is there a way to have progressive discoverability of interactions on the Internet?

For instance, once we've had a few conversations together, I'm willing to disclose more about myself, where I live, etc. But on the Internet, it's either my full pedigree because I'm shouting on Twitter or nothing at all. You've got nothing between 500 million tweets a day on Twitter and a closed group chat.

What I love about programmable cryptography is that you have layers of interaction in between. Maybe if we've interacted five times already, automatically you will have access to more information about me. And that's why I think it's splendid!

It goes against the Internet's global stratification. It's great to be open, but how do you manage folksiness and closeness at scale? That's what really interests me.

The work of the Cursive team and the Tonk team's Speakeasy are fantastic tools for creating that narrative.

So, I'm excited about programmable cryptography for trustful human interaction.

Account abstraction

Pavel says: I like how you focus on identity and reputation. So you can learn a small subset of information, but that would allow you to access different activities or different actions across various ecosystems, and having an open login and extending that from your passport or just any type of general authentication without relying on a third-party authentication provider. So, someone can use OAuth, which allows you to log in with your Google account. But then, in the future, we can see that you can have a proof of anything, and then you can use that as a means to log in… I think zkEmail is working in a similar direction with that. It's really cool to see these use cases in terms of authentication and identity verification.

That's the thing that really interests us at Hylé: what we have access to by virtue of being ZK first.

One of my pet peeves is wallets. I've come to absolutely hate wallets, and I've worked on them for a good chunk of my career. It's a disgrace that it's 2024, the Bitcoin whitepaper was in 2008, and whenever I want to onboard anyone on the blockchain, it's always like, okay, so you're going to have to download MetaMask, and then you're going to have to... It's ridiculous!

Lucky for us, we're moving in the right direction. A massive first step was account abstraction. Okay, cool. Now, we can have more logic, but it's still not intuitive.

You can read more thoughts about this here:

In our demo VibeCheck, we use WebAuthn. We're only verifying the proof of a WebAuthn signature, which means that you can use anything. You can have a username and password. Anyone with a French passport can use this application!

It's a lot more expressive than what you have right now with just smart or programmable wallets. And it's composable: you can have proof of an ECDSA signature, proof of having a Metamask wallet, proof that you are a Thai citizen, and proof that you're over 18 years old… and make all of those the criteria for a transaction.

Gaming

Onchain gaming

DeFi is the one thing with product-market fit in blockchain. Stablecoins are fantastic, and they've become the standard for the sophistication of smart contracts and dApp development standards.

But DeFi apps have precise requirements:

very low trust minimization
decentralization
very high availability
very high censorship resistance.

Games are quite the opposite. Gamers, no matter what they say, are OK with a two-hour downtime. You're not saving lives, you're not trading millions, you're sending your fleet to attack an enemy. But in exchange, you want things to be very fast.

What happened in the gaming ecosystem onchain was that we went from « let's be minimally onchain » to the point where you only have the assets. These are the Axies, the Sorares. And now, the pendulum is swinging back in full force in the opposite direction.

And that's how you get the onchain gaming scene, which is very experimental. It's a fun crowd of people who are really pushing the EVM, pushing blockchains to the maximum, and trying to do things that are basically illegal and that no one has really tried to do before.

It's challenging because the standard so far was DeFi. So you can see in a lot of onchain games that they kind of look like DeFi. You try to move resources from there to there.

Two teams on that front are really pushing the narrative: Playmint and Topology. Two excellent friends of ours at Hylé. And what they realized is they both started from very onchain. The Playmint team is a team of gaming veterans, and Topology was a very early Starknet builder. They started, and they tried to cram as much logic as they could onchain. They eventually realized that it just didn't work.

It can work for some types of games, but the type of games that the Playmint team had built previously, like Fall Guys, it just doesn't work. You need something that goes faster. So what they're looking at now is the same train of thought that we've been having at Hylé for a while now, which is: «Let's just do the hard thing offchain and sometimes go onchain when it matters ».

For instance, Topology uses CRDTs, and there's very low censorship resistance. You can cheat, but you always have the option of going back onchain, and that's what's great! You don't start by requiring people to have MetaMask to go onchain and pay dollars of transaction fees. You provide them with the option of going onchain.

You're not onchain; you're possibly onchain. That gives you a lot of reassurance in terms of resistance, but it's not the limitations of blockchain, this blandness agent of some sort. We will not require you to be onchain at all times.

This opens up a whole new realm of possibilities. All of a sudden, I'm back in Web2. My users don't need a wallet, I don't need to tell them what MetaMask is or what a gas fee is, and I don't need a Paymaster system.

They're just going to play, and maybe one of them has a high score and is willing to pay five bucks to have it verified onchain and inscribe it on a provable leaderboard. These are the things that are just not possible in the blockchain.

Let's not forget that in 2017-2018, digital cats brought down Ethereum. It was always the games that turned everything into shit. And that's where I think it really forces you to rethink things very differently.

Speedrunning

Cheating is a growing issue in some gaming communities. For example, speedrunners have categories for all games, and each category has rules.

A problem that you have with these things is cheating.

What you're doing is very difficult to manage for multiplayer games, and speedrunning is a multiplayer game. You have dozens of people or more speedrunning a game according to specific rules and then sending their game for the leaderboard. They’re like asymmetric, asynchronous multiplayer games.

The issue is the game is not happening on a centralized server. It happens on each player's machine, which can be tinkered with. And the proof that you're going to provide is a video. It's easy to cheat: you can do something called splicing, where you remove some parts of the video to speed things up. And it's challenging to track: usually, people get suspicious because a given player was awful two months ago, and all of a sudden, they're number one.

So, theoretically, you could prove that someone has played according to the rules of the game. And that would deter people from cheating using modified software or not respecting the laws of the game.

The Beat Saber leaderboard

Pavel says: I was playing a game recently called Beat Saber. On the scoreboard, one of the high scores was in the range of 2 billion. That person obviously cheated. So, one could prove that the execution of the game was correct and then send that proof to Hylé. Would you imagine that being the flow for the pipeline in that way?

There are limits to what you can prove. There's no difference between having a proof and having the person play on a centralized server controlled by the company. In both contexts, the result is the same: you will be sure that the person has played by the rules.

But you can't be sure that the person is not using out-of-bounds stuff. Maybe the person playing Beat Saber was using a bot. And there's no way ZK can really assert this, the same way that the centralized server can't know that. So there are limits to what you can do there.

What's interesting is the possibility of creating more rules. If you play with a centralized server for a multiplayer game, there's one way to play. But if you play your game with three of your friends with a little consensus, and you say, « OK, we're going to play according to that rule set », then you're able to verify on Hylé that you've played according to that rule set. You verify it after the fact. You're not asking for permission; you're asking for forgiveness. Maybe one of the checks can be, okay, a human needs to check this, and you have a list of people who are authorized to do so.

Provability can solve many issues, but as David from Playmint told me, people will just cheat.

I was talking about it with Will Robinson from Alliance DAO. He shared a story about an onchain game that tried so hard to identify bots that the bots just got more human-like, to the point that they couldn't be distinguished from humans. And so, it wasn't that bad because, to escape detection, these bots became barely better than humans. So, as a human player, you always had someone to play with that wouldn't kill you on the spot or be massively better than you. So that was an amusing side effect.

Provability: infusing web3 into web2

Putting banks onchain

You can look at ZK as a magnificent API between onchain and off-chain. It's great.

One thing that I'm very excited about with provability is, and I'm echoing Krane (from Asula and Bedlam research) there, onchain and off-chain domains. He has a very nice framework for thinking about different things happening in the blockchain.

Let's take rollups. Rollups are an extension of Ethereum, and they just post state and verify their state on Ethereum. And Krane has this funny idea of saying, «Well, Binance is a rollup ». It just has different trust assumptions. It's very stateful, but it has very low trust minimization. You really, really have to trust Binance. But basically, as far as Ethereum is concerned, Binance is a rollup. Ethereum has no idea what's going on on the other side of the spectrum.

I realized that with provability, it would be effortless for Binance to become a rollup. They just post a validity proof of a system's state transition. And they would not even need to rewrite everything in Noir or Cairo. They could do this using a zkVM. This would be highly inefficient. But maybe they just post their validity proofs every week, and that's it!

And once I started thinking about this, I realized we can finally put banks onchain.

Improving on classic web2 systems

We've been trying to put the banks onchain for a really long time, and the way we've been trying to approach it is going up to Goldman Sachs, putting our hand on their shoulder, and saying, « You've been doing it wrong all this time. You should trash everything and rebuild it onchain. Here's Solidity. »

What I'm excited about with provability is typical Web2 systems, rather than rewriting their entire systems in a specific language and adapting to the blockchain, can just use a little tiny adapter called ZK to go onchain.

We talk about rollups now, but eventually, everything will be a provable server. Like I said before, with Binance, there will be a spectrum of different decentralization options.

I can definitely see Web2 businesses deciding to go onchain, running a zkVM, and settling on Hylé once a week. And it's great!

It's very different from the ideal version that we had of migrating everyone onchain. But in my mind, it's a massive improvement over the status quo and something we should strive for. So that's what I'm very excited about with programmable cryptography.

How Hylé works

The limitations of traditional proof verification

Native proof verification

The issue with blockchain is that thousands of computers are redoing the exact same computation over and over again, which is how we get trustlessness.

Our approach at Hylé only focuses on proof verification.

If you’re interested in native proof verification, you should read our detailed article about that!

What rollups do on Ethereum is simply verify state transitions: « Arbitrum went from A to B, StarkNet went from C to D. » As far as Ethereum is concerned, that's the only thing that they see.

In the context of provable applications, everything works like this.

I have an application that's going from state E to F, and I'm going to send the proof of that and the new state of the application to Hylé. And Hylé is going to say, «Okay, that's the new state; that's the proof. You're good to go ».

And you do not require the nodes to run the costly computation on top of this, which opens up exciting possibilities. The execution environment does not constrain you.

On Ethereum, or basically any programmable L1 at the moment, you are limited by the least powerful node.

So it's very logical that people would ask, « Why don't we just make the blocks bigger? » And it's a very reasonable thing to say, « Let's just do the bigger thing. Let's just add bigger computers. » But it defeats decentralization because it means that only the big computers can participate in consensus.

Zero-knowledge tech breaks this. You can verify extremely large proofs on consumer hardware, and you can separate the work between the person doing the work and the person verifying the work.

And I think it's a very, what Ivan Illich would call a tool for conviviality. It's a tool that anyone can use. And in the context of big block blockchains like Solana, well, it's not very convivial because you're trusting that the massive machines are going to run the network.

What's great with ZK is that you can have these massive computers do exceptionally hard work, and they can be centralized, efficient, and VC-funded. However, the network can also be very decentralized. It can run on a smartphone and have oversight of what's going on on the other end.

That's what we're doing at Hylé. We're a blockchain, a network blockchain that does a lot less stuff than normal blockchains do. But because we're tailor-made for ZK, we don't need to ship a VM.

You can come in with any type of programming language as long as it's provable. In order for you to have an application on Hylé, it's very easy: you just say how you're going to verify your program.

The proof lifecycle

At the top: ZK transaction on another network. Bottom: ZK transaction on Hylé.

You can run a Solidity contract on Hylé; just specify how to verify it. You can run a Rust application on Hylé: just say, « Use RISC Zero to verify this ».

Not only does it make it easier to verify the proofs, but as a user, as an app, you don't even have to think about it.

You're just going to send provable payloads to Hylé. Hylé takes care of sequencing them: «This one came before that one ».

Then, you need to know how to verify those programs. So you run the computation, generate the proof (that's the job for the network validators), and then send it back to Hylé. Hylé says that the proof is valid and pays everyone.

Delayed proving

The question we're trying to solve is: How do you ensure that proving is not a bottleneck for your network and your application?

Sometimes, proofs take a lot of time to generate. There's always an overhead versus just running the code. When you're dealing with very large proofs, it can take several minutes or hours to generate a proof.

So, the way provable apps work is:

they run somewhere
a proof is generated
the proof is verified.

That's basically a rollup. Everything is a rollup. This is also how systems like Mina work. Mina only verifies proofs; it does not ship a virtual machine.

However, issues arose, and they led to us creating delayed proving. We’ve written about it here if you want to read more:

I do think it's the only way you can really solve this elegantly. This gives you extremely high throughput, without proving as the bottleneck, and solves concurrency issues.

You get all the good things of having a provable application:

you choose your development environment
you choose your execution environment
you choose the level of decentralization that you want.

You don't have to deal with the pesky problem of every application needing its sequencer. You just offload this to Hylé.

Hylé vs. aggregation layers

We differ from aggregation layers in that we don't focus on verifying the proofs. We focus on abstracting every single step of the process.

We don't even require users to come with proofs! We just need them to come to us with provable payloads.

We don't want to make proofs cheaper to verify or generate. We want to abstract the whole supply chain to deal with proofs.

We want people to say, « I want this verified. Take care of it. »

Conclusion

I think programmable cryptography was born on the blockchain, but in the same vein as what the character in Interstellar says, « mankind was born on Earth, but it was never meant to die there ». It's a bit the same.

I'm very excited about all the cool stuff that we're going to be able to do with programmable cryptography, in ZK in particular, that may or may not be related to blockchain. That's why I'm excited about what we do at Hylé: we're giving the little tiny part that you need to be onchain. And the rest is for you to decide.

I don't think there's been a better time to be in blockchain and even more so to be opinionated about what you want to build in blockchain. And it's okay to say, «Maybe I don't want to be fully onchain at all times. Maybe just a tiny bit is okay. » And what does that expand? What does that allow? That's what I'm excited about.