Charles Hoskinson: Cardano | Lex Fridman Podcast #192

Lex Fridman 0:00 The following is a conversation with Charles Hoskinson, founder of Cardano, co-founder of Ethereum, and a mathematician who's one of the most well-read and knowledgeable people on the technical side of cryptocurrency that I've ever spoken to. Quick mention of our sponsors: Gala Games, Allform, Indeed, ExpressVPN, and Eight Sleep. Check them out in the description to support this podcast. As a side note, let me say that Charles is not just a mathematician or cryptocurrency innovator, but also a Colorado-based farmer of bison and mushrooms, a gamer, a fisherman, and a world traveler. When I asked him if he has a nice professional picture of himself, he sent me a picture of him in Mongolia with a hawk on his shoulder, meeting the Mongolian president. That, to me, pretty much says it all, speaking to the humor and the intelligence of a man who's bold, innovative, and does not shy away from a bit of fun and a bit of controversy, which makes him a fascinating human being to explore ideas with. I do want to say, in terms of ideas, that, at least to me, cryptocurrency is much bigger than just a way for a few Americans to make a quick buck through meme-driven speculation. It is technology that enables freedom from oppression, from suffering in the world, because money is power. Mongolia, for example, was a reminder of that for me. Next day, after talking with Charles, I spoke with Yeonmi Park, who's a North Korean defector and who spent time in Mongolia as many defectors do in her and their escape from North Korea. Her story, the story of North Korea, the story of atrocities throughout the 20th century committed by Hitler, Stalin, and others, is a reminder that the world is full of darkness, but it is also full of beauty and love, and it is a world worth fighting for in every way we know how. This is the Lex Fridman Podcast, and here is my conversation with Charles Hoskinson.

Lex Fridman 2:09 Let's start with a fun question. If we're living in a simulation, what programming language do you think it's written in? And, uh, maybe from a software engineering perspective, what do you think are some of the design principles that it operates under?

Charles Hoskinson 2:22 You know, there are a lot of really lovely papers, like, uh, one came out of MSR, the autodidactic universe. Did you have a chance to see that?

Lex Fridman 2:29 No.

Charles Hoskinson 2:29 Oh, you gotta read it. It's, like, April of 27- uh, '21. It's just brand new. But basically, the idea is that the universe is like some sort of giant self-learning system that can self-evolve, almost like nomic. And then you got Wolfram running around saying, "Hey, we can come up with these, like, very simple rules and we can reconstruct all of reality at, uh, some arbitrary point." Uh, so I have absolutely no idea what's right. You know, I- I look at it kind of like a formal system, and I say, well, if you're stuck within the system, it's hard to actually understand that you're inside the system. You know, it's kind of like a, u- um, an object language to a meta-language. Uh, you know, there's this thing that is outside of it, but because you're constrained and limited by the simulation, you can't really understand the nature of the thing that's outside of it. Uh, it's almost like Minecraft. You can build these redstone computers within Minecraft and simulate and emulate things within it, but you really can't go outside of that, uh, that environment.

Lex Fridman 3:19 The people outside of it can formally prove that it's correct or whatever, but the creatures inside of the system can't hope to perfectly understand it and improve something about it.

Charles Hoskinson 3:28 Well, also the question is, it's a computation question. You know, does P equal NP? 'Cause you'd have to be able to emulate all of these.

Lex Fridman 3:35 Yeah, how long will it take?

Charles Hoskinson 3:36 Yeah, exactly. And so, so I have no clue what type of language it would have to, to look like, but, um, it would probably not be anything we're used to at the moment. It'd have to be something else, and we'd have to have some more fundamental resolution of, of the relationship these formal systems and how they get extended. So, that's like a 22nd century question.

Lex Fridman 3:54 (laughs)

Charles Hoskinson 3:54 ... instead of a 21st century.

Lex Fridman 3:55 Do you like... Do you find the Stephen Wolfram idea compelling? It's a very different way of programming, which is you set some rules, you set some initial conditions, and let it run and see what happens.

Charles Hoskinson 4:06 Yeah, and it's not a new concept. I mean, like, the Santa Fe Institute's been doing that for a long time. And you can use it for economic modeling, and you can show that in certain cases, there's this concept of simple rules evolving into a complex system i- is somewhat more predictive than trying to build a complex top-down model for things. And I guess there's some analogies to these things in AI, where, you know, you start with some simple things and then somehow it just figures stuff out in its environment over time, and much better than if you actually tried to model it w- with Prolog or, you know, something like that. So, that, that is exciting because you get to just do a few things, let the thing run, and then see what happens. And that's a lot of fun. In fact, it got so exciting, uh, Wolfram came to us, and he said, "Hey, let's do an NFT marketplace." And I said, "What do you want to do?" And he said, "I got all these universes to sell."

Lex Fridman 4:51 (laughs)

Charles Hoskinson 4:51 And I said, "Okay, well, that's gonna be fun." So, we're gonna set up an auction system or something like that with him, and I think maybe end of this month or next month, we'll, uh, we'll figure out how to do NFTs on Cardano with, uh, with Wolfram universes. So, as soon as we can sell one, I'll give you one, and then, then we can all just claim that we're living in some sort of Wolfram simulation.

Lex Fridman 5:10 I'm- I- I don't know how much money I have, but I'm gonna give everything I have to get Rule 30-

Charles Hoskinson 5:15 (laughs)

Lex Fridman 5:15 ... which is one of his universes, uh, that he's created. One of the ones... one of the first ones where he discovered, uh, some interesting, uh, complexities from-

Charles Hoskinson 5:24 I think Rule 30 is Turing-complete, or is that 45? I can't remember which one.

Narrator 5:27 (laughs) You know your stuff.

Charles Hoskinson 5:29 Yeah.

Lex Fridman 5:29 Actually, I'm not sure if they proved anything about Rule 30 in terms of whether it's Turing-complete or not.

Charles Hoskinson 5:33 Okay.

Lex Fridman 5:34 But there's fun competitions on it, which is trying to predict something about Rule 30, about the way it evolves. And so far, nobody's been able to do it. Just like looking at the middle column, try to predict as the system evolves, say, anything, like, conclusive about the future of the system as it evolves. It's fascina- it's both, um, beautiful that simple rules can create that kind of complexity.

Charles Hoskinson 5:56 Mm-hmm.

Lex Fridman 5:56 And it's also sad that we can't, like, make perfect sense of it, like, perfectly predict the future.... even though it's all simple and deterministic, we can't say something conclusive about, like, when the thing will end. When will this little cellular automata, like, evolve in a certain way, and then nuclear weapons will be invented and they blow each other up, and then there'll just be this empty, o- uh, 1D cellular automata?

Charles Hoskinson 6:21 Well, doesn't that make it fun, though? I mean ...

Lex Fridman 6:23 (laughs) Yeah. It's fun, but when you're trying to create... And we'll talk about (laughs) , uh, something that operates the economy and the way humans transact and cooperate and fall in love and work together, then you'd like to be a little bit more formal and try to say something conclusive. If this entire universe is just cellular automata, then, uh, the, the... being conclusive is kind of hopeless, generally speaking. And the hope is, I guess, that there will be pockets of which... of... within the cellular automata where you could be predictive, where you can be... where you can formally show that something is true, and then you can rely on that. You'll be resilient and all those kinds of things, even though the rest of the thing is a giant mess that's unpredictable.

Charles Hoskinson 7:09 Yeah, yeah, didn't they call that Laplace's demon?

Lex Fridman 7:11 Yes.

Charles Hoskinson 7:11 Yeah.

Lex Fridman 7:11 Well, I wonder what the, the demon is up to these days.

Lex Fridman 7:14 Okay, thank you for entertaining me with that. But sticking on philosophy, you've also mentioned, among others, that Bertrand Russell and, uh, Saul Kripke are two of your favorite philosophers. Uh, maybe you can comment on what ideas of theirs you find insightful, and also what to you is the difference... Because you're both an engineer and a thinker, so what to you is the difference between philosophy and computer science?

Charles Hoskinson 7:40 Yeah, so, you know, the... There's both a, a deeply human element to both Russell and Saul, and then there's this c- of course, amazing work that they did in the late 19th and 20th century. And you can't really talk about, uh, Russell or, or Saul without also mentioning Wittgenstein and, uh, Tarski. You know, it could... because when you actually look at these guys and you put them together, what they were attempting to do was increase the level of precision we had in analyzing both formal languages and also language in general.

Lex Fridman 8:08 Yeah.

Charles Hoskinson 8:09 And, and so Wittgenstein makes no sense at all to me, so I... there's, there's-

Lex Fridman 8:12 (laughs)

Charles Hoskinson 8:12 ... amazing people out there that somehow can parse that, but-

Lex Fridman 8:15 He doesn't make sense to himself either.

Charles Hoskinson 8:17 I think you're right about that. However, Kripke has Kripkenstein, you know? Yes, he has.

Lex Fridman 8:21 (laughs)

