Ethereum in 25 Minutes

Transcript

[Music] [Beep] [Applause] Oh, let me check. This one, okay, let me try this. What? What's happening to it? [Inaudible] No, it's just coming slowly.

How do I go back? Oh, up, up. Yes. Okay, great. Thank you. So I heard people in the audience complaining on WeChat about them being too quiet, so I'm going to try to keep it closer to my mouth this time around. We'll see if it works. Great. So this is one of the standard presentations I give when people want a quick overview of the entire Ethereum protocol. So chances are you'll listen through this. You'll catch some things. You won't catch other things. But at the very least, you'll kind of understand what the broad structure is.

And if there's any particular piece that you don't fully understand, we have quite a few materials online that can tell you about the rest. So we have our GitHub Wiki, the website. If you are a developer, you can even read things like the yellow paper and see Ethereum source code. If you want to get that deep and understanding as of sort of how the Ethereum protocol works, I highly recommend doing those things. If you have specific questions, I also highly recommend even going into some of our public channels. So if you go to like Gitter.im, G-I-T-C-E-R.im/Atheorem, for example, you can actually like literally just talk to our developers and they're like right there.

And you can ask questions. We're generally a fairly friendly community, I hope. So anyway, Ethereum in 25 minutes. So first of all, how did the project start? So project started back in 2013. At the time, people were very interested in blockchains. People were looking at Bitcoin. People were excited about Bitcoin. But people were also realizing that blockchains are useful for things other than just money. So back in 2011, there was a project called Namecoin, which was trying to make a blockchain based domain name system.

In 2013, there were projects called Colored Coins, which were trying to like digitize arbitrary digital assets or arbitrary assets and put them on the blockchain. There were protocols called Mastercoin that were trying to integrate all sorts of fairly complex features. So there was a consensus that you can do lots of different really cool things with Bitcoin or with other blockchains. Asset issuance, crowdfunding, title registration, lots and lots of stuff. Problem is, most blockchain protocols were designed like this. Pocket calculator, single purpose device, works reasonably well for all you care about, is adding in multiple numbers, but it does nothing else.

Ensure someone with a computer with an advanced computer science degree with a good calculator can kind of hack it to play a video game inside of it. But do you really want to do that? So after this, in 2013, there were people who were making protocols that looked like this. So Swiss Army Knife. Basically, you come up with a list of 10 or 20 features he wants to have, make a little tiny thing for each one of them, stick them together into a knife, and there you go, that's your product. Or in this case, you know, that's your blockchain. So back at the end of 2013, there were lots of projects that looked like this.

They just said, okay, you know, we want blockchains to be responsible for asset issuance, crowdfunding, bets, prediction markets, identity registration, title registration, pick a list of 20 different things, have a list of 20 different transaction types, and have a little piece of the protocol that supports each one. So this is all well and good. Problem is, what if you come up with your list of 20 applications, publish your protocol, then the next day some guy says, oh, look, I discovered a 21st blockchain application. How am I going to fit it in? In 2013, this is exactly what started to happen.

So this is the Ethereum way. [laughter] [applause] So why do we love smartphones so much? Basically because a smartphone is nice and generic. You buy it once and immediately comes with 50 or 100 applications. If someone comes up with a new application, they write the code, they upload it to the Google Play Store, and if you want it to be accessible in China, you can upload it to the Huawei store as well.

And then if anyone wants to use your application, they don't need to buy a new phone, they don't need to buy a new hardware dongle, you just download the app and they can start immediately running it. Very simple. And the cost of actually developing an application, all you have to do is write code. You don't have to make your own hardware, you don't have to have your own manufacturing, you don't have to have your own distribution. Just write a piece of code, upload it, and let people download it, and you're done. So this is the kind of abstraction and simplicity that I wanted to bring to the blockchain world with Ethereum. So Ethereum is a blockchain.

I'm sure if people here are familiar with blocks, I'm sure people here are familiar with transactions. And these are all well and good, but Bitcoin has them too. Namecoin has them too, Litecoin has them too, Dogecoin has them. I'm not sure if Bitcoin has blocks though. I don't know, Bitcoin might even run out of the server, I haven't even checked. Proof of server, the best kind of POS. But we have a few tiny additions. So the main thing that makes Ethereum tick is this built-in programming language.

So basic concept is if you have some new kind of application, what you would do is you would write the rules of your application in a piece of code, take this piece of code, you would call this a contract, upload it to the blockchain, and now you have a special type of account, and this type of account sits on the blockchain and anyone can send a transaction to this account in order to interact with this account. So two types of account. One type of account is a user account, controlled by people like you, and the other type of account is a contract which is controlled by a piece of code.

