Hi, this is Charles Hoskinson broadcasting live from warm, sunny Colorado. Today is May 1st, 2024, and I want to make a video briefly about a major piece of research that is near and dear to all of our hearts. As many of you know, we've been working for several years now on the Ouroboros Leo agenda, which has many names like input endorsers and parallel chains. We're researching various aspects, and the long and short of it is that we're trying to figure out a solution to the blockchain trilemma that stands the test of time.
I’m going to make a brief whiteboard video to talk about the paper and show you guys some of the details, but I’m not going to publish the full paper just yet. Agalo is going to do a whole series of videos and work on our scalability side later in the month. We’re currently cleaning up the paper and getting the last-minute details done for full public publication. It’s been submitted, but I wanted to talk a little bit about it because I know many people in the ecosystem are interested in this particular piece of work.
So, without further ado, let me share my screen. A normal blockchain protocol has this concept where your rate of change is a block. Ideally, you have some concept of a leader who commits a block, and there are many different ways to select those leaders. We typically break them down into two different categories: Nakamoto style and BFT style. Some of the industry is now going down the BFT road, but we all started in the Nakamoto style, named after proof of work. We typically call this proof of X consensus, where X can stand for anything you want—work, stake, or other types of consensus.
The issue is that when you run this entire environment, the security model is what's called delta bound. When you think about it, there's a certain amount of time between these blocks, and we say that all the things that are going to happen will occur within that delta. It’s kind of an upper ceiling for delivery times, but we don’t say much about throughput inside the system. In practice, whether you're in the proof of work world or the proof of stake world, these are very low throughput systems. A lot of capacity is left unused, so you have this huge amount of network capacity, but the actual work being done is much lower.
What Ouroboros Leo is about is saying, "Okay, let's optimize the protocol." It can be either a proof of work or proof of stake protocol, and we want to utilize as much of our network resources as possible. We typically call this one minus delta. In a perfect world, delta is equal to zero, meaning you utilize 100% of your network resource. Usually, you multiply this by the percentage of honest actors.
This paper details a solution to two particular problems that inhibit your ability to fully utilize all of your network's available resources. The first problem is the issue of protocol burst. One of the leaders may have the right to participate and have a whole bunch of legitimate history but could broadcast all of that at once to flood the network, effectively hampering performance for everyone else. You spend all the network's resources but only get a small amount of work done. We typically resolve this through some notion of freshness with VRFs or other methods. Proof of work is natively immune to this.
Then you have message equivocation, which occurs when a leader submits multiple messages that are indistinguishable but different in that you can’t distinguish their validity. They’re both valid, but both can’t be true at the same time. This can be used to spam and consume all the resources of the network. The vast majority of complexity in designing your peer-to-peer network and your consensus protocol comes after you've established a system for electing leaders, whether that be work-based or stake-based.
What Ouroboros Leo does is come up with five different strategies that are very complementary to what we have built in our ecosystem. These five strategies effectively eliminate the threats of protocol burst and message equivocation, allowing us to utilize nearly all network resources and thus approach an alpha of zero. For the most part, stake pools do things the right way, getting as close as possible to an optimal protocol, meaning you're utilizing all the resources of the entire system instead of just a chosen slice with a large margin to compensate for the risk of message equivocation and protocol bursts.
This uniquely takes advantage of some of the things that only Cardano has, like extended UTXO, Mithril, and other in-house technologies. There are proofs of equivocation, proofs of data availability, asynchronous block delivery, and a cluster of blocks we call input blocks that are made asynchronously. They get stored by reference on the blockchain, and then you produce proofs associated with them using something called an endorser block.
The magic of the paper is how all of this is done. It took many years to reach this elegant point. The important takeaway is that we're solving the two problems of protocol burst and message equivocation. A legitimate payload that’s been withheld and then blasted onto the network can drain resources, while a payload where only one should be true can spam the network. These issues can dramatically slow down the performance of the protocol. You’ll see a lot of optimized BFT protocols that, when they encounter Byzantine behaviors, get very slow. Red Belly is a good example; it’s quite fast with hundreds of thousands of TPS, but when you have dishonest actors, performance declines dramatically.
We term protocols like Ouroboros Leo as a meta-protocol. It’s not a replacement for Ouroboros but rather a reconfiguration such that when you integrate these five items, you can run the chain at the highest possible speed that this type of standard blockchain architecture can achieve. While doing parallel block processing allows many people to participate, it still looks like a single sharded environment, and performance increases to an optimal state.
This means you’re never really going to get much faster with the protocol environment, leading to a dramatic enhancement of TPS and TPT for Cardano. It allows for a much larger computation unit budget and brings a lot of exciting advancements into Cardano. This is super hard to do in an accounts model because of the way transactions work, but it’s much easier thanks to extended UTXO and Mithril. The proofs of data availability are straightforward to create because of that.
When we publish the paper, it will discuss each of these five areas and include all the protocols. It’s a really cool paper. I’ll show you just the front; those are the authors, but we’re not sharing the full details yet. I was hoping we’d have it up on ePrint by the end of the month, but it got submitted to a conference, and they’re going to take a second pass at it to add a few more things and clean it up. It will be out very soon, and we’re going to make some videos to explain how the entire protocol works because it’s so important.
Where do we go from here? There’s currently an active team prototyping Ouroboros Paris, and they’re working hard on it. The hope is to get the entire prototype done throughout the summer. We’ve had some internal conversations about scaling that team up a bit and also starting the prototyping of Ouroboros Leo because there’s a lot of overlap between some of the principles of Leo and the underlying protocol. Both are meta-protocols designed to enhance the properties of Ouroboros.
My hope is to get all of that prototyping done and get both protocols into RFP state. Then we can pick vendors, get those vendors through a process, and say, "Hey, how do we do this with fixed costs and fixed time?" Let’s do it quickly because I believe next year there’s going to be a huge drive in cryptocurrency adoption. There will be a lot of scalability demands on Cardano. I think Ouroboros Leo will provide a dramatic increase in overall layer one performance. When complemented with rollups, which we’re getting with Pluto V3, and thanks to projects like ZK Fold and Midnight, along with advancements to our programming model and partner chains, this combination will make us best in class for scalability.
I mentioned solving the blockchain trilemma. We still have 50% Byzantine resistance; it doesn’t reduce to a third or a quarter with this protocol, which translates to much higher security than all the other projects pursuing these types of solutions. We still maintain our best-in-class decentralization, and with partner chains, it will dramatically increase because more revenue will come in, attracting more stake pool operators. You’ll have more operators overall inside the system.
On the scalability side, this is an optimization that gives you an optimal result, meaning it’s not possible to really get much more throughput out of the system. Yes, we can shard, but that would require dramatic changes in the system, and it’s not clear if this would be meaningful given the TPT model. We can explore different directions.
As scientists, our organization has worked incredibly hard to balance and put together an elegant solution, building upon the work done in-house and elsewhere. We’ve read tons of papers, from Prometheus's papers to David Shein's papers and many others across the industry. We’re really proud of this as a company, and I’m very proud of the scientists who contributed to this monumental research accomplishment. It’s the closest the industry has gotten to a true solution to the blockchain trilemma.
There are many other things that can be added, like a distributed mempool or other optimizations, but what this does is unlock so many possibilities. By opening the blockchain protocol, we can integrate more primitives and hooks into Cardano, accommodating for recursion, Mithril certificates, Plutus enhancements, and all the hooks for Hydra.
I want to thank all the scientists involved. For the community, I can’t wait for you to go through the paper. As I mentioned, it will come soon, and I hope this gives you a sense of what to expect. It’s a sneak peek, but you don’t get to see how it’s done or what it does. However, we owed it to you to share what it solves. It really resolves the protocol burst and message equivocation issues behind scalability, creating a beautiful optimal result for delta to approach zero.
Overall, it’s an exciting accomplishment of the scientific rigor of our community and how they come together. The prototyping will be challenging, but hopefully not long. The goal is to scale resources dramatically, and once it’s in RFP, the community can decide how quickly we want this—faster, more expensive, more risk—but then we get it sooner. We have to decide where that balance falls during the RFP process, which will be a lot of fun.
We’ve had a great time working with the team on Genesis. There’s a little more to do, and we’ve discovered some interesting aspects with Genesis. As we move through the summer with the bookend hard fork that we have with Chang, Ouroboros Paris and Leo are next in line. I believe Cardano will be best in class for scalability across the entire industry, continuing to run without shutting down every 15 minutes, and it doesn’t compromise security. The blockchain trilemma feels really good, and I’m proud of that.
Thank you all for being part of this. It’s an exciting day. When I made the Roger Ver video yesterday, I was actually reading and taking notes on the paper. It was sad to see him have his troubles, but it’s a new day, a new month. May 1 is going to be one of our best months as a community, with more months to come that just get better. We have a lot to look forward to, with great technology and events coming down the pipeline.
In Barcelona, we had a fantastic event with Catalyst and the community, with over 100 people showing up. There was a developer hackathon in France, and it was a wonderful location where people had a great time. A lot of people are building, focusing on scalability, with tons of Hydra demos. We’re trying hard to get some video games to run on Hydra to showcase its power. It’s very challenging to get a game to run on a blockchain, but I think we’ll be pleasantly surprised by Rare Evo.
As I mentioned, Plutus V3 is coming, which enables the whole ZK world for us. Mithril adoption continues to grow, and this pulls Mithril into the core of Cardano because it’s necessary for the data availability proofs required for optimizing the ledger. It’s going to open up many more development capabilities, which is why it’s so important for all of you building projects on Cardano to join Intersect. It’s incredibly important because you’re a special interest group, whether you’re an NFT project or any DeFi project. Whatever you need on Cardano, join so there can be discussions through the working groups about what needs to be in the roadmap.
When you open up the ledger to do surgery to put in an overlay protocol, a meta-protocol like Ouroboros Leo, you can add a lot during that time. If the interface needs to change, the block headers need to change, or new authenticated data structures need to be put in, now is the time to have that discussion and translate it into SIPs that can be bundled together for the core developers to consider and implement. If you don’t talk, they don’t know; if they don’t know, they don’t do.
Intersect is the nerve point for these discussions, where those conversations can be held. It’s truly a development organization; it’s not a bureaucracy or just something for governance and budget. It has the repositories and product functions currently for 100% of the users of Cardano. Unless there’s a node I don’t know about running on mainnet, all of the nodes are the Haskell node, and over 15 companies contribute to that project worldwide. The product backlog is consolidated as a result of a member-based organization, similar to the Linux Foundation.
It’s really important that people join and express their needs and wants. We’ve gotten much better as an ecosystem at rapid prototyping and rapid research translation. In the past, a paper like this would sit around for quite some time as we caught up to it. Now, a prototype group is being discussed and spun up literally a few days after publication, with the express intent to get it to a point where a company would feel comfortable signing a fixed-cost, fixed-time contract to get it into production in Cardano. That’s a world of difference from where we were as an ecosystem not too long ago.
Because of this newfound velocity, it’s crucial to have real-time sampling of developers’ desires and intent. What do you need to make your dApps better? I’m very proud that the science continues to measure up. There are all kinds of new things on the agenda beyond Ouroboros Leo, but this marks the end of an era. It’s the conclusion of the original Ouroboros agenda. It can’t get any better. Kronos gives you a decentralized clock, Paris provides fast finality, and Ouroboros Leo optimizes to a point where you’re running at maximum throughput. Genesis gives you the ability to boost from Genesis, and Prous offers a realistic network model with adaptive security. The Ouroboros model in general provides the Bitcoin model for Nakamoto-style leaderless consensus.
This has been a long road. We started working on it as a community in 2016, which is eight years of papers, thousands of citations, millions of lines of code, and prototypes. It’s bittersweet to see something like this come to fruition because now there are different ideas and protocols that look and feel different. We’ll turn Ouroboros Omega into the next generation, but Ouroboros Leo was pretty special. I remember when we started discussing it seriously; all the scientists came together at a conference in Santa Barbara a week before they went over and did intensive work sessions at a vineyard. They spent a whole week drinking wine and thinking about crypto and how to build something like this, pulling all the pieces together, whether it be parallel chains or other concepts.
It took longer than we thought because it had to be built in a way that would be easy to roll into the prototype and then into implementation without requiring a dramatic departure from what we’ve already done. This is a moment and an opportunity to discuss how aggressive we want to be with the proof layer of the system. What properties do we want to prove about the system? This is why special interest groups are so important. It’s also an opportunity to talk about how much future-proofing we want to incorporate as an ecosystem.
For example, this is a very VRF-heavy paper, using it for freshness proofs among other things. It would benefit us to discuss implementing a post-quantum VRF and using that same mechanism for Quantum signatures, which would also enable post-quantum Mithril certificates. This would effectively act as an internal checkpointing system immune to quantum computers, representing a major step forward. The Algorand community has been leading the industry in this respect, and it would be quite easy for us to collaborate with them and others to achieve this.
Additionally, we could find optimization and improvements in the VRF design to meet the needs of these types of protocols. These are some of the interesting roadmap questions we need to discuss through Intersect and the decentralized product process. We’ve already started making a list of researchers we think we could collaborate with to design something like this and get it to market. That would be an incredible leap forward and a major enhancement for Cardano against quantum computers.
There are also really interesting questions about how to better enhance and model the extended UTXO model. This is starting to pay dividends; not only did we get isomorphic state channels and much easier rollups, but we’re also seeing much easier scalability. It’s the gift that keeps on giving, and we need to keep doubling down on that because it’s one of the things that makes Cardano so profoundly unique and different from the rest of the cryptocurrency industry.
I’m very proud and excited about that. Pipelining and parallel block production were introduced with diffusion pipelining back in 2022, but this requires an overhaul and a much larger notion for protocols like Ouroboros Leo. It’s elaborated and specified in detail in the paper what exactly is required. Given that artifact, we should also discuss some network enhancements along the way, as we’ve been writing papers on those lines.
These are examples of things that can be fixed when surgery is performed. The more actors in the room discussing their needs, the easier it will be to create a balanced and holistic roadmap that benefits everyone. We also need to have open discussions about the specifications and certification. Now that we live in a multi-client environment, we have to port the hard fork combinator notion to the other clients. We need to ensure portable upgradeability, so when it’s triggered on the Haskell side, it also triggers on the Pragma side and the Harmonic Lab side.
We’ve already started conversations from Intersect to Pragma, and Intersect will reach out to Harmonic to discuss coordination on the specification and upgradeability side. What is a certified client? This is what makes our ecosystem unique. We’re not afraid to embrace diversity, competition, and new ideas. In fact, it’s quite the opposite; it thrives on the quality and quantity of those ideas that come in. As long as they
1:07:35
26:05
26:19