[Podcast #1] Matteo on play-by-email provable games

On the Hylé podcast, we talk about cool applications that leverage cryptography in general and zero-knowledge technology in particular, with a new guest every episode.

Our guest for this first episode, Matteo, is an independent applied cryptography developer. He is also Hylé’s first grantee, and he built a play-by-email provable game engine using zkEmail and RISC Zero for proving and Hylé for verifying and settling the proofs.

This was a fantastic first episode, with conversations including why zkEmail is so cool, what Matteo is most excited about in cryptography, and having annoying friends who lie about beating you at chess!

If you prefer the written format, you can read the highlights below.

Play-by-email provable game engine

zkChess

Sylve had the idea that you could play chess via email and use zkEmail, a library that can create proof that you received a specific email. You could prove that you won the game by email, which would allow for a system where you can't cheat. Sylve and I've known each other for a long time, and we've always been talking about zk and zkApps even before either of us was in zk; we started talking about this and thought, this is a good idea.

Two people would play together, and at the end, they could have a verifiable game that one of them won or lost. That's the main idea.

And then, on top of that, when I was talking with Sylve, I was like, « It's a good idea, but you could just abstract the zkEmail and RISC Zero parts » and just have a game engine for any play-by-email game.

I built the zkChess example, but anything playable by mail can be implemented—not just games, but any email exchange!

The library is just a mail server. When it receives the mail, it asks the dev, « Okay, what do I do with this mail now? » This is the idea of the whole library. « Okay, I received this mail. Can I prove something? Yes? No? Okay, I should not have to prove anything. Do I have to prove something? Okay, I'll compute the proof now. »

It's plug-and-play. The library has one function that says « process email.» If you return « true,» it will prove. If you return « false,» it won't do anything. The processed email is whatever you want because you implement it when you implement the game.

We are creating an abstract layer to make it easier to verify it on Hylé and prove it with RISC Zero and zkEmail.

The server cannot cheat. The only downside is that the server could censor. If we play a game together, you could maybe rig the server so it doesn't send the proof to Hylé if you lose. This is a downside, and there is a way to mitigate this, but it's not in the scope of the project.

For UX, it's better to have a server that you can just CC the emails to instead of proving everything locally. And you could, in theory, do everything peer to peer, but it's just much better to CC a referee and let it do the proving on the server side instead of locally − it's less expensive that way.

Proof composability

In zkChess, we use two different proof systems:

• zkEmail is super robust and high-quality, and it's in Circom, which is a pain to write compared to…
• RISC Zero, especially if you use that premade Rust library for chess. I verified that the library was valid, and then the chess engine was done, and I could prove it with RISC Zero.

Then, using Hylé, I could combine the two proofs using proof composition to ensure that they are actually linked together and that I have two valid proofs with the same inputs.

Without proof composability, you could verify the Circom proof inside the RISC Zero proof and write the verifier inside, but it would be costly. With zero-knowledge proof, you want to do the fewest things possible inside your proofs in general because proving time gets very long.

So, instead of verifying it inside the proof, I just verify it on Hylé. With proof composability, instead of putting layers and layers on top of each other, « this proof verifies this proof, which verifies this proof, etc. » You just put two proofs and combine them with Hylé. It avoids having to rely on foreign field arithmetic and multiplies the number of transactions that can be done.

Proving only the two last moves

If I can be a bit technical about the way I did the chess part, I did not prove every move of the game because I realized you don't have to prove every move. You can just prove the last two moves to make sure that the whole game is valid.

Let's say I play a wrong move, and I say, « I played this bad move, and it gave me this board. » Okay. And then you say, okay, I played this mate on this board, then I cannot complain that you cheated the whole game because I just said the move before that I played this move. So you just have to have the two last moves to prove the entire game, which makes the game kind of stateless.

With zkEmail, since you sign every mail, when you send an email, you basically say, «This board is the board I'm playing, and I play this move on this board. » You imply that everything before was valid. If there were a problem, you would say to the server, « Hey, no, this is wrong. »

So I only need the two last moves to prove it's a mate:

1. Player A: I play this move. I sign it. It's this board now.
2. Player B: I play mate on this board.

Now it's complete; the game is valid.

It's super fast because the only thing my server waits for is emails. I don't prove anything before the checkmate, so the game is fluid; everything goes smoothly. And then, at the end, the server does the job. And then, when there's a checkmate, we're done playing. So it can take time; that's fine. So the game is smooth. And then, at the end, the proof is computed. I think it's quite fun!

Chess was an easy example, but people should do other stuff with my engine, please!

What's next for provable apps

It's very funny because we're at a time when everyone is doing infra and saying, « Oh, we need to build more apps. »

Then when you start to try building apps, you realize you don't have enough infra.

It's a bit frustrating because we're almost there. But at the same time, we need,
I think we need more projects that actually build apps, and we need smaller projects that do apps. It's a pain to create apps right now, especially debugging stuff… I don't know; the docs are terrible.

You need a lot of knowledge to build real apps, I think, but sometimes it feels like there is this meme about standards that are, « Oh, we have 14 standards. We need one more to have every standard be standardized. »

It feels like this sometimes with infra because you have « Oh no, this infra created this new problem. So we need infra to solve this infra problem. » And I think with RISC Zero, SP1, every zkVM, jolt (I like jolt. I contributed to jolt.)

With these zkVMs, it's super easy to build cool stuff.

An app idea: verifiable reviews

You could have proof that you went somewhere; you just tap your phone on an NFC card and generate the proof. And then, when you have this proof, you can create a review that is only, « Okay, this guy has scanned the card. " You can have all the restaurants that have all their cards and all the reviews, and you cannot create fake reviews because you have to go to the place to post the review.

For example, in those « verified buyer » reviews on Amazon, Amazon
checks that your account has bought the product. And you could do this on
a platform that's not Amazon and just use zkEmail to prove that you got an
email with the bill for that object before reviewing it. We could finally fight fake reviews efficiently.

Moving offchain

I also think people need to change their mindset and not put everything onchain. This is my controversial take because people have the blockchain world too much in their minds, and they always want to go onchain and verify the proofs onchain. But if you leave this paradigm and you just go « okay, let's just verify stuff. »

And for example, Hylé is like this, right? You can just verify stuff and then
settle on this thing that has been verified.

It just creates much more opportunities because you can use RISC Zero locally or on external servers. And I believe people need to open their minds. It's fine to use normal databases to store stuff. My project uses databases that are
entirely Web2. The proof comes at the time you actually need it.

You just need to pinpoint the place where you need to prove: «Where is decentralization needed? Where is trustlessness needed? »

It comes back to the fact that you have this email server for zkChess. It's not decentralized and uncensorable, but it's trustless, and it creates proofs. This is the point. If there is like a bet of 100 million dollars using your zkChess project, then you probably need censorship resistance. But if it's to play a simple game,
I think we're good with a centralized server.

It allows you to play games against someone you don't trust. I think this is the cool point: someone you know might want to cheat, like a dishonest person, and it's cool to have zero-knowledge proofs that enforce it. I like the idea of « It cannot happen. » You cannot cheat, by definition.

What's next for zkChess?

For this project, you could, in theory, use Hylé for settlement and then place some bets on Ethereum. And it would be a fun project to do.

I think the coolest thing with Hylé that you could easily implement is using the state and doing an ELO computation because it would be very easy, with my system, to do. Because the ELO system is probably there, there is a library in Rust that does ELO, I'm sure. You could have a proof with RISC Zero. And then you could use that to put it on Hylé, like on the state of Hylé, to have a verifiable ELO.

If you think of Chess.com or LiChess, which are the two largest websites, in theory, if I'm an administrator, I can put myself as grandmaster and at 3000 ELO, and nothing stops me. It's trust-based. I don't think it's the most sensitive case where you need to have a trustless thing, but I think it's an excellent example of how you can quickly build trustlessness.

Having a ZK proof of the results allows you not to have to share everything with someone you don't trust, but also to have verifiable information that both of you can trust.

Barriers to entry

I think the main barrier to entry is the lack of examples.

Infra, in a way, for sure. Sometimes you try to do stuff, but it just doesn't work.

But I think the biggest barrier to entry is that it takes so long to do everything. Like debugging your stuff, doing everything is super long. Actually, with RISC Zero, it's very easy to set up and very easy to debug. So that's a good thing, for example.

But with Circom, it took me a long time to debug some stuff. It's terrible. And I think we lack examples.

I hope my code can help people who need to do zkEmail. The team gives the examples, and then there is zkP2P, and then that's it. It seems that one uses zkEmail apart from that, I've never found them. No one talks about how it's done, its architecture, or anything. And this is, for me, the biggest thing for beginners.

Maybe cool stuff exists, but you wouldn't know where to find it. If it's a problem for me, that's a problem for a lot of people, I think, because I'm already pretty deep into the apps. So I think, yeah, discoverability.

It's like Solidity back in the day. You need more people doing new contracts and doing new stuff. And just push out the word that you can do cool things. One thing I once said to the RISC Zero DevRel was that they should go to Rust hackathons that are not crypto and just talk to people and create new stuff. They should get out a bit of crypto and try to make people learn about ZK in a way that is not related to blockchain. I think blockchain and ZK are closely related, but at the same time, ZK can be and probably will be much bigger than blockchains. I don't know, for me it's… we need to have more people doing stuff, it's a bit of an egg and chicken problem.

What Matteo is excited to see next

I'm waiting for witness encryption in cryptography. It's the coolest thing in cryptography.

Usually, when you encrypt a message, you have a private key and a public key. Yes. And you encrypt it with the public key and you can decrypt it with the private key. The thing is, with witness encryption, the idea, like the general idea, is to be able to encrypt a message that can be only decrypted if you have a certain witness. But a witness can be anything, including a proof. So you could have, I don't know, yeah, you'd get something that is encrypted and that you can only decrypt if you have proof that you went to an offline event.

This is witness encryption.

From what I remember, in theory, you could even encrypt with something that you don't have the answer for. So you could encrypt and say, "If you have proof that 1 is equal to 2, then you can decrypt the message." Something like this.

In ZK… more apps, more stuff. I think zkEmail and zkP2P are doing very cool stuff. It's exciting to see all the stuff coming from them. I think Cursive is doing very cool things as well with MPC. Very excited about MPC in real life as well. I think it will be very cool. I think if you look at what PSE does, I think it's very cool in general. This is what I'd say: keep an eye on the 20-star projects on GitHub from PSE because they're doing very cool stuff.

Apart from that, I'm very excited about VerITAS, a paper that proves that a given image has specific edits but nothing else, which is very cool. I would like to see apps. The problem is that I've been so much into research stuff that sometimes it's hard for me to go back to apps because I am too excited about research papers and things like this and research projects. So, sometimes, I'm a bit disconnected.

I think it's a problem for a lot of people in ZK. You start looking at the new tools that exist, and you're like, « Oh, we need to do something with this. » And not necessarily, « I want to build this. What tool will allow me to build it? » It's « Oh, there is this new paper. I want to implement this paper, even if it's not useful; I just want to do it because it's cool. »

I think co-SNARKs are very interesting as well.

I like cool apps, trustless apps, and stuff related to identity as well. I think it's very important. It's very cool. There's identity stuff, and I'm especially excited about identity stuff that already exists in our space. That's why I was like, zkEmail is very cool because you have the discoverability of emails. You just need an email to create a wallet. You just need an email to create a chess game.

I think if you start to create new identities, you lose the plot a bit because we already have too much stuff, too many accounts, and too many ways to do things. I would say, in general, if you need to create a new account, I don't see the use. And if you've got one, it's just better. That makes sense. I'm very excited to see how we can use existing identities, either passports, Google accounts, or email addresses.

You can find Matteo's provable play-by-email game engine on GitHub and follow him on Twitter.