If you send one unit of Ether to an account that is controlled by code, then no person controls it anymore. The only thing that can actually move that Ether is the execution of that contract's code itself. So it basically is an automaton sitting on the blockchain that's executing exactly as the code on the blockchain says it's going to execute. So this is all well and good. Let's try an example. So the hello world of Ethereum is sort of basic, a minimal sort of DNS system.

So the idea here is you want to store a mapping of basically domains. So you have something like, I don't know, Vitalik.eth, George.eth, Ethereum.eth. Ask me about my cool Ethereum hacking services.eth. So you have a bunch of domains that people might want to register. And for each one, you want to store the IP address that it points to, and you want to store who owns that domain at that particular time. So we have two functions.

One of them is for registering a domain, and the logic is pretty obvious. If the domain has not yet been registered, then you set the owner to yourself. And another function that says set the IP address. If you own the domain, then you can set the IP address. And this is like the basically the minimal thing that's like all you need in order to have a maximally simple domain name system. Now, as I understand, Nick Johnson is going to be presenting about a much more complete and better one at some point over the next three days. But this is sort of the kernel. This is what you start with. So you have this piece of code. Then what you would do is you would compile it.

You would get some byte code. Then include the code in a transaction. Push the transaction up onto the blockchain. Now what you have created is a contract. And a contract has an address. It has some 20 byte string that represents sort of the location of the contract. And look like 0x357c, whatever. If you want to register a domain, what you would do is you would send a transaction and you would specify this transaction is going to be talking to this contract. Now, what can the transaction do? Well, it can do.

It can try to register or it can try to set the IP address. So let's say you want to register a domain. What you would do is you, in the transaction, you would encode some information that says, I want to call the register function and I want to call the register function with some particular piece of data. Like, I don't know, George.eth or whatever. Take this transaction and include this data. Publish the transaction. When the transaction gets included, the code runs. And you notice it says self.domains address.owner=msq.center. So what that line of code basically does is it says, whatever address sent that transaction, record that address in the contract's storage as the owner of that particular domain.

So you notice at the top of the contract here, it says, like, data domain. So it basically stores a mapping going from a domain to the owner and the IP address of each domain. So the code and the storage, like both of these things are what we call sort of part of the Ethereum state. So what we mean by the state is sort of current information associated with the Ethereum protocol. So stuff that you have to care about right now. This includes account balances, how much ether you have, a non-sis, it includes contract code, and it includes contract storage.

So for example, right now, this piece of code is nowhere in the state. If I send a transaction, publish a transaction which creates the contract, the contract's code is now in the state. Now, if I send another transaction which then talks to this contract and registers a domain, then the process of executing that transaction is going to change the state. And the new state is going to contain some storage key as the basic we say this particular domain has some particular owner and some particular IP address. So that's kind of what the state means. So it's stuff that you have to kind of care about now.

So in Bitcoin, for example, the state is pretty simple. It's just like how much money everyone has at some particular point in time. The second thing is history. So history is things that happened. So transactions are part of the history, receipts are part of the history. Don't have time to go into them, but feel free to research them more. So this is kind of important because a lot of people ask things like, "Oh, you know, who stores the transactions or if a contract executes then who executes the contract, where are the results stored?" And the answer at this point basically is that if you are a full node, then as a full node, what you do is, number one, you download all the blocks, you download all the transactions.

When you receive a block, what you would do is you would see what the state was before the block, then you would execute all the transactions in turn, and you would update your own state. So all full nodes basically execute all transactions, they would execute all contracts, and full nodes, some of them store the history, some of them don't store the history. So there are clients that are increasingly coming out that let you sort of not store large portions of the history, and this is good because it saves you hard drive space. So the state in Ethereum consists of basically a key value mapping.

So basically the state in Ethereum is like a bunch of account objects. And account objects, once again, two types of accounts. One of them is just an account controlled by a person, or some external user controlled by a fridge, controlled by a dog, the other kind of account is a piece of account controlled by code. So these accounts have four pieces of data. One of them is the nonce, and that's basically just a kind of highly technical thing that's used to prevent transaction replay attacks. Second thing is a balance, so how much Ether the account has. Third thing is the code.

And the fourth thing is storage tree root, which basically points to kind of the storage of that particular contract. So every contract has its own kind of sub database that it can kind of read and write to as it wishes. Now contracts cannot write to other contract storage databases. So a contract storage kind of is its own property. The contract, only the contract can actually read and write to storage that it belongs to itself. So also important. So code execution, every transaction specifies a two address. Now if the two addresses just sum regular account that doesn't have code, then all you're doing is moving Ether around.

