[Interview] What is Hylé, with Sylve on the "GM with Siborg" X space

Missed the latest X Space hosted by SiBorg Labs, where Sylve talked about Hylé's vision and future? We’ve got you covered! Our discussion is now available on YouTube. If you prefer the written format, you can find the full transcript below!

Sylve: Hi there everyone.

Maxime: What we usually do, here, on this space is, we start by a few questions on the personal side of things, regarding your background, etc.

Then we go about a few questions on your company, what are you doing? Why, etc. And we try to deep dive on those aspects. So to start, please introduce yourself and especially tell us what you did before, entering in the Web3 ecosystem.

Sylve: Sure thing. Thank you very much for having me here. I'm, I'm excited to be on the pod. So I'm Sylve, I'm turning 30 in a few weeks, which is tough, I'll be honest. I'm the co-founder of Hylé. And to answer the question that you had about «when did you arrive in crypto?»

I think I started in like 2016, 17. And «what did you do before entering Web3?» I wasn't doing anything before entering Web3 because my first job was as a product manager, working on the B2B products at, the hardware wallet company, headquartered in Paris. So I started my professional career in the blockchain space, straight up.

Maxime: Okay. So you entered the crypto market back then. Why, back then, did you join Ledger?

Sylve: The reason I joined Ledger is because I really wanted to work in a startup environment. I was really excited about blockchain in general. I think I encountered blockchain first in 2015 because I was a hardcore libertarian back then.

I like to say that I came for the revolution and I stayed for the people and the projects. It was just on the back of my mind. I was just looking at it from time to time. Then I worked, I had an internship in venture capital and some of my time was allocated to research on new topics.

So that allowed me to really deep dive into what Ethereum was. So a really big blog post, really big research notes about, «Oh, Ethereum is pretty cool. We should buy ETH, buy BTC. We should buy one of these very weird CryptoPunks and see what happens.» So that's… They didn't exactly listen to me, but that was a really fun experience.

Then I wrote my master's thesis when I was in business school, around NFTs. And that was, I think, the first paper written about… like, formal paper written about NFTs, because that was in end 2017, beginning of 2018. And that's what drove me more, I think, into the blockchain space. So I just joined Ledger because it was a very reputable company, I wanted to work in product management, so it was a match made in heaven.

Maxime: Okay. I think that's good. And I think that, doing research and people that do research in crypto, that's something extremely, valuable because I've been reading so much, in the last year and, yeah, definitely amazing to see that you have written like cool stuff on the ecosystem.

We have one question that we ask in general at the beginning of the pod, to, know a little bit more. Basically the question is, what is the first crypto you bought and what is the latest one, so what's the first and what the latest one you bought?

Sylve: Oh, that's a tough one. I think I bought BTC first because back then in Ledger, like I joined in 2018 and back then it was a lot of BTC maxis. So I think I got BTC-pilled quite early and the latest one… probably bought a shit coin on Starknet to test out an AMM.

I think I forgot.

Maxime: Okay, so that, that's interesting. And why Starknet? Are you in some way, involved without saying too much about, Hylé? Why did you choose Starknet? What do you do there?

Sylve: After Ledger, we built a first project with my co-founder, Lancelot, called briq, and it was the biggest NFT protocol on Starknet.

We were the first project to launch on testnet, on mainnet… we started in '21 and the project is now continued by a new team, former people from the Nouns DAO, and, that's how we learned everything we know about zero-knowledge proofs, about building a network. It was an extremely exciting experience because we got started in October '21.

So the test net was only a few months old. We built briq, which was basically a composability protocol fully onchain. So it was a very early onchain game. You could think of it as a mix between Minecraft and Lego, but running fully onchain. Working with zero-knowledge proofs in Cairo and Starknet back then was like eating and like chewing glass, but it was a very exciting experience.

We learned a lot about how to build a network, build a community. In our years on Starknet, I worked on the Starknet Foundation as a governance lead, and we also co-created a fully provable game engine using zero-knowledge proofs written in Cairo, called Dojo, and most projects in StarkNet right now are using it.

So it's like a version of mods, like the Solidity thingy for engine games, but specifically targeting provable applications and it's written in co-created. So we spent a lot of time in the StarkNet ecosystem.

Margaux: Could you please just explain what is a zero-knowledge proof?