Charles Hoskinson 8:21 He has his, he has his, h- his whole building on that, right? And he, he built a whole hierarchy. And at least there I have modal logic, and I have the little boxes and, and I have the diamonds, and I can do a computation, and I can kind of reason about things that our people are saying. Uh, but really it was all just about provi- uh, precision and, and the nature of truth, precision, the nature of necessity and possibility. And, and the magic of these statements is that you can then start getting a better understanding of, of basically how far a formal language can take you. And so that's the, that's the work of it. You know, David Hilbert also did the same thing. And, you know, Russell, he got his career started working with Alfred North Whitehead. He was a logician. And there was this whole desire in late 19th century mathematics to formalize mathematics in a completely new and better way. And they started with geometry, and Hilbert's geometry was like a complete system. Although recently we've discovered there's a few holes in that, but for the most part is complete, and, you know, the axioms are, are independent and they're consistent. And they said, "Oh, well now we can do this for all of mathematics." And, you know, r- Russell and Whitehead wrote this huge set of, of books, like two big books, Principia Mathematica, 1,000 pages, and the conclusion is one plus one equals two. So they, they linked set theory and arithmetic and logic all in these beautiful ways. Then, little by little, as we entered the 20th century, uh, logicians started chipping away at this idea that you could actually construct a complete system of, of mathematics. First with Godel and then later with the work of Turing and Church and others, they said, "Oh, you're not complete, you're not decidable."

Lex Fridman 9:52 Mm-hmm.

Charles Hoskinson 9:52 And so suddenly, Russell was left in this really bad position where his early life's work was, was basically forgotten, so he had to kind of reinvent himself. And so he went into ethics, and he went into different fields of philosophy. He became this titan in analytic philosophy, and he was also a great pacifist, and, and he was just a phenomenal writer. You know, uh, if you read Why I am Not a Christian or any of his other attacks on, on metaphysics, you know, he said, "Look, I, I can only deal with the world I'm in in the senses that I have, and if I can deduce it, I believe it. If it's outside of that, I really can't make meaningful statements about it." And he said it in a lovely English prose that you would expect of a man of his stature. Now, Saul Kripke, it was like the complete opposite. This guy's a really down-to-earth dude, not aristocratic at all, and, you know, he was one of those guys that just could have done anything because he was so... he's so brilliant. I guess he's still alive.

Lex Fridman 10:43 I think he's 80-something, isn't he?

Charles Hoskinson 10:44 Yeah, exactly.

Lex Fridman 10:45 (laughs)

Charles Hoskinson 10:45 Yeah. He's, he's getting up there, man. But, I mean, literally when he was in high school, he wrote these papers in logic and Harvard contacted him and said, "Hey, could you teach graduate courses at Harvard?" And he said, "No, I, I really would like to finish high school first before I go and teach grad school at Harvard." (laughs) And so this is just one of those guys that you, you can see through his work that he can think deeply about anything. He's like the Galois of philosophy, and he chose to try to clean up a lot of the messes that Tarski and others couldn't resolve. He said, "Let's really get serious about the nature of truth. Let's really try to resolve paradoxes. Let's really try to build things in such a way that the work that we leave behind can actually be built upon and it's not thrown away every 50 years or 100 years." Uh, it was the same for Tarski. He comes in, he says, "We mathematicians love this concept of truth, but yet we've never really created a nice rigorous definition that, that doesn't have paradoxes embedded inside of it." So he had to invent metalanguages and object languages, all these notions and so forth. So I really like those, those four if, if you think about them, and there's a lot of great lessons. And where it's relevant today is, you know, you have human beings and you have computers, and they're trying to understand each other. And computers live in the formal world, and human beings live in the natural language world.... and those bridges between those two are, are still not completely clear. And so, a lot of the work that these guys were doing in 20th Century and 19th Century had nothing at all to do with that, but gives you hope that perhaps a bridge can exist between those two worlds. And maybe there are some nice tools for that bridge to be built upon, and maybe that one in some way will allow computers to better understand us. I mean, they've even created languages, natural spoken languages, that are completely ambiguity-free, like Lojban and things like that.

Lex Fridman 12:23 What?

Charles Hoskinson 12:24 Yeah, right?

Lex Fridman 12:25 Wait, what?

Charles Hoskinson 12:25 L-O-J-B-A-N, Lojban. Uh, it's based on a language called Loglan, and it's a, a spoken language that's equivalent to first-order predicate calculus. It-

Lex Fridman 12:33 Oh, interesting. So, no ambiguities, it's logically consistent?

Charles Hoskinson 12:36 Yeah. Lojban is-

Lex Fridman 12:38 But can you still have fun in it? Like... (laughs)

Charles Hoskinson 12:40 You can get very-

Lex Fridman 12:40 Can you write poetry or what?

Charles Hoskinson 12:41 Yeah, you can... There's people who actually write poetry in Lojban and-

Lex Fridman 12:44 I'm gonna switch to that-

Charles Hoskinson 12:45 Yeah, complete-

Lex Fridman 12:45 ... and start tweeting in it.

Charles Hoskinson 12:46 Yeah, there you go. Uh, so, so, you know, there's a lot, lot there and they're just fun to study and think about. And unfortunately, if you go down that rabbit hole, it, uh, it, you'll spend way, way too much time and there's diminishing returns. Now, the second question you asked was one on theoretical computer science to, I guess, engineering.

Lex Fridman 13:03 Philosophy. No, no, no, no, no, no.

Charles Hoskinson 13:04 Oh, and philosophy.

Lex Fridman 13:04 So, first step, you said humans and computers.

Charles Hoskinson 13:07 Right.

Lex Fridman 13:07 So, theoretical computer science is theory of the computer, and philosophy is the theory of the human. And then we can dissect different stuff about the computer, but in terms of these two worlds of the theory of the human, which is philosophy, and the theory of the computer, which is computer science, what, what do you think is the difference? Like, as we try to bridge that gap, as you mentioned-

Charles Hoskinson 13:28 Mm-hmm.

Lex Fridman 13:29 ... what is going to be, uh, the biggest challenge? Like, can we formalize love? Can we formalize, uh, music, art, poetry, all that kind of stuff? Or is that a human nonsense that we need to get rid of?

Charles Hoskinson 13:42 No, I don't think it's human nonsense at all. I mean, there's even attempts to, to create algorithmically generated music and, you know, the question is- is- is love just strictly a chemical phenomena or is there something like metaphysical about it or, you know, transcendent of, uh, of some sort of formal system? Uh, I mean, computer science is just saying, "Hey, we have this notion of com- computing. We have this, this brain that we've constructed, this formal system that we've built, and given that we have it, what can we do with it?" And so some people worry about the roots of the tree of knowledge, you know, the great Yggdrasil of computer science. They- they worry about the roots and say, "How far can we- we grow them and let's keep adding these new models of computation." And other people worry about the- the trunk of the tree, and some people worry about the leaves of the tree. And the more advanced the field gets, the closer and closer it gets to the people who constructed it, us. You know, we have better image processing, we have better ways of handling speech to text, and we have better ways of computers kind of understanding the intent of what a human being is saying. And then the question is, well, how will a computer understand love or poetry or music? Well, it'll understand it the same way we understand it. You have to get a computer to grow up to a point where it can learn the way we learn or as close to it as possible, then you just expose it to the things that we were exposed with, and then at some point, the computer will start creating things. So, the question is, well, how do you quantify creativity? And I have no clue about that, but it's a-

Lex Fridman 15:09 You make it into an NFT and see how much it sells for.

Charles Hoskinson 15:12 (laughs)

Lex Fridman 15:13 (laughs) That's one way. (laughs)

Charles Hoskinson 15:14 Yeah.

Lex Fridman 15:15 But basically, yeah, there's... so much of it is subjective. And that- that's a fascinating whole area of, that I'm fascinated with, this human-robot interaction, is how do we create compelling experiences that are subjectively compelling, whether it's art or just two humans talking or two humans interacting in some kind of way, to maximize the- the richness of the subjective experience? And I think that could be an optimization problem that could be solved. We're solving it all the time.

Charles Hoskinson 15:40 Right.

Lex Fridman 15:41 Human civilization is constantly trying to... We're constantly trying to pr- uh, impress each other. When we're younger, trying to get laid. (laughs)

Charles Hoskinson 15:49 Right.

Lex Fridman 15:49 Uh, whatever, fall in love, impress your boss at work by all the awesome stuff you do. I mean, we're trying to optimize that problem that's purely, for the most part, it's subjective.

Charles Hoskinson 15:59 Right. Did you ever watch Blade Runner 2049?

Lex Fridman 16:01 Yes.

Charles Hoskinson 16:02 Yeah. Did you remember the whole relationship between Joi and K? You know, and like, did- did she really love him, the hologram, or not? Was it like fake love or real love?

Lex Fridman 16:10 Fake it till you make it is my view on love. Uh, no comment from Charles. So,

Lex Fridman 16:15 let's, uh, let's go to the difference between, uh, theoretical computer science and software engineering, or, um, I don't know if you draw a distinction, but if we look into this computer world now, is there a difference between theory, things you can say formally, and the pragmatic implementation of that theory into actual systems that people use-

Charles Hoskinson 16:37 Yeah.

Lex Fridman 16:37 ... which is, I would, I guess we'll call software engineering?

