Ethereum Basics (Vitalik Buterin) | AI Podcast Clips

So then what is the origin story? Maybe the human side, but also the technical side of Ethereum.

Sure. So I joined the bitcoin community in 2011, and I started by just writing. I first wrote for this sort of online thing called Bitcoin Weekly. Then I started writing for Bitcoin magazine and.

Sorry to interrupt. You have this funny kind of story, true or not, is that you were disillusioned by the downsides of centralized control. From your experience with wow, World of Warcraft. Is this true or you're just being witty?

I mean, the event is true. The fact that that's the reason I do decentralization is witty.

Maybe just a small tangent. Have you always had a skepticism of centralized control?

Is that to some degree? Yeah.

Has that feeling evolved over time or has that just always been a core feeling that decentralized control is the future of human society?

It's definitely been something that felt very attractive to me ever since I could have learned that such a thing is possible, even technically.

So. Great. So you were. You joined the bitcoin community in 2011. You said you began writing. So what's next?

Started writing, moved from high school to university, halfway in between that and spent a year in university. Then at the end of that year, I dropped out to do bitcoin things full time. And this was a combination of continuing to write Bitcoin magazine, but also increasingly work on software projects. And I traveled around the world for about six months and just going to different bitcoin communities like I went to first in New Hampshire, then Spain, other European places, Israel, then San Francisco. And along the way, and I've met a lot of other people that are working on different bitcoin projects. And when I was in Israel, there were some very smart teams there that were working on ideas that people were starting to kind of call Bitcoin 2.0. So one of these was covered coins, which is basically saying that, hey, let's not just use the blockchain for bitcoin, but let's also kind of issue other kinds of assets on it. And then there was a protocol called mastercoin that supported issuing assets, but also supported many other things like financial contracts, like domain name registration, and a lot of different things together. And I spent some time working with these teams, and I quickly kind of realized that this Master Coin protocol could be improved by kind of generalizing it more. Right. So the analogy I use is that the Master Coin protocol was like this Swiss army knife. You have 25 different transaction types for 25 different applications. But what I realized is that you could replace a bunch of them with things that are more general purpose. So one of them was that you could replace three transaction types for three types of financial contracts with a generic transaction type for a financial contract that just lets you specify a mathematical formula for kind of how much money each side gets.

By the way, just small pause. What's you say financial contract. Just the terminology. What is a contract? What's a financial contract?

So this is just generally an agreement where kind of either one or two parties kind of put collateral kind of in and then they depending on kind of certain conditions like this could involve prices of assets, this could involve the actions of the two parties, it could involve other things, they kind of get different amounts of assets out that just depend on things that happened.

So a contract is really a financial contract is at the core, it's the core interactive element of a financial system.

Yeah, there's many different kinds of financial contracts. There's things like options where you kind of give someone the right to buy a thing that you have for some specific price for some period of time. There's a contract for difference where you basically are kind of making a bet that says like for every dollar this thing goes up, I'll give you $7. Or for every dollar the thing goes down, you give me $7. Or something like that.

But the main idea that these contracts have to be enforced and trusted.

Yes, exactly.

You have to trust that they will work out in a system where nobody can be trusted.

Yes.

This is such a beautiful, complicated system. Okay, so you were seeking to kind of generalize this basic framework of contracts. So what does that entail? So what technically are the steps to creating Ethereum?

Sure. So I guess just to kind of continue a bit with this Master Coin story. So started by giving ideas for how to generalize the thing and eventually this turned into a much more fully fledged proposal that just says, hey, how about you scrap all your features and instead you just put in this programming language? And I gave this idea to them and their response was something like, hey, this is great, but this seems complicated and this seems like something that we're not going to be able to put onto our roadmap for a while. And my response to this was like, wait, do you not realize how revolutionary this is? Well, I'll just go do it myself. And then I.

What was the name of the programming language?

I just called it Ultimate Scripting.

Great.

So then I kind of went through a couple more rounds of iteration and then the idea for Ethereum itself started to form. And the idea here is that you just have a blockchain where the core unit of the thing is what we call contracts. It's these kind of accounts that can hold assets and have their own internal memory, but that are controlled by a piece of code. And so if I send some ether to a contract, the only thing that can determine where that kind of ether, the currency inside Ethereum, goes after that is the code of that contract itself. And so basically kind of sending assets to computer programs becomes this kind of paradigm for creating these sort of self executing agreements.