Sylve: Absolutely. The crux of it, if you really want to do it very simply, it's you want to be able to give certainty to someone that you know something without revealing that thing. An example that people usually use is I want to prove to you that I know where Waldo is in the Where's Waldo game.

And it's difficult because if I show you where Waldo is, I don't want to reveal that to you. So I want to prove to you that I know where Waldo is, but I don't want to show you where Waldo is. So the example that people give is you take a very big cardboard cutout, make a very small hole, and then you press the book on the cardboard box, and then the person is able to see through the hole, the little head of Waldo, but they don't exactly know where it is.

Zero-knowledge proofs are a lot more complicated than this, but the core of the mechanic is this. You're able to prove something without revealing the thing. If you want a slightly more complicated example, I want to prove to you that I have solved a Sudoku, without revealing the solution.

So what I will do is, I will take every line and every colon, will cut down every single number and all lines in all, columns. They sum up to 45. It's the sum from one to nine. So I will take a line, I will shuffle the numbers, then give it to you. Then you can count for yourself. It's okay, that's 45.

And for each row, in each column that we do, your confidence level rises up to the point where it's not really useful if you do the last three columns. Zero-knowledge proofs in practice work quite similarly where these are probabilistic proofs. So you give a very high chance, a very high degree of certainty to the person that is asking for the proof that the program has been run correctly.

This was a research topic It was a very exotic type of research topic, I would say, 20 years ago, the first papers were in the 90s. And one of my favorite forum posts is by Satoshi Nakamoto in 2010 about using zero-knowledge proofs on Bitcoin. The forum post is something like, There's this weird branch of mathematics called zero-knowledge proofs.

If these things worked, it would be really cool. And we'd love to have it on Bitcoin, but we don't. So we can't really use it. It was very inefficient back then. And the first projects to really implement them were for Zcash for privacy purposes. Zcash was, let's say, a version of Bitcoin where you could hide through what they call shielded transactions, your transfers.

So you would produce a zero-knowledge proof that something was transferred, but you couldn't look up who it was sent to, who received it. You were using the privacy aspects of zero-knowledge proofs. Now they're a lot more, I would say, popular, and research has surged because they're used to speed up blockchains.

The core of the issues that blockchains have is that you're asking thousands of computers to redo the exact same computation over and over again And that means that you're limited by the smallest computer in the network because you need to make sure that everyone can run the computation.

So what you do with zero-knowledge proofs is, hey, let's have this very big computer do all the work for everyone else. And then that computer will produce a proof that it has done the work correctly. And then the smaller computers can run in a very decentralized setup and verify the work of the bigger computer.

That's basically how rollups work. Layer 2, like StarkNet, they do a lot of things outside of Ethereum, but then they will post a proof to Ethereum and that thing gets proved on Ethereum. So zero-knowledge proofs are now in a Cambrian explosion. It started from super hairy research topics and papers 20, 30 years ago, and we're now exiting the research lab and moving firmly into the engineering realm where it used to be that you needed to have a PhD in cryptography in order to produce a proof that you've computed the square root of nine and that it's three.

And now you can just use basic code, you don't need to be a cryptographer. You can just, let's say, be an engineer to use zero-knowledge proofs. And that's very exciting in the field.

Maxime: Okay. Thanks for those explanations about zero-knowledge proofs, I think now is a good time to explain, what is your company and what do you do exactly there?

Sylve: Yes. So Hylé is a sequencing and settlement network for provable applications. Very concretely, Hylé is a Layer 1 blockchain that does two things. It orders the transactions and it's able to verify zero-knowledge proofs. The reason we're building Hylé is because we spent a lot of time in the Stark ecosystem and so we became very acquainted with a programming language that was built by the StarkWare team, called Cairo.

And Cairo is a programming language that allows you to just write proofs. So you can write a program and that program can be proved. And we thought, «Hey, that's really cool.» And we can build a whole lot of applications, just using the language, but not necessarily StarkNet as the underlying blockchain.

And that got us thinking, «Hey, now that we can just run the code of what you've built anywhere on your computer, on the server, everywhere… why should you run this code on the blockchain?» Because that's currently how blockchains work: when you send an NFT to someone, when you use an AMM, when you use any application on the blockchain, you're asking all the little computers in the network to do the work for you.

So the thing we were thinking is, hey, is there a better way of doing this by just making sure that all the applications are provable? That means that they're written in a language that can be proved. So that's how Hylé works. Hylé is a very specialized network that caters to these applications that use ZK.