Charles Hoskinson 16:40 So, you know, the engineer, they're obsessed with the domain of, well, what do you want to accomplish and who are you accomplishing it for? So, they live in the world of people, uh, if they're good engineers. And they say, "Okay, what's the experience? Uh, you know, how are we going to use this? Why are we going to use this? What's the commercial application? What's the non-commercial application?" And you collect all these business requirements. And when- once you've done all of that, the better job you do, the more self-evident it is of how do we apply the toys and tools of computer science and other such things to actually resolve that. And, you know, the point of theoretical computer science if, from the software engineering domain, is it can tell you kind of where your guard rails are. It won't make perfect programs and you, there's no such thing as that, but rather, it can give you a good notion and sense that your program has some desirable properties. Like, it'll, maybe it'll, you can prove that it can terminate if you're dealing with total programs, or maybe you can prove you'll never have a buffer overflow or, you know, you'll, it won't divide by zero somewhere or something like that. You know, some event won't occur that'll cause a catastrophic failure in your system. But there's always this combinatorial explosion between what you can test and think about and what you can actually code.So, the stuff on the left-hand side lives in a different cardinality, a different universe. There's something significantly larger there. And the tools on the right-hand side, you know, we have property-based testing, and these SAT solvers. We have all this great stuff here in formal methods land and computer science theory land, but there's only a small subset of things that they actually give you good answers about. So, the balance of the two things is basically saying, "Well, what do you care about? And what are you okay throwing away?" That's the art of engineering and, and building these types of things. So, you know, cryptocurrencies, we deal with these complex distributed systems that have cryptography and game theory and Byzantine actors. Uh, so, uh, the balance there is saying, "Okay, what can't fail in that system?"

Lex Fridman 18:37 Mm-hmm.

Charles Hoskinson 18:37 And that's the kind of stuff that you want to apply as heavy a toolset as you can, because when that stuff fails, you either have the loss of billions of dollars, privacy, or perha- potentially even life, depending on how these systems get adopted. But then other things, you know, what can fail? Is it okay if the block doesn't get made ev- you know, every now and then? Is it okay if your latency goes up or your, your network suddenly becomes asynchronous and, you know, you disconnect from it and you have to restart the computer or something like that? That's probably okay. It's an inconvenience and burden to the user, and if you actually try to chase that tail, you'll end up spending 10 years chasing phantoms and ghosts. And meanwhile, you know, the whole world moves on. So, it's really figuring out those balance of the two, and what's really beautiful is that the, the formal methods tools have gotten so much better over the last 20 years in particular, mostly because of incredibly high investments from Microsoft and Google and big universities, 'cause these guys are building these gargantuan systems, if you look at the Googleplex or what Amazon has or others, and y- they have so much value, so many users, so many things going on, and no person can keep that in their head. A- and so, you're talking about systems may have 10 million lines of code, 15 million lines of code, millions of nodes connecting, faulty processes happening all the time, hackers breaking in on a regular basis. So, when you're trying to model all of that, you're trying to ask yourself, "What formal guarantees and properties can I get to simplify the system as much as possible?" So, instead of the applications of formal methods slowing you down, in many cases, it actually massively reduces your debugging time and your ability to find where errors occur. In some cases, you can't find where errors occur inside these massive concurrent systems. And you say, "Well, where are cryptocurrencies going?" We're talking about just the same thing. But we're talking about a much more hostile operating environment, where instead of it running in a pristine data center in California somewhere, it's running on your cell phone, it's running on your mom's phone, it's running on your dad's phone, it's running on, you know, some computer in Mongolia that may have good internet on Tuesday, but not any other day. So, when you live in that kind of environment, you, you really do need to think carefully about a whole new class of protocols, and then you need to think carefully about a whole new class of tools and techniques to test the reliability of those systems, and you need to separate the world and say, "What is high-assurance and cannot fail? 'Cause if it fails, people lose money. And what is low assurance and it's okay if that falls apart?" The other thing I'll mention is there are, uh, perverse financial incentives in our industry, because the reality is when something blows up, the people who built those things that blow up usually get paid upfront. So, what they're focusing on is time to market, speed to market, and getting tokens out, and getting them liquid. And me- and then p- people come in, they buy it, but if there's a niscient bug in some DeFi protocol, it'll probably be discovered six months later or something like that. It blows up. Who suffers?

Lex Fridman 21:27 Mm-hmm.

Charles Hoskinson 21:27 The users.

Lex Fridman 21:28 They already got ... The people that created that already got paid.

Charles Hoskinson 21:30 E- exactly. That's why you pay the guy who makes the brake software for your train last.

Lex Fridman 21:34 (laughs)

Charles Hoskinson 21:34 And you make sure he rides the train every day. (laughs)

Lex Fridman 21:38 Uh, so that, that's, that ... You're basically describing the complexity of a distributed system that's fundamentally game theoretic, and like, if we think about turtles all the way down, it's humans all the way down. It's, I mean, you ... At the very bottom, it's still human nature. Is there something you can say formally about human nature to try ... You said it can't ... There's certain parts of the system that can't fail. You know, some people talk about nuclear war in that same kind of way.

Charles Hoskinson 22:05 Mm-hmm.

Lex Fridman 22:05 That there's this game theoretic construction of mutually shared destruction. Oh, that rhymes. See, I'm a poet. That system can't fail (laughs) 'cause you're gonna blow e- everyone up. But you can't formally say for sure it's, it's not going to fail.

Charles Hoskinson 22:20 Right.

Lex Fridman 22:20 So, like, you, you're basically tr- trying to chase, like, statistically reduce the probability that the, the, these particular critical aspects will fail. And then you test, I guess, by deploying in the real world at small scale-

Charles Hoskinson 22:33 Right.

Lex Fridman 22:33 ... to see where things go wrong.

Charles Hoskinson 22:35 Yeah, it's a great question, and, you know, the, the problem with game theory and mechanism design is that you can develop this concept of a rational actor, and I don't think in my life I've ever met a rational actor. You know, there's a rational actor on Tuesday, but, you know, any other day of the week, who the hell knows? And there's even a ... I think there was a book, Freakonomics, and there's a few of these things where it just shows again and again where people behave in ways that are against their best interest. So, then you have these protocol designers and they say, "Well, we need an honest majority for this thing to work." Uh, and they say, "Oh, okay, well, we'll create this incentive model and rational actors will behave with that incentive model." And they say, "Well, the individual won't do that, but the firm, the government, the entity will." The problem with that is we have a lot of counterexamples where the system was actually behaving in weird ways. Like, we almost completely eradicated the human population twice in the 20th century. Once during the Cuban Missile Crisis, and again in the 1980s. There was a Russian colonel, and they installed a new satellite system, and it said, "Hey, the Americans are launching missiles at us. You need to turn the key and, you know, launch all the missiles in the silo." And he said, "Oh, that's not right. That, that doesn't seem right." And he was reprimanded for not launching the missiles. Uh, so in both cases, uh, a single person stood against the systems of superpowers between us and nuclear annihilation. Uh, so, i- in general, we're really bad at building these types of things. So, what you look for instead is say, can the system be self-correcting?It's not about avoiding a problem, it's more about can the problem be resolved? And that's how nature engineers things. It gives you an immune system, it gives you the ability to heal. If a rainforest has a fire or some catastrophic event, the, the ecosystem will find a way to patch things up. So it's a better question of how do you align the incentives over the long term of a system where all the actors within this system, when an event occurs that disrupts it, have an incentive to push it back into a healthy, productive, useful state? Which is, uh, going back kind of to that complexity theory stuff that we began with and a little bit about, you know, how do you handle modern economics? Like for example, we knew this, uh, coming into the COVID crisis that there would be catastrophic economic disruption throughout the entire world. In the developi- developed world, it was print lots of money and hope to God it works. In the developing world is try not to starve to death. Over 100 million people were pushed into acute starvation. So acute hunger. Uh, it was a terrible situation, but every economist knew we were going into that. So then the question is how do you restart the system? How do you realign the system and so forth and make sure that it doesn't collapse at some, uh, at some point? So it's an imperfect, inexact science. Um, and that's actually one of the things that makes our industry so much fun is that these are kind of like micro experiments for the macro. In, in years past, you never got a chance to experiment with monetary policy. I mean, it's like every 20 years, 30 years, they'd have some conference usually in a cool island like Jamaica and be like, "Okay, let's go talk about monetary policy and like amend the Bretton Woods agreement." And these would be nation states, invitation only. And now you have over 8,000 cryptocurrencies floating around, all with their own monetary policy and their rules and it's very Darwinian. A lot are dying, some are succeeding, anomalies happen like Dogecoin and you say, "God, is this temporary? Is this permanent? Why doesn't this horrible thing die?" And then other things you think would be absolutely successful and just take off and be in the top 10 don't really get as much traction. Like Algorand is a great example of that.

Lex Fridman 26:00 Mm-hmm.

Charles Hoskinson 26:00 I mean, Silvio, he's, uh, he's an incredibly bright guy. Every time I go to MIT, we have dinner and, you know, his work is, is legendary, and it's just beautiful and elegant, and he literally has all the people. He went and hired Tal Robin and, you know, she gutted IBM Research, and Craig Jentfri, the guy who did homomorphic encryption under Dan Boneh is there. There's all these amazing people on that team, and they have money in the VCs. So you'd say, "Okay, that's a contender."

Lex Fridman 26:25 Mm-hmm.

Charles Hoskinson 26:25 But if you look at market adoption, Ethereum Classic sometimes is above it.

Lex Fridman 26:29 Mm-hmm.

Charles Hoskinson 26:30 And other things are above it. So it's-

Lex Fridman 26:31 And then there's this weird Darwinian evolution produced, uh, Dogecoin organism that's just like stomping all around.

