 So this is actually not the first time I've given this talk, right? This is... I've given something like this about pretty much once every DEF CON, I think since at least DEF CON 1. And the point of this talk has always been to just give a kind of big rapid fire introduction into some of the basics of how Ethereum works, some of the basics of what Ethereum tries to accomplish, and, you know, just try to get it done within, I guess, right now it's 1.8 kiloseconds or 150 slots. So what is Ethereum, right? Ethereum is a general-purpose blockchain. So people have seen a general-purpose system platforms before, and people have seen blockchains before, and I think at this point we can all kind of intuitively understand what the value of both of those categories is, right? So blockchains can facilitate a large-scale consensus. They can protect against censorship. They can enable censorship-resistant applications. Blockchains are always available. If you build on a blockchain, then the thing that you build on that blockchain is going to be available. It's not going to just get pulled under you because, you know, some particular company decides it would be 12% more profitable if they just changed the API on you without notice. It is, you know, independent of any one particular nation-state. It's not dependent on any particular centralized corporation. Avoid dependence on centralized parties. It's one neutral ground at a time when almost every other grounds that we see is picking sides of some kind or other. And, you know, often for very good reasons, but blockchains are this kind of base layer between parties that do not trust each other, you know, still allows them to have positive-sum interactions. Blockchains can allow applications that are open, that are transparent, where people who participate on them can be sure that the application is going to follow the rules that they signed up for, right? So blockchains are great for, you know, things that really need stability. So there is a good reason why money is the first app. But there's other apps as well. I'm sure a lot of people behind those apps are going to be talking a lot about them at this conference. General Purpose platforms are powerful too, right? General Purpose platforms are interesting because they open the door to independent innovation. So if you have a general Purpose platform, then it just makes it much easier to build something on top of it because if you want to build some specific thing, instead of having to, like, rebuild all the infrastructure yourself, you know, you just add a tiny little piece, right? They can create powerful network effects between different types of applications. So, you know, you got your Uniswap, and then you got your, like, DAO that plugs into the Uniswap, and then that Uniswap itself gets used to trade between, you know, USDC tokens and maker tokens, and you can create these kind of complicated chains of seven different applications that all talk to each other, and sometimes they talk to each other in insanely crazy ways and one single transaction that really fund people from Paradigm go and write amazing blog posts about. But so General Purpose platforms lower the barriers to entry. They make it simpler to build. They enable a lot of innovation, and often General Purpose platforms end up being far more useful than even the creators originally imagined. So Ethereum is a General Purpose blockchain, right? And so Ethereum tries to be both. So this is, like, one of the sort of three-minute pitches of, you know, what Ethereum could allow you to do. So what is Ethereum and how does this work? So these three pictures are from a slide that I used to describe Ethereum at some of the previous Ethereum in 30-minute sessions, right? So, you know, you have, like, single application blockchains, which are, like, pocket calculators. Then you have, like, multi-application blockchains that explicitly support a small number of applications, I call them Swiss Army knife blockchains. And then you have, you know, the smartphone blockchain. Oh, it's a, you know, it's General Purpose. And if you want to do something, you just, like, download the app, right? So these days, you know, unfortunately, you know, we're in, you know, 2022. And, you know, talking about a general blockchain being General Purpose as though that's something cool is, you know, kind of like someone's selling a house, describing their house by saying, you know, we're really modern. We have a refrigerator. Who here has a refrigerator? Well, lots of people have not raised their hands. I'm impressed. I guess, do people, like, order out? Do people eat raw food? Like, what's the idea here? I don't know. I mean, people have done a refrigerator-free living successfully for, like, you know, 1900 years in the AD era alone, but that's, you know, it's still impressive. Anyway, so, like, what does the blockchain look like, right? So one of the, yeah, exciting things about doing this presentation this year is that, like, I actually had to change it a lot, right? Like, between a lot of the, yeah, previous cell ones, it's like, okay, you know, it's a theorem, here's how it works, okay, it's a theorem, it's how it works, okay, it's a theorem, it works, but in between the last DEF CON and this one, the way that the Ethereum blockchain works just, like, changed very fundamentally, right? And the rate of change and our ability to actually execute on and implement changes to the Ethereum protocol, significant changes that we have wanted to do almost since the protocols are launched and that we've been talking about for almost a decade, but, you know, finally managed to done, has really been accelerating, right? So we had EIP-1559 in, you know, 2020 and then the beacon chain launched and now the beacon chain took over and, you know, Ethereum is only a proof-of-stake system, so, you know, lots of very big changes and, you know, lots of different things that we have to talk about, right? So, like, remember back in when, during the proof-of-work era, we had to talk about how, like, blocks include un-uncle blocks, right? Do people remember this? Do people remember how, like, sometimes people would even, you know, try to be gender-neutral, call them armor blocks instead of un-cle blocks as well? And, like, you know, I get the sentiment, very honorable sentiment, but, like, come on, like, armor just sounds like an insult for people who meditate. But, okay. So these days, you know, we're proof-of-stake, right? And the blockchain looks kind of different from what it did before, right? So let's, like, talk about what the blockchain looks like without reference to, you know, the dark, old proof-of-work era that our grandchildren will eventually remember in the same light as how they remember how houses used to not have refrigerators. So, you have blocks, right? And blocks contain transactions. What is a transaction? A transaction is an object sent by a user that contains information about something that they want to do, right? So, if I want, if I have, like, some ETH, ETH is the e-cryptocurrency inside of Ethereum, and I want to send you one ETH, then that request would be packaged up inside of a transaction. If, let's say, I have an NFT and I want to send you the NFT, that request is packaged up inside of a transaction, if I want to publish an entirely new application, then, and create the smart contract for the application, and that's something I'll cover later, but that is also packaged up inside of a transaction. So, a transaction is like a package of data that contains information about stuff that somebody wants to do. These transactions get included in blocks. Every block is created by a validator, so blocks are just these packages of transactions, and one new block comes every slot. One slot is 12 seconds. Then we have attestations. Attestations confirm blocks, right? Attestations are like these messages signed by other validators that basically solidify the position of a block inside of the ETH blockchain, right? So, when a block gets published, and then that block, within a few seconds, it almost immediately gets thousands of attestations supporting it, and that solidifies that block's position in the chain, such that other blocks that compete with that block that also try to claim that they're... that are not kind of children of that block, that are no siblings, and then try to claim that they're the real history, those blocks are not going to be able to get through, right? So, as Danny mentioned, in the entire almost month that Post-emerge Ethereum has been running, we've only had like 26 reorgs, and that's maybe an overcount, and even those cases are cases where a block is published too late, and it probably did not get many attestations, right? So, lots of attestations in parallel solidify the position of a block in the chain. Block gets published, block gets attested, block gets published, block gets attested, block gets published, block gets attested, right? People understand? Raise your hand a few, will I understand? Okay, wow, it's like more people understand this than have a refrigerator, this is like a basic. Okay, so, let's talk about what happens inside of a blockchain, right? So, the blockchain keeps track of information that we call state, and the state that the blockchain keeps track of is made up of accounts, right? And there's two types of accounts. Basically, you can think of them for now as like accounts controlled by people and accounts controlled by robots, where the robots also only exist inside of the chain, right? So, an externally owned account, this is an account that represents a user, right? So, like for example, if you hold ETH today, that ETH is stored inside of your externally owned account, right? So, there exists a record, which is like an ELA that is in the blockchain that the blockchain keeps track of, and that object contains the record saying, you know, hey, this address contains this amount of ETH. The other kind of account is what we call a contract. A contract is like a computer program that lives on chain. The code of that computer program is on chain. So, the chain stores the code of the contract, the chain stores internal storage of the contract, internal storage is like memory that that contract has the ability to update, and contracts are basically how all applications that are in Ethereum work, right? So, an application generally has an on chain component that controls the business logic of that application that generally is one or a set of contracts. So, what do contracts look like? So, this is an example of a source code of a simple smart contract. This is by the way in a language called Viper. It's a less well-known language. It's the kind of largest alternative to Solidity. So, if people aesthetically prefer coding in Python syntax, I mean, I personally think Python is like way aesthetically superior to anything using curly braces, but I know this is a controversial topic and like half of you are gonna cancel me. But, you know, if that's you, or if you like some of Viper's kind of other features that like try to kind of take a very pro or from scratch approach to being sort of more restrictive and more secure in various ways, you can check it out. But, this is a simple, you know, contract for a domain name registry, right? So, basically the same sort of thing that ENS is trying to do, right? So, what do we have here, right? So, we have first like a mapping, right? Domains mapping bytes 32, we're gonna add to a domain, right? Right, so, the bytes 32 here is like, basically, you know, the address like what the domain is, right? So, the, you know, I'm just kind of being very lazy and very simple, not introducing strings or variable lengths or fancy stuff. And, you know, if you wanna like register George, then you would just like put 26 zero bytes and you would like stick George at the end. And, you know, that would be the key in the mapping. And then the value in the mapping is just who is the owner and what is the IP address that the domain corresponds to, right? So, then we have two functions. The first function is set owner, right? So, the point of this function is basically, if you are the owner, then you can transfer ownership to a new owner. Or, if the domain is not yet claimed, then you can call this function, set it to yourself or set it to some owner and you can become the owner, right? So, you should be able to, you know, if you have any programming experience, just kind of read the code and understand what's going on, right? Basically, you look at what the owner of the particular domain that you're looking at right now is. And, if that owner is zero or if that owner is you, then you can set the owner to whatever you want, right? So, that's one function. And then the other function is, well, if you are the owner, you can set the IP. So, what's actually going on here, right? Basically, we have these functions and it's a piece of code. How does this actually kind of translate to what's happening on a chain? So, this is a transaction flow example, right? So, basically, what we have here is, you know, you have the contract. It's the kind of bubble on the bottom, the 0x849c41 down there, right? That is an account, it is a contract account, and the contract account is going to have a piece of code. What is that code? It's the compiled version of this, right? So, that lives on chain. And then you have that contract and it also has some storage. Now, at the top, we have a transaction, right? So, as we mentioned before, transactions are like these packaged objects that represent requests to do something. So, in this case, we're going to make a request to change the, basically calls a set address, right? So, we're going to call it with a particular domain, we're going to call it with a particular new address, and you're going to make a transaction where the two of the transaction, right? The two address is the account that you're calling, right? So, it's going to be 0x849c41 down there. The data is going to be the stuff that you call it with. And then the signature is like cryptographic data that proves that it actually is you, the owner of the sender account that actually created the transaction, right? So, the signature determines who the sender is. Only the sender, like only the owner of the actual private key corresponding to the sender can actually create a transaction with that sender. So, that transaction gets included in a block. What happens in the EVM, right? So, it starts off with a call from the account at the top, the CA291D up there, right? The account at the top, which is an externally owned account, that is the account owned by you, right? Now, what does that account do? So, what are the state changes that happen? So, first of all, your balance goes down a bit to pay for the transaction fee, and then a bit of balance gets transferred to the miner, or now to the block proposer, and then it makes another call. And that call calls down to the contract that is the application, and the data of the call encodes what you want to do. And then basically, it actually does like a series of storage operations that just are what's happening here, right? So, first you do an S load, a storage load, to figure out like what actually is in the domain, or in the storage for the particular domain. It returns, let's say, a zero, because nothing has happened there yet. And then we S store, and in this case, we're changing the address, S store, add a particular address that maps to where that domain is stored, and it's going to store the new address there, right? So, this is a very simple example, but this is a bit of a view of what happens inside of the EVM when you send a transaction. So, gas, this is something in Ethereum that has not changed yet, right? So, gas is the unit of resource consumption within Ethereum, right? So, examples of gas. So, a transaction costs a base 21,000 gas. Each computational step costs usually between 2 and 10 gas depending on how complicated the operation is. Editing a storage slot costs 5,000 gas, or it costs 20,000 gas if the storage slot is not filled yet, and so you're actually expanding the storage. And every byte of data in a transaction costs 16 gas, or if it's a zero byte, then it only costs 4 gas, right? So, gas is like this master unit that represents all of the resources that are being consumed during the execution of a transaction. If you send a transaction which gets included in a block, you have to pay a fee that's proportional to how much gas the transaction consumed, right? So, whatever amount of total resources the transaction has consumed, you have to pay an amount proportional to that, right? So, the fee is basically the, it's called the base fee plus priority fee multiplied by the gas you used. So, the base fee is like a fee that's adjusted by the protocol, it adjusts up or down to try to keep the usage at about the same level, and then the priority fee is like an extra amount that you pay to the block proposer to sort of encourage them to add your transaction, and in this particular, generally, people just set a priority fee of one, but, you know, if there is a particular time where lots and lots of people are sending huge numbers of transactions and the blocks are congested, you can set a higher priority fee to get in first. And a maximum of 30,000 gas can be spent inside of each block, right? So, who remembers how much gas a basic transaction costs? Hey, that's in the previous slide. 21,000, okay. So, 30,000, 30 million divided by 21,000. Anyone want to guess about how much that is? One refrigerator, excellent answer, yes. So, it's, okay, right. So, it is, you know, going to be about in the 1400 range, right? So, a maximum of 1400, you know, roughly simple transactions can make it into each block. And, you know, if the transaction, but on average it's going to be 700 because like the priority fee adjusts to keep the average usage around 50, or sorry, the base fee adjusts to keep the usage around 15 million. But, you know, if the transactions get more complicated, then they start consuming more gas and, you know, a block can include fewer of them. So, that's what gas is. So, this is what a transaction object looks like, right? So, a transaction, as we mentioned, is like this big blob of data that represents, you know, a thing that a user wants to do that gets included on chain. And, you know, you can see kind of some of the parameters of what they are. So, transaction type. This particular transaction type is 0x02. There's also 01 and like others before it. Chain ID. Which chain is this for? Are you even sending a transaction for Ethereum or for Ethereum Classic or for ETHPOW? Who here has sent a transaction on ETHPOW? No hands raised, almost. Okay, a couple of hands raised. Okay, no, don't worry, you're not canceled. So, okay. You know, just, we want to give people the ability to send a transaction on one chain instead of sending it on all the other chains. You know, it's not that hard, right? It's more of a deep-lay value, right? So, every time you send a transaction that gets included, the nonce also has to go up by one each time, right? So this prevents a transaction that you send for being included more than once. Pretty simple. Max priority fee, the priority fee that you're paying. Max fee, which is like the maximum base fee that you're willing to pay. Gas limit, the maximum gas the transaction is allowed to consume. Destination, which as the transaction goes to, the amount, how much ETH that you're sending. Data is, if you're calling a contract, then what is the data that gets passed in the call? Access to list is like this fancy way to access some accounts and some storage slots kind of earlier and access them a little more cheaply. And then the signature is just like a cryptographic thing that verifies, you know, who sent the transaction. Okay, so high-level languages, right? So, you know, we mentioned that there is Viper. There is also Solidity. There is also, you know, LLL. There is like a long list of various high-level languages that you can write contracts in. So, when you write a smart contract, you're generally writing in this high-level code. There's a compiler. The compiler converts the high-level code to bytecode and it also outputs an ABI. ABI stands for Application Binary Interface. It's basically the way to encode particular requests, like things that users want to do. Users attempt to call particular functions in the contract into a set of bytes, right? So, in this case, like if you call, you know, set owner with a particular, you know, with particular address, actually, this should be set IP. I put an IP and that's a bit of a mistake, right? Then you can use the ABI and you can convert that into some call data, right? And the call data is what actually gets into the transaction, right? So, there is this kind of logic that happens that basically converts this sort of high-level human-readable stuff that people want to do. You know, both the human-readable code of the contract and kind of human-readable instructions like, you know, I want to send Bob25E because I really like him. You wouldn't put the I really like him part into the contract. You would just send him a lot of node off-chain or something. But, you know, convert that into a kind of byte request that the EVM understands. So, proof of stake incentives, right? So, the thing that actually kind of keeps the whole thing safe. So, we talked about blocks. Who gets to produce these blocks in attestations? Anyone can if they deposit 32E and become a validator, right? And if you have less than 32E, then you can join the system through stake pools, right? So, there are stake pools, you know, there's Rocket Pool, there's Lido, there's a bunch of other pools. And if you have less than 32E, you can kind of become part of a validator using a stake pool as well. So, deposit 32E becomes a validator and in each slot, 12 seconds, 1 over 32 of all validators attest to the block that was created during that slot. The validators get revenue, right? So, why would you stake? Well, you get rewards. You get two kinds of rewards. You get in protocol rewards. So, you get automatic rewards for creating blocks, creating attestations, you know, doing all of the good things. And you also get priority fees and MEV from transactions, right? So, you know, you get revenue in two ways. And validators can, you know, withdraw at any time. Well, this will be enabled in the next hard fork, right? But validators will be able to withdraw at any time with a delay. And usually, that delay will be pretty short. But in extreme cases, like if everyone's trying to withdraw at the same time, then there is going to be a queue and you might have to wait for some amount of time. So, that's proof of stake consensus, right? Basically, you know, if you have 32E, if you can deposit, become a validator, and all of these validators are the ones that participate in this big system of blocks and attestations that keeps the chain progressing and keeps the blocks that are being added safe. Fork choice, right? So, the reason why we need to have, like, weird fancy stuff and consensus is because what if you have this situation where people publish two blocks and those blocks disagree with each other, right? So, in this case, you have two blocks and these blocks are, you know, they're sister blocks, right? They have the same parent. So, clearly, you can't get, like, put both of these blocks in at the same time. They might have conflicting transactions. They have some of the same transactions. They even might have some of the same transactions in different order, right? But blocks are, you know, what happens if you have, like, two blocks that create two conflicting histories? You have to choose one of these histories somehow, right? And the mechanism that does this choosing is called the fork choice, right? Because the block chain forked, and we have to choose one part of the fork. So, the mechanism that does this right now, it's called LMTGhost, and it's very simple. It's just attestation counting. Basically, you have block A and you have block B, and you just count the number of attestations that support block A or support its children, and then you also count the number of attestations that support block E, block B, or support it indirectly by supporting its children. You see which side has more. In this case, the top side has four, the bottom side has six, the bottom side wins, and so you choose block B, right? So, this is one part of the upper of stake consensus. There is also this mechanism called Casper FFG finalization, right? Casper FFG finalization is, like, this extra gadget that lives on top of this attestation game, and it gives us this really extra special property that if more than two-thirds of validators are online and honest, then after two epochs, so one epoch is 32 slots, or 6.4 minutes, so after 12.8 minutes, a block gets finalized, and that block cannot be reverted, right? So, if we take this example, if we take the block B over here, after one epoch, if more than two-thirds of the attestors in that epoch support B, then B is justified, and if after another epoch, more than two-thirds of attestors still support B, then B gets finalized, right? Once a block is finalized, it cannot be reverted. But, you know, in practice, waiting for the Casper FFG finality is, like, more a thing for high-value use cases. If you are just making a very simple application that's not doing anything super high-value, then, generally, one of what we call safe slot is enough for most applications, right? So if you have one slot, we're doing that slot, the proposer acts correctly, and he gets lots of attestations, then that's, like, generally enough to be secure. The next tree is... Who here knows who's on the picture here? Who here thinks it's Ray Kurzweil? Who here thinks it's Ray Dalio? Who here thinks it's Craig Wright? Who here thinks it's Satoshi? Interesting. So a few people think Ralph Merkle is Satoshi. That's fascinating. Okay, I gave away the answer. It's Ralph Merkle, right? So Ralph Merkle is great because he invented Merkle trees, the Merkle dam guard construction for hash functions, which actually has some problems and it's, you know, why people want to switch to sponges lately, but it was an amazing invention for its time. And, you know, he recently... also doing some interesting stuff about cryonics, but, you know, Merkle trees are great and doges are also great. Ralph Merkle and doges are not actually connected. The only connection is that I like both of them. But the... So what are Merkle trees, right? A Merkle tree is like this data structure that lets you create one small object that commits to a large number of objects, where it becomes very easy to prove for any one of those objects that that object is inside of this entire... big entire tree, right? So you have this one object that's called, you know, a header and it might be committing to, like, a million different things. And for any one of those million things, you can make a short proof that shows that one thing actually is, you know, in the set of things that's been committed to. Why do we care about this? Well, Ethereum blocks are big. The Ethereum state is even bigger, right? The Ethereum state is like 40 gigabytes. So what if you want to prove something that happens in a block or prove something about your account and you want to prove it to someone that has these block headers that are at the top but that does not have the entire 40 gigabytes or the entire, you know, really huge amount of data in the Ethereum chain. Well, merkle proofs come to the rescue, right? Basically, you just provide the value, you provide a couple of, like, sister hashes going up along the tree, and anyone can verify the proof by just kind of continuing to hash up the values going up together and then seeing whether the root they get matches, right? So really powerful technology. Ethereum actually, you know, uses it everywhere. Last fun thing were your two protocols, right? So most people are increasingly, more and more people don't use Ethereum directly. They use what are called Layer 2 protocols that inherit security from Ethereum and add higher scalability on top, right? So rollups, I wrote an article on them. They're really fun. There's a bunch of them. From a user's point of view, living on a modern Layer 2 feels like living on Ethereum. You know, applications work the same way, but because these applications don't stick everything on Ethereum directly, fees are many times lower. So Layer 2s are great. Layer 2s are how Ethereum is scaling. And, you know, we encourage everyone to pay attention and learn a lot about Layer 2s this year. So finally, you know, future directions. The merge. Done. Yay! Okay. Next stop. The search. Increasing scalability. Going finally, going sustainably below 5 cents of transaction, getting us the thousands of transactions a second. Next stop. The verge. Replacing merkle trees with more efficient structures that let Ethereum nodes be much lighter. Ethereum nodes don't have to have huge amounts of data. It becomes much easier for anyone to run them. Yay! The purge. Clearing out old data. Clearing out technical debt. Making Ethereum nodes easier to run and making the Ethereum protocol simpler. Woohoo! And the splurge. Grab bag of various useful stuff. Account abstraction. EVM improvements. Proposure builder separation. Making everything amazing with ZK Snarks. Yay! Ethereum is getting better and will have to keep rewriting this presentation for next year. Amazing. Thank you guys. Bye-bye.