And our bet is that ZK will be completely ubiquitous and we're building the network that is most specifically tailored for these type of applications.

Maxime: Okay. And, I'm not, an expert at all on ZKP and all this works. But something that I heard and I don't know, you tell me if it's right or maybe wrong or else, but some people thought that it costs a lot in terms of, computing power, etc. How do you manage this? Is it true? And if yes, how do you manage all this computation?

Sylve: That's absolutely true. And, a bit like what Lavoisier the father of chemistry said, nothing is lost. Nothing is created. Everything is transformed. And you can't get your lunch and eat it too. So verifying proofs is great because if something took, I don't know, maybe days to compute, it takes a lot less time, like maybe minutes, to verify. The problem is you need to generate that proof and generating a proof is costly in terms of machine time and energy. So that's why there's a lot of research that is being done on improving the proving technology itself. It used to be that it would take probably, I don't know, 10 hours to prove very basic operations. And now we're able to prove entire Ethereum blocks, which is a much, much more complicated type of logic.

So how do you handle proofs? The issue with proofs is they're really cool, but they introduce delays. Let's say that you want to run an application and have all your users generate the proofs themselves, and then send a proof over to Ethereum or Hylé to get verified. It's going to be very costly for them.

They may not have access to the high end hardware to generate these proofs. And there may not be sophisticated enough to use to, to know the proving services. So how do you do this? The way we're tackling this is by making sure that people don't even have to think about proofs.

So the way it works for Hylé is people will just send transactions on Hylé, just like you would be sending a transaction on Ethereum. And these transactions will later be proved by different proving networks to be verified on Hylé. So think of it as you, as a user, will send a transaction on Hylé with a little bounty to say, «Hey, if you prove this for you're going to get that much money.»

And then that thing gets proven,verified on Hylé, and then you get your funds. So the way we're targeting this is by not requiring users to generate the proof themselves. We're not centralizing proving, we're making sure that proof generation is not the bottleneck for the network and for these applications.

Margaux: Great. Thank you. Also I have a question in terms of competitors. Do you have some competitors? And, if you have some, what did you give, in advantage for them? Like what is the difference from you to another Layer 1 that does proof verification?

Sylve: So you have several projects that are doing what we call proof aggregation.

Proofs are not only timely to and costly to generate, they're also quite expensive to verify. So how do you verify zero-knowledge proofs right now on the blockchain? If you take the example of a Layer 2, zkSync, it generates the blocks, then a prover will generate a zero-knowledge proof of this.

Then that proof is sent over to Ethereum, and then a Solidity smart contract is deployed on Ethereum. And so the prover just sends the proof as a transaction on Ethereum, calling the verifier smart contract and it will tell it, «Yo, verify this.» And it costs between 250k gas to 5 million gas.

That's for the smallest proof to the biggest proof. So that's between, roughly 15 to a few thousand. And Ethereum is just not made for this. Right now, how blockchains treat verification is just like any other program. So you can write any program on the blockchain, but you have access to special things that are embedded in it.

And verification for proofs is not one of them. It's treated like any other. So the verification for zkSync on StarkNet is the same class as an NFT project or an NFT smart contractor in your smart contract. So that means that it has a lot of overhead. It's very costly. It's very expensive. Ethereum is just not made for this.

And it's quite normal because when Bitcoin or Ethereum were built, zero-knowledge proofs were not to the point that we would think that we'd have verification code that could run. So what we're doing at Hylé is the nodes of the network, rather than redo the computation and run the Ethereum virtual machine, for example, what they do is that they run the native verifiers for the different zero-knowledge proof systems. So that's similar to saying, if you want to launch a very resource intensive video game, you use specialized hardware like a graphics card rather than use your CPU, your central processing unit. The choice that we've made is to specialize in zero-knowledge proof verification because by doing this it means that we can do it much more efficiently than anything else.

The trade off for this is that we don't work the same way than others. We don't have access to an execution environment on Hylé. You cannot tell Hylé to do things. You can only ask Hylé to verify things that have already been done before. But our vision is that ZK will become so good that you will not even see the difference, and it makes sense to specialize in doing this, the same way that you have specialized chips for graphic computation or AI computation.

We're basically doing the same thing. Hylé is a network that is specialized for ZK.

Margaux: So what is the future now? Like in terms of your roadmap, you build that and what is like the next step?

Sylve: So we built a first MVP for Hylé using, a little toolbox that people use when they want to build blockchains.