Charles Hoskinson 26:38 (laughs)

Lex Fridman 26:38 Evolution doesn't make sense.

Charles Hoskinson 26:40 E- exactly, but maybe it's w- we're the problem, not evolution, you know, 'cause the market's the market and, uh, y- you know, you can scream and s- and, and cry and pout and stamp your foot and say, "This makes no sense," but that's the way the world works. You know, there's pl- plenty of mountain climbers that didn't want gravity to apply to them. And it's the same situation here. You know, there's plenty of people in these marketplaces that had the best of intentions, the best team, the best technology, and for whatever reason, they didn't get that adoption. So the question isn't the local, it should be the, the long term, and will the system over time converge to a state that actually is useful and meaningful to society and actually solve problems for it. And that's, uh, that's what we try to figure out is, you know, how do we perturb these things in a way that kind of push them in that direction?

Lex Fridman 27:24 So before we go into this fascinating Darwinian evolution of cryptocurrencies, um, let me ask you sort of a basic programming question. There's a fascinating aspect to your work with Cardano that you use Haskell as, um, to build the infrastructure. But even stepping back more looking at this landscape, another place where Darwinian evolution operates, looking at this landscape of programming languages. You as an engineer, you as a philosopher, both, what programming languages do you think are interesting, and more practically, what programming languages, if you were to advise like students today, should they learn?

Charles Hoskinson 28:05 Yeah. So there's the pedagogy of learning how to program and, and to express the theory of computer science. Like you have to learn how to write algorithms, you have to learn what data structures are, you have to be able to do analysis of these things. And that probably the, I think the, the debate is over Python is probably the best language or JavaScript to, to get started with 'cause they're very useful. The libraries are amazing. There's just tons of online materials. Even MIT is now teaching their introduction to computer science in Python. Uh, and they used to do Lisp. I mean, these, these guys were hardcore.

Lex Fridman 28:37 I still love Lisp.

Charles Hoskinson 28:38 Oh, man, it's great. You know, these, these are your father's parentheses. They're elegant weapons from a f-

Lex Fridman 28:42 (laughs)

Charles Hoskinson 28:42 ... from a time long ago. Uh, but, you know, that's, that's a great starting point. And the... it's not about falling in love with a language, it's just falling in love with computing. It's about falling in love with having a dialogue with a computer and thinking about, "Well, how would I solve that? How would I interact with that? What, what does this need to look like?" Um, functional programming is what we've chosen to use for Cardano mostly because we're living in the academic world. We've written 105 papers. And the problem is you have to translate that work into code. And the gap between an imperative language like a C++ or C and these academic rigorous papers is extremely large.

Lex Fridman 29:19 Mm-hmm.

Charles Hoskinson 29:20 And so there's gonna be a lot of semantical ambiguity between those two. And what I mean by that is that you might end up implementing a s- a wrong thing. You might think that what you've built is the paper, but the computer's not going to tell you that 'cause the paper's written in prose and maybe typed up in LaTeX or something. But there's no proof chain, evidence chain that you can show that there's no ambiguity. When you look at a functional language, you're a little closer to math. And so as a consequence, the translation of the papers that we spent so damn long writing and writing proofs about and so forth to code is much smaller. Now the downside is these functional languages tend to be a bit more academic and they tend to have not necessarily the best Windows support and the libraries aren't so good. And also they tend to be a little slower when compared as a whole on average to languages like C, for example. So it's really a question of, okay, what are you designing for for version one? Are you designing for performance and are you designing for developer accessibility? Are you designing for correctness and are you designing for, uh, the, a, a high fidelity representation of the protocol?Okay. So, uh, Haskell was chosen as kind of the version one, because we knew that the kinds of people who think about that are also the kinds of people that would have an easy time reading a paper like Ouroboros-

Lex Fridman 30:39 Mm-hmm.

Charles Hoskinson 30:39 ... and working their way through all of this. And they would do a pretty good job running a formal specification and then translating that into running code. Then once you have that, you have a blueprint that you can actually reason about, maintain, and if you really wanted to, you could then turn that into a Rust code base or into a Java code base. Going the other way around would be, you know, kind of, kind of pointless and counterproductive. The other side of it is that... Haskell code or functional code tends to be significantly more concise, and I actually have a, a real-life example of that. So, if you take a look at Mantis, you know, we, we implemented a full Ethereum node in, uh, Scala. It's only about 14 or 15,000 lines of code. If you compare that with like C++ Bitcoin, I think that's 120, 150,000 lines of code. So, it's almost 10 times smaller, and so less code, less to read. And you tend to read code significantly more than you would, uh, read, uh, write code. So, i- it's always an advantage for maintenance, understandability, documentation, uh, and other such things when you have more concise code bases. And also, it's, it's a lot easier for you to apply l- uh, stronger tools to a functional code base, uh, like static analysis or property-based testing or these types of things, uh, than an imperative code base. But, you know, the thing is there, it's, it's almost like a religion. It's like, say, or, or language, it's like saying, uh, what's French versus Russian versus English, everybody has their adherence. They say, "Oh, they had the best poetry here." Or-

Lex Fridman 32:07 Russian, yeah.

Charles Hoskinson 32:08 Yeah.

Lex Fridman 32:08 Wins.

Charles Hoskinson 32:08 There you go, always Russian. Everybody has their favorite tools and their f- their, their favorite languages, but it just comes down to what problems are you trying to solve and what problem domain do you live in? If you're inventing new protocols based on science, you're gonna take the time to write a paper, go through the peer review process, uh, as you've done personally, and you know how hard it can be to get into a conference and go through that and get your ass kicked. Then you also have to apply the exact same level of care to the engineering side in terms of the implementation of that, or else you will make a mistake, and that mistake will probably be an exploit in the system that destroys the security properties of the system. So, we really had no choice but to go to some notion of functional. The question was, what's the Goldilocks language? Do you use a hybrid language like Sh- Scala and F# or Closure where you still have some connection to understandable things like .NET or the JVM? Or do you go to an overly academic language like Idris or Agda or, you know, Isabelle? And in there, you could really dial up the correctness and write all kinds of crazy proofs. But by the way, it's like s- the seven people who write your code, they go on vacation a lot, you'll never get anything done. So, Haskell kind of felt like a nice middle ground between those two where if we needed to pull into the left, we could. If you wanted to pull into the right, you could as well. That said, it's really amazing to see what the hybrid languages have done. If I was a new student in computer science and I said, "You know, learn any language to grow your career from," uh, Scala 3 is probably the language to go with.

Lex Fridman 33:37 Interesting.

Charles Hoskinson 33:37 Yeah, it's great, 'cause it's like you want it to be like Java, it's Java, and it looks kind of like a Java program. You want it to be like Python and scripted and you use a REPL, you can do that. You want to go hardcore dot, you know, d- uh, dependent object types and do like weird proofs and stuff in the functional, you do all that.

Lex Fridman 33:55 Mm-hmm.

Charles Hoskinson 33:55 You have access to all of these things, and Martin Aderski is a brilliant guy. He's done some phenomenal work basically, 'cause he was a, he was one of the guys who created JVM and he's worked on compilers for over 20 years. He, he did a lot of really hardcore work in trying to build a concise, nice, modern language that does a little bit of everything. And it's got great applications in data science and in AI, and it's also heavily used in modern companies. Like Netflix uses Scala for all of their microservice architecture.

Lex Fridman 34:23 Interesting.

Charles Hoskinson 34:23 Yeah, so there's, that's a great language. And it's easy to pick up, and it's easy to hire people into it. You just find these Eastern European guys who were Java programmers for 10 years, 15 years-

Lex Fridman 34:32 (laughs)

Charles Hoskinson 34:32 ... and they got tired of making $20 an hour, so they picked up Scala so they can make $35 an hour.

Lex Fridman 34:38 (laughs)

Charles Hoskinson 34:38 And they're really good at it, you know?

Lex Fridman 34:39 Yeah.

Charles Hoskinson 34:40 And that's a great gateway drug 'cause you know you have like quick check-in Haskell, you have Scala check in Scala. You know, you can also build, do model checking. You can also go and use a TLA spec and, and make it work with Scala and so forth. So, it's a, it, it gets you a little bit of everything, and, uh, you know, you can then move around that entire design space in a beautiful way.

Lex Fridman 35:01 (inhales) So, the recommendation is, uh, maybe if you wanna go vanilla, you go Python and JavaScript.

Charles Hoskinson 35:07 When you're getting started.

Lex Fridman 35:08 Just getting started.

Charles Hoskinson 35:08 'Cause that'll get you everything. You can-

Lex Fridman 35:10 And then-

Charles Hoskinson 35:10 ... do web scrapers and anything. It's, it's just fun.

Lex Fridman 35:12 Like all this experiment with drugs in undergrad, this was where Scala 3 comes in, it's a gateway drug to then potentially more hardcore functional languages like Haskell. Do you think C and C++, C++ still has a role?

Charles Hoskinson 35:24 No, I think Rust is completely-

Lex Fridman 35:25 Rust.

Charles Hoskinson 35:25 ... replaced the need for them. Go and Rust, uh, you know, those are the, the, the two twins of doom. I mean, Google created Go-

Lex Fridman 35:32 (laughs)

