Brief Notes on Leios

Hi, this is Charles Hoskinson broadcasting live from warm, sunny Colorado. Always warm, always sunny, sometimes Colorado. Today is May 1st, 2025. It’s amazing how fast time goes. I wanted to share some updates related to Warborus Laos.

If you’ve been following, every month there is a live stream with the prototype team currently working on Orborus Laos. The implementation across the ecosystem starts with writing the paper, which in Laos's case was the hardest and most elegant paper we ever wrote because it’s part of a telescoping protocol. Unlike a really fast, high-performance protocol you see with BFT protocols like Narwhal and Tusk, what we wanted with Laos is to be stackable, almost a telescope coming out section by section with Prowse. The idea is that Laos extends Prowse and operates within the same security models and constraints. If for whatever reason it doesn’t work the way we thought, it collapses back down to the current protocol that we have.

Typically, you don’t do this with new protocols; they’re not backwards compatible. They’re new protocols. We wanted to maintain all the original security assumptions of Prowse: 50% Byzantine resistance, the same synchronous network model, and the other things you’ve come to know and love with 24/7 uptime. The design requirement of Laos was to have an infinitely scalable protocol, a one minus delta protocol. Basically, as good as it gets.

I’m going to show you a single thing that was posted on Twitter based on a screen share from our presentation. If you take a look right here, you’ll see these input blocks. This gives you some ideas of what the TPS rates can be based on the average transaction sizes. With just that one input block, you can see that the maximum is about 6 TPS, the minimum is 393, and here’s your average rate. With five input blocks, ten input blocks, twenty, thirty, you can achieve 11,000 TPS for your minimum, with a maximum of 180 at 16 kilobyte transactions, which are huge.

You can increase this IB rate as much as you want. The thought process behind it is to have a protocol where year by year you play a kind of tick-tock game. Your tick is where you set a parameter in the system for how many input blocks you want the system to run at. This is like utilizing the space between the big blocks, the Prowse style of doing things. You start that initially very conservatively, then optimize during the talk phase.

As you optimize, you increase the number of input blocks as needed. As you do this, you use more resources per consensus node and more on-chain resources, meaning the cumulative size of the blockchain gets larger. There’s a larger mempool requirement and other considerations. But this gives you a protocol with a parameter where you can turn up scalability. Currently, the only way we can turn up scalability is with block size.

You can turn that up, maybe do some clever things about pre-processing, which we’ve done during the Shelley era and the Goguen era. Ultimately, you don’t have a very strong lever to massively increase the throughput of the system. Input blocks mean you have more happening in parallel, asynchronous to the ranking blocks inside the system. This means that by simply turning it up, you can massively improve throughput inside the system. If you want to read about it, there’s a lovely blog post that Olga put out.

Let me share my screen. Pi, one of the people on the prototyping team, is currently working on a write-up that he’s having reviewed by Phil, Dario, and Brian. I highly recommend reading this article, "Advancing Orborus Laos: The Next Leap in Scalability," which goes into some of the design aspects. This provides a basic understanding of how it works with input blocks, endorsement blocks, and ranking blocks inside the system. So, instead of one block, you have three blocks, and you can go parallel with these types of things.

This is the traditional linear structure, and these are the concurrent aspects when you start having lots of input blocks. It’s a really elegant protocol, and there are many cool things we’ve been able to incorporate into the design, learning lessons from things we’ve learned from Mithril, parallel chains, and many of the papers we wrote in the past. Now, because there are more levers that you can pull, the scalability game is less about inventing a new protocol and more about efficiently utilizing existing protocols. For example, let’s make the mempool a distributed resource instead of a replicated one. We can have a larger logical mempool, but your physical memory footprint can be quite low, like 4 to 8 to 16 GB.

This means you could run it on a Raspberry Pi. Let’s find ways to approve many transactions with GPU power in addition to CPU power because those are already highly parallelizable. We can also make these systems more multi-core enabled so that local consumer hardware remains relevant. We should be more efficient in our utilization of network resources and potentially share them in different ways than we’re currently doing in a peer-to-peer manner. Even though there’s much more traffic on the network, your local load per consensus node is much more distributed instead of replicated.

This tick-tock style cycle, like what Intel used to do with process nodes and CPUs, works very well. You set a configuration, then optimize within that, go to the next level, optimize again, and repeat. This means that year by year, Cardano gets naturally faster without requiring a brand new design or protocol. If for whatever reason the system has a flaw or collapses, it collapses back to the prior protocol, Prowse, which we’ve relied upon for the past seven plus years to prove transactions 24/7. So, how much longer will this take?

We’re starting to really scale up prototyping. There’s a great team working on this, and more new people are coming in to focus on finishing the prototyping, simulation, and formal specification writing. This will likely conclude in the second half of this year. The output will be a formal specification, simulations, and a SIP. Once those three things are present, we can then RFP to a specialized firm, and there are several who could do this work, like GAWA, Modus Create, and a few others, co-sourced with our engineers to implement in the Haskell node.

