Sylve on Daria Strategy's podcast
Sylve was on Daria Strategy's podcast yesterday. You can watch the video or read the highlights below!
The vision for Hylé is to enable everyone to benefit from the technology of provable applications, specifically zero-knowledge proofs.
So, what are these? They were a very obscure research topic some 10 years ago.
My favorite forum post is one by Satoshi Nakamoto, who discusses what solution they could implement to help scale Bitcoin.
This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.
Originally, a coin could be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double spending that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?
It's hard to think of how to apply zero-knowledge-proofs in this case.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
− Satoshi, August 11, 2010
Since then, research in zero-knowledge proofs has advanced tremendously: it's been used as the number one factor to help scale blockchains. Currently, that's their only use case, but we believe that the technology will improve to the point that everyone will be able to use it to build entirely trustworthy applications.
We're designing the blockchain network that is made for this.
Zero-knowledge proofs came after blockchains; blockchains are about 16 years old already! Zero-knowledge proofs, in their current form, are closer to 5-10 years old. Right now, most people are taking zero-knowledge proofs and trying to cram them into blockchains; what we're doing is designing a decentralized network that is specifically tailored for provable applications.
Why are zero-knowledge proofs so appealing?
Daria asks: Why are ZK proofs so attractive to the blockchain community and investors?
One of the best things blockchain has ever done is funding research and enabling the development of many cryptographic tools that were very theoretical 20 years ago: ZK, MPC, FHE…
Why is ZK particularly interesting? Well, I like to think about it as I think about the steam engine. I've already written about it:
Sylve Chevet
ZK has so many use cases outside of the blockchain, though! It's great for a bank to prove that they actually have the funds that they tell you they have. It could also be a way for you to prove that you're a citizen of a certain country without going through a very, very lengthy KYC process. Zero-knowledge technology tremendously lowers the cost of trust.
But the first thing we actually used it in was the first niche that desperately needed it, and that was blockchain. But obviously, it's going to generalize to a lot more than just blockchain.
Understanding Hylé
What's a lean blockchain?
We chose the term « lean blockchain » because Hylé provides the minimal functionality needed from a blockchain in a post-ZK world.
When blockchain started, you had Bitcoin, which was a very, very simple network. Bitcoin allowed you to exchange value—that was its only function. You do not have a lot of expressivity on Bitcoin. You can't write very complex programs. It's not designed for this. Then, Ethereum came in. Ethereum is branded as the « world computer.»
You can build what are called smart contracts: programs that run on Ethereum, a massive decentralized computer that no one owns. When you send a transaction to Ethereum, everyone on the network will verify that computation… and that's very expensive.
Because it's decentralized, all the little computers that create this giant « world computer » go at the same speed. You're trying to run while holding hands with a million different people!
You need to coordinate—that's what consensus is about. So, it's already complicated to synchronize all of this. One of the issues with synchronizing this is that you can only go as fast as the slowest runner, no matter how fast your fastest sprinter can go.
That's currently how blockchain infrastructure is built. You need to ensure that anyone can join the network and perform computations.
When developers stumble upon the idea of blockchain, they often have the very simple yet normal idea of saying, «Why don't you just have bigger blocks? Why don't you just use bigger computers? » And that would be similar to saying, «Why don't you only have Olympic champions? » And sure, that's a solution. But if you do this, no one can get into the network; no one can participate in it. It's not inclusive. So what we do is that we limit the network speed to the slowest runner, let's say, a high-end consumer laptop.
With zero-knowledge proofs, we can now benefit from the speed of the fastest runner and ensure that the slowest runner can participate in the consensus. This is done by having the very powerful computers do all the hard work themselves and coordinate their work.
And then, the slower computers verify the work done by the faster ones.
So Hylé will sequence transactions. We'll just say, « Okay, this one came before this one. This one came before that one. » That's very light data availability. Then, Hylé will verify the proofs created by the fastest runners and by the very, very powerful provers and computers.
What we do has several benefits:
- You can anonymize the content of your transaction as much as necessary.
- The network is very simple. We don't have an execution environment; we accept any provable language, including specialized ones like Cairo and generic ones with zkVMs like Rust. Hylé natively ships verification for these languages, so you don't need to learn a new programming language.
Provable applications
Currently, as an industry, we try to put a lot of things onchain − everything we can, really. With Hylé, you will be minimally yet sufficiently onchain. So that's why we talk about provable applications.
« Provable » applications mean that they can generate proofs but that every single transaction doesn't need to be approved and verified somewhere. If I have to give an example, that would be video games on the blockchain. People have tried to build video games on the blockchain, and it's very difficult. It works for slower-paced games, but if you're playing something like a shooter game that runs very fast, it's going to be very difficult.
Zero-knowledge technology doesn't only give you scalability and anonymity; it also gives you flexibility because it means that you can just have a centralized system that runs offchain, and you're still able, at any point in time, to generate a proof, like a checkpoint of what has happened in the game, and send that on Hylé.
Why Hylé handles zero-knowledge proofs well
Native proof verification
If you need a refresher, you can check out our simple introduction to zero-knowledge proofs.
In the context of Ethereum, you need to write a verifier in Solidity, a programming language that the blockchain understands.
There are many operations that are very, very costly in the ZK world. An example is hash functions, which are used everywhere. The hash function used on the VM is very STARK- and ZK-unfriendly. If I manage to set up my verifier, then I need to verify the proof. For that, I'm going to need to send a transaction on the blockchain, and that also has a cost.
How do we do better than this? We specialize in doing one thing really, really well: verifying these proofs. Rather than having an execution environment on which you can have everything, we only have one type of function available on Hylé, which is to verify those proofs.
We are running native verifiers.
Delayed proving
It's slower to prove something than to execute the code for it. Compiling some types of proofs can take several hours. That is diminishing as research improves, but there's always going to be an overhead versus just computation.
And that's very, very, very costly. So, to optimize for this, we do something called delayed proving. Delayed proving means that you're just sending transactions on Hylé that are not proved but provable, and Hylé is going to timestamp them.
It's like a restaurant: you book a table, and then you come in.
Hylé orders your transactions, and then you can take more time to prove them. That means that you have instant finality; the proof comes later.
Proof composition
Finally, because we run these proof systems natively, we have native proof composition.
Our first builder on Hylé, Matteo, built a provable chess-by-email game.
Let's say you win. We're going to call a referee by email, and the referee is going to generate two zero-knowledge proofs:
- a proof that your email address was the one who won, using zkEmail
- a proof that you have actually won, using RISC Zero.
In a normal setup, to verify this on a blockchain, you would need to put the first proof inside the second proof or the second proof inside the first proof.
That is called recursion. It is quite costly because it's like matryoshka dolls: you need to put proofs inside proofs, and it's quite difficult and very expensive to do and to compute.
The way we do this is by… not doing this. Just send the two proofs to Hylé, with each proof referencing the other. Hylé will verify both of them at the same time.
You can use any proof system you want without having to think about recursion or how they work. We remove that complexity completely.
We've got a blog post coming up about proof composition!
What industries should leverage Hylé
Some of the examples that I really love are around identity. For example, zkPassport, Open Passport, or Rarimo use the signed data on your passport to emit statements and proofs.
There are many discussions in the European Union about getting content to certain websites for minors. That means you need to go through a whole KYC process, which is not only very invasive but also quite costly.
One way that we tried to tackle some compliance issues is by telling banks and organizations to go onchain, but the switching costs are just so high that nobody does that.
They could also keep operating in a centralized fashion… and to be honest, I quite like that my bank is regulated! That's something that I trust—that's what most people trust. I like having the option of having cryptocurrency at the same time, but I like having my bank. What I would love, though, when I connect to my banking dashboard and they show me that I have a hundred euros in my bank account, is to be sure that I actually have a hundred dollars there.
The banking system could operate as a provable program. Any new operation changes the state of the application, a bit like a blockchain, that could be used to generate proof of the validity of the operations that they're doing.
That's the brilliant part of zero-knowledge proofs. You could have a guarantee that the bank was operating the exact piece of software that had been audited.
Even without discussing switching costs and everything else, not everything can operate in full transparency. Some things benefit from being private, and these things just can't need to be run on the blockchain.
The zkBoost consortium
Generating proofs is not easy. This task will be offloaded to specialized companies and hardware providers.
The good thing is that thanks to zero-knowledge proofs, you can trust that these provers are doing the right work. You can have centralized proving with decentralized verification, and that's what Hylé does.
So, we can offload a lot of the proving work to these specialized actors and agents, such as the proving services, the proving markets, and the proving networks. Hylé will tremendously benefit from this, and we need these folks to exist.
The analogy for Ethereum would be that you have block builders. They're not part of the protocol, but you have people outside of the network who are synchronized into building very efficiently.
It's going to be quite the same thing for proving.
On Hylé, people will broadcast many provable transactions that need to be proved. zkBoost is basically a standardized API for these proofs, so we can very easily offload computation somewhere else.
It's beneficial for all actors in the ecosystem because if the proving services and proving networks don't agree on how to receive these proofs, it's going to be very difficult to offload to anyone in particular. You need standards, and standards make things scale a lot easier.
It's standardization work. For example, email addresses are a standard. Early companies had to agree that « addresses should be something @ something dot something else.»
How are these things going to be formatted? What type of proofs are needed, and where do the proofs go in the payload? What's the size limit? We need to agree on all of this.
What have you done recently and what is your roadmap?
We shipped a test version of Hylé using the Cosmos SDK, which allowed us to iterate very quickly on our needs.
We built an application ourselves to test it and check what needed to be changed compared to the Cosmos toolkit.
Alex Sirac
Now, we're building our client. We're developing the consensus of the network.
We will have a version of Hylé that developers can test to build provable apps by the end of 2024.
About the Hylé branding
Daria says, Let's talk about your branding. I really like it. It looks so French, authentic, and attractive! Who was responsible for branding, and why did you think of the train?
When we set out to build highly, my co-founder and I decided to optimize for motivation and interest.
We both have an interest in blockchain and in making the world a better place (yes, I know it sounds corny).
This means building an organization for a project that's going to outlast its inception: Hylé, the network, has to outlast Hylé, the company.
This is why we chose to have a mostly onsite team in Paris.
So, the idea for this branding came in the same vein: «What do we like, what resonates with us? » My co-founder and I have always been big fans of a very weird niche of aesthetic called GiscardPunk.
Valéry Giscard d'Estaing is a former French president. There's a tiny subreddit and part of the Internet dedicated to finding things and images that resonate with that era, which is the 1970s in France. The aesthetic… it's orange, there are trains, there's concrete, there's nuclear power. There's the Minitel, which was the French version of the Internet back in the day.
We love to think about this. We set out to build a brand around something that looked like us, something that could be authentic, something that we could show to the world is different, not the usual shades of gradients that you see in blockchain.
You'll see many buildings and many people because we believe that technology should serve people rather than be very abstract concepts. We just wanted to build something that resonated with us.
Learning about ZK
Daria asks: What can you recommend to people who are interested in the concept of zero-knowledge, and where should they start?
First of all, Daria's podcast, obviously!
The second is the Zero-knowledge podcast by Anna Rose and her team. It's a great way to get exposed to that content and the people working in the ecosystem.
David Wong is a very good cryptographer and a great communicator. He has done some sessions on YouTube. If you want to really dive into the inner workings, that will be the best resource some sessions on YouTube. If you want to dive into the inner workings, I think that will be the best resource that you can find.
It's a very small ecosystem. There are just so few people working in it. No one has built that, and maybe you think that your app is not great, but if you compare it to everything that has been done, there are so few examples of applications that are actually being built. It's great to start with a very low-level programming language to understand how memory works, etc., but it's not necessary.
That's why I really love SP1 and RISC Zero because there are tools that allow you to get on with ZK without even learning a new language. You can just use Rust. That's a tall order because it's still a hard language. You can use « normal » programming languages to build your application and toy with it.
That's why Matteo used a zkVM for the project: rather than build circuits himself, he thought, « Oh, I can just use a Rust library that's already well used and has a lot of stars on GitHub and put it into a zkVM.»
We're in a state of ZK where we're slowly but surely exiting the lab and entering the hackathon phase, where you can actually let engineers, hackers, and tinkerers think about use cases.