Charles Hoskinson 35:32 ... just to get rid of C. Y- they hated C that much. And then, uh, Rust is just a phenomenal language as well.

Lex Fridman 35:37 Hate can be a great motivator.

Charles Hoskinson 35:38 Yeah.

Lex Fridman 35:39 Uh, let me ask a question from Reddit on this topic. We'll go in-depth first today.

Charles Hoskinson 35:43 Sure.

Lex Fridman 35:44 Um, "As a developer, why should I be incentivized to create Cardano-based applications? What is on the Cardano developer roadmap? Any other language..." I guess this is the key question I want to ask.

Charles Hoskinson 35:55 Right.

Lex Fridman 35:55 "Any other language support other than Haskell?" The example this person gives is, "Typescript, Go, Java, Python, et cetera. Also, have you considered a yearly conference focused around developers?"

Charles Hoskinson 36:07 (laughs) Yeah, we call it PlutusFest, and we, we did the first one in 20...... 2018, 2019, I can't remember, and, uh, we were gonna do one last year, but then COVID hit.

Lex Fridman 36:17 Mm-hmm.

Charles Hoskinson 36:17 So, we'll, we'll bring it back and we'll probably do it annually at the University of Wyoming for their hackathon there. In fact, it just so happens that coincides with the Goguen Summit, so we're doing that in, I think, the third week of September. But yeah, it's great to do an annual conference, you can bring a lot of cool people together and you can do hackathons and awards and so forth. But to the question in particular, uh, Plutus is, is like any other language. Plutus Core, you can compile things in- into it, so it's entirely possible to write a Scala to Plutus Core compiler or a TypeScript compiler or something like that. But, you know, I'm a big believer of, of separation of concerns, and we don't live in a single chain model anymore, uh, so, you know, you, you have a situation where you probably wanna have different execution environments and different chains, so you have different virtual machines there. And that's why we work so closely with University of Illinois, Urbana-Champaign, Grigore Rosu's team. At, uh, runtime verification, what they did is they said, "Let's start with something very familiar, LLVM," which has been around for a really long time and they happen to have created it there with Apple, "and let's take that and translate that into the blockchain space." Okay. Then once you have it, then it's very easy to modify compilers of standard languages like the Cs and C++s and other such things that do compile to LLVM already and have them run there. So, that's a different execution model than what we tried to build for Plutus, which focuses on correctness, okay? So, then all you have to really do is say, "Can both of these models co-exist within the same ecosystem?" 'Cause then you kind of... and I ca- I did a video, it was called like the Island, the Ocean, the Pond, and the basic idea was, say, you have an island where everything's perfect. Calypso lives there, life is great, uh, you know, people feed you grapes every day, but maybe you can't do everything on the island, you know? And s- uh, the ocean's big, it has everything, but the ocean's got sea monsters and sharks and Boaty McBoatface and, you know, all kinds of crazy stuff, right?

Lex Fridman 38:08 (laughs)

Charles Hoskinson 38:08 So that's what Yella is about, it's basically this, this will bring LLVM into our world and at some point in the next three to five year time horizon, we can bring modern programming languages in, but you're- they're gonna come in with all their flaws and their warts and their problems. And then, uh, the pond was the idea of the Ethereum Virtual Machine. There's some network effect around it and there's some great tooling that's, uh, materialized and evolved, and it's not clear if that's the standard yet or if like Myspace or Blackberry or all these other things, it'll fade away. Well, if it becomes the standard, okay, don't, uh, don't fight nature, just support it. And the same thing that gives you the ability to f- uh, bolt on the LLVM will also give you the ability to bolt on the EVM, and they can run with their own models and they're encapsulated, bulkheaded, separated systems, but you can move ADA applications, information between those two systems.

Lex Fridman 38:59 Mm-hmm.

Charles Hoskinson 38:59 And so your main chain will always stay somewhat conservative and have the minimum viable amount of expressiveness required on it to do all kinds of interesting things, and also for interoperability, be able to talk to all kinds of interesting things. But it's not trying to be everything to everyone. There's never gonna be an ice cream store in the island. You'll have the grapes and the beautiful women, but no ice cream.

Lex Fridman 39:20 (laughs) Now you're just like distracting me with the

Lex Fridman 39:23 ice cream. Uh, so just for- because we'll throw around a bunch of terms, for the record, what is Plutus?

Charles Hoskinson 39:28 So, Plutus is a programming language. It's kind of a DSL that we built on top of Haskell. And, uh, basically we wrote it, uh, after spending about three years thinking about all smart contracts. We were trying to figure out, like, what is the ideal language to express a smart contract? And then we started thinking, well, what is a smart contract? Is it the whole application or is it just like a submodule within an application? And usually it's, it's the latter more than the former. You can build a self-contained program like a script, but usually what's happening is you'll have it like a video game, let's say World of Warcraft or something like that. You say, "Hey, maybe I wanna actually create gold in War- World of Warcraft that's actually a currency," you know? Okay, so I'm gonna issue a token. Well, and then maybe I wanna create some mechanics behind how people are gonna trade that amongst each other, so that would be like a smart contract layer and issue an asset. So, you have this centralized server running and proprietary software controlled by a single company, but then you've opened your application up to a broader world, and what you've done now is added a blockchain layer and the blockchain handles the accounting of that asset and the spending policy of that stuff. So, that is a much smaller program than what Blizzard is doing with World of Warcraft. So, the point of Plutus was, let's create a language where you can write these small to mid-sized programs and have a high degree of confidence that they behave with correctness and also they give you deterministic results on the consumption of resources. You can run things locally and you actually understand what it costs to run, and that doesn't change when you deploy it on the system. If you dial up the expressiveness of the system and, uh, like Ethereum does and these, these big mutable account systems, the problem is you have to have global state, so whatever you test locally doesn't actually necessarily translate to what you've deployed, okay? So, we, we spent a long time asking like, where's the Goldilocks zone? Bitcoin's script was too restrictive, and every single time Satoshi tried to dial it up, it led to mega problems. Like, there was a beautiful thing called the value overflow incident in 2010 which led to the creation of billions of Bitcoin, uh, they had to quickly clean that up and sweep it under the rug and pretend like it didn't exist. But that was mostly because, uh, of an issue with how the scripting language was implemented, and when you look at Ethereum, it- it's like this puric game of, of stomping down these skirmishers where every update there's something they have to change or tune and then it's not clear how you shard such a model. So, we said let's build something that's in the middle of this, and that's what Plutus basically is, and it's really designed to play very nicely with off-chain infrastructure as much as on-chain infrastructure. So you can look at all those different examples, whether it's Wolfram wants to auction off their universes or Blizzard wants to, uh, issue an in-game currency or you're Uber and you want to start putting peer-to-peer dynamics inside your system, you're gonna gracefully connect to that on-chain code, and it's very clear how those two things connect together. It just so happens Haskell's really good for this. They have template Haskell and it makes it very easy to embed domain specific languages, and it makes it very easy to wire your Haskell code onto off-chain infrastructure. So, you know, in the future, you'll be able to have your off-chain run in Node or the Java Virtual Machine or .NET application, and there will just be this beautiful interface and then it can talk to all your on-chain code, and that's written in that DSL and you have a high degree of assurance that it's, uh, that it's right.

Lex Fridman 42:49 Is there, um, like a Hello World program in Plutus that reveals the beauty of the- this balance that you're referring to? Sort of, uh, simple but not too simple, the Einstein idea?

Charles Hoskinson 43:00 Yeah. Uh, so we did do our first Hello World program actually today, uh, 'cause we just-

Lex Fridman 43:04 Yeah, I heard about this.

Charles Hoskinson 43:04 Yeah. Um, but you know, the, there, you'd want to have the whole round trip. So you'd like to have an interaction, and I think a video game would probably show it the best. Like, if we could re-implement CryptoKitties or something like that on it, and you have this off-chain infrastructure, and you have your GUI and your front end, it's running on your phone or a browser, and most of that lives off chain. And then, but your crypto kitties, they'd live on the blockchain. The f- the whole round trip, end-to-end with relatively low fees and low latency, and, uh, and high availability of service, it never goes down, uh, that would probably be the best thing to do. And we'll have something like that by August. It's pretty easy to build this stuff.

Lex Fridman 43:39 So what kind of off-chain interactions are supported with Plutus? What are the limits you wanna put on the thing so it doesn't get chaotic?

Charles Hoskinson 43:44 Well, that- that's the beautiful thing. When you have a less expressive model on chain, it means you can do anything you want off chain.

Lex Fridman 43:50 Anything. Uh, so you started talking about smart contracts, but, uh, let's zoom back out and ask, uh, the big question here is what is a blockchain and what is a cryptocurrency?