There is an open question of whether the alternative clients will be far enough along to also implement Laos concurrently. We’re trying to figure this out with those clients, and subject to budget approval, it may be the case that by the time the design is done, there’s enough maturity that with some additional resources, they could launch concurrently with the Laos node. Typically, it takes about 9 to 12 months of implementation effort from a SIP to bring this into the protocol, depending on how much housekeeping and re-architecture has been done to accommodate what’s been going on with Laos. The prototyping team of Laos has been in direct contact with the ledger team, the consensus team, and others at Input Output to coordinate and prepare for the SIP. This is the most invasive change to the node since the Shelley era when we moved from BFT to Shelley.

The ledger logic has to change, the block structure has to change, the network stack has to change, the consensus logic has to change, and new cryptography has to be introduced. It’s a very complicated surgery and overhaul, and the node is getting a little long in the tooth with its old design. It needs to be updated and modernized. There’s an ongoing maintenance process right now to update as much as possible, improve the architecture, and remove technical debt in anticipation of Laos. One of the things we’ve been working on is a follow-the-sun development model.

Instead of a single development team working 9 to 5, Monday through Friday, we’d like to stack teams so that some people work at night, some during the day, and some on weekends. This translates to code being written 24/7 so that it can get to market faster. This is a much more expensive, energy-intensive, and time-intensive development model, but it’s typically done when you want to get things to market as quickly as possible. This approach isn’t very popular among my engineers because they understand the consequences. It is extremely stressful and draining.

Nobody wants to work in a follow-the-sun model because it involves a lot of handoff work and redundancy due to overlapping shifts. It’s not cost-effective, but it dramatically decreases your time to market. We’re trying to figure out how to implement this in anticipation of the SIP being written. The firms that will bid on the RFP for the SIP are already co-developing with the prototyping group, so they’re familiar with what’s going on with Laos. They won’t go in cold and have to go through several months of product discovery to come up with an implementation plan.

The hope is they can hit the ground running and start working on it from day one in a meaningful and structured capacity. This is one of the highest priorities of the engineering group. We believe this is one of the biggest differentiators in the history of the industry. With the tick-tock model, we can solve the blockchain trilemma without sacrificing decentralization or security. Scalability is an organically tunable parameter based on your beliefs about how fast you want the blockchain to grow and the capabilities of the consensus nodes.

The people who control the network parameters are in control of how to tune that. You can also look at a rolling average of block utilization. If you want to be more conservative with resources, you can dial back, and if you want to be more liberal, you can dial forward. You now have a lever to control that. As you can see, there are thousands and thousands of potential TPS.

This work is parallel and complementary to the work on Midgard, Gummy Worm, and other layer 2 solutions. The UTXO model is scalable because every output can be a proof instead of a transaction, and all those proofs can represent rollups or off-chain activity. You can technically implement hydro channels, things like Midgard, optimistic roll-ups, recursive SNARKs, and more. This is very complementary to what Seb is working on with StarStream, which we’re very excited about. We believe adding a native folding scheme into Cardano would be a massive leap forward, provided we choose the right cryptography.

All of these are currently in the budget proposal to be pursued in parallel by independent teams who are non-conflicting, meaning they can work without disrupting each other. As these projects come to market, it will position us perfectly for the enormous transaction volume that Bitcoin DeFi, XRP DeFi, and our evolution into an AVS system will bring. What’s really cool is we’ll start utilizing some of these second and third-order technologies like Mithril and Hydra in the design of the systems. Everything is based on rock-solid theoretical foundations. These simulations, prototypes, and formal specifications give us enormous certainty that what we’re implementing will not only work but will be revolutionary.

This is truly the crowning achievement of over ten years of careful thought, research, and engineering. On behalf of Input Output, I’d like to thank everyone in the community who participated in this and for all the amazing work they’ve done with us. As the CEO of Input Output, I’d like to thank all of our partners, engineers, and scientists who have invested so much time and effort to get us to where we are. It’s really exciting every month to watch the Laos team come together in real time to create a best-in-class scientific prototype. Nobody in the cryptocurrency industry writes a SIP with such dense simulations and prototyping and a formal specification as the definition of an RFP.

Nobody does that. The fact that we’re doing this at this level with such rigor shows who we are. We haven’t missed a beat at all. The strong potential for concurrent implementation in multiple languages like Rust, Go, and Haskell further validates the design of the system, tests its durability, and shows that it can withstand the long term. Laos is the future, and we’re really proud of it.

It’s probably the best science we’ve ever done as a research group, and that’s saying something because we’ve published over 240 papers. It is the capstone of the Orborus agenda, the culmination of many incredible ideas over the years, and we’re very proud of it. I hope you take the time to read the blog post. Pi is writing a very in-depth post that will help people understand why Laos is so special. That will come soon.

As I mentioned, there are live meetings every month that you can watch, where people discuss this. We’re only going to get more aggressive with the prototyping. I’m trying hard to throw every resource I can at accelerating things. If I see anything interfering with our progress or slowing it down, I try to remove those obstacles, reassign people, or terminate relationships. I will continue to do this because I consider this one of our top priorities.

It’s about time that Cardano gets to reap what it has sown and enjoy the fruits of its labors. It’s time we get to enjoy being the fastest cryptocurrency on the planet, and you get to decide how fast that is. Your foot is on the accelerator pedal, and that’s good protocol design. I love that we never compromised our rigor in this process. Everybody told us to move fast and break things, but we decided this time to be the tortoise.

Paradoxically, we are going to win the race because of it. Thank you so much for listening, and please enjoy all the write-ups. Cheers.