Self. Executing. It's so cool. That code is sort of part of this contract. So that's what's meant by smart contracts.

Yeah.

So how hard was it to build this kind of thing?

Harder than expected. And originally I actually thought that this would be a thing that I would kind of casually work on for a couple of months, publish, and then go back to university. Then I released it and a bunch of people, or I released the white paper.

The white paper. The idea is there.

The idea, the white paper. A whole bunch of people came in offering to help a huge number of people and have expressed interest. And this was something I was totally not expecting. And then I kind of realized that this would be something that's kind of much bigger than I had ever thought that it would be. And then we started on this kind of much longer development slog of making something that lives up to this sort of much higher level of expectations.

What are the. Some of the. Is it fundamentally like software engineering challenges?

It was there social.

Okay, so there's social. So what are the biggest interesting challenges that you've learned about human civilization and software engineering through this process?

So I guess one of the challenges for me is that I'm one of the kind of apparently unusual geeks who is never treated with anything but kindness in school. And so when I got into crypto, I kind of expected everyone would just kind of be the same, kind of altruistic and nice in that same way. But the algorithm that I used for finding co founders for this thing was not very good. It was literally what computer scientists call the greedy algorithm. It's the first 15 people who applied back offering to help kind of are the co founders.

Oh, you mean like literally the people that will form to be the founders? Co founders of the community. The algorithm. I like how you call it the algorithm.

Yeah. And so what happened was that these like, especially as the projects got really big, like there started to be a lot of this kind of infighting and there were A lot of like I wanted the thing to be a nonprofit and some of them wanted to be a for profit. Um, and then there started to be people who were just kind of totally unable to work with each other. There were people that were kind of trying to get an advantage for themselves in a lot of different ways. And this just about six months later led to this big governance crisis. And then we kind of reshuffled leadership a bit and then the project kept on going. Then nine months later there was another governance crisis and then there was a third governance crisis.

And so is there a way to, if you're looking at the human side of things, is there a way to optimize this aspect of the cryptocurrency world? It seems that there is from my perspective. There's a lot of different characters and personalities and egos and like you said, I don't know if you know. I also like to think that most of the world, most of the people in the world are well intentioned, but the way those intentions are realized may perhaps come off as, yeah, as, as negative. Like what is there, is there a hopeful message here about creating a governance structure for cryptocurrency that where everyone gets along?

And after about four rounds of reshuffling, I think we've actually come up with something that seems to be pretty stable and happy. I think, I mean I definitely do think that most people are well intentioned. I just think that like one of the reasons why I like decentralization is just because there's like this thing about power where power attracts people with egos and so that just allows us very small percentage of people to just ruin so many things.

You think ego has a, you think ego has a use? Like is ego always bad? It seems like it sometimes does.

Within the Ethereum research team, I feel like we've found also a lot of very good people that are just primarily just interested in things for the technology and things seem to just generally be going quite well.

Yeah, when you're, when the focus and the passion is in the tech. So that's the human side of things, the technology side. Like, what have you learned? What have been the biggest challenges of bringing Ethereum to life on the technology side?

So I think first of all just, you know, there's like the first law of software development which is that when someone gives you a timetable, switch the unit of time to the next largest unit of time and add one. And we basically fell victim to that and so forth. Instead of taking three months, it ended up taking 20 months. To launch the thing that was just, I think, underestimating the sheer technical complexity of the thing. There are research challenges. So, for example, one of the things that we've been saying from the start that we would do one is a switch from proof of work to proof of stake, where proof of stake is this alternative consensus mechanism where instead of having to waste a lot of computing power on solving these mathematical puzzles that don't mean anything, you kind of prove that you have access to coins inside of the system and this gives you some level of participation in the consensus.

Can you maybe elaborate on that a little bit? I understand the idea of proof of work. I know that a lot of people say that the idea of proof of stake is really appealing. Can you maybe linger on it longer, explain what it is?