Charles Hoskinson 44:02 So a blockchain is just a ledger, and really, it has three nice properties. You're timestamped, you're immutable and auditable, either in a global or a local sense. And so there's all kinds of things mankind has invented where it's really important that you, when you put some information down, it doesn't change, and other people can see it, uh, and that you know when it was put down. For example, a property ledger. So when you buy land or you have rights associated with land, like mineral rights or water rights or these things, you'd like to transitively see how does it go from Alice, to Bob, to Charlie, to Jim, and so forth, and, uh, what was the state of these things as they were transitioning? So how much did they pay? Uh, you know, when did it occur? Et cetera, et cetera. The metadata that follows that. Okay, well normally, these types of ledgers are so important that they're managed either by governments or regulated entities. And the issues, uh, are that while they can be efficient, they're generally brittle to political manipulation and they're brittle to geopolitical events. For example, when Syria fell apart, you know, the very first thing ISIS did is they started saying, "Hey, uh, the ownership of the land, it's gonna fundamentally change. We've decided that, you know, this guy over here now owns all these things." And then when peace comes, like how do you unwind all of that, put it all back together? Uh, so the, the power of a blockchain is that it gives you a transnational way of sorting all these details out and putting it all together in a, in, in, in, in a place that you know that even if it's inconvenient to a very powerful actor, that it will still stay preserved. This is, uh, an asymmetry we haven't had as a society. Usually kings and empires, they have the ability to decide what's true. Uh, and then suddenly, you have this asymmetrical thing that is above them, kind of like a synthetic laws of physics, and once something goes in there, you know that that's there. Okay, so that's the first part of it. The second part of it is that it's auditable, meaning that instead of saying only the high cleric or the president or, you know, some very special club of people get to see what's going on, suddenly now all the people can actually see who owns what where. Like imagine a tax system where, you know, the Pro Publica just leaked, um, the, the taxes of all these different billionaires and said, "Well, how much did they make and how much did they pay?" Well, imagine a tax system where that's just done by default, or any other social systems where this type of information is put in by default. So, uh, it's tremendously useful, uh, uh, this type of structure in all kinds of things, medical records, supply chains. You know, just a good thought experiment is I travel a lot, I've been to 52 countries in the last five years. Imagine if I got sick in Zimbabwe, you know, I get hit by a car or something and I'm unconscious, and a Zimbabwean doctor calls my doctor in Colorado and says, "Hey, you know, I, I need all of Charles's medical records. Uh, you know, he's unconscious right now, uh, but I need it to treat him 'cause he's quite ill." Uh, they'd say, "Who is this person in Zimbabwe? Why, I don't know you. I can't give you his records. I need his consent. Oh no, he's unconscious in the hospital. I can't do it." Well, a broker system that would allow the movement of medical records would be an example of what a blockchain could potentially do in the foreseeable future. Cryptocurrency's just an application that runs on top of a blockchain, 'cause it- it turns out that when you issue property, you also can issue tokens of value, and then you can have a monetary policy. It can be inflationary or deflationary. You can have demourage where it decays over time, or whatever have you. Uh, and the very same mechanics that would ensure your property records are secure, your medical record access is secure, could also be applied for the ownership of the cryptocurrency. And again, you can either be completely transparent and everybody can see what everybody owns, and that's what Bitcoin does, or you can be as opaque as you seek to be. That's what Zcash basically attempts to do. It says, "Hey, let's keep these things as private as possible," but they have relatively the same mechanics in terms of those properties of auditability and time stamping and immutability. You know things won't be reversed. You know that people aren't gonna manipulate the time stamps, and, uh, you can audit at least enough to know that the ownership

Charles Hoskinson 48:02 is right.

Lex Fridman 48:03 But the way, if you think about physics and the universe, the universe has figured out a way to update the ledger of physics in a way where like a lot of people can be updating it and it s- stays consistent. Is there, um, is there something you can say about the task of updating the ledger when a bunch of people are trying to do it, or a bunch of entities are trying to do it?

Charles Hoskinson 48:24 Well, yeah, that's the whole point of a consensus algorithm. So whatever ledger you're running, there has to be some mechanism to decide who's in charge, and that's what proof of work does and proof of stake does, and all these other systems, and you break them down to basically three steps. And so we'll use Eve for kind of step number one. Hi, Eve, how you doing? And we're gonna-

Lex Fridman 48:42 Do you want to do this? Do you want to do-

Charles Hoskinson 48:43 ... Wally for step number two. And I need the monkey. Give me the monkey. (laughs) What's the monkey's name?

Lex Fridman 48:48 Uh, Daisy.

Charles Hoskinson 48:49 Daisy the monkey. Okay. I like Daisy. Daisy's a very confused monkey.

Lex Fridman 48:54 Ponder- it's pondering its own mortality just-

Charles Hoskinson 48:56 Right. And so anyway, the first step is, is all about basically deciding who's in charge for that moment. So blockchain is just a sequence of events. The heart has to beat....the metronome has to click. So somebody has to be in charge, and so generally, you have this notion of a resource, so there's some pool of resource out there. And it can be a token, and i- in that case, it's a plutocratic system, and that's what proof of stake does. Or it can be computation, uh, but there can be other resources, but computation is what proof of work does. And so you make so many hashes, and then eventually, somebody wins, and that person who wins is now the person who basically gets to decide the order of transactions and put-

Narrator 49:32 Mm-hmm.

Charles Hoskinson 49:32 ...them all together from their perspective in the system. Then once that person wins, they'll make the block, that's step two, and after it's made, transmit it, and it gets validated and accepted. So actually, it's quite fortuitous you have the magnifying glass 'cause at this sta- stage, people are trying to decide, uh, "Is what I'm looking at correct or not?" Now, there are other ways to potentially conceive of this, but this particular model gives you a kind of a way of thinking of, uh, all consensus algorithms in one setting. You can be Algorand. You can be a classic BFT protocol. You can be Paxos. You can be Raft. You can be proof of work. You can be proof of stake. It's always the same idea. Uh, you have to find someone or some group to be in charge. They'll reach a consensus on order. They have to then do some work, a- uh, change the state of the system, update it, and then the network has to accept that that's valid. So even if this process works well, this side will say, "Oh, you created a Bitcoin out of thin air. You're not allowed to do that," so that's rejected.

Narrator 50:33 Mm-hmm.

Charles Hoskinson 50:33 Okay, so there's checks and balances and guards all the way through. There's a meta question of fairness in all of this. Okay, so the proof of work people, they're kind of a cult, and they say that this is the only truth, and everything out here, any other resource is not legitimate or valid. A- And there's not a lot of evidence to that, but that's what they believe. The proof of stake people, the downside and weakness they have is it's a plutocratic model. The more ownership of the system you have, the more control you have over that system, and then i- i- it suffers from the same thing that shareholder models suffer from, whereas you may maximize short-term gain over the long-term viability of the system. So a really cool question is, can you build systems that are multi-resource? So instead of just pulling from one resource to select who wins, you know, this 25% of the time and maybe this 25%, you can do that. In fact, uh, the cryptocurrency space did that a long time ago. There was a cryptocurrency called Peercoin in 2011, and it was a hybrid proof of work, proof of stake. So some of the blocks were made with the token ownership distribution, and some of the blocks were made with proof of work, but you could keep adding. You could put in like, "Hey, I- I want hard disk in my thing." You can put Permacoin in or something like that, so you create an incentive for hard drives. And then you could say, "Oh, no, I- I wanna do like a human system, like a proof of merit." Oh my God, now we're up to four, and you just keep adding.

Narrator 51:51 Mm-hmm.

Charles Hoskinson 51:51 And th- each of these pools will have different adherence and actors, and then you can actually balance out the whole thing.

Narrator 51:57 So as opposed to having one cult, you have many cults.

Charles Hoskinson 51:59 E- Exactly.

Narrator 52:00 And they argue.

Charles Hoskinson 52:01 And the cults argue with each o- and we call that a government.

Narrator 52:03 By the way, not all cults are bad. Physics is a cult too.

Charles Hoskinson 52:06 And it's sometimes bad. (laughs)

Narrator 52:09 It's honest, at least. Nature is a cult. (laughs)

Charles Hoskinson 52:12 (laughs) Yes.

Narrator 52:13 Nature is metal.

Charles Hoskinson 52:14 Yes.

Narrator 52:14 Check out the Instagram.

Charles Hoskinson 52:15 So that's really the- the- the crux of it. You know, you have a ledger, and the- and the ledger is just all about saying, "Hey, we need to put some stuff in here, and once it's put in here, you can't turn it back." And, uh, you know when it was put in, and everybody can see it or some group can see it, and then you need to pick somebody to modify that. So all this chaos will happen. All these transactions are ha- all around the world, and our perception of them are different. There's a beautiful paper from Lamport that kind of talks about this from the '70s. It's like one of the most classic papers ever in computer science. I think it's been cited like 50,000 times or something-

Narrator 52:47 Mm-hmm.

Charles Hoskinson 52:47 ...like that. It's a crazy paper. But basically, you have to figure out, okay, well, somebody has to be in charge. Some group has to be in charge, and you can do it with, uh, a meritocratic, hashocratic computation thing. You can say, "Well, if you have coins, 25- 25% of the supply, 25% of the time, on average, you'll be selected to have the right to do this or give it to somebody else, or you could search for other resources." And they could even be human resources, like some notion of merit or social benefit. Maybe you get a token for that, and you can weight it with these other systems, and that's where kind of where everything's going. You know, we're getting to a point where we've really optimized all the properties here. We've proven all these nice things about it, and there's a lot of competition to- to basically build like the perfect proof of stake system, whether you're Polkadot or Algorand or any of these other guys. But now the next step is say, "Well, why don't we just s- have one? We should have multiple resources," and the point is each of these has different trade-off profiles, and so they balance each other, and you end up building a much more resilient system, so it's not winner take all with one particular demand.

Narrator 53:49 Okay, so there's a million questions this bring up right there. But- but- but first,