It's called the Cosmos SDK. SDK means it's a toolkit for developers. We used a little toolbox and we built a blockchain from scratch and then we started adding more of the logic that we want for Hylé, so we started adding these verifiers for the different proof systems, and then we started tweaking and that works.

It's already live. You can already try it out. We built an application using it that mixes zkML. It's a very fun application. You just smile and it will generate a zero-knowledge proof that you have actually smiled and then you get tokens on Hylé. This is all for test, don't hold me at gunpoint for it.

These things are meaningless. It was just to showcase that you can run an application in a fully provable mode. But we realized very quickly that Cosmos SDK works really well if you don't remove stuff. And because Hylé doesn't need a lot of these things, it can be a lot simpler. And that's where we started to see the cracks in the Cosmos SDK.

So we decided that we were going to rebuild basically our own node system or own blockchain from scratch in Rust to make sure that we would have only the features that we need. That allows us to have a lot more control over how Hylé works and to really optimize for zero-knowledge proofs.

For example, blockchains use signatures all the time. Your wallets use signatures, Hylé doesn't have signatures because we verify proofs. So we verify the proof of your signature. That means that we do not need to choose which curve, which type of signature we want to use, which type of wallets, we only need to make sure that all these signatures can be proved.

And that we support. So it's like you have a very big funnel and everything gets bundled into a proof and that we support. That's a really cool thing about zero-knowledge proofs. It's like a massive, a giant connector, a giant API for, different IT systems.

Maxime: And so when will you go on mainnet?

Sylve: Oh, that's a tough one. We're already, it will take us a couple of years. I think currently our goal is to release a new version of the test version of Hylé in the next two, let's say three to four months, with this new system. Iterate on it, build new projects, build new applications and see how it works.

Maxime: Okay. And, so actually it's very interesting, it's my first time really talking with someone, that is really like building something, on this field. One thing, that is very important and that is more, on something that we do, which is linked to consumer and especially to traction.

So as you mentioned, you're a Layer 1 blockchain. It's very hard today to be a new Layer 1, especially in terms of attention, fragmented liquidity, etc. So what is your strategy? Even if you plan to go mainnet in a few years, you still have a bunch of time, to see that, but do you have a strategy in mind to, to go, to get more users, tractions, etc.?

Sylve: A whole meta game in the past years was to build Layer 2s. The reason people built Layer 2s is because we saw that it was very costly to run your application on Ethereum. If you think about the very early project that we're running on Ethereum, you think about CryptoKitties, you think about Sorare, Axie Infinity, and all of them completely clogged Ethereum, each and every one of them.

So what they did is they either build their own chain… that's what, Flow, like CryptoKitties did with Flow, or they built app chains, side chains, validity rollups. That's what Sorare did with StarkEx, and that's what AXIE did with Ronin. And we realized that the Layer 2s are still, there's very few of them that actually use Ethereum for security.

If you look at, Optimism, for example, Optimism is closer to a sidechain than a Layer 2, because it doesn't even have fraud proofs enabled. We're still very far from it. What we realized is, you don't really get that much benefits from being a Layer 2.

I think it made sense, maybe 2 to 3 years ago, because that's what the meta was around and that was the narrative around Ethereum growth. But all in all, the way that proving technology is evolving, there will not be a difference between different Layer 1 blockchains and Layer 2s.

Because each of these blockchains, each of these networks will be able to be fully proved. And then you'll be able to verify the proof of these blocks on other blockchains. And that will be really good for bridging, because it means that you get instant bridging, thanks to ZK, because you know that, okay, this guy deposited that, the money on the bridge contract, and you can send that information and verify it on the other chain, then you can unlock the money right away.

But that means that the difference between Layer 1, Layer 2s is going to completely blur. You're just going to have ZK bridges all over. And being a Layer 1 or a Layer 2 will not make much sense. Also because the way you can very clearly see that people are now moving to app chains.

Because the issue with Layer 2s is that you have a fundamental misalignment of incentives. Why would you be on a Layer 2 if you're an application developer? You're on a Layer 2 because you have access to liquidity, all that good stuff. But in the end, you don't really care if you're there. You would much rather have control over your own stack.

You would much rather have control over the sequencing of transactions over much more of this. It's like living in a co-living rather than in your own apartment.

