**A** (0:12):
I'm going to give a talk called A Conservative Approach towards a Rival Roadmap. Kind of give you some of my thoughts about Eth 2.0 as well as some learnings that we've done from Cosmos and how I think like, you know, things that should be, I think should be integrated into ethics. ETH 2.0 that could help improve ETH 2.0. So a bit about me. I work mostly on Cosmos and Tendermint, but I also run a podcast called Epicenter. I run a validator called Sitka. So just a little bit of background of where I'm coming from. So yeah, Ethereum 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 phase. I think it's phase numbers I wrong is actually phase zero. But yeah, we have the first phase which is we just basically have this main chain which is the current proof of work Ethereum chain that we have today. And then we start building this beacon chain which 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 can provide data to the shards. Then 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 till now is up to this point, not at this point up to up to this point. Right. You'll notice that there's not much you 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 a WebAssembly VM or something like that. And then finally in phase four we're going to start working on cross shard transactions. And this phase is not even been like spec'd or discussed or like you know, it. 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 which I'll get into in a minute. But one thing that's even more worrisome to me is this one way staking proportion. You know, in this phase, in the first phase we have this one way burn where I have ether on the main main net. Ethereum I have to bur. I don't want to use the word peg because peg implies 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 E. Like 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 word. This is very worrisome to me. So what do I think's 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 to blame for a lot of it. But you know, there are a lot of centralization happening in the valley here. We don't know how resistant it is to cartelization. We don't know. No, 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. But all of these things, I'm very bullish on proof of stake. But the main fundamental issue proof of stake is it's highly experimental. And I just do not feel comfortable shifting a, a $30 billion network to this untested security model. Like, you know, I think that will eventually we'll find out the answers to these questions, but it'll take time and experimentation and I don't think trying to 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 it as fast as possible. I think that's making some tasty decisions. So. And I think the problem came when we started this, which is the merging of Casper and Sharding. I think that, you know, up until last year, up until last summer, the Casper team research team was distinct from the Charding team. And then about last summer they decided to merge these into, you know, Shaftsper or E 2.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 Sharding is way more important than proof of stake. Like, you know, Sharding there's an immediate, urgent demand, need and demand for it. We need it to scale Ethereum 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. Okay, this is what we have today. The current Ethereum main chain. We have proof of work and we have EVM here. Let's first off, you know, let's focus more on side chains where, you know, and let's test these sidechains with proof of stake and these proof of stake. 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 eth back and forth onto these sidechains, use them there, move them back, these side chains that have the EVM on them. We already have a lot of people experimenting on things like this today. Like the POA network has their xdai chain 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. 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, it's really generalized. So you can allow you to talk between many different frameworks. You can talk EVM chain to Cosmos SDK chain to the yellow chain to a parity substrate chain. That's really the goal. But yeah, so let's test proof of stake on sidechains first, then eventually, then 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 like, you know, there's a lot of research that's already been going into how to like, make more and more trustless sidechains, and I think we should really double down on those efforts. I think the Scaled Labs people, they've been doing a really cool job on coming up with some great ideas there. You know, I don't want to. I don't want to go too much into their stuff, but, you know, you should take a look at how they do it. They have this one like one staking manager contract that basically assigns validators to different shards on their system. And it's running on the Ethereum proof of work chain in the evm. There's also a lot of other cool stuff like you know, the mat. Like everyone who's working on ZK rollup I just thought matter as an example but there's a lot of cool people working on like ZK rollup techniques. The plasma group came up with this OVM system with and some people at consensus they have some cool stuff with minimal viable merge consensus. This guy, you know, many of you know him, he's been cracking my high low. He's been kind of working on a lot of cool ideas and here he has like secret projects. So I can't go too much into it but he's working on some cool stuff along these lines. So 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 like, you know, keep the EVM on there but remove the like plug into it where basically stop allowing people to deploy new contracts on the root chain. So 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 onto 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 root EVM onto other chains. And then finally when a lot of time goes by, like you know, maybe five years, something 10 years, you know proof of work has proved itself on Bitcoin and ethereum for like 10 years. I think proof of stake needs that level of confidence and like 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 2.0 roadmap. Now we'll talk a little bit about application specific shards which I think that's something which I think is great that I've seen this actually happening in the last couple 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 this is 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 a lot of the biggest contract bugs usually have come from weird vulnerabilities and like nuances of pvm. Whether it's a DAO bug, the parity bugs or most of the bugs usually come from weird things. With PVM 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 opcode 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 zcash 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 is 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 no, 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 good 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 we should be focused on 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 is 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 be on Ethereum is a parasitic relationship in both directions. Maker hurts Ethereum and Ethereum hurts Maker. Here's why so Ford maker, as a DAI 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, by 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 demands 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, I don't know, Perry decides to get their funds back or maybe it's Prague POW or something, you know, who decides which fork wins. Historically I would say the EF is probably one of the strongest voices on which side of the fort 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 stopped running the Oracle, the DAI 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 shards where they don't have that much high control over the governance of the system as a whole, I think that can help a lot with some of these kind of dilemmas and better for the maker system, the die holders as well. Okay, I'm going to do another time. Okay, so the next thing I'd like to talk about is delegation in protocol. So in 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 of the delegators to that validator go down together. Now Ethereum thinks that we could do this process through smart contracts where you could go ahead and as a validator I want to go validated company called Sitka. I go ahead and deploy a validation contract and people can give ETH to me in the contract and I can validate on their behalf. This is suboptimal. There's some easy reasons why it's suboptimal. 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 delegate 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 ETH 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 unbond bonding period. I've got what the recent numbers are. If it's around 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 my who I'm delegated to. This makes validation delegation super sticky. If you have delegation in protocol, what you can do is you can just instantly swap delegation your eth from 1 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 delegate 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 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 you, as fast as they want. They can just instantly, you know, let's say this, I'm delegated to, you know, I'm mining with a pool that support 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 gonna get into a very sticky validator set that's not gonna 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, validator one, we should slash validators more for the larger the validator is. So let's say one validator, this validator has 5000 ETH and this one has 1000 ETH 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 slash because they're bigger, but they also get a higher percentage of tokens slash. This incentivizes people to not delegate towards larger values, incentivizes to go towards smaller validators. But now. Wait, what, What? Why wouldn't I just instead. Just sybil right, like Instead of running one validator of 5000 ETH, I'll split that into five validators of 1000 ETH 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 one validator of 5,000 ETH double signs, maybe we can slash them at 5%. But let's say five validators of 1,000 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 unlived during the same epoch, we slash them even more. This also has a very nice side benefit that it 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 them as possible so you don't get slash 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 of groups. This is if you, if you. This might sound like a familiar formula. It's also similar to the one that's in the like quadratic, the radical market stuff, the quadratic stuff. It's a very 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 slash. 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 use a formula, it actually magnified because two validators slash 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 there's someone else who's a validator of 1% and you both double sign together. You get slash at 29. There's 29% slashing. But. But what if the other person is trying to grief 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 the account the inverse Gini coefficient. So the more unequal that validators, the number of validators got slashed in that epoch, the more unequal their stakes are, the lower that constant should go and the more equal their stakes are, it should go higher. And so that will kind of basically help solve a lot of the. Those kind of griefing attacks. Yeah, that's it. Thank you so much.