Back to Index

Ethereum Basics (Vitalik Buterin) | AI Podcast Clips


Chapters

0:0 Intro
5:0 What is Smart Contracts
6:51 How hard was it to build Ethereum
11:32 Proof of Stake
12:46 Virtual Miner
15:42 Sharding
18:19 Software Engineering
20:24 Timelines
23:53 Future of sharing ideas
26:34 Ethereum composability

Transcript

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.

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 sort of... 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.

It's possible even technically. So great, so 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, 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. I went to first in New Hampshire, then Spain, other European places, Israel, then San Francisco.

And along the way, 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 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 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, a lot of different things together. And I spent some time working with these teams, and I quickly kind of realized that this MasterCoin protocol could be improved by kind of generalizing it more.

So the analogy I use is that the MasterCoin protocol was like the 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 like 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, a 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, there's many different kinds of financial contracts. Like 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 contracts 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 that 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 MasterCoin story. So started by kind of giving ideas for how to generalize the thing. And eventually this turned into a much more kind of fully fledged proposal that just says, "Hey, how about you scrap all your futures 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 they 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 Ether, the currency inside Ethereum, goes after that is the code of that contract itself.

And so basically you're 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. So how hard was it to build this kind of thing?

Harder than expected. I mean, 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. I released the white paper. A whole bunch of people came in offering to help, a huge number of people have expressed interest. And this was something I was totally not expecting. And then I 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 log of making something that lives up to this much higher level of expectations. What are some of the... Is it fundamentally like software engineering challenges? It was. Is there social? Okay. And 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 was 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 replied back offering to help are the co-founders. Oh, you mean like literally the people that will form to be the co-founders of the community.

The algorithm. I like how you call it the algorithm. And so what happened was that these... Especially as the project got really big, there started to be a lot of this kind of infighting. There were a lot of... Like I wanted the thing to be a non-profit and some of them wanted to be a for-profit.

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. 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... I also like to think that most of the people in the world are well-intentioned, but the way those intentions are realized may perhaps come off as negative.

Is there a hopeful message here about creating a governance structure for cryptocurrency where everyone gets along? 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 one of the reasons why I like decentralization is just because there's this thing about power where power attracts people with egos. And so that just allows a very small percentage of people to just ruin so many things. You think ego has a use? Is ego always bad?

It seems like some of us... 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 the focus and the passion is in the tech.

So that's the human side of things. But the technology side, 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 there's 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. So instead of taking three months, it ended up taking 20 months to launch the thing. And 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 a proof of work to a proof of stake.

More 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 a little longer, explain what it is? Sure. So basically the idea is like, if I kind of lock up a hundred 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 lock and lock those 200 coins, then they get a kind of twice as big virtual miner, they'll be able to create blocks twice as often. And so it tries to do similar things to proof of work, except instead of the thing and rate limiting your participation being your ability to crank out solutions to hash challenges, the thing that really limits your participation is kind of how much coins you're locking into this mechanism.

Okay. So interesting. So 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 identities more stable, verifiable or whatever the right terminology is. Right. And this is definitely a common critique. I think my usual answer to this is that proof of work is even more of that kind of system.

Exactly. I didn't mean it in that statement as a criticism. I think you're exactly right. It's equivalent to 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. Yeah. And just to that, maybe take a small tangent, one of the criticisms of cryptocurrencies, 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 that? Maybe I'm just under informed. Is there like legitimately environmental impact from this? Yeah. I mean, I know 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 a proof of stake and the other is what we call sharding. Sharding solves another problem with blockchains, which is a 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, 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 from on the networking layer.

And so instead, we have to have kind of subnetworks and the ability to quickly switch between subnetworks and other subnetworks, talk to each other. And this is all doable, but it's a more complex architecture. 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 broadcasting messages and this is more like ad hoc networks.

Like yeah, you're shouting within smaller groups, smaller group, but you have like a bunch of subnetworks. Exactly. And you have to switch between. Oh man, I'd love to see that. So it's a beautiful idea from a graph theoretic perspective, but just the software, like who's responsible? Like if this was a theorem project, like the people involved, would they be implementing like what's the actual, you know, this is like legit software engineering.

Who like, 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 there, is it a legit, almost like large scale open source project? There is. 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. It's like you have to invent job titles for this stuff. The reason is that like 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 like fun places like Australia.

And so, you know, you kind of just need a bunch of kind of almost nonstop cat herding to just keep getting these people to kind of talk to each other and kind of implement the spec, make sure that everyone agrees on kind of 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? Like 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 kind of proof of 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? Yes, 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 kind of the merger phase, which is where the accounts and smart contracts, like 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 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 kind of almost fully implemented. Because 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, you know, it took like over a decade for people to move from Python 2 to Python 3.

