 I'm going to give a talk called a conservative approach towards a radical roadmap. Kind of giving a short of some of my thoughts about ETH 2.0 as well as learnings that we've done from Cosmos and how I think like you know things that should be I think should be integrated into ETH 2.0 that can help improve ETH 2.0. So you know a bit about me I work mostly on Cosmos and Tenderband but I also have a podcast called Epicenter and a podcast called SICKA so just a little bit of background of where I'm coming from. So yeah at the end of 2.0 the basics many people are probably somewhat familiar but just for a brief overview what we have is we have this multi-phase system where we have this like phase I think this phase numbers are wrong it's actually phase zero but yeah the first phase which is we just basically have this main chain which is the current proof of work theory that we have today and then we start building this beacon chain which is provides this Casper FFG state. Then we get to phase two then so this phase zero thing this is what's happening in like a couple of months. Then eventually we'll get to this point where we start to do shards and we provide data to the shards. Then in the next phase we'll finally start to add an execution engine. By the way so far the only thing that has been planned up to now is up to this point not at this point, up to this point right. You'll notice that there's not much we can actually do with these shards yet. Then finally in the next phase we'll add the execution engine where we can actually run an EVM or WebAssembly VM or something like that and then finally in phase four we're going to start working on cross-shared transactions and this phase has not even been like specced or discussed or like you know. So this is kind of like you know my main issue here is I think this is going about it in the wrong order. I think we'll talk about it in a minute but one thing that's even more worrisome to me is this one-way staking portion. You know in this phase, in the first phase we have this one-way burn where I have Ether on the main net Ethereum. I have to burn my Ether. I don't want to use the word PED because PED implies you can bring it back somehow. I have to burn my Ether and then that gets sent over and you'll notice it's a different color because you know it's a different type of Ether. If you can't transfer it back I think that these things are going to have two different exchange values. They're going to be treated very differently and you know when you try to bring it back you can't. It's a one-way burn. This is very worrisome to me. So what do I think is wrong here? So you know heads up I love proof of stake. You know I've spent the last two and a half years of my life working on proof of stake but you know proof of stake has some problems as well. You know you know we don't know exactly how it faces with decentralization. You know in cosmos we see this concern today where there are you know I'm partially blaming for a lot of it but you know there are a lot of like centralization happening in the ballot here I said. We don't know how resistant it is to cartelization. We don't know you know especially in a proof of stake system where you use the money token as a stake. How does that affect the economics of the system? What kind of censorship attacks are possible? One thing I'm personally very worried about is the neutrality of proof of stake which we can get into later. You know all of these things you know I'm very worried about proof of stake but the main fundamental issue with proof of stake is it's highly experimental and I just do not feel comfortable shifting a 30 billion dollar network to this untested security model. Like you know I think that proof of stake will eventually will find out the answers to these questions but it will take time and experimentation. And I don't think kind of jump head first because and I think there's like sort of panic moment where it's like oh we feel like we're behind and so we need to like just jump into the next fast spot. I think that's making some tasty decisions. So I think the problem came when we started this which is the merging of Kasper and Shardis. I think that you know up until last year up until last summer the Kasper team, research team was distinct from the Shardis team. And then about last summer they decided to merge these into you know Shasper or E2.0 or whatever. And so this is where I think the things went wrong and I would say that you know when we're weighing these two things I think Shardis is way more important than proof of stake. Like you know Shardis there is an immediate urgent demand need and demand for it. We needed to scale a theory of proof of stake. You know it's great but I think it can come in time. And so here's my proposal of what I think is a more reasonable way of approaching it. Okay this is what we have today. The current Ethereum main chain, we have proof of work and we have EVM here. But first off you know let's focus more on sidechains. Where you know and let's test these sidechains with proof of stake and these proof of stake tracks. So you stake your Ether on the Ethereum main chain and then you could become a validator on the sidechains. And so you know you can move your Ether back and forth onto the sidechains, use them there, move them back. These sidechains that have the EVM on them. We already have a lot of people experimenting on things like this day like the POA network has their X sidechain and stuff and so this is really good. But they're not using it. They're using it with proof of authority. I think what we should be focused on is experimenting with proof of stake on sidechains first. Also you know a little bit of a plug for Cosmos. You know if you don't want to use the EVM for all these you can use different types of VMs and systems. The purpose of IDC which Chris gave a great talk on it this morning is really generalized so you can allow you to talk between many different frameworks. You can talk EVM change or Cosmos' decay change or yellow change or parity substrate change. That's really the goal. So let's test proof of stake on sidechains first. Then eventually there's already so much great research happening in the process of... I think that the thing between sidechains and shards it's a little bit more of a spectrum. There's a lot of research that's already been going into how to make more and more trustless sidechains. I think we should really double down on those efforts. I think the scale labs people they've been doing a really cool job on coming up with some great ideas there. I don't want to go too much into their stuff but you should take a look at how they do it. They have this one staking manager contract that basically assigns validators to different shards and stuff and it's running on the Ethereum proof of work chain in the EVM. There's also a lot of other cool stuff. Like everyone is working on ZK roll up. This doesn't matter as an example but there's a lot of cool people working on ZK roll up techniques. The plasma group came up with this OVM system and some people had consensus. They had some cool stuff with minimal viable merchant senses. This guy, many of you know him. He's been kind of working on a lot of cool ideas and here he has secret projects so I can't go too much into it but he's working on some cool stuff along these lines. I think we should really be focusing on building these proof of stakes, testing proof of stake at the shards. Then, once some time passed, then what we can do is suddenly take off the, keep the EVM on there but remove the plug into it where basically stop allowing people to deploy new contracts on the route chain. All the contracts that are still there still are running but no more deployment of new contracts. If you want to deploy a new contract, they go on to the shards. Next, after some more time goes, then we can start to allow a system that allows you to easily migrate some of the contracts off of the route EVM onto other chains. Then finally, when a lot of time goes by, like maybe five years, something, ten years, proof of work has proved itself on Bitcoin and Ethereum for like ten years. I think proof of stake needs that level of confidence and history to it before we should be ready. Finally, we can go ahead and change the proof of work chain to a proof of stake chain. How am I doing on time? Okay. Cool. Now, so that's kind of my proposal for the ETH 3.0 roadmap. Now we'll talk a little bit about application-specific shards which I think is great that I've seen this actually happening in the last couple of months now with this whole execution environment idea that's kind of being adopted which is really good and so I can just talk a little bit about why I think it's great. So, you know, I think smart contracting systems really should be used for contracting, not for applications. Now, contracting are things that like are short-term, one-time use things need high levels of customizability. ICOs are the like perfect use case for smart contracting because they are short-term use things. They need high levels of customizability. But like, you know, if you're building a DEX, you're building a prediction market system, you probably want a more custom-built, efficient state machine for this. You get a lot of benefits when you do this. You reduce a lot of the attack surface, a lot of the issues with, you know, a lot of the biggest contract bugs usually have come from weird vulnerabilities and like nuances of EVM, whether it's the DAO bug, the Parity bugs, or, you know, most of the bugs usually come from weird things with EVM. You get a lot more efficiency gains because you have a custom-built state machine. You're not, you know, you're not, this is like, you know, if you have, you can have a much, instead of having this giant opt-code system and running on interpreted code, you know, you have much more simplistic state machines which makes it much more efficient. Finally, you can fine-tune to optimize for your application. So, you know, right now, you can't really implement Zcache like privacy in the EVM in an efficient way because it's very, you know, it's not fine-tuned for it. A great example actually, it's missing the cryptography that you need. A great example of fine-tuning for your application, if you want to build a payment system, right? Payments, there's a reason Bitcoin was built as a UTXO system. UTXOs are better at payments because, you know, they can be parallelized way more easily. But, you know, the EVM was optimized for the average use case, not for the specific use case. And so, for the average use case, you need an account because, but if you want to build a payment system, you probably want to optimize for your application. Choose the best design patterns that are here for your application. And so, this is why I think you really should be in this Ethereum sharding, you should kind of not be focused on trying to make all shards equivalent, they all run the same VM, but really, you should be focused on application-specific shards. And this is kind of what, like, Polkadot has been doing for a while and it's actually, it's great because I think Ethereum is starting to realize this and it's shifting towards this with the whole execution environment system. The other thing is what I like to call the maker dilemma. So I'd like to explain why I think maker should be not on Ethereum. I think maker being on Ethereum is a parasitic relationship in both directions. Maker versus Ethereum and Ethereum versus Maker. Here's why. So, for a maker, as a die holder, you are getting the security of the MKR token. If the MKR holders wanted to, they could steal all of the collateral from the maker system. So you're getting the security of the MKR token, but you're paying for the security of ETH, which doesn't make sense, you know. But paying your transaction fees at ETH and like, you know, the gas fees are like changing relative to the demand of Ethereum rather than to the demand of the maker system. And so you're overpaying for security. It's harmful in the other direction as well because let's say there's a contentious hard fork in Ethereum tomorrow. That's, I don't know, a pair of you guys get their funds back or maybe it's CROGPOW or something, you know. Who decides which fork wins? Historically, I would say that ETH is probably one of the strongest voices on which side of the fork wins. But I'd say today I think it's probably the MKR holders because the MKR holders could decide, you know what, in this contentious fork, we're just going to stop running the oracles on one side of the chain. And when they start to stop running the oracles the dye on that side of the chain just crashes and the entire DeFi ecosystem on that side of the chain crashes. And so this is kind of very, so this is giving the MKR DAO, the maker DAO, way undue amount of influence over Ethereum governance. And I think this is unhealthy for Ethereum in the long term where you give certain projects or entities such a high amount of influence. And so this is why I think by putting the applications on their own isolated charts where they don't have that much high control over the governance of the system as a whole, I think that can help along with some of these kind of dilemmas. And better for the maker system the dye holders as well. Okay, I'm going to do that. Okay. So the next thing I'd like to talk about is delegation and protocol. So the Ethereum, they very much don't, they don't want people to, at the base layer, they don't have this notion of delegation. In Cosmos, what we do is, you know, validators and delegators, in the protocol you can go ahead and delegate your atoms to a validator and they would basically state for you. And then the protocol would keep track of like, oh, okay, these many of my atoms came from this delegator, these many of mine came from this delegator, what not. And if this validator gets slashed, then all the delegators so that the validator go down together. Now, Ethereum thinks that, you know, we could do this process through smart contracts, where, you know, you could go ahead and, you know, as a validator, I have a validator company called SIGGA, I go ahead and deploy a validation contract and people can give each to me in the contract and I can validate on their behalf. This is sub-optimal, there's some easy reasons why sub-optimal, one is, you know, I don't really want thousands of validators writing their own contracts, eventually some of them are going to have bugs, I'd rather have a default one into the protocol. But more importantly, there's a feature you can only get when you put delegating in the protocol natively. So, let's say, it's called instant redelegation. So, this is how redelegation would have to work in Ethereum. So, let's say I have some each delegated to validator A and I want to change it to validator B. What I would have to do is, I would have to unbond from validator A, wait the entire unbonding period, I've got what the recent numbers are, it's about three months or six months, so I have to wait that entire unbonding period, then I get the money back in my account and then I can delegate to validator B. That means I have to go for months without rewards just in order to change who I'm delegated to. This makes validation super sticky. If you're a delegation in protocol, what you can do is you can just instantly swap your ETH from one validator A to validator B instantaneously and what we can do is we can put, because it's all in the same state, we can create something called pseudo unbonding period. So, let's say you're delegated to validator A, you go ahead and change it to B. What happens is you're put into a pseudo unbonding period for validator A while you actually delegated it to B and you're getting the rewards from validator B. But, let's say some evidence comes that you double signed or something, we can slash you because it's all in the same state. We can still slash in validator B even though you're in this pseudo unbonding period for validator A. So, this is really important because I think it will reduce the stickiness of delegation. You know, proof of work centralization isn't great, but it's not that it's okay because miners are able to jump between mining pools as fast as they want. They can just instantly, you know, let's say I'm delegated to, you know, I'm mining with a pool that is supporting a bit that I don't like, I can just easily switch my hash rate to a different pool. And we need to make it that easy to do for delegation as well, otherwise we're getting into a very sticky validator set that's not going to be able to change over time. Finally, the last thing I'd like to talk about is proportional slashing. So, proportional slashing is also something that, you know, I think Ethereum has started to adopt since we started talking about it, but, you know, the idea is, you know, we should slash validators more for the larger the validator is. So, let's say this validator has 5,000 e, and this one has 1,000 e, and they both get slashed. This one should get slashed at a higher percent, 5% rather than 1%. So, not only do they get more tokens slashed because they're bigger, but they also get a higher percentage of tokens slashed. This incentivizes people to not delegate towards larger validators. Otherwise, you could go towards smaller validators. But that way, why wouldn't I just instead just civil, right? Like, instead of running 1 validator of 5,000 e, I'll put that into 5 validators of 1,000 e each. So, what we can do here to solve this is we also punish more heavily the more number of validators fault at roughly the same time. So, if 1 validator of 5,000 e is double signed, maybe we can slash them at 5%, but let's say 5 validators of 1,000 e each slash, we should slash all of them at 20%. So, we kind of have to take, within an epoch, we can say if multiple validators double sign within the same epoch or are online during the same epoch, we slash them even more. This also has a very nice side benefit that incentivizes you to de-correlate yourself from all the other validators. So, let's say you know many other validators are running on Google Cloud. You want to not run on Google Cloud because you know that if Google Cloud has some issues, they're going to go offline and you want to be as separate from that as possible so you don't get slashed at a higher rate. And so, you know, this is the general form of the equation that I think really works. It's the square of sum of square roots. This might sound like a familiar formula that's also similar to the one that's in the quadratic, like the radical market stuff, the quadratic stuff. It's really a useful formula and so, you know, we can see it actually gives you a lot of the benefits you want where like, you know, the more validators are slashed, you know, if these two, if we weren't taking into account, you know, we had 1% and 5%, it would look like there's a 15% slash. But really, because we've used this formula, it actually magnifies the slash more because two validators slashed at the same time. And so, you know, what we might want to do is add some constants to this. How do we choose what to add the constants? One thing that I think we should do is let's say you are a validator of 10%, and if someone else who's a validator of 1%, and you both double sign together, you get slash at 29. There's 29% slash. But what if the other person is trying to grieve you? They're willing to lose that 1%, but in order to punish you as much as possible. So what they could do is they could actually split that 1% into a thousand different validators and get them all to double sign at the same time as you. They lost the same amount, but they suddenly magnified the slash to 1,300%. Which is crazy. And so what we should actually do is this k should be kind of based off of, you should take into account the inverse genie coefficient. So the more unequal that validators, the number of validators you've got to slash in that epoch, the more unequal their stakes are, the lower that constant should go. And the more equal their stakes are, they should go higher. And so that would kind of basically help solve a lot of those kind of greaking attacks. Yeah, that's it. Thank you so much.