 Okay, great. So I was originally here to give a talk specifically about what was called maximally verifying like clients and charting, and I will end up touching on a lot of that in this talk in certain ways, but I also wanted to make it broader a bit and basically make it be not just about scalability and just about charting, but also a kind of general outline at a proposal for what I think a sensible path for Ethereum protocol development in general to be going forward over maybe the next two to four years or so, right? So I'll start off by just let's take a look at what's been going on in Ethereum so far, right? So in Ethereum, we've first of all had a lot of successes. So first of all, the Ethereum blockchain and Ethereum protocol work. You may have noted the total lack of a crippling DDoS attack on the network this year. Many applications and we've gone to somewhere over a thousand applications at this point and I'm pretty sure people aren't even really counting anymore. And it shows in all the charts, right? So this is the Ethereum transaction chart and we just recently broke above 500,000 transactions per day for the first time, which in case you can't divide is something like over seven transactions per second. And so it's, well, it's like, or almost exactly seven transactions per second at the peak actually. So the skill, the amount of activity on the Ethereum blockchain is orders of magnitudes higher than it was one or two years ago. And this includes not just Ether transfers, it includes ERC20s, it includes Ether Delta, it includes various different DApps. And it just, it includes just a whole bunch of different smart contracts of various types. This is another diagram I'm fairly proud of. This is the global Ethereum network with more than 20,000 nodes worldwide with hubs existing all over North America, including East Coast and West Coast, hubs all over Europe, a bunch in Russia, a smaller but still very significant and growing amount scattered across the various hubs in Asia and increasingly nodes starting to show up in places like South America and Africa as well. According to the data that got scraped from either this site or another site a couple of days ago, we seem to have one node in North Korea, but not sure if that's actually in North Korea. Yeah, so in general, a lot of progress, right? And if you look at just by ZNTM as well, by ZNTM hard fork basically has gone through and you can now take advantage of cryptographic primitives that are available in accelerated form on top of the Ethereum blockchain in order to build privacy-preserving applications and people already are. So you just saw Zockerty's in the last presentation. Just yesterday, I saw on Reddit someone announced a protocol that was doing a reputation market based on ZK-Synarx. I know of one project that's trying to do things with ring signatures, actually multiple projects. So I also know of at least a couple of projects that are taking advantage of RSA verification to do things like better communicate between Ethereum and existing DNS between a custodian e-residency and just various other things. So the privacy part of the three kind of major challenges to Ethereum success that I've outlined, privacy, security, and scalability is actually quite well on the way to being solved. Now there is still a lot of work to be done. Someone actually has to build the ring signature stuff. Someone actually has to build Zockerty's. People actually have to use it. People have to actually make using their own knowledge-proof practical, but we've made progress. So what are the challenges? So scalability is probably challenge number one, right? So in, this is a quick excerpt from the Sharding FAQ where I talk about this challenge called the scalability trial lava. And I basically state that it seems likely that blockchain systems can only have at most two of these three properties at the same time. Number one decentralization, which I define as basically being able to run without trusting super nodes, scalability, so being able to process many more transactions than a regular laptop, and security. So basically, it's okay to be vulnerable to 51% attacks, but you definitely cannot be vulnerable to 0.51% attacks. There is a very, very big and growing graveyard of systems that claim to solve the scalability triangle, but actually completely don't. So I actually think that the scalability triangle is solvable, but it basically requires significantly more kind of complex technologies than the kinds of technologies that we have available. Part of this is something called the data availability problem, which I'm not gonna talk about today because it really does require a one hour presentation to go through. But basically, it gets this problem that a lot of people don't even think about, but basically not only do you need to verify that the blockchain is valid, you also need to verify that everyone can access the blockchain. And even ZK Snarks and Starks cannot solve that part of the puzzle. And there's mathematical proofs based on information theory that say that if you cannot solve that part of the puzzle, your protocol is basically cannot be secure. The relevant paper here is one, basically one that says that batch updates for cryptographic accumulators are impossible. So I'm gonna head to Justin Drake for that one. So it is a very significant and hard challenge. So basically right now, every node processes every transaction, the capacity of a blockchain is limited to the capacity of one node, and it's actually even worse because we need to have safety margins for anti-DDoS purposes, the limiting factor in Ethereum scalability, and Ethereum's likely worst point of DDoS vulnerability is likely to be discreet. And also Ethereum VM execution is currently absolutely not paralyzable. So these are just known facts and the severe limit, the extent to which Ethereum in its present form can scale. So the likely solution to a lot of this, there are more incremental solutions that we can do. So for example, you can use EIP648 to greatly improve paralyzability, but if you wanna really solve the fundamental problem, every node processes every transaction, basically sharding. And the way that you think about sharding is, well, basically you can split the blockchain state, so split the set of information that everyone needs to keep track of into N universes, and we call each one of these universes a shard. So each universe has its own account space, its own account, its own contracts. You can have transactions within each shard, and you only allow asynchronous communication between shards. So if you wanna send a coin from shard A to shard B, you actually have to have two transactions, the first transaction on shard A, and the second transaction on shard B. And contracts on shard A cannot synchronously call contracts on shard B. So you cannot call a contract on shard B and get a response and do something with that response in one transaction. And the benefit of this is that each client only processes a small portion of all the activity on the network. So the reason why we call it quadratic sharding is because if you imagine, though a processing capacity of one computer to be N, then you can imagine N shards, and each shard has N worth of activity. Each node would have to process the activity on basically just the one shard it's interested in, and every node would have to process the activity of kind of the entire system of shards. So the amount of activity of each node would basically be N at the top and N at the bottom, so a total of two N, but the capacity of the entire system would be N squared. And theoretically it can make the sharding be exponential, but quadratic is simpler, and there might be good reasons to keep it quadratic. And it may well be a reasonable approach to say, if we only do sharding up to quadratic, and if you wanna go up to exponential, then basically have to stick with things like sharding in plasma, or sorry, state channels in plasma. Another challenge that we've had is this kind of challenge of governance and protocol evolution. So basically, we have this trade-off where on the one hand we want progress, but on the other hand there is demand for protocol stability. And hard forks making deep changes are hard, right? So we've finally gotten Byzantium out on October 16th, and Byzantium is the result of over a year of work, a large amount of testing, and even after a year of testing, we still required some pretty epic work between the Go team and the Parity team doing super advanced forms of fuss testing that I don't even fully understand in order to catch a fairly large number of bugs that appeared pretty close to launch. So hard forks making deep changes take a long time to code, take a long time to agree on a long time to test, and there is a high risk of consensus bugs, especially since the Ethereum network has basically seven different clients that all have to implement the protocol and agree on it. But even with all these challenges, we've done Byzantium and we've done it successfully. So, but the problem is that on the one hand, hard forks making deep changes are hard. On the other hand, to get to what we want to see in Ethereum 2.0, so to get to this kind of highly sharded, highly scalable network, as well as all of the EVM upgrades we want to do, all of the parallelizability upgrades we want to do, EVM 1.5, EWASM, potentially more pre-compiles, in order to get to this ideal end state, very deep changes are exact to what we need. So what do we do? How do we handle the trade-off? So intuition, one blockchain, two systems. And I'll make this clear with the diagram that I'll show in the next slide. So here is what a sharding system as we're already starting to build might as could possibly look like, right? So you have the main chain and in the main chain, it's basically everything is basically as it was before. You have your blocks, you have your state route, you have your transaction route, you have your state, you have your accounts, your contracts, your storage. Now, what we're going to do is in the main chain, we're going to add something or a called a Validator Manager contract. Now, what does the Validator Manager contract do? It basically runs a proof-of-stake system that maintains the consensus for a kind of two-layer sharding system that exists kind of on top of or even inside the main chain in a certain sense. So the Validator Manager contract would keep track of validators and would allow anyone to join and leave the system in the service of Validator and basically assign the right to create blocks on in each of these end shards that the Validator Manager contract keeps track of. The VMC would also keep track of block headers for each of these shards, but what the VMC would not do is it would not verify the full blocks of the shard and the VMC would not contain a copy of all the new consensus rules. Instead, basically, actually creating valid blocks, actually enforcing that the blocks are valid in the shards, actually enforcing that the data in the shards is entirely available and follows the desired consensus rules, basically would be the responsibility of the proof-of-stake that exists inside the Validator Manager contract. So the Validator Manager contract would initially be this kind of very low-risk thing to participate in. There would actually not even be a risk of total slashing in the same way that there is in CASPER and the goal would be to basically just get a fairly significant portion of ether-stake participating in this and basically if you are part of the Validator Manager contract, then you just get assigned randomly the right to create blocks in each and every one of these shards at periodic intervals. I should probably use more correct terminology. We call the blocks inside of shards collations. So if you have a transaction, then transactions get grouped into collations and the collation headers then get put into the Validator Manager contract and they get put into transactions that get included into blocks. So we have this kind of two-layer structure where at the top layer, you would have the blockchain and at the bottom layer, you would have all of these different shards and each shard would be like its own universe and connecting the two universes, you have this Validator Manager contract which enforces the proof-of-stake, basically maintains an internal light client for each of the shards and processes and facilitates things like moving ether from the main chain to the shards and possibly from one shard to the other. So you can think of the differences between the two systems between the main shard world and the new shard world so somewhat like this. So scalability, so main shard is OFC. So C is the letter I normally use to refer to the computational capacity of one node. So the main shard would have a scalability of just OFC which is exactly what it does now and the new shards would have a capacity of OFC squared and the reason for this is you have OFC shards and each of the OFC shards itself has OFC capacity. By the way, if you're not familiar with big O notation just like don't think about the O's, main chain scalability of C, new shards scalability of C squared because there's C shards and each shard has C transactions per block. Consensus algorithm, so on the main shard the consensus algorithm is currently proof of work. In the very short to medium term we hope to transition it into hybrid proof of stake in the form of a Casper friendly finality gadget, a paper for which was released on archive something like five days ago and which is actually I would say nearing the kind of final stages of a full specification and eventually we will transition the main chain consensus into full proof of stake. Now the consensus switch itself is designed to be fairly conservative and so possible to implement in this kind of fairly slow and careful way, right? So for example, the first part of the switch to hybrid proof of stake actually doesn't require a hard fork. Technically it requires this weird kind of soft fork where basically it's not even like a real soft fork instead it's just an optional change to the forksuous rule that's used inside of a client. The only thing you would need a hard fork for is when we want to basically stop providing rewards to proof of work miners or at least reduce the words to proof of work miners and switch the rewards to validators. So the switch to proof of stake I'm fairly confident can be done in this kind of gradual fairly conservative way. Main shard has full security basically the same security guarantees we can expect to have now and the governance of the main shard basically in order to kind of satisfy the demand of people that really wants to have basically stronger immutability and less risk on the main chain we can have norms of governance that emphasize conservatism and strong immutability more than today. Now what happens to the new shards? So scalability OFC squared consensus is this proof of stake where in order to vote in the proof of stake you would have to deposit ether into the validator manager contract and the validator manager contract would randomly assign to you the right to create blocks on all of these shards. The security would be 50% on its majority of the on chain proof of stake holders now and basically what we want to do with Ethereum 2.0 and sharding solidify enough then eventually the shards would be kind of tightly coupled and the two would have roughly the same level of security. Now the governance for the new shards is basically just going to be on chain ether voting. So basically for these new shards because you have this proof of stake we might as well have this proof of stake be used in order to basically vote on what the protocol changes are within this sharded universe. So basically validators themselves already are going to be the ones that enforce the consensus rules so why not just have them be just the kind of are the ones that decide on the rules already so we might as well accept this and we basically actually take advantage of this because this kind of on chain ether voting governance would give us the ability to basically emphasize fast evolution in the new shards initially and then when we have this tight coupling and when every client becomes basically a fully validating client for all the shards then the kind of governance would become much more conservative. So this is kind of the dichotomy that I'm suggesting where we can have these two universes at the same time where the universe on the left, the main shard is just basically continuous working as Ethereum. We do not need to negotiate EVM 1.5 negotiate E-wasm between seven different Ethereum implementations and we can focus on relatively milder things that do things like state size control that do things like just improving security, possibly improving parallelizability a bit, heavy focus on the proof of stake switch and we have this other new universe or really these new end universes in which basically the implementation of all of these things that we've already been working on over the last one or two years can basically be rolled out onto the main net much, much faster. So here's what an implementation roadmap might look like, right? So sharding road, basically step one is you would implement this kind of sharding universe as a proof of stake sidechain and in a proof of stake sidechain in each shard you would have collations and the collation headers would be verified and processed by this on main chain validator manager contract. Block creation rights are assigned by a simple proof of stake in the VMC. Clients would just get randomly assigned the right to create blocks and randomly shuffle between shards and in the first step you could have one way ETH convertibility. In the second stage you could make the ETH convertibility two way. Now this is what a node for the Ethereum sharded network might look like, right? So you already have the existing Ethereum nodes that talk to the existing Ethereum network. Everything on the left does not need to be changed one single bit. What you have on the right is you could have a sharded chain node. Sharded chain nodes would be responsible for basically broadcasting full collations, right? So collation headers would go into the validator manager contract. Full collations would only be broadcasted in the sharded chain network between all of the nodes that are participating in the sharding system. So sharded chain node would be written in Python initially and it could be designed in such a way that it can talk to any Ethereum node by RPC. Now if we want fast evolution we could have like basically one or two clients for the sharded chain node initially and then over time ramp it up to the full seven as some more teams become ready. So basically you would have this kind of fairly partial split between what happens on the Ethereum side and what happens in these sharded networks where basically you would really have a sharded network for basically every single shard, right? So after this you would add two way convertibility. You would move the collation headers from the VMC into let's say being main chain Ethereum uncles and then step four would be tight coupling. So tight coupling basically means if you have a block in the main chain that contains a collation header which is invalid then the entire main chain block is invalid. So invalidity on the shard side will be able to cause invalidity on the main chain side. And this would be basically when the main chain and the shards would both switch into this kind of tighter security mode. And stage four is something that theoretically could happen later. Ideally it should happen basically when things on the sharding side are actually reasonably stabilized. So remember the shards that I'm suggesting are creating new address space. They are not affecting existing address space. This gives us a unique opportunity to make many very important, many efficiency improving but backwards incompatible changes to the Ethereum protocol. So what kind of changes do we wanna make? Well, we can just list through a few, right? So number one, changing merkle trees from hexary trees to binary trees. This is a no-brainer. It makes the merkle proofs four times shorter. Account state tree redesigns. So you might want to get rid of contract storage trees. You might wanna have multi-level nested trees. You might wanna have a different account system. These are things that we can brainstorm. These are things that we can think about and optimize. EVM upgrades. So basically, can we make the EVM efficient enough that pre-compiles are no longer necessary? It seems like it's very likely that we can. So in the Ethereum community, we have had these two paths for optimizing the EVM where one of them is the second of Greg Colvin's approach of EVM 1.5, which is more moderate upgrades in addition to the existing EVM. And the second one is this full-scale replacement with EWASM. Well, basically the idea would be let's work together, let's come up with what combination of these two models seems most reasonable and let's just immediately apply it as the only EVM available in the shards. And so this way, you would have much more efficiency without having to worry about as many backwards compatibility issues. Paralyzability. So there are fairly simple Ethereum upgrades that we can do. So EIP648 is one example. There's also a sharding EIP, which has a stricter version of EIP648, which basically lets you execute Ethereum transactions in parallel. If you can do that, then we basically have, if we really, if we want it, kind of unlimited access to the kind of big block scaling route. So if we have parallelizability, if we want to, we could always make the blocks bigger. And all that would happen is that the kind of resource requirements of running a node would just be a bit higher. But if you have enough cores, you would still be able to process a block fairly quickly. So parallelizability is something that if we tried to add it to the existing Ethereum, I mean, it would require some fairly deep changes. But if we can make this kind of new system where we have parallelizability right from the start, then it might be easier. Stateless clients. So stateless clients are a topic that I've written about slightly, but they're a topic that you might end up hearing about more and more over the next few years. While or so, the basic idea behind a stateless client is this, right? So, I mean, as you might have seen from the diagram, stateless clients have something to do with a Merkle tree. Everyone bow down to Ralph Berkel again. Yeah, okay. So consensus nodes do not hold the entire state, right? So consensus nodes, so basically full nodes, minors, anyone, do not need to hold the entire state. They only need to hold the root hash of the state. People who want to send transactions would apply attached Merkle branches, so witnesses, basically proving the correctness of the specific portions of the state they want to access. So if you have a state root, and if I want to send a transaction that sends 10 coins from address A to address B, I would provide two Merkle branches that prove the existing balances of address A and address B. Then the transaction, the blocks would get passed around with the witness, and that's all the information that a node needs in order to execute the block, execute every transaction in the block, and figure out what the new state root is going to be, and what the new Merkle branches are, and what the portions of the state are that got modified by that transaction. So the idea here is that we can substitute each individual instance of a disc read. So basically each individual instance of reading like a storage key or an account from disc, which takes possibly something like a millisecond with about one kilobyte of bandwidth, assuming we optimize the Merkle tree and assuming a billion accounts. If we go up to a trillion accounts, then we'll only need shock core 1,300 bytes of bandwidth. Now the benefits of this are that, first of all, it makes it much easier to reshuffle validators when charting. Basically the idea is that if you're in a stateless client's architecture and used yet suddenly reassigns to a new shard, you do not have to download the state of the shard. In a stateless client paradigm, fast syncing is literally pretty much instant. And this is true regardless of what the state size is. Stateless clients allow us to care much less about the state size. So even if the state was like one petabyte, nobody really needs to store that one petabyte and they massively increase parallelizability kind of as a side effect. This is one other secondary scalability path that basically it might even just make sense to do it in the shorted universe from day one. So regardless of each individual proposal, the general idea is that we could have ongoing development of the Ethereum protocol happen in two layers, where the first layer basically involves relatively small changes, efficiency improvements, getting Casper rolled out. And then the second layer is the one where rapid development and experimentation happens. And it's the one where we could get to thousands of transactions per second, actually fairly quickly, and on a significantly accelerated schedule if we want to. So if there are applications that do not need super-duper high security, then they can just go on the layer too fairly quickly. So this gives us the benefits of basically both approaches at the same time. So safe and conservative layer one and all this rapid development in layer two and the ability to use layer two in order to do all of these protocol improvements that developers have been dreaming about the whole time without having to go through this kind of political process of getting all seven clients to agree on it and write a million tests for it and fuzz it for six months in the short term. In the longer term, even as the sharding system solidifies, of course the sharding system will end up focusing more and more on conservatism and security and eventually the two will be kind of merged in some nice and clean way. But look, this is something that if we want to can wait three or four years. So the good news is that along with the initial work of unsharding, having a proceeding very quickly to the point where we are basically just inches away from having a working CASPER proof of concept testnet in Python, we also have initial work on sharding that's being done in this repo. So we have some developers that are working on a sharding capable client and that are starting to work on some of these stateless client improvements, starting to experiment with some of these optimizations. And the hope would be to also, if there are other client developers that wants to participate in this as well, then look, this is something that should happen totally openly and this is a process that should eventually go beyond just happening inside of one client. And basically in the short term, the sharding stuff would continue as kind of proof of concept in test mode. And the nice thing is that because this is not being done as a hard fork, because this is being rolled in gradually as this kind of loosely coupled overlay at first and tightly coupled over time, basically there is no sharp testnet to mainnet cutoff. So the extents to which the shards are attested and the extents to which the shards are mainnet actually kind of flows fluidly from one to the other over time. So basically this way we can get development of both scalability and a large number of other needed improvements in both quickly and safely with respect to the existing Ethereum protocol. Thank you.