Ethereum in 25 Minutes, Version MMXVII

okay so this is intended to be a kind of introduction that's as simple as possible while at the same time covering all of the important bits of basically what the etherium protocol actually looks like from a technical standpoint so I'll just kind of dive straight into it and start off with the basically the background which has you know why does the theory of need to exist so back when I came up with the original white paper at the end of 2013 there was already a large amount of interest from the public in blockchain technology and particularly people starting to look at using blockchain technology going beyond what was then just Bitcoin the currency and people were looking at various applications issuing assets on the blockchain crowdfunding domain registration projects like named coin land title registration gambling prediction markets IOT applications healthcare applications many different applications of blockchains that go beyond I have 50 bitcoins I send 20 bitcoins to you you now have 20 bitcoins so the problem is most existing blockchain protocols at the time were designed like this right so what properties does a pocket calculator have it can do one thing and it could do one thing fairly well but that's the only thing that he can do now granted if you have some super fancy TI 80 whatever you can probably try come up with some way to program a video game on top of it but like nobody really wants to do that so in general it just ends up being one tool they can do one thing so problem is what if he wants to do more than one thing well you could buy five different devices for five different purposes but it very quickly becomes too clunky so the next step is that people were starting to create protocols that worked like a Swiss Army knife so you might imagine a group of people come into a room and they brainstorm for an hour and they come up with 25 different blockchain applications and then they come up with 25 different transaction types transaction type 1 create a crowd fund create transaction type 2 participated a crowd fund transaction type 3 create an insurance contract grant transaction type 4 create a two person bet transaction type 5 register a domain name and so on and so forth for every application they can think of so this is what I mean by a Swiss Army knife protocol and at the time there are actually quite a few of these that were being created the problem is though that if you have a Swiss Army knife protocol and you have these people come up with with 25 different projects sitting together in a room they create this protocol release the protocol one week later some teenager from Finland comes up with the twenty-sixth blockchain application and then you have to change around the entire protocol so why not make a protocol that works like this right so basically why not make a blockchain protocol that basically works like a smartphone it's instead of the blockchain protocol supporting just a very small suite of applications and that's all that you can do instead we have a blockchain protocol where the blockchain protocol supports the a programming language which gives you the ability to create applications and what is an application well anyone can write a piece of code and package that echo it up and upload it and you have an app and if anyone else wants to use your app that you can just download the app and it appears on their phone and they can use it and run it right so this is basically the reason why one single phone can make phone calls browse the Internet listen to music have text conversations with people play games and just basically do thousands of things all in one device right this is the power of general-purpose computation and this is the kind of spirit I wanted to bring to the blockchain world so the concept right so first of all aetherium is a blockchain yay but you know there is a few tiny additions right so first of all aetherium has this built-in general-purpose programming language that allows you to program a very wide array of applications inside of it now in a blockchain that is intended only to support money transfers then there would be one type of account and that type of account would just be an account that's controlled by some user and that account will hold coins and you would be able to pass those coins from one account to another in aetherium we have two types of accounts the first type of an account is an account that is controlled by a user so you have a cryptographic private key and there exists a corresponding aetherium address and if you have the cryptographic private key you can use this to digitally sign messages that perform operations on behalf of this address and these operations are transact all transactions they can be broadcasted to the network and if they get included in a block then those operations get executed the other type of account is basically an account controlled by a piece of code that is in run inside of the blockchain itself so you could have a account which is controlled by a computer program and this computer program has some set of rules and the rules might say if thing a happens then send some coins to person X if thing B happens then send some coins to person Y if things C happens then just hold on to the coins for now and if you then send coins into this account then the code of that account is the only thing that has the power to make those coins move anywhere else from that on so it is literally digital assets that are under the direct control of a computer program now of course these contracts can be used for many more things than just controlling digital assets they can be used to represent the business logic of basically arbitrarily complex on blockchain applications so this includes things like ENS the etherium name system this could be used to keep track of some kind of on blockchain voting scheme this could be used to keep track of various on chain issuer backed assets and missed lots of different use cases so anyone can create an application with any rules basically just by defining it as a contract so DNS the whole world of aetherium this is basically kind of the simplest contracts you can write that still does something reasonably useful so the idea is that this is a piece of code and I mean you might notice that the code has changed somewhat from last year basically the reason why is that last year's code was written in serpent and we now have Viper which is much better than serpent and maybe some people will talk about it later so basically you have two functions and these two functions represent things that you can do with the contract and at the top you have a declaration of basically you know like what the contract stores so the contract stores a mapping of basically don't make a domain - what is the owner of the domain and what IP address the domain is supposed to point to there is a function called register and if a domain does not yet have an owner then the owner gets set to basically whoever sends the message so whoever sent the transaction that made that function call and you have another function set IP and that function call is fairly simple it basically just checks if you own the domain that you're trying to set the IP address of and if it does then it sets the IP address to whatever you want so in a contract basically a where does all this information gets stored right so in a simple blockchain you can think of the state that the blockchain keeps track of as just basically being a simple mapping of accounts to balance us address one two three four five has 70 coins address B seven eight eight four has twenty thousand coins and so on and so forth the etherium state is a bit richer so it's still a mapping of account to thing inside that account but the thing inside that accounts key to be considerably more complex so first of all you have the account balance so how much ether does the account have you have the nonce which is basically a counter that gets used for a reef for replay protection and you have the code of the contract if that account is a contract and you have the contract storage and a contract storage is this kind of mini database that basically any contracts and on the ethereum blockchain can use so in this case the mapping of domains to who owns that I mean what is the IP address would actually get stored in contract storage now the history in a blockchain is things that happen so you have transactions and in aetherium you have this concept called receipts so currently all full notes us to a store state some full notes store history and there is the possibility of full nodes that do not store history so there we go every account object contains four pieces of data I'll leave that open for about five seconds in case anyone wants to photo it five four three two one okay now code execution so every transaction specifies a to address so every transaction specifies or basically what is the destination or the target of that transaction now if the target of a transaction is just a regular account or really in any case and if that transaction contains ether then the transaction also is a transfer from one account to another account now if the target of the transaction has code so if the target of the transaction is a contract then the code of the target address executes and the code has the ability to do a bunch of things so the code has the ability to send either two other contracts it has the ability to read and write to a contracts own internal storage so if you were to look at this example then a call of the register function would be a transaction in this transaction would you know basically lead to this the owner of the domain being said and that actually is writing to storage and the if-statement actually also is reading from the contract storage so it could read and write through storage and it can even call other contracts so this is also called an internal transaction basically contracts can talk to other contracts in the exact same way that user external users can talk to contracts every full node on the blockchain processes every transaction and stores the entire state its bold because it's important so gas in aetherium so in general there's something called the halting problem which basically says you can't really tell in general whether or not a program will just keep running forever so you can make a program where basically figuring out whether that program will stop after a certain number of steps or whether will keep going forever is something that just mathematically cannot be proven one way or the other so the solution that we have is this mechanism where we charge a transaction fee basically per computational step that a transaction consumes in the unit in which we measure the computational steps is called gas so gas is not a currency right gas is not kind of something that you can transfer or hold gas is basically a unit of measurement it says this computation if it if it consumes 30,000 units of gas then that means that the protocol says that this computation takes about thirty thousand units of effort in order to execute so there's also special gas B's that are applied to operations that take up storage transactions to take up space basically any kind of cost that gets incurred by the etherium network is translated into some kind of gas expenditure so every transaction has to specify the gas limited sure it's actually has to specify the amount of maximum gas that that transaction can consume then when the code executes the execution starts using up the gas and if the code execution stops before the gas is used up then everything is good but if the code execution gets to the point where all the gas is spent then the transaction basically reverts exit with an error but the sender of the transaction still has to pay a fee so the gas limit in aetherium he has a counterparts in the block size of women in Bitcoin and the way that it's set is fairly simple basically miners vote on it and currently the gas limit is at 6.7 million and if there become and if there comes that need to raise it then miners can vote to raise it fairly simple transactions so it transactions in etherium have seven parts to them so there is the transaction nonce which is basically an T transaction replay so if you send a transaction so if let's say I send 10 ether to Bob then this prevents Bob from taking my transaction and including it in the blockchain 100 times so that instead I sent a thousand ether to Bob every transaction so far it can only be included once I'm gas price is the amount of ether that you pay per unit of gas that your transaction takes up so this is a the transaction via goes to miners start gas the maximum amount of gas that the trend so the maximum amount of computational resource that this one's actually can consume um to the target the value transactions could send ether um data which is if your transaction has a target which is a contract then the contract can read the data so this is a way of doing things like specifying function arguments and VRS which is an ECDSA signature for the cryptographers here the V is in there because you need an extra bit in order to recover the public key from the signature so we do the public key recovery thing and not kind of verification the way that say Bitcoin does it um logs so blogs are this kind of append-only a form of storage which is not readable by contracts in the point of logs is basically to say here is an event that occurred during contract execution and we want it to be very easy for people to search for these events and to detect that these events have taken place so a log has up to four topics and there's a bloom filter so you can search for topics very easily and it also allows you to store any amount of data the logs get put into a miracle tree which allows very efficient light act light client access to logs so if you have a light clients then you can search through logs and you can use topics as a keyword and this once you very easily finds events that contracts have created of a certain type so very useful for a kind of decentralized application programming a theory and virtual machine so basically you have a stack and numbers can be pushed and popped from the stack you have memory memory is in temporary array of data that the VM can access so memory only kind of exists ephemerally within one execution context once the execution execution finishes then the memory stops existing storage is like the contracts database it's its permanent storage environment variables so contracts in the EVM can access things like the block number and the timestamp um you have logs and sub calling so contracts have the ability to call contracts by sending what we call these internal transactions now it's most of the time you're not going to be writing in etherium virtual machine code directly because aetherium virtual machine code directly is very cumbersome to write in instead you'll be writing in high-level languages that can pile down into e vm code and there's a bunch of them you have VIPRE you have solidity you have LOL you have bamboo once again you might notice serpent is no longer on the list if you are still using serpent I suggest you switch to Viper so the API so this is the way that function calls get compiled or encoded into transaction data so if you're calling a contract then what that's actually doing is it's making this function call and or sorry if you make a function call it's actually doing is it's creating a transaction in the transaction has data which is specified in this format right so you have four bytes for a function ID you have 32 bytes for one arguments 32 bytes for another argument and if you try to call a function of a contract then you and your clients would create this transaction broadcast the transaction to the network and the contracts code has the ability to read the transaction data and it interprets that you're the first four bytes of the transaction data as which function is getting cold and the other bites as well what are the arguments so that's basically how function calling works in a nutshell Merkel Trias everyone please bow down and pray to Ralph Merkle okay Ralph Merkle is single-handedly beat his Merkel tree is single-handedly responsible for making light clients possible so it's very important to show the technology a huge amount of respect but basically the idea is that it's in Merkel tree is allow for efficiently verifiable proofs that a transaction was included in a block or generally efficiently the archival proofs that any particular piece of data is included in a much larger piece of data so if you have a huge hunk of data then you can make what's this data structure called myrtle tree out of the data and with this Merkel tree you can then for any given piece of data in the tree make what's called a Merkel branch which is basically just these kind of hashes going up the tree at all of these intermediate levels and by checking the hashes against each other you can basically check that this piece of data actually is in this tree right so by to build up the tree you would basically take your data hash two pieces together then hash that for every two pieces then you - two hashes hash two hashes let's we'll eventually have one hash at the top and then to prove the membership of any one particular piece you would get this kind of branch of hashes and check them against each other if there is even one error so if you try to make a proof of a piece of data which is not actually there then at least one of the hashes will not match up in aetherium this gets viewest in order to prove transitive that some particular transaction is in a block but there is also something called the state tree so the state tree is a Merkel tree of the entire aetherium state so basically every account every contract the balance the nonce the contract code contract storage the entire state all the data in aetherium is hashed in this tree structure and the root hash of this tree structure goes into the block header and this is called the state so from in one block to the to the next block there are going to be some parts of the state that get modified and so the Merkel tree will change but we have a specific kind of tree called the Merkel Patricia tree which basically means that when this thing gets changed the number of updates to the Merkel tree that have to be made is actually fairly small it's basically log logarithmic per update so with this basically a white client can ask the network for you know give me a Merkel branch for one particular account and some full node can reply back with this branch and a white client can itself basically check the hashes of the branch going all the way from the top to the bottom and if all the hashes match up then you know great and the white clients is that basically accepts and has this confirmation that this particular piece of data representing you know the balance of some account or some storage key actually is in the Merkel tree so Merkel's reason aetherium are used for transaction state receipts patrícia trees allow for efficient in certain delete operations block headers contain these three trees so what's new in Byzantium so Byzantium was this hard fork that we did that went live on October the 16th and it introduced a bunch of wonderful new privacy features so these are kind of the three main probably most interesting features in Byzantium so basically you know if there are features directly but these are the some three interesting things that just become enabled by the new features in Byzantium right so basically in Byzantium we have what are called pre compiles so basically think kind of optimized virtual contracts don't let you do elliptic curve addition elliptic curve multiplication elliptic curve paring and big number math and this allows you to write contracts in aetherium that do things like verifying ring signatures verifying zk snarks if you're applying RSA signatures so this could be used to really increase etherium compatibility with existing systems that use just via public keys and certificate authorities and so forth ring signatures at Z key star or both very powerful privacy technologies and you'll be hearing about these later and aside from this there are also a bunch of important features things like the static call opcode which allows you to write safer contracts that don't have like the same kind of mute ability and reentrant see issues in some cases this also lets you do pure functional programming more easily you have revert of return to copy revert op codes that help you see if gas of course that makes the EVM more efficient in some cases and a bunch of this fairly long tail of smaller improvements but you know basically I would say the motive main theme of the Byzantium hard fork is adding in this kind of strong cryptography that makes powerful privacy-preserving applications possible so if and there there are already lots of interesting things that are being built on on top of it there is already you know I mean Zeki snark based reputation system that I've heard about yesterday so this is moving forward quite quickly so future directions so Casper um see a chungmu presenting right after me Vlad is going to also present about his version of Casper called Casper CBC sharding so see my presentation basically right at the end of today though I will say that it's not just about charting and it actually does kind of get significantly broader than that also just all this long tail of kind of eve of EVM upgrades much smaller protocol upgrades now this is future directions for the etherium blockchain kind of course specifically there is now a much larger list of future directions for second layer architecture intermediate tools systems that can be built on top of aetherium this includes scalability solutions like plasma this includes all of the stuff that can be built on top of ring signature but you know elliptic curve multiplication pairing CZK snarks this includes various other privacy-preserving protocols this includes like state channel systems and all of these are also wonderful and really important advancements that will hope that we'll hear more about as well so thank you and once again hope you enjoy the conference [Music]