Sure. So basically the idea is if I kind of lock up 100 coins, then I turn that into a kind of quote, virtual miner. And the system itself kind of automatically and randomly assigns that in a virtual miner the right to create blocks at particular intervals. And then if someone else has 200 coins and they walk on the walk, there's 200 coins, then they get a kind of twice as big virtual miner. They'll be able to create blocks twice as often. So it tries to do similar things to proof of work, except instead of the thing rate limiting your participation being your ability to crank out solutions to hash challenges, the thing that really limits your participation is how much coins you're locking into this mechanism.

Okay, so interesting. So that that limited participation doesn't require you to run a lot of compute. Does that mean that the richer you are? So rich people are more like their identity is more Right.

And this stable. Yeah.

Verifiable or whatever. Whatever the right terminology is.

Right. And this is definitely a common critique. I think my usual answer to this is that like proof of work is even more of that kind of system.

Yes, exactly. I didn't mean it in that statement as a criticism. I think you're exactly right. That's equivalent that proof of work is the same kind of thing, but in the proof of work you have to also use physical resources.

Yes. And burn computers and burn trees and all of that stuff.

Is there a way to mess with the system over the proof of stake?

There is, but you will once again need to have a very large portion of all the coins that are locked in the system to do anything bad. Got it.

So yeah. And just to that, maybe take a small tangent. One of the criticisms of cryptocurrency is the fact that I guess for the Proof of work mechanism, you have to use so much energy in the world.

Yes.

Is one of the motivations of Proof of Stake is to move away from this?

Definitely.

What's your sense of the. Maybe I'm just under informed. Is there legitimately environmental impact from this?

Yeah. So the latest thing was that Bitcoin consumed as much energy as the country of Austria or something like that. And then Ethereum is like right now, maybe only like half an order of magnitude smaller than Bitcoin.

I've heard you Talk about Ethereum 2.0. So what's the dream of Ethereum 2.0? What's the status of Proof of Stake as the mechanism that Ethereum moves towards? And also, how do you move to a different mechanism of consensus within a cryptocurrency?

So Ethereum 2.0 is a collection of major upgrades that we've wanted to do to Ethereum for quite some time. The two big ones, one is Proof of Stake and the other is we call Sharding. Sharding solves another problem with blockchains, which is scalability. And what Sharding does is it basically says instead of every participant in the network having to personally download and verify every transaction, every participant in the network only downloads and verifies a small portion of transactions. And then you kind of randomly distribute who gets how much work. And because of how the distribution is random, it still has the property that you need a large portion of the entire network to corrupt what's going on inside of any shard, but the system is still very redundant and very secure.

That's brilliant. How hard is that to implement and how hard is Proof of Stake to implement? Like on a technical level?

Yeah, software level, Proof of Stake and Sharding are both challenging. I'd say sharding is a bit more challenging. The reason is that Proof of Stake is kind of just a change to how the consensus layer works. Sharding does both that, but it's also a change to the networking layer. The reason is that Sharding is kind of pointless if at the networking layer you still do what you do today, which is you kind of gossip everything, which means that if someone publishes something, every other node in the client hears it on the networking layer. And so instead we have to have kind of subnetworks and the ability to quickly switch between subnetworks and have the sub networks talk to each other. And this is all doable, but it's a more complex architecture and it's definitely the sort of thing that has not yet been done in cryptocurrency.

So most of the networking layer in cryptocurrency is you're shouting, you're like broadcast messages and this is more like ad hoc networks.

Like yeah, you're shouting within smaller groups.

Smaller group. But do you have like a bunch of subnet like.

Exactly.

And you have to switch between. Oh man, I'd love to see the. So it's a beautiful idea. So from a graph theoretical perspective, but just the software of that, like who's responsible? Is the Ethereum project? Like the people involved, would they be implementing. What's the actual. This is like legit software engineering. How does that work? How do people collaborate, build that kind of project? Is this like almost like, is there a software engineering lead? Is it a legit, almost like large scale open source project?