Maxime: I agree, but actually I was, in [Token 2049], two weeks ago in Singapore, and I listened to a talk about exactly these topics: app chain, no app chain, because we see on some part that people do, okay, Layer 1, Layer 2, even Layer 3, and some others defend the thesis of app chain.

And, an interesting answer on why, app chains may be also difficult was about the comparison with building an app on a phone. When you build an app on a phone, it's the same. The comparison was basically, okay. «You want to build an app on a chain and you build your own chain» is similar to, building your own phone.

Why are you building the app on this phone? And so what this means, just about, costs and complexity. So do you think that we'll see, have some action even regarding, the cause that, it could bring up the complexity. And even if we put apart, the liquidity side that you mentioned, because if we go on the ZK part, you already answered the fragmented liquidity issue.

When building a company, you still have a focus issue where you, for me, I think it's difficult to either build, a chain and an app and also yeah, it costs a lot. So yeah, that's my point of view on this part.

Sylve: That is currently really true. Because the way that people think about these things is because they want to build app chains.

And what are app chains? App chains are blockchains that are only used for one single application. There is a fundamental misunderstanding about what you want as an application developer. It is true that it is very costly and very difficult to build a blockchain yourself. And if you're an application developer, you don't want to do this.

The question is, wait, do I really need to be fully on the blockchain for this? And that's where we're getting now. Now that you're able to basically prove anything and generate zero-knowledge proofs of anything, you do not need to build an app chain.

The only thing that you need to do is make sure that the application that you're building can be proved. And that's it. You do not need to build blocks. You do not need to build indexers. You do not need to reuse the OP stack. It makes sense if what you're doing really requires your application to run like a blockchain.

For everything else, you do not need to be a blockchain. So I think the comment from that person is at the same time very true and extremely wrong. To take a very concrete example, it's been what, 16 years since the Bitcoin white paper and it's been 16 years that we want to put the banks on the blockchain.

That has been the thing that we've been saying for 16 years and we tried everything, we even tried to have the banks build the blockchain themselves. That was HyperLedger, Fabric and you had a bunch of banks, managing nodes for private blockchains together and it didn't work.

I think fundamentally it's like the meme between the guy who's pointing at the moon and the other one looking at the finger. Why do you want to be on the blockchain? What are the affordances that you want to have? You want your users to have more control, you want your system to be censorship resistant, and you would also like optionally for it to be private.

Running a blockchain, like building a blockchain and being fully onchain is one way of achieving this. Using zero-knowledge proofs is another, and it's now competing with that first way of building things. The pipe dream that we've all had was, yeah, of course, Bank of America is going to burn every single line of code that they've ever written and rewrite everything in Solidity.

And I'm actually quite impressed that we managed to delude ourselves into thinking this. The way it's going to go is, first of all, Bank of America is never going to do this. And second, they will keep their own code. They will keep their own system. They're just going to generate zero-knowledge proofs of how their systems work and send that to the blockchain.

And that's it. And that bit, like building the zero-knowledge proof systems that allow you to do this is super difficult. But lucky for us, you don't need to redo that every single time. You now have systems like zkVMs, which are virtual, ZK virtual machines, where you just take your code, put them in the virtual machine, it runs, it's very slow, but then it generates a proof.

And that's okay, you don't need more than this. So I think the comment is very true and completely misses the mark.

Maxime: Okay. I think it's a very good answer and an interesting one. So we digress a little bit on this question, but to continue about this distribution question, what is your distribution strategy?

Do you have any insight that you can give us? Maybe which type of people are you targeting? Web3 to start. Do you want to go also on the Web2 side and target Web2 businesses? And what is the strategy for this distribution and bringing people on ID?

Sylve: I think I'm super excited about wallets.

It is one of my favorite pieces of technology, obviously, because I worked at Ledger. And being very early on Starknet, I managed to, it was the, I think the first network to implement something called account abstraction, which means that your wallet is a small contract rather than just a very dumb key. And that's something that always interested me, the wallets, because on anything on the internet, you start using the website, then it asks you to build an account.

On the blockchain, it's the opposite. It asks you, the first thing you do as a user on the blockchain is, hey, download the wallet. Why? I don't know. Just download the wallet. And it's very cumbersome and it's very difficult to use. You have all these guys that are making fun of you because, oh, this guy is dumb.

They did not secure their 24 words and bury them on a metal plate in their backyard. Somehow we all believe that this is the normal way of doing things. What you're asking is a really good question. And I believe that if you're only targeting Web3 users, you're doomed. Because everyone is competing for the same, what, maybe 500,000 people over the planet?

