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 Ethereum 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 is, you know, why does Ethereum 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 are looking at various applications, issuing assets on the blockchain, crowdfunding, domain registration, projects like namecoin, land title registration, gambling, prediction markets, IOT applications, healthcare applications, many different applications of blockchains that go beyond, you know, 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 the pocket calculator have? It could do one thing. And it could do one thing fairly well. But that's the only thing that it can do. Now granted, if you have some super fancy TI 80, whatever, you can probably come up with some way to program a video game on top of it. But nobody really wants to do that. So in general, it just ends up being one tool that 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 one, create a crowd fund. Transaction type two, participate in a crowd fund. Transaction type three, create an insurance contract. Transaction type four, create a two person bet. Transaction type five, 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 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 26th 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 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 code up and upload it, and you have an app. And if anyone else wants to use your app, they 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, Ethereum is a blockchain. Yay! But, you know, there's a few tiny additions, right? So first of all, Ethereum 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 will be one type of account. And that type of account will just be an account that's controlled by some user, and that account will hold coins. And you will be able to pass those coins from one account to another. In Ethereum, we have two types of accounts. The first type of account is an account that is controlled by a user. So, you have a cryptographic private key and there exists a corresponding Ethereum 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 called transactions. They can be broadcasted to the network. And if they get included in a block, then those operations get executed.  So, you could have an 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 thing 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 control on 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 Ethereum 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 there's 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 Ethereum. This is basically one 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 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 what the contract stores. So, the contract stores a mapping of basically a domain to what is the owner of the domain and what IP address the domain is supposed to point to. There's 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, where does all this information get 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 balances. Address 12345 has 70 coins. Address B7884 has 20,000 coins and so on and so forth. The Ethereum state is a bit richer. So, it's still a mapping of account to thing inside that account. But the thing inside that account can 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 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 contract on the Ethereum blockchain can use. So, in this case, the mapping of domains to who owns the domain, 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 Ethereum, you have this concept called receipts. So, currently, all full nodes store state. Some full nodes 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 two address. So, every transaction specifies basically what is the destination or the target of that transaction. Now, if the target of each transaction is just a regular account, or really in any case, and if that transaction contains ether, then that 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.  So, the code has the ability to send ether to other contracts. It has the ability to read and write to a contract's own internal storage. So, if you were to look at this example, then a call of the register function would be a transaction. And this transaction would basically lead to this, the owner of the domain being set, and that actually is writing to storage. And the if statement actually also is reading from the contract's storage. So, it can read and write to 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 external users can talk to contracts. Every full node on the blockchain processes every transaction and stores the entire state. It's bold because it's important. So, gas in Ethereum. 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 it 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. And 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 consumes 30,000 units of gas, then that means that the protocol says that this computation takes about 30,000 units of effort in order to execute. So, there's also special gas fees that are applied to operations that take up storage, transactions that take up space. Basically, any kind of cost that gets incurred by the Ethereum network is translated into some kind of gas expenditure. So, every transaction has to specify the gas limit. A transaction 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, exits with an error. But the center of the transaction still has to pay a fee. So, the gas limit in Ethereum is a counterpart to the block size limit 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 comes a need to raise it, then miners can vote to raise it. Fairly simple. Transactions. So, transactions in Ethereum have seven parts through them. So, there is the transaction nonce, which is basically anti-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 send 1,000 Ether to Bob. Every transaction so far can only be included once. Gas price is the amount of Ether that you pay per unit of gas that your transaction takes up. So, this is the transaction that the VIA goes to miners. Start gas, the maximum amount of gas that the, so the maximum amount of computational resource that the transaction can consume. To the target, value transactions can send Ether. 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 VIAs in there because you need an extra bit in order to recover the public key from the signatures. So, we do the public key recovery thing and not kind of verification the way that, say, Bitcoin does it. Logs. So, logs are this kind of append-only form of storage which is not readable by contracts. And the point of logs is basically to say, here is an event that occurred during contract execution. And we wanted 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 Merkle tree which allows very efficient light client access to logs. So, if you have a light client, then you can search through logs and you can use topics as a keyword. And this lets you easily find events that contracts have created of a certain type. So, very useful for decentralized application programming. Ethereum virtual machine. So, basically, you have a stack and numbers can be pushed and popped from the stack. You have memory. Memory is a temporary array of data that the VM can access. So, memory only kind of exists ephemerally within one execution context. Once the execution finishes, then the memory stops existing. So, storage is like the contract's database. It's permanent storage. Environment variables. So, contracts in the EVM can access things like the block number and the timestamp. You have logs and subcalling. So, contracts have the ability to call contracts by sending what we call these internal transactions. Now, most of the time, you're not going to be writing in Ethereum virtual machine code directly because Ethereum virtual machine code directly is very cumbersome to write in. Instead, you'll be writing in high-level languages that compile down into EVM code.  You have Viper. You have Solidity. You have LLL. 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 ABI. 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're making a function call, what it's actually doing is it's creating a transaction. And the transaction has data which is specified in this format. So, you have four bytes for a function ID. You have 32 bytes for one argument, 32 bytes for another argument. And if you try to call a function of a contract, then your client would create this transaction, broadcast the transaction to the network. And the contract's code has the ability to read the transaction data. And it interprets the first four bytes of the transaction data as which function is getting called. And the other bytes as well, what are the arguments? So, that's basically how function calling works in a nutshell. Merkle Tree is. Everyone please bow down and pray to Ralph Merkle. Okay. Ralph Merkle is single-handedly, well, his Merkle Tree is single-handedly responsible for making light clients possible. So, it's very important to show the technology a huge amount of respect. And basically the idea is that it's Merkle Tree is allowed for efficiently verifiable proofs that a transaction was included in a block, or generally efficiently verifiable 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 a Merkle Tree out of the data. And with this Merkle Tree, you can then, for any given piece of data in the tree, make what's called a Merkle 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. So, to build up the tree, you would basically take your data, hash two pieces together, then for every two pieces, then you'd hash the hashes, hash the hashes, that will 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 Ethereum, this gets used in order to prove that some particular transaction is in a block, but there is also something called the state tree. So the state tree is a Merkle tree of the entire Ethereum state. So basically every account, every contract, the balance, the nonce, the contract code, contract storage, the entire state, all the data in Ethereum 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 root. So, from one block to the next block, there are going to be some parts of the state that get modified. And so the Merkle tree will change. But we have a specific kind of tree called the Merkle Patricia tree, which basically means that when the state gets changed, the number of updates to the Merkle tree that have to be made is actually fairly small. It's basically logarithmic per update. So with this, basically a light client can ask the network for, you know, give me a Merkle branch for one particular account. And some of a full node can reply back with this branch. And a light 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.  So, Merkle trees in Ethereum are used for transactions, state, receipts, Patricia trees allow for efficient insert and 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 much of wonderful new privacy features. So these are kind of the three main, probably most interesting features in Byzantium. So basically, you know, there aren't features directly, but these are 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 that let you do elliptic curve addition, elliptic curve multiplication, elliptic curve pairing, and big number math. And this allows you to write contracts in Ethereum that do things like verifying rank signatures, verifying ZK Snarks, verifying RSA signatures. So this could be used to really increase Ethereum's compatibility with existing systems that use just via public keys and certificate authorities and so forth. Ring signatures in ZK Snarks are 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 the same kind of mutability and re-entrancy issues in some cases. This also lets you do pure functional programming more easily. You have a return data copy, revert opcodes that help you save gas, opcodes that make 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 sort of main theme of the Byzantium hard fork is adding this kind of strong cryptography that makes powerful privacy preserving applications possible. So, and there are already lots of interesting things that are being built on top of it. There's already, you know, ZK Snark based reputation system that I've heard about yesterday, so this is moving forward quite quickly. So, future directions. So, Casper, see Chiang Wu 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 sharding and it actually does kind of get significantly broader than that. Also, just this long tail of kind of EVM upgrades, much smaller protocol upgrades. Now, this is future directions for the Ethereum blockchain kind of core specifically. There is now a much larger list of future directions for second layer architecture, intermediate tool systems that can be built on top of Ethereum. This includes scalability solutions like Plasma. This includes all of the stuff that can be built on top of ring signature, you know, elliptic curve multiplication, pairing, ZK Snark. This includes various other privacy preserving protocols. This includes state channel systems and all of these are also wonderful and really important advancements that I'll hope that we'll hear more about as well. So thank you and once again, hope you enjoy the conference.