If the two address actually has code, then the code runs, and the code can do things. So the code can send Ether from that contract to other contracts. The code can read the contract storage, the code can write to the contract storage, and contracts can even talk to other contracts. So once again, every full node processes every transaction, every full node stores the entire state. And this is actually fairly similar to how Bitcoin works. It's bold because it's important. As Vlad likes to say in the previous DevCon.

So gas. This is another one of those sort of important misconception points. So basically one of the problems with a kind of extremely free and Turing complete scripting engine is the halting problem. And the halting problem basically says, given a particular program, if you start running it, there is absolutely no sort of data. There is no guaranteed way to tell in advance whether or not the program is ever even going to stop. So you might have program A, which does a few things on the stops. Program B, which is an infinite loop.

Program C, which is some kind of highly disguised infinite loop. And you can basically come up with programs where there is no sort of automated mechanism that can tell which programs are infinite loops and which of them are just going to halt after a billion steps. So what we do in Ethereum is we have this concept of gas. And the idea basically is that when code executes, we count the number of computational steps that the code takes. And every transaction assigns itself a budget. So a transaction might say this transaction is allowed to consume a maximum of one million gas. So what does that mean?

So let's say this transaction goes to some contract. The code starts running. And one of two things can happen. One of them is before the million steps run out, execution stops. In that case, everything is fine. Second case is it gets to a million computational steps. Then you get what's called an out of gas error. Oh, look, this transaction budgeted a million steps, but it already took up a million steps and it looks like it's going to execute some more. It might even run forever. I have no idea. So what I'm going to do instead is we're just going to halt execution right there and just revert the whole thing and the transactions essentially failed. Now, for some technical reasons, even if your transaction fails, for this reason, you still have to pay the transaction fee for it.

But this is the point of this mechanism is basically that no matter what kind of weird code you have in the transaction, it's guaranteed that nodes will be able to process it within some deterministic way within some fixed amount of time. Now, there are other blockchain projects that try to solve the problem with timeouts, so they say try executing the code for one second and if after one second it's still running, then you halt. The problem with this approach is that it's not deterministic. So one computer might take 0.9992 seconds to run a particular piece of code. Another computer might take 1.008 seconds to run a piece of code.

And if the two disagree with each other, then your blockchain has a fork. Gas completely deterministic, a computational resource control. So another important thing is that for every transaction, you have to pay a transaction fee for each unit of gas that you consume. So heavier computations cost more. But one important point is that these two things are separate. So there is the notion of gas, and the notion of gas is basically just a deterministic method of metering computational resources. And then separately from that, there is protocol economics, and the rules of protocol economics say that if you want your transaction to be included, you have to pay for it.

And so if you want to send a transaction to the Ethereum public chain, you have to pay for each unit of gas. If you are doing some kind of Ethereum-based private network, you do not need to have ether. So just one important thing that lots of people get wrong that would be good for people to remember. So gas limit, so the equivalence of the block size limit in Bitcoin is the gas limit in Ethereum, 4.7 million gas per block. Now gas isn't just about counter-computational steps. You also get charged gas for writing to the state, reading from the state, a bytes in your transaction, bytes that you add into receipts, bloom filter topics. So you get charged gas for almost every resource that you can consume inside of Ethereum.

And out of all of those things together, there is a limit that you can't consume more than 4.7 million. So the gas limit actually does adjust automatically, and miners can't vote on it. So if Ethereum blocks start getting full, then basically miners are going to be able to just vote the gas limit up, and what no one needs to download any new software. Transactions, 7 parameters, nonce, so basically prevents replay attacks. So for example, if I send you 10 units of ether, then what stops you from taking my transaction, and just including it in a block 10 times to try and drain 10 ether from my account over and over again. The answer is every transaction has to include a unique number, and if once a transaction is of a particular nonsense processed, the nonsense in the state goes up.

And if it tries to verify the second transaction, well, the nonsense mismatches now, and so the second time around, you can't include it anymore. Gas price, so the amount of e3 you pay for every gas, start gas, that's what the amount of gas that you budget yourself, destination address, amount of ether that you send, data. So if you're just sending e3, you don't need to care about data, if you're talking to a contract, then data is readable by contract code. So data is how you specify what function of a contract you're calling, what parameters you're calling it with, anything sort of more complex about that. And VRS, elliptic curve digital signatures, feel free to research them yourself, I think elliptic curve math is cool.

Receipts not going to bother with those. So Ethereum Virtual Machine, we have a stack, we have a concept of memory, storage, environment variables, so contracts have access to things like the timestamp. And this is great because you can have contracts that say, if the time is greater than, you know, something like January 1st, 2018, then do something. And there's lots of wonderful use cases for this, logs, contracts, calling other contracts. Now in general, if you're a contract writer, you're not going to be writing in like, Ethereum Virtual Machine Code directly. You're going to be writing in higher level languages, so Solidity is the most well supported one right now.