This is a ridiculously low amount of users and people. Our strategy there is to leverage all the really cool affordances and features that zero-knowledge proofs give you. To give you an example, there is a project called zkEmail. It allows you to generate zero-knowledge proofs out of the emails that you send.

So for example, if you receive an email from your bank, with your bank statements stating that you have a hundred euros on your bank account, you're able to produce a zero-knowledge proof of that. So I'm able to go to Margaux and tell her, «Hey, here's a zero-knowledge proof that I own more than 50 euros».

And that's because I use zkEmail. So if you trust the bank, you're able to trust that the bank has sent this to me. You can use the same system to build wallets. You can onboard people on the blockchain without having them to, without requiring them to download a wallet, just with existing Web2 systems.

That's the really cool thing about ZK proofs. You can take existing Web2 systems, proof them and have them interact onchain. So in terms of affordance and strategy, it's really cool because you can start doing normal marketing. Hey, just like what PayPal did with referral links. If you invite five people on PayPal, you get 10€ and they get 10€.

You can do the exact same thing because using this thing, for example, your email is your wallet. So I invite Margaux, then she invites you, you both get 10 euros, 10 tokens, and you go on. And this is impossible to build without zero-knowledge proofs, basically,

Maxime: Okay, very good answer. But if we look at, the wallet landscape at the moment, I can still, download a wallet, for example, on my phone with a kind of easy experience where, you even have to now, if I build an app, I have to like, Privy, thirdweb, all of those guys that, enable us to just mentioned with only an email or a Twitter account to create wallets basically without having to solve those 12 words, etc.

This is my point. I've been talking with a few other builders and something that. I and this is where, I I don't know if it's really about I disagree with you or agree, but it's I think that new for the wallets, we, I think we're beginning to see an interesting shift with those wallets. It will be much more. For example, I think that wallets will become real social apps because from wallets you will use no, maybe, onchain discovery tools, socials, etc. And this is the kind of things where I think we will go. So on the part of, what you said about not having any more wallets, I think we will still have wallets and those wallets will become not only wallets, but real social apps.

And so the question is, with zero knowledge, I don't know if this is the tech that is used by some of people doing account abstraction. Of course, this is used by, Starknet, etc., but for example, guys like Privy and thirdweb that's already enabled an easier onboarding phase.

Is there some difference with those guys?

Sylve: I know exactly what you mean there. I think the efforts that they make on the onboarding side is misplaced. Let's think about, Google. When you first wanted to use like Gmail or Google sheets, did people tell you to, use Gmail or did they tell you create a Gmail account?

The fun thing with blockchain is that you start with the account and that we're trying to sell people accounts and the accounts, they exist. That's the very, very weird thing. You have an application on your phone, that's your account. It's, and I understand what you mean about it's a mix between SocialFi, it's also your window into blockchain.

They're basically web browsers. The problem is, they're very bad web browsers and they're making progress there. But if you think of it, you never start with the account on anything on the internet. You end with the account. I do not know how many accounts I have. Right now, I don't know. I look at Dashlane, my password manager, and maybe, I don't know, rough estimate, I maybe have 600 of them.

Some of them have different passwords, some of them I even forgot. Wallets work the opposite way. It's an object, it's a keychain. But that's not how accounts work on the internet. My take there is that wallets will exist, but it will remain a very niche type of application. I do not think that people will onboard by having a wallet application on their phone.

I think people will onboard by not even knowing there they have a wallet. And that's why I'm very excited about ZK, because it allows you to use existing Web2 systems as authentication without adding anything in the mix. I log in on the app using a zero-knowledge proof of my email, and that's it.

And I think that is much more powerful. I have a very funny story about this. When we were on Starknet, we were very close with the Argent team. They're pioneers of kind of abstraction and smart wallets. And they built something that we had been requesting for a while, which was a web wallet. So web wallet is something very similar to what we're discussing here.

What I wanted is for people to go on briq. Start playing and just use their email address to connect to the application. And there would be a small contract deployed with that email address, all that good stuff. But I did not want the users to download MetaMask, RGX or any other type of application, because that's still that's still fucked up when you think about it, like what? I don't want to have to download another app to use the app that you're already trying to sell me on.