How do you see the move from like this phase zero for different consensus mechanisms? Do you see there being a drastic phase shift in people just kind of jumping to this better mechanism? So in phase zero, I don't expect too many people to do much because in phase zero and phase one, the new chain, they get it deliberately and it 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 each one. And then when the merger happens, then the merger is a operation that happens all at once.

So that's kind of one of the benefits of a consensus system that like 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? Casper FFG 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 worth mentioning? There is. So Casper FFG combines together kind of two different schools of consensus algorithm design. So the general two different schools of the design are, right? One is a 50% fault tolerant, but dependent on network synchrony.

So 50% fault tolerant, but it 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 the 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. 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 like archive as in like ARXIV and Casper FFG. That's an archive. The paper is an archive. Yeah. Who are the authors? Myself and Virgil Griffith. That's awesome. I'll 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 cryptocurrencies? 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 as closed source, then that kind of kills the point. And so there is 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 then 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 for example, we have this forum called ETH Research, that's like E-T-H-R-E-S-E-A-R and then dot CH. And there we publish just ideas in a form that's kind of half formal, like it's halfway in between.

It's a kind of a text write up and you can have math in it, but it's often much shorter than a paper. And it turns out that the great majority of new ideas, they're just kind of fairly small nuggets that you can explain in like five to 10 lines.

And they don't really need the whole formality of a paper. Exactly. They don't require the kind of like 10 pages of filler. And so introduction and conclusion is not needed. Yeah. And so instead you just kind of publish the idea and then people can go comment on it. That's brilliant.

Yeah, this has been great for us. I think I interrupted you. Was there something else on Casper FFG? No, so Casper FFG is just kind of combines together these two schools. And so basically it creates this system where if you have more than 50% that are honest and you have a network synchrony, then the thing kind of goes as a chain.

But then if network synchrony fails, then kind of the last few blocks in the chain might get replaced, but anything that was finalized by this more asynchronous process can't be reverted. And so you essentially get a kind of best of both worlds between those two models. Okay, so I know what I'm doing to them.

I'm going to be reading the Casper FFG paper. Apologize for the romanticized question, but what to you are some or the most beautiful idea in the world of Ethereum? Just something surprising, something beautiful, something powerful. Yeah, I mean, I think the fact that money can just emerge out of a database if enough people believe in it, I think is definitely one of those things that's up there.

I think one of the things that I really love about Ethereum is also this concept of composability. So this is the idea that if I build an application on top of Ethereum, then you can build an application that talks to my application and you don't even need my permission.

You don't even need to talk to me. So one really fun example of this is there was this game on Ethereum called CryptoKitties, the just involvement of breeding digital cats. And someone else created a game called CryptoDragons, where the way you play CryptoDragons is you have a dragon and you have to feed it CryptoKitties.

And they just created the whole thing just like as an Ethereum contract that you would send these tokens that are defined by this other Ethereum contract. And for the interoperability to happen, like the projects don't really need to, like the teams don't really need to talk to each other.

You just kind of interface with the existing program. So it's arbitrarily composable in this kind of way. So you have different groups that could be working. So you could see it scaling to just outside of dragons and kitties. It could be you build like entire ecosystems of software. Yeah.

And I mean, especially in the decentralized finance space that's been popping up in the last two years, there has been a huge amount of really interesting things happen as a result of this. Is it a particular kind of like financial applications kind of thing? Yeah. I mean, there's like stable coins.

So this is a kind of tokens retain value equal to one dollar, but they're kind of backed by a cryptocurrency. Then there's decentralized exchanges. So as far as decentralized exchanges goes, there's this really interesting construction that has existed for about one and a half years now called Uniswap. So what Uniswap is, it's a smart contract that holds the balances of two tokens.

We'll call them token A and token B. And it maintains an invariance that the balance of token A multiplied by the balance of token B has to equal the same value. And so the way that you trade against the thing is basically like you have this kind of curve, you know, like X times Y equals K.

And before you trade, it's at some points on the curve. And then after you trade, you just like pick some different, any other points on the curve. And then whatever the delta X is, that's the amount of A tokens you provide. Whatever the delta Y is, that's the amount of B tokens you get or vice versa.

And that's just, and then kind of the slope at the current points on the curve kind of is the price. And so that just is the whole thing. And that just allows you to have this exchange for tokens. And even if there's very few participants and the whole thing is just like so simple and it's just very easy to set up, very easy to participate in.

And it just provides so much value to people. And the fundamental, the distributed application infrastructure allows that somehow. Yes. So this is a smart contract meeting. This is all a computer program that's just running on Ethereum. Smart contracts too are just fascinating. They are. you