Narrator 53:53 linger on this topic and say what is proof of work, what is proof of stake, just zooming in on each-

Charles Hoskinson 53:58 Sure.

Narrator 53:58 ...of those, and what are the differences?

Charles Hoskinson 54:01 Okay, so, uh, they all have the same three properties of pick someone in charge, do something, and validate it. The difference is that the picking mechanism for proof of work is you have to solve a puzzle, so you're- it's basically like buying lottery tickets, and you can buy a certain amount every second with your computing devices, and some of them are Asic resistant, so you run 'em on like a laptop or a GPU, and some of them are you specialize hardware that you have to either manufacture or buy from someone who sells it to you. And that's just how many tickets per second you can get, and eventually, you hit those magic numbers, and when you do, it means you ha- have the right to make the block, and generally, you bundle the block-making with the proof-of-work system. Now, you can do this looking for a single-... or you can do this to actually shard it and look for multiple block makers at the same time. So, there are sharded proof of work protocols, like PRISM is an example of that, and, uh, uh, actually, Ethereum got started this way with Specter, and, and Ghost, and Phantom, the Avi, Avi Zahar's work, and Yonatan Somlapinsky. But the basic idea is you pick some collection of people, they make some collection of things, and there's some way to sort it all out, serialize it, and prevent double spends. Great. Proof of stake is the same, uh, but it's a synthetic resource. So instead of doing things, they say, "Well, if you had 25% of the hash power, on average, over a long period of time, you'd probably win 25% of the time. Well, why don't we just introduce some randomness in from some source, and then 25% of the time, on average, over a long period of time, you'll win?" So, it's a synthetic resource, uh, but you still have to do the other two things. You still have to make the block and you still have to validate the block. The big difference is, this step in the proof of work world is horrendously expensive. You use more energy than the nation of Switzerland. And the problem with that is that you have less resources for the other two, and the other problem with that is that, uh, if this is horrendously expensive, you have an economy of scale kick in. So what ends up happening is the system becomes less decentralized over time because you have these vertically integrated operations. I mean, not everybody can go build a mining facility on a volcano in El Salvador. Not everybody can go to Mongolia and set up a five gigawatt power plant and a huge data thing. Not everybody has access to the patented ASICs that people produce, 'cause what if I don't sell it to you and I have the patent on it, or what if I control the supply chain for these things? So, you'll end up having centralization around maybe 10 or 5 major operations, as we've seen, uh, historically with proof of work, and, uh, that means you end up having, like, a ruling class of a mining oligarchy in the system. Proof of stake, if you design the parameters correctly, you actually get more decentralized over time, because as the currency goes up in value, the distribution of the currency tends to get more, more egalitarian. Uh, for example, Bill Gates, when he started Microsoft, he had 64% of the shares. Now he has less than 5% of the shares. So there's founder drift over time. As the value goes up, divestment occurs, you have more and more and more people coming in. That means there's more people who can participate in the consensus. You can even tune economic parameters, and this is what we did with, uh, Cardano and Ouroboros. We, we created this concept of K in the system, and it's just a parameter, and it's, it's like a forcing factor that tends to accumulate a certain amount of stake pools, so you can set it to 200, and then 500, and 1,000, and so forth. But the basic idea is as the price of ADA goes up, you make K larger, and then you end up, in practical terms, having a larger and larger set of actors making blocks-

Lex Fridman 57:26 Mm-hmm.

Charles Hoskinson 57:27 ... that are unique and distinct. And the other good thing is this is a virtual resource instead of a physical resource, which means it's portable by the click of a button. So let's say China says, "Mining is bad, we're gonna shut it all down," and it looks like they're moving in that direction. You have all these people in WeChat just, like, trying to sell miners or trying to figure out, "How the hell do I move miners?" You know, 'cause they have these huge data centers they've constructed. You can't exactly go and grab a server and, like, take it with you. It's huge. It's a lot of work, and if the government seizes it, well, it's their property now. A virtual resource, you can click a button and redeploy it to a different jurisdiction. So, to me, for a virtual asset, it makes a lot more sense to try to tie your security to something endogenous, something within the system, because it's, it's just like the asset, it can move anywhere at a click of a button-

Lex Fridman 58:12 Mm-hmm.

Charles Hoskinson 58:13 ... and human beings have a much harder time attacking something like that.

Lex Fridman 58:16 Well, so people, maybe you could sort of play devil's advocate and say, "What is the strength of proof of work system?" Because some people would argue that proof of work has, because it's outside the system, uh, it's tied to physical resources, it's more secure, it's less prone to, um, to attack by large groups of people.

Charles Hoskinson 58:36 Yeah, that's a great question, and the first question we had was could proof of stake actually work or not? So, the problem was that the engineers kind of led when the science should've led, and so there were all these PoS protocols that came out in the early 2010s, like, to- Peercoin was the first, and then NXT and others came out, and there, they had suffered from things like the random number generation wasn't good, they had grinding attacks, and nothing at stake, and all these other things. And there's a lot of beautiful properties for pro- proof of work from a theoretical sense. We even wrote a paper, uh, called GKL, uh, named after the authors Juan Garay, uh, Nico Leonardis, and Aggelos Cassis, our, our chief scientist. It's got 1,100 citations now, and it's, you know, it was published in 2015. But basically, all it did is just modeled a blockchain and created some security properties for it, and then it started talking about, "Well, what does proof of work actually do for you?" And it, it turns out, it does a lot. It's an asynchronous system. You can bootstrap from Genesis. So, if Eve joins the network, and Wally joins the network, and Daisy joined the network, then you give them some different chains, like five or 10 different chains, they can run a calculation, and they will always pick the longest chain, the heaviest chain inside the system. That's a great property of proof of work. Until we published Ouroboros Genesis in 2018, uh, you actually needed to solve that in proof of stake with a trusted checkpoint. So some actor had to be observing, watching the whole thing, and creating checkpoints, and then when new people joined in, they would only be able to distinguish between a chain based upon a checkpoint telling them that. So you have to do a lot of really wonky, crazy math to show and create this notion of, like, density to be able to show that that's possible. But there's a lot of properties of proof of work that were super hard to replicate and emulate in the proof of stake world. Uh, Micali kind of revolutionized the whole VRFs thing. Uh, uh, there was a group out of Cornell that talked about better network conditions, they wrote a paper called Sleepy. Uh, we did Genesis, uh, we also did the very first provably secure protocol, but that was six years of work and, like, 12 papers, and it's still not done. There's still a few polishing things that have to be cleaned up because, you know, it's, it's, this is a physical resource, and there's, there's something there. But there's a flaw to proof of work that is a little problematic. It's a winner take all type of a system, so-... maximalism is kind of philosophically and computationally built into it. Let's say you have two proof of work systems, and they have roughly the same market cap and hash rate-

Lex Fridman 1:01:02 Mm-hmm.

Charles Hoskinson 1:01:03 ... and they use the same algorithm. Then the problem is that if the miner comes in, and let's say the miner has enough resources to have 51%, uh, for e- any of these chains, they actually have a perverse incentive to come and destroy one chain and short sell the asset, it's called a gold finger attack, and then go mine the other asset, 'cause they're not bound to that asset. They're not loyal to it.

Lex Fridman 1:01:26 Mm-hmm.

Charles Hoskinson 1:01:26 And they can make just as much profit mining this as they can make mining the other system, and markets allow them to profit from the destruction of a system. So, that's something that proof of stake doesn't suffer from, because the only way you can participate in a proof of stake system is you have to actually own equity in it. You have to have ownership in that system. So if you go and destroy Daisy's chain, uh, they, uh, it would just be a net loss for the most part, unless you have really messed up markets or something like that. So, there's always trade-offs in all these things, and this is why I like this concept of going one to end and having multiple resources, because why not have proof of work and proof of stake together if the proof of work is useful, not wasted computation, and why not add other things like create incentives for network relay? Right now, there's no incentives in the system for you to run peer-to-peer nodes and share data. Right now, it's not a problem, but if you're running, like, Amazon Web Services level of bandwidth, it could cost you, like, $5,000 a month in bandwidth just to run a full node or something like that. No one would do it. So then your system will centralize along the weakest link, whether it be the storage layer, the computation layer, or the network layer of, uh, the system. So if you can incentivize the resources differently, then you'll be in a beautiful position where, uh, you, you end up having a resilient system that pays its own bills.

Lex Fridman 1:02:39 S- so how does Cardano solve the consensus problem? Do you tend to eventually wanting to solve it in the hybrid approach of proof of stake and proof of work?

Charles Hoskinson 1:02:50 Yeah, this was the philosophical difference between Vitalik and myself. You know, the, the problem with the people on the Ethereum side is they're really bright, and these really bright people, what they do is they try to do everything all at once, 'cause they're really, really smart and they keep going until they run up against the wall and then they realize that the problem's a lot harder. If you're more experienced, and that's why we brought in proper academics like Aggelos and others, 'cause they, they'd been beaten up through life.

Lex Fridman 1:03:14 (laughs)