And when they did this, we realized. First of all, it worked. It was a really good experience, but I've run into really fun issues. I made a transaction and then I sat there and I was like, where is it? And I was looking for my wallet. I was, because this is my Web3 habit. I use my wallet to look at my account, to look at my balance, to look at my transactions.

That's my safe space in a sense. But because I wasn't using a wallet there, I was lost. I was asking, wait, where did the transaction go? And then I asked my co-founder, I said, Oh, do we have something in the UI of briq for me to see this? And I realized that, Oh, okay. dApps right now, they can have very lousy experiences because the wallets need to take care of that.

You don't need to provide, necessarily, an account history, a transaction history, a full dashboard of everything because the wallet will take care of this. And I think it's going to take a lot of rewiring in UX, in developers brains, in app builders' brains, and even users' brains. And I think there, I got into massive arguments about this topic, but I really do not think that the current UX that we have on the blockchain will be mass market.

Maxime: Yeah, I agree with you on this point. Definitely the UX is still, shitty at the moment, but hopefully, it will evolve and it will be better and better. You know what, I really liked your vision on this and I can, only agree with you on those spots. Maybe a quick question that we need to ask, and even if, that is not for now, etc.

We usually ask, the people that come here, if you will have a token. So will you have a token in your ecosystem? And if yes, how this token will be implemented and works with your entire ecosystem.

Sylve: This is a super hard question, to which we do not have an answer at the moment because it doesn't, Hylé doesn't work like other networks.

Something as trivial as managing transaction fees, for example, is super hard. So we asked a couple teams how they handle these sorts of things. Like, how do you handle the token for payment, for token for transfer? It's super easy if you do it, let's say the Ethereum way, but it's very difficult if you try to do it any other way.

Long answer, short answer. Hylé will have a token. It's necessary for governance. It's necessary for decentralization, for proof of stake, all that good stuff. How exactly will that be implemented? We still have way too many things to figure out before we can talk in more details about that.

Maxime: Okay. Very good. And also there is something that, we haven't, talked about yet, which is about the onchain name system that you're building. Can you tell us, a little bit more about what is it? And, how is it different from something like ENS?

Sylve: Yes. ENS, the Ethereum naming system is really cool because who are you on Ethereum, your 0x49ABC something, and it's very difficult to know if you're sending money to the right address.

So what ENS provides you is the dumbest smart contracts in the history of mankind compared to its usefulness, which is a table where you have your address. And then on the next column, you have your name. So rather than say, Oh, I want to send money to 0x4986, you say, Oh, I want to send money to Armando.

The problem is that this thing is not implemented natively. So smart contracts cannot call armando.Eth. Smart contracts need to know Armando's address, and everything needs to know this. So it would be similar on the internet to every single service needing the exact IP address of everyone else, rather than knowing the URL, knowing the domain name.

And so that's what we're enshrining on Hylé. We're enshrining the fact that contracts will have basically domain names. So that it becomes much easier to find them. And because also way easier to interact with them from a web two perspective, it will look a lot closer to. Basically, a DNS system.

There's a lot we need to figure out there, but our intuition there is that it's fundamental enough that you need to enshrine it at the protocol level.

Maxime: Okay. It's good, it's interesting. And so, now just quick question on your network. Can we test already this, on testnet or, you do, because you mentioned that you're doing some kind of not MVPs, a few kinds of test, can we test already that on our testnet?

Sylve: Yeah, absolutely. You can go on vibe.hyle.eu, and you can try it by checking our first application. You can see the devnet. Be aware. It's highly experimental. It's highly slow and it's highly orange.

Margaux: Okay, nice. I just have a question. If I understand well, as the ZKPs give more privacy, it could be like a subject or a problem with all the regulation stuff or how does it work on that?

Sylve: That's a good point. it's quite difficult to know exactly how regulation will look at privacy in ZK. The good thing on that front is you have the, ANTS, l'Agence Nationale des Titres Sécurisés, the agency in France that is taking care of your passports and stuff like this, that is investigating using ZK for privacy.

For example, there are, I don't know if the bill has passed or if the law has passed yet, but there are a lot of discussions regarding gating certain websites, adult websites, for example, to minors, with a lot more stringent regulation. And it's quite difficult to do. So what the way they do it now is either they require a full KYC or a credit card imprint.

Neither of these are very privacy friendly. So the best solution for this are solutions using ZK passport. Your, information on your passport is signed by the government, which means that you're able to produce a zero-knowledge proof that You are over 18 and a French citizen, and that came from a correct passport, so you could go on a website, and that was a hackathon project by a team that built something called CornHub.