There is, yeah. So we have someone named Danny Ryan on our team who has just been brilliant and great all around and he is a kind of de facto kind of development coordinator. I guess you have to invent job titles for this stuff, right? The reason is that we also have this unique kind of organizational structure where the Ethereum foundation itself kind of does research in house, but then the actual implementation is done by independent teams that are separate companies and they're located all around the world and fun places like Australia. And so you kind of just need a bunch of almost non stop cat herding to just keep getting these people to talk to each other and kind of implement the spec, make sure that everyone agrees on what's going on and kind of how to interpret different things.

So how far into the future are we from these two mechanisms in Ethereum 2.0? What's your sense of the timeline? Keeping in mind the previous comment you made about the sort of general curse of software projects.

So Ethereum 2.0 is split into three phases. So phase zero just creates a proof of stake network and it's actually separate from the proof of work network at the beginning just to kind of give it time to grow and improve itself.

Do people get to choose? Sorry to interrupt. Do people get to choose?

I guess which they get to choose to move over if they want to. Then phase one adds sharding, but it only adds sharding of data storage and not sharding of computation. And then after that there is the merger phase, which is where the account kind of smart contracts. All of the activity on the existing Eth1 system just kind of gets cut and pasted into Eth2 and then the proof of work chain gets forgotten and then. And all the Things that were living there before just kind of continue living inside of the proof of stake system. So for timelines, phase zero has been almost fully implemented and now it's just a matter of a whole bunch of security auditing and testing. My own experience is that right now it feels like we're at about a phase comparable to when we were doing the original Ethereum launch, when we were maybe about four months away from launch.

But that's just a hunch.

That's just a hunch, yeah.

So how it took over a decade for people to move from Python 2 to Python 3. How do you see the move from this phase zero for different consensus mechanism? Do you see there being a drastic phase shift in people just kind of jumping to this better mechanism?

So in phase zero, don't expect too many people to do much, because in phase zero and phase one, the new chain deliberately doesn't have too much functionality turned on. It's there. Just like if you want to be a proof of stake validator, you can get things started. If you want to store data for other blockchain applications, you can get started, but existing applications will largely keep living on eth1. And then when the merger happens, then the merger is an operation that happens all at once. So that's one of the benefits of Akinsanza system, that on the one hand you have to coordinate the upgrade, but on the other hand the upgrade can be coordinated.

So what's Casper FFG, by the way?

CasperFG is the consensus algorithm that we are using for the proof of stake.

Is there something interesting specific about Casper ffg, like some beautiful aspect of it that's.

There is. So Casper FFG combines together kind of two different schools of algorithm design. So the general two different schools of the design are right. One is 50% fault tolerant, but dependent on network synchrony. So. So 50% fault tolerant, but you can tolerate up to 50% of faults, but not more. But it depends on an assumption that all of the nodes can talk to each other within some limited period of time. Like if I send a message, you'll receive it within a few seconds. And the second school is 33% fault tolerant, but safe under asynchrony, which means that if we agree on something, then that thing is finalized, and even if the network goes horribly wonky the second after that thing is finalized, there's no way to revert that thing.

And that's fascinating how you would make that happen.

It's definitely quite clever. I'd recommend the Casper FFG paper if you Just search archive, as in arXiv, Casper, FFG.

That's an archive. The paper is an archive.

Yeah.

Who are the authors?

Myself and Virgil Griffith.

That's awesome. Take a small tangent. This idea of just putting out white papers and papers and putting them on archive and just putting them publicly, is that at the core, is that a necessary component of cryptocurrency? Is that the tradition started with Satoshi Nakamoto? What do you make of it? What do you make of the future of that kind of sharing of ideas?

I guess so, yeah. And it's definitely something that's kind of mandatory for crypto, because crypto is all about making systems where you don't have to trust the operators to trust that the thing works. And so if anything behind our system works is closed source, then that kind of kills the point. And so there is the kind of a sense in which the fundamental properties of the category of the thing we're trying to build just kind of forces, openness. But also openness just has proven to be a really great way to collaborate. And there's actually a lot of innovation and academic collaboration that's just kind of happened ad hoc in the crypto space the last few years. So, like, for example, we have this forum called ETH Research that's like ETH R E S E A R. And then ch and there we publish kind of just ideas in a forum that's kind of half formal, like it's halfway in between.