 Yes, okay, great, thank you. So I heard people in the audience complaining on WeChat about the mic being too quiet, so I'm gonna try to keep it closer to my mouth this time around. We'll see if it works. Great, so this is one of the sort of standard presentations I give when people want just like 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 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 the Ethereum source code. If you want to get like that deep an 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-T-E-R.im slash Ethereum, 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 Covered 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 adding and multiplying numbers, but it does nothing else. Ensure someone 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, that's your blockchain. So back at the end of 2013, there were lots of projects that looked like this. They just said, okay, we want blockchains to be usable 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 a protocol, then the next day some guy says, oh look, I discovered a 21st blockchain application. How am I gonna fit it in? And in 2013, this is exactly what started to happen. So this is the Ethereum way. So why do we love smartphones so much? Basically because a smartphone is nice and generic. You buy it once, and it 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 one good, but Bitcoin has them too. Namecoin has them too, Litecoin has them too, Dogecoin has them. I'm not sure if Paycoin has blocks though. I don't know, Paycoin might even roll out a 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 so 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 wanna store a mapping of basically domains. So you have something like, I don't know, Vitalik.Eath, George.Eath, Ethereum.Eath. Ask me about my cool Ethereum hacking services.Eath. So you have a bunch of domains that people might wanna register and for each one you wanna store the IP address that it points to and you wanna 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 basically the minimal thing that's like all you need in order to have like a maximally simple domain name system. Now as I understand, Nick Johnson is gonna be presenting about a kind of 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 like some particular piece of data like I don't know, George.Ether whatever. Take this transaction, include this data, publish the transaction, when the transaction gets included the code runs and you notice it says self.domains address.owner equals MSG.Center. So what that line of code basically does is it says whoever, whatever address sent that transaction record that address in the contract 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 some 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, nonces. 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 keys that basically 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, who stores the transactions or if a contract executes and who executes the contract so 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 the 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 like read and write to storage that belongs to itself. So also important. So code execution, every transaction specifies a two address. Now if the two address is just some 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 contracts 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 entering 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 guaranteed way to tell in advance whether or not the program is ever even going to stop. So you might have like program A, which just like does a few things and then stops. Program B, which is an infinite loop. Program C, which is like 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 gonna halt after like 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 what transactions might say, this transaction is allowed to consume a maximum of one million gas. So what does that mean? So let's say that 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 gonna execute some more. It might even run forever, I have no idea. So what I'm gonna do instead is we're just gonna halt execution right there and just revert the whole thing and the transaction's essentially failed. Now, for some technical reasons, even if your transaction kind of fails for this reason, you still have to pay the transaction fee for it. But 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 deterministically 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 like 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 then the two disagree with each other and then your blockchain has a fork. Gas, completely deterministic, resource management, 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 like 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 like 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 kind of good for people to remember. So gas limit. So the equivalent of the block size limit in Bitcoin is kind of 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, bytes in your transaction, bytes that you add into receipts, bloom filter topics. So you get charged gas for kind of almost every resource that you can consume inside of Ethereum. And out of all of those things together there's this limit that you can't consume more than 4.7 million. So the gas limit actually does kind of adjust automatically and miners can vote on it. So if Ethereum blocks start getting full then basically miners are going to be able to kind of just vote the gas limit up and like no one needs to download any new software. Transactions, seven 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 once a transaction with a particular nonce is processed the nonce in the state goes up and if it tries to verify the second transaction well the nonce mismatches now and so the second time around you can't include it anymore. Gas price, so the amount of ether you pay for every gas. Start gas is like the amount of gas that you budget yourself. Destination address, the amount of ether that you send. Data, so if you're just sending ether 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 with that. And VRS, elliptic curve digital signatures. Feel free to research them yourself. I think elliptic curve math is cool. Receipts, not gonna 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, calling 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 gonna 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 us 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, blockchain friendly. So ABI. So this is basically that if, you know, I actually want to call some contracts and if I want to register a domain name, then how am I gonna do that? Well, over in the Serpent example, you might notice that I might want to do something like call the setIP function with some particular address and with some particular IP address. So 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 called the ABI by which 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 ASICs 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. So fast block times, mergle trees. So this is also a kind of very important key some 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 that 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 mergle tree and I think mergle trees are like awesome and really important. So we should have Ralph Merkle saying it's all about the mergle tree and you should have some doges because doges are cool. I hope it's not a violation of security as well to say that Dogecoin is awesome and if you wanna buy it, you can. Cool. So, mergle trees, the point basically is, so this is how the Ethereum light 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 some particular contract's code is, what some particular contract storage is, what some particular lock says. But what if you're a light client? What if you're on a phone? What if you're on an IoT device and you don't have a phone? 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 20 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 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 this particular account 175, then you don't actually have to download the entire blockchain yourself. Instead, all you do is you download what we call kind of this Burkle 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 Burkle 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 a node gives you a sort of Merkle proof that says this particular key and this particular account is 45, 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 are at that particular time to inspiring to screw you over, this actually is what the state of the blockchain is in this particular place at that time. So the light client, there was like a test of 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 Merkle trees 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 a very fun stuff that we're working on in the future. So things like proof of stake that I'm going to end a 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 like implement any kind of advanced cryptography on top of it. Now for like VM 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.