Hi, this is Charles Hoskinson broadcasting live from warm, sunny Colorado. Today is October 6, 2023, and it's time for an okonomiyaki video. Many of you know I used to live in Osaka, in the Kansai region of Japan. While I was there, one of my favorite treats was okonomiyaki, which translates to "a little bit of everything" or "how you like it grilled." Basically, they put a bunch of stuff on a pancake and cook it late at night, preferably while you're drunk. It's just an amazing thing to eat. In conversation, it also means a discussion that's a little bit about everything, as opposed to one specific topic.
Every now and then, we do some roll-up videos, and this is one of them. First off, many of you come to me and ask, "Hey, where did all the AMAs go?" It's not that I've discontinued the AMAs; it's just that, due to time constraints, I've put them temporarily on hold. I want to come back to them in a more structured way. What we're trying to figure out is the best way to do this. I'd like to break it into one AMA per month and schedule a time for that, along with a collection of fast-paced Q&As every week or two. This way, we can get the question volume rolling, and the AMA can have a larger and hopefully more engaged audience.
What I'll probably do is a live stream to Twitter and YouTube for my AMA and then work on some form of a scheduled Twitter Space. Maybe I could do a Twitter live stream every two weeks and then once a month, an AMA. We're still working on the format of how to segregate between those two platforms, but I would like to engage on other platforms as well, like Gab, Mastodon, and Truth Social. There are dozens of these platforms, and I don’t pick winners and losers; it’s nice to broadcast everywhere. Overall, we're working on an entire social media strategy to figure out the best way to accommodate that.
As many of you know, IO has become a venture studio. We actually have almost six or seven companies now, depending on how we dice it up and spin them out, that are incubating inside the venture studio. Most of them are related to Cardano. We've had a lot of CEOs, a lot of board meetings, and a boatload of team building. Probably the most PR we've done is for the Midnight Project, which we've been working on internally for years. There's a lot to say about that in the future. Right now, we’re just doing tons of meetings and execution work.
In addition, there's all the work related to SIP 1694 and the recent summits and conferences we've attended, like Rare Evo and NFT XLV, soon to be the Cardano Foundation Summit over in Dubai. There are dozens of things like that, plus all the community events we've hosted—over 50 events for SIP 1694, for example—and a lot of internal workshops related to specific technologies. For instance, we just finished a workshop in Scotland for Ouroboros.
We have a huge amount of work under the hood, in addition to external meetings. For example, we have monthly meetings with the Wyoming Stablecoin Commission at the state of Wyoming for their stablecoin. We've had a lot of external meetings with foreign regulators, discussing how they should regulate cryptocurrencies. There's a lot of engagement at the state level with various actors. We've been floating through all of this, plus maintaining all the open-source programs and projects we have, like Hydra and Mithril. The publication volume for Mithril 2 is almost done and about to be published. We're wrapping up Ouroboros Leos, and hopefully, that will be a strong end-of-year publication.
That's the bedrock of what we'd like to do with input endorsers. There's now a whole prototyping stream that needs to be done for it. As I previously mentioned, Paris is the finality gadget of Cardano, which really improves the state of affairs there. There’s been about a year's worth of work on that backbone protocol, with big improvements to extended UTXO and Plutus BLS support for Plutus, which is another thing we've been working on. It should come in Plutus version 3. There are a lot of protocols that rely on that, especially for cross-chain bridging. We've been doing a ton of R&D on Plutus and these things, so things are moving along.
Another topic that came up is the projects that didn’t work out as well as we anticipated or hoped. There’s been a collection of these that I’d like to mention because I think sometimes it’s unfair what people say. Two in particular are the Plutus Application Backend (PAB) and Yella. PAB was our guess about what the development tooling and experience needed to be for someone building an application on Cardano. That guess was not right. Over a two-year period, we, along with the community, built out a constellation of upgrades to Plutus tools and SDKs that basically encompass the original intent of that. It’s not that it wasn’t delivered; it’s just that nobody wanted to use that idea, so it pivoted and turned into things like TX Pipe, Ain, Marlo, and upgrades to Plutus.
There’s still a lot to do, but it’s very common when you develop a programming language to have an unstable standard library and an unstable development kit for about two to three years. If you don’t believe me, you can go back and look at the records for languages like Clojure, Scala, Kotlin, Python, Ruby, and even the development of D, which still doesn’t have a canonical library last time I checked. In every case, it takes about two to three years for the core language to stabilize enough for standard stuff to start flowing. In fact, when Rust came out in 2015, it was very primitive. No one would dare use it. They said, "Oh no, Rust, we can’t use that." Now it’s the most common programming language in the cryptocurrency space.
It takes time for languages to evolve, and Plutus has been going through that evolution. With every generation, you get improvements to the compiler, syntactic sugar, new tooling, new capabilities, and new built-ins. Obviously, you look at what people are trying to accomplish in the DApp ecosystem, and you gradually increase the expressiveness of the language while trying to preserve and protect the extended UTXO model and the determinism of the system. It’s a challenge at times because there’s always something you leave out that a developer would like to have.
If you look at the evolution of things today versus 2021, when the Alonzo hard fork happened, it’s been night and day. Now, Yella is a different animal entirely. Back in the day, I wanted to combine the account-based model and the extended UTXO model in one system because they both serve different purposes and have a lot of utility. It really helps with the data availability side of the house if you have some notion of an on-chain virtual machine. That’s a lot more complexity, so we wrote a paper called "Cheric Ledgers," done by Bruno Pailo. There were divisions in the philosophy of the engineering team; the formal methods and functional language people really didn’t enjoy the idea of putting both of these things in one system.
They compromised a little bit and put some account-style stuff in the system for stake pools and rewards, and you’ll see that in Alleged SPE. But for the most part, it’s an extended UTXO system. Yella and K were really built as a next generation of what the Ethereum Virtual Machine should have been. It was a radically different view, much more traditional based on LLVM, which is a very well-established model for compilation. It was a compilation target Apple created back in 2001 in collaboration with the University of Illinois at Urbana-Champaign.
So, when we worked with Gregori, who was at the University of Illinois at Urbana-Champaign, we suddenly had something that looked like prior IP. There was a lot to love about Yella; it was a proper development model, a proper virtual machine, and there was a lot of great stuff there. It was register-based instead of stack-based, which is much more sensible from a programming perspective. We could borrow about 20 years’ worth of compiler design.
We started from K specifications, so we had a formal representation of the system. The hope was that with Yella, we would achieve something called semantics-based compilation. Semantics-based compilation basically translates to this: if you have one programming language, let’s say Python, and you have formal semantics for it, you write down the operating model of how that language works. If you have another language like C, you write a specification for it. You should have a way of unambiguously translating the intent of the program to some sort of standard like the K framework.
The hope was that this could become a universal translator for programming languages. So, if you wanted smart contracts on the system to support your idea, instead of writing a compiler, you would just write your specification of the language in K, register it on-chain, and then an SBC compiler would understand what to do with any program there and translate it in a way that it could execute on Yella. That was the hope.
What this would mean is we could take normal programming languages and write subsets of them in K, creating a standard library specifically for that language to support smart contracts. This way, normal developers could write code in that paradigm. This was an R&D project, and we put an enormous amount of money into it. There were 19 people working full-time on Yella for years, millions of dollars were spent, and papers were written, called reachability logics and other things.
We never achieved semantics-based compilation, and we never quite got Yella and K to a point where it would make sense to make that the backbone of a smart contract system. In addition, it was like oil and water trying to get these mutable account-based people to work well with the functional programming and formal methods people. They spoke different languages and had different philosophies and paradigms, making it very difficult to put these two things together.
The ocean is something I still would love to do, and it would be nice to see Yella and K resurrected in a product. But this is the nature of prototypes in computer science: you have a pretty good idea, you pursue that idea, you spend millions of dollars on it, and it doesn’t quite work out the way you hoped. We have many examples of that technology. For example, HD DVDs versus Blu-ray: it’s a perfectly legitimate paradigm, and there were a lot of great partners, but Sony won that fight, not Microsoft and Toshiba.
You also see this a lot with certain programming paradigms. XML, for example, was thought to be natively embedded in every language. It was considered the markup language for all things, everything to everyone, and it lost a lot of favor. No one anticipated the rise of JSON the way it moved, and now it’s canonical. You have databases based on it.
Technology works this way: you have to be agile and move in the right direction. It made a lot more sense to say that if we are going to do something that uses accounts and K and Yella, it probably ought to be done on a side chain of Cardano, not on the main chain. The main chain is now stable; it’s been up for more than six years, and a huge amount of transactions have been processed—billions of dollars of value move on a fairly regular basis. It makes no sense to gamble and say, "Let’s add a completely different programming paradigm into the system." The window for that at layer one is pretty much closed, and it would add too much complexity.
Also, it would create a situation where it’s ridiculously hard for people to build competing clients. The more complexity you put in that system, the harder it is to write a complete specification. It’s harder for people to implement a client, and then an engineering team would need four years to write something to compete with the Haskell client. You probably want to keep your layer one concise and simple if you can, and every generation simplify it where you can, so you can have multiple implementations of that.
You don’t lose the ocean; you can always chase the ocean. It’s just that K never caught up. We bet big in a lot of different directions, and there’s a lot of amazing computer science that was done, but it doesn’t always work out. This doesn’t mean we lied or misled people. We have the receipts; we hired 19 people, and there were research partnerships. We’ve worked closely with Gregori for years, and we have a ton of code that came out. People were even testing Yella on an EVM-style testnet using the Scala code, and I still think the repos are floating around somewhere.
It’s just that we couldn’t get the transaction size, the performance, or the integration into the formal specifications of Cardano. It made no sense to laden the system with that much complexity. Had we started way back in the day with that paradigm, we could have probably gotten it done if it hadn’t happened with the Byron reboot. But it probably wouldn’t have been advantageous to Cardano in its current iteration and form; it would have introduced a lot of problems.
I’ve come to agree with the architects who disagree with the integration of Yella into layer one. It would be nice to see it, though, in K on a side chain. That’s an example of how these things go. When you look back at seven years of history and all the different components of the systems, you see a lot of false starts and things that didn’t work out as well as you hoped. But when you compare that to the things that did work out, we now have active specifications for Conway.
We have a beautiful node that is fast, super reliable, and very easy to configure, install, and work with. Thousands of people who aren’t us are doing that—stake pool operators, among others. We have a vibrant smart contract ecosystem that’s evolving rapidly on top of extended UTXO. You can just go and watch UTXO for two hours and see every block, observing all the activity and how diverse it is. That’s completely community-led and built.
There’s great decentralized governance coming, with minimum viable governance through SIP 1694 being completely ratified through a community-led process. There’s a great member-based organization starting to aggregate everybody together for a decentralized product backlog. Plutus has gone through multiple iterations, and Ouroboros still remains the best consensus algorithm in the industry. Liquid non-custodial staking, no slashing, no bonding—you don’t lose your money. The founders aren’t afraid to stake their own money. Little things like that really do make a big difference.
It’s a very extensible protocol family, and there’s a lot of science behind it. I see a lot of lies floating around about how our peer review is somehow not appropriate because they’re peer-reviewed at conferences instead of journals. This again shows how little experience and knowledge the critics have about how computer science works. The dominant way of going through peer review in the computer science world has always been conferences, not journals.
If you look at Crypto or Eurocrypt, more than 90% of the papers submitted are rejected, and there’s a formal referee process. These are papers rejected from Harvard, Stanford, and other places, so it’s just as rigorous as a journal would be. The reason we do it at conferences is that computer science moves much faster than most scientific domains, and there’s a much stronger industry association with this. People float from industry into academia on a pretty seamless basis, especially in artificial intelligence.
You need a faster pace and a faster refereeing process for computer science than you would typically see with a journal referee process. If you look at how people get tenure and how people get hired, if you’re on a hiring committee at Cornell and see someone with a bunch of Crypto and Eurocrypt papers, you would say, "Wow, these are amazing." You wouldn’t say, "Well, those are conferences; where are the journal publications?"
Again, people lie. These are some of the things I don’t expect the general public to know because it’s a domain-specific issue. What gets irritating is when people say the 200 papers that are published aren’t worth anything because they didn’t meet some arbitrary standard. I would always ask, "What journal should we submit to and publish in if not Eurocrypt or Crypto for Ouroboros? What would you prefer instead, and why is that more credible? Please point to the university hiring decisions and tenure decisions associated with that."
They can’t answer the question because they don’t know; they’re just babbling like incoherent idiots. We’re in a transition time in Cardano. There’s a lot of pent-up frustration that people have because not everything worked out exactly as intended, or the markets are in a bad state, or they want some boogeyman to blame. But the reality is that it’s never been better as an ecosystem.
If you look at where we stand—facts, decentralized governance, the measurement of decentralization, institutions to protect and preserve the product backlog, the level of community participation, and the ability to actually start looking to the future and writing a budget for Cardano as a whole—having that decentralized government adjudicate that and eventually vote for a budget to get funding to institutions that can carry out a multi-year roadmap is something no other cryptocurrency really has.
We never stumbled in the things that matter. The network hasn’t gone down and had to be manually reset by people. The extended UTXO is future-proofed, and it’s perfect for rollups and off-chain activities, which is where the entire industry is going. We have a rich and vibrant side chain model that we’re going to be talking about soon, and I think people will be pleasantly surprised.
There’s been a lot of execution on the core threads of things and a lot of the side threads, which are nice to have. Some of them are coming true, like Mithril and Hydra, for example, and Marlo, which people are already starting to use. There are a lot of great community projects, like TX Pipe and Blockfrost, that are doing great work. There’s a vibrant wallet ecosystem; I think there are 14 or 15 wallets in the Cardano ecosystem.
That’s what we have to pay attention to, and we have to push forward and keep going. We can’t allow ourselves to perseverate on things in the periphery that don’t really matter and don’t have a bearing or impact on where things are. We also have to understand that we’re in a moving ecosystem; we’re not standing still. We’re riding a river, and we have to do things on the boat, but the boat is moving from that river.
There are macro factors, regulatory factors, and competitive factors. If you were designing a cryptocurrency in 2015, Ethereum hadn’t even launched; there was no canonical smart contract methodology. If you’re designing a cryptocurrency
1:07:35
26:05
26:19