Charles Hoskinson 1:03:14 You know, Aggelos worked with David Chaum and these other... It's really hard to work (laughs) with those guys. And they, they'd already been humiliated and yelled at, had chalk thrown at them and all that stuff, and so they were humble enough to say, "I'm not smart enough to solve the big problem, so don't even try." What you do is you decompose it and you say, "Okay, what's the first problem to solve in a chain of problems that you can compose your way up to a working system?" And i- uh, once you get far enough along, you have something that's pretty good, and then you have an obvious path forward of how do you iterate and improve that system. That's why we started with GKL 15, because it was just saying, "We don't know what, what a fucking blockchain is."

Lex Fridman 1:03:50 Mm-hmm.

Charles Hoskinson 1:03:50 This is... J- what is this thing, right? What is the security properties of this stuff? Like, what, what do we really mean? Then we did Ouroboros Classic, the original Ouroboros protocol in 2017, and that protocol was like a synchronous system, and it assumed the nodes were always on, and it s- it worked, but it was useless because that's not real life. Then Proust came out, and then suddenly we relaxed things.

Lex Fridman 1:04:10 These are all, by the way, names for consensus algorithms

Narrator 1:04:13 Yeah.

Lex Fridman 1:04:13 ... implementations.

Charles Hoskinson 1:04:13 ... the papers that we published, and they were all peer reviewed. Like, GKL was EuroCrypt, that's a very hard conference to get into, and Ouroboros Classic was Crypto and Proust was EuroCrypt, and, uh, Genesis was CCS. So, uh, basically, every step of the way was first an academic validation that there was some merit to the work that was done. Second, it solved a particular class of problems, either showing the feasibility of the entire problem, 'cause when I said, "L- l- let's do the model first, 'cause let's see if we can do an FLP thing, let's see if we can get a possibility theorem." That's great, 'cause you're done. It's like, you know, those, those short math papers where like, "I found a counter-example." It's like, "Oh, okay, this whole thing is falling apart, 'cause you, you have a two-line proof. Thank you." Uh, so that's what we were looking for in the beginning of the agenda, was let's either prove it's possible in a straw man case or show that there exists an impossibility result, in which case we can just abandon the entire inquiry. Proof of stake's impossible. And then, once you've gotten past that threshold, it goes from theory to practicality. What actual network conditions are you looking at? Are you okay with living with an external clock, or do you want to build time from within? Uh, how are you generating random numbers? Et cetera, et cetera. And every step of the way, each paper, you're solving one particular class of problems. With Prysm, it said, probably shouldn't know ahead of time who Eve is. Uh, you know, you probably shouldn't know who's making those blocks. That should be something you know after the fact. But if you know ahead of time, you can attack them, you can DDoS them, you can cause all kinds of problems.

Lex Fridman 1:05:35 Mm-hmm.

Charles Hoskinson 1:05:35 Okay, so, you know, adaptive security, also we move from an MPC random number generation, which was great, but very heavy and very slow, and you can't scale to large amounts of people, to a VRF based system, which is super fast but a little dirtier, 'cause Al Grant actually did some great work there.

Lex Fridman 1:05:52 W-

Charles Hoskinson 1:05:52 There was some good knowledge there.

Lex Fridman 1:05:53 What are the really hard problems that you... Maybe if you just linger on-

Charles Hoskinson 1:05:56 Sure.

Lex Fridman 1:05:56 ... a little bit, what are some of the really hard problems you had to solve along this chain of papers, ideas, the evolution of the consensus algorithm?

Charles Hoskinson 1:06:03 Yeah, it's-

Lex Fridman 1:06:03 Mm-hmm.

Charles Hoskinson 1:06:03 Not only are they really hard problems, they actually require different cryptographers, because you're moving from mathematician style cryptographers, like the Neal Koblitzes and the Adi Shamirs, you know, the people that, like, start as proper mathematicians and they really love theory, and that's their thing, and the proofs are dense and they're thick and they're beautiful, to practical applied work, where you're saying, "Okay, now this is something an engineer can look at and say, 'I know how to build that.'"

Lex Fridman 1:06:28 Mm-hmm.

Charles Hoskinson 1:06:28 "I know how to think about that." So, uh, that transition from GKL to Ouroboros Classic to Proust, the, the, the... I'd say the biggest leap was Classic to Proust, because that was going from a system that would only work in a consortium chain, like Fabric...

Lex Fridman 1:06:43 Mm-hmm.

Charles Hoskinson 1:06:43 ... to a system that would actually work, and is working. That's what's implementing Cardano today, you know, $50 billion cryptocurrency and all these people. That was a huge leap. But that paper alone wasn't enough. We also had to layer on the economic model.... because we said, "Well, hang on a second here, not everybody's gonna be online all the time to, to be available to make a block, so you need some notion of delegation. The minute you have a notion of delegation, (laughs) you have these stake pools. What the hell does that mean?" I- and so this is a beautiful kind of interdisciplinary notion that layers computer science and biology together. And minute that complexity starts going up, you start seeing cell specialization. So you go from single cell organisms to organisms where you, you know, have eyeballs and brains and hearts, and each of these tissues do different things. Well, analogously, complex distributed systems start getting specialization. You move from the single celled thing, Bitcoin, where everything's a full node, they all have the same rights and responsibilities, a lot of homogeneity in that system, but you're only as good as your weakest link. You're only as, you're only as capable as whatever the basic cell can do, to a specialized system where you start having these actors in the system that are actually a little different than the other actors. So you introduce this concept of the stake pool, and suddenly now you have this actor where you're probably gonna be online 24/7. You're probably gonna have extra relay infrastructure. There's a, a trust relationship where you don't own the ADA, but you have a right to use it for something, and a person's made that choice to endow you with that. The minute that you introduce specialization though, the system gets more complicated, the game theory gets more complicated, and then you start having to think really deeply and carefully about, "Okay, well, can this now introduce a new attack vector that we didn't have before?"

Lex Fridman 1:08:22 Mm-hmm.

Charles Hoskinson 1:08:22 So that leap from Classic to Prowse and adding in stake pools and figuring out how to handle the game theory there was exceedingly hard. It took two years to do that.

Lex Fridman 1:08:30 So stake pools allows for multiple parties to delegate their staking capabilities to others. Can you describe a little bit how this works?

Charles Hoskinson 1:08:38 Oh, it's-

Lex Fridman 1:08:38 'Cause it's kind of fascinating.

Charles Hoskinson 1:08:39 ... it's, it's a super simple concept. So you register a pool, and then the pool is there and they're, uh, basically they advertise and they're actually registered on chain with a certificate, and then in the wallet software itself, you can see all of the pools that have registered. There's over 3,000 of them now inside the system, and you can click a little tile and it shows you all the metadata that's in their certificate, and says, "Hey, I, you know, I, I have my own pool, it's called Rats." (laughs) You know, King, King of the Rats. Uh, so you can see all the stuff that's described there, and pools have an operating fee 'cause they're like a business, and they say, "Well, if you delegate to me, uh, I'll charge this much. So if you get like, uh, you know, $100 in rewards, I'll give you, you know, 90 and I'll take 10," or something like that. Uh, and then you make your decision, and whichever one you select, you click, you know, Delegate, you push the button, and then you have now given your staking rights to them until revoked.

Lex Fridman 1:09:29 Mm-hmm.

Charles Hoskinson 1:09:29 Okay? So it lives there. And then, uh, the stake pool's weight in the system is proportional to the amount of stake that they have delegated to them, and then we have this other limiting factor, K, which says that you get diminishing returns with the more stake you have. So it's kind of like an S function.

Lex Fridman 1:09:44 Mm-hmm.

Charles Hoskinson 1:09:44 So you kind of go up and up and then eventually caps, and then at some point you get no rewards beyond a certain threshold. So there's an incentive to split pools to different owners after some point.

Lex Fridman 1:09:53 Interesting.

Charles Hoskinson 1:09:54 Yeah. And so, so that's a complex thing, and you have to actually model the game theory out to understand where those parameters should be set. And we didn't know how to do that, so what we did-

Lex Fridman 1:10:03 Mm-hmm.

Charles Hoskinson 1:10:03 ... is we, we bought talent. We went to Oxford and we hired this guy named Elias Kasoupis who's an algorithmic game theorist, and we said, "Hey, would you like to do some game theory work in crypto?" And he's like, "That sounds fun." So he spent a year and a half, we built all these beautiful models, and we kind of figured out what those curves needed to look like.

Lex Fridman 1:10:18 So figure out like the S curve that would result in a nice distribution-

Charles Hoskinson 1:10:21 Exactly.

Lex Fridman 1:10:22 ... of responsibility. So not everybody, uh, delegates to the King of the Rats.

Charles Hoskinson 1:10:26 Ex- exactly.

Lex Fridman 1:10:26 How does it feel to be royalty, by the way?

Charles Hoskinson 1:10:28 (laughs)

Lex Fridman 1:10:29 (laughs) It's not a very impressive kingdom, but, uh, you're nevertheless a king.

Charles Hoskinson 1:10:33 I'll take it, 'cause I think it's the kindest thing people call me in this space.

Lex Fridman 1:10:37 Oh, yeah. People love you. So, okay, so that, th- I mean, so, so is that, would you say, a solved problem, the game theory of stake pools?

Charles Hoskinson 1:10:45 No. It's, um, the starting, and then I was getting back to my original point that you build things in iterations. Every step, i- if you've done it right, is an invitation for 10 more sexy, fascinating, fun problems, and this is why we have such a great time building labs. You know, we started in Edinburgh, now we're at Tokyo Tech and University of Wyoming and Athens, and