You can also write code in serpent, there's also something called LLL. So there are kind of other languages that you can write your code in. And then the idea is you would write your code in these languages and it can plow down to Ethereum code. So the code that you write is like nice and readable, the code that is Ethereum code is like extremely compact, fast to execute, watch in front of them. So, ABI, so this is basically that if, you know, I actually wants to call some contracts, and if I wants to register a domain name, then how am I going to do that? Well, over in the serpent example, you might notice that I might want to do something like call the set IP function with some particular address and with some particular IP address.

So the way that you do, the way that you actually do a call is by sending a transaction. The way that you specify what you're calling is in transaction data, and there exists this nice standardized algorithm, we call the ABI by which you can call the ABI. So you can encode the data. So the first four bytes represent the function ID, then 32 bytes for the first argument, then 32 bytes for the second argument. If you have variable sized arguments, it gets more complex, but feel free to research this. So we have a new mining algorithm, and this mining algorithm strives to be kind of memory hard and GPU friendly. So the goal is to sort of prevent, um, as a six or prevent specialized hardware from like being the dominant force in mining because that would make mining too centralized.

But at the same time, CPU mining has other issues, so we have this sort of GPU mining that's a nice middle ground. It's a fairly pretty algorithm once again. It's called ETH hash. Um, so fast block times, Merkle tree is. So this is also a kind of very important piece of the Ethereum protocol. So the reason why I have this picture here is because about a year ago there was this cover in the New York Times, and basically you have Life Masters that's saying it's all about the blockchain. And personally, I think it's not just about the blockchain, it's about the Merkle tree, and I think Merkle trees are like awesome and really important. So we should have Ralph Merkle saying it's all about the Merkle tree, and you should have some doshas because doshas are cool.

Um, I hope it's not a violation of security as a lot of say that dogecoin is awesome, and if you want to buy it, you can. Cool. So Merkle tree is the point basically is, so this is how the Ethereum Lite client works. So the problem is, okay, if you have the entire database, if you have the entire state, if you have all the transactions, then you can know, let's say what your account balance is, what's some particular contracts code is, what's some particular contract storage is, what's some particular log says. But what if you're a Lite client, what if you're on a phone, what if you're on an IOT device, and you don't have enough resources to process the entire blockchain.

So the blockchain itself right now, the blockchain is three bytes, the sort of state size of something around between like five and twenty bytes depending on which client options you use. So it gets pretty big for a phone. So if let's say you have a tiny device that has like 50 megabytes in very low processing power, then what do you do? So this wonderful fellow came up with this algorithm, where basically what you do is you store this kind of really clever hash tree, where you store the pieces of data at the bottom, then you like have hash tree. And you like have hashes of those, and you have hashes of hashes and hashes of hashes. And the end result is, if let's say all that I care about is getting key for let's say some like this particular key of, you know, this particular account 175, then you don't actually have to download the entire blockchain yourself.

Instead, all you do is you download this, what we call kind of more of this Merkle branch. You verify that the hashes inside of the branch are consistent. And as long as you have the block headers, you just kind of verify the Merkle branch against the block headers. And what you're doing is you're essentially allowing the miners to kind of help you verify that this particular piece of the state actually is what the node says it is. So if you see if a node gives you a Merkle, this sort of Merkle proof that says this particular key in this particular account is 45, if you have, if you can verify the proof of work and you can verify the hashes, then basically you can verify that unless like all the miners or something at that particular time can spiral in a screw you over, this actually is what the state of the blockchain is in this particular place at that time.

So the white client, there was like a test about an alpha version that was released a couple of weeks ago. I've tried it, it works great. So block headers contains three trees. So Bitcoin uses a Merkle tree just for transactions. We use Merkle trees for transactions for the state. So this includes account balances, contract code contract storage, receipts. So we have Patricia trees which allow you to kind of update the tree very efficiently. And so those are kind of the basic building blocks of the Ethereum protocol right now. There's also very fun stuff that we're working on in the future.

So things like proof of stake that I'm going to end the scalability that I'm going to talk about in my presentation later today. Privacy support. So basically with privacy you don't have to actually build things into the base protocol. Because the Ethereum protocol was during complete, you can basically implement any kind of advanced cryptography on top of it. Now for like the efficiency reasons there are still sort of protocol tweaks that we have to make, but even still it's something where like the vast majority of the work actually does sort of happen on the higher levels. Virtual machine upgrades, sort of more flexible use of storage and scalability and these things are great.

And just to set a good example, I'm going to stop now because the clock tells me to stop now. So thank you. [Applause]