If you want to go and see _corn _on CornHub, you needed to produce zero-knowledge proof that you were above 18 with any type of compatible passport, and because these passports are, standardized, it means that it's very easy to do. So I think regulation at the moment is. not really looking at it.

I don't think it will be much of an issue. Rather, I do think that it's a very exciting opportunity, because this is impossible to do. In any other way.

Margaux: Okay. Yeah. And also it's more, maybe if you have an opinion on that, but, of course we heard a lot of ZKP, stuff like this, because it's sometimes I feel like in crypto, you have some trends and then you feel that Twitter is going to be on this topic, but do you think it's like really understandable, like for everyone?

Sylve: So I don't think it really matters. The same way that people do not know that their connection on the internet is secured by HTTPS or they don't know what TLS is. But they do know that there's a big red warning when these things don't work and they're going into a phishing attempt or accessing a bad website.

I think it's going to be the exact same thing users shouldn't care about that.

Maxime: Yeah, I think that's one of, I think that the sense of the question was more, on the narrative part. So we know that in the Web3 ecosystem, and I don't know if it's good or bad, but it's extremely narrative driven. When we start the narrative we have now, we know that it's important that if you want a narrative that works well, you need to be, easy to understand.

And that's exactly, the case with, for example, meme coins, which, is, I would not say useless for the society, but that is not the most useful thing that we have, as humans, created. But if we look at the narrative, everybody's going there because everybody can understand a meme.

So do you think that, because at some point you need, even if you want to touch Web2 people, etc., you need traction? And what we see at the moment that you have traction because people are interested by what you do. And in general, it's because of simple use cases, or marketing, etc.

And so do you think that this topic, because it's a very interesting topic. But it's also not the simplest one. So do you think we'll still, how will you manage this? And do you think you will keep up on the narrative part?

Sylve: I think it's a good question. What kind of affordances and what kind of technology can be built using ZK that can't be built anywhere in any other way?

I think it would be a fun mix of Privacy oriented applications and, just more decentralized applications. A good example that I can give you is, how would you build a dating app, in a decentralized fashion? It's not something that is very trivial to do because you need to be able to hide information.

And I think that the progressive disclosure, the ability to select what kind of information you want to give to people is a unique thing that is provided by ZK. And that you cannot do in any other way. So to be quite honest, I do not have the good answer to that question. What we do know is there are thousands of really cool use cases that you can build with ZK that allow you to be more decentralized faster and especially more, more private. I don't exactly know what will be the meme coin for ZK, but I think it's something regarding selective disclosure of information to other people.

Something that you can do with ZK is you can build an ERC 20 that can only be traded by people of a certain nationality. Or people that have managed to produce a zero-knowledge proof that they beat _Doom _up to a certain point. And this is these are very stupid examples, but this is only possible using ZK.

I think the privacy aspect, the ability to keep integrity while keeping privacy at the same time, is going to be the very interesting thing.

Maxime: Okay. And maybe I have a quick question, maybe to finish, I think you're probably already discussing or look at the work of Sismo, that, If I'm correct, worked on those kind of, of subject. Are you using some part of their tech or research to move forward?

Because for example, the example you just shared reminds me of, a discussion that I had with Sismo. So do you use kind of their tech or looking at what they build at some point?

Sylve: I never really followed Sismo too closely. From what I remember, they were using ZKPs to disclose personal onchain information to other people. They were really early to this. It's very impressive what they managed to build. To be quite honest, I don't even know what kind of tech they built. The thing I do know is that the ZK tech moves so fast that even stuff that we were using, eight months, six months ago are useless right now.

So I'm not sure, exactly what we could reuse from that.

Maxime: Okay. Thanks. I don't know if Margaux, if you have some other questions?

Margaux: I think I'm good, but it was really interesting. And thank you.

Sylve: Thank you very much for having me.

Thanks a lot. And if you have, a last word or something, if you go to some, IRL events, where we can meet you, etc., please, you can share it now if you want. Absolutely. We'll be going to zkSummit in Lisbon next week, and then we'll be at DevCon in Thailand in November.

So, looking forward to seeing people there.

Margaux: Yeah. Nice. We'll meet there in Thailand.

Maxime: Amazing. Thanks for your time. Thanks a lot. And yeah, see you next week, guys. Bye!

Margaux: Bye!