 And we're alive. All right, guys, we've got a special show for you today. We are going to be discussing what is proof of stake for Ethereum. Hopefully, our special guest, Rick Dudley, will be explaining that understanding. But above first, his bio. Rick Dudley is an opinionated and passionate developer. He works very closely with Vlad Zamir, Zemmifer, on implementing CASPER in Ethereum, and is the leading member of Koala Organization as a founder and CEO of the startup of Alcanize. Rick, welcome to the show. Hi, thanks for having me. Hey, thank you for joining us. So as the title states, we're going to be talking about proof of stake. So why don't we kind of dive in, and maybe you can give us the bird's eye explanation of how Ethereum wants to implement its version of proof of stake. Yeah, so CASPER is the working title. I'm pretty sure it'll be the production title for the Ethereum proof of stake protocol. What it does is it provides a set of, basically, the validators create a set of justifications or a set of bets on which block they think is going to be the next block, and then they provide a bunch of justifications for why they think that block is going to be the next block. And then in that process, the justifications are basically irreversible. So when a validator says that this block is going to be the next block, they provide a set of justifications that should never be reversed, basically. So the main property is that it's a monotonically increasing set of confirmations. And if the confirmations ever go down, that's because a validator equivocated, and they can be detected. So those are sort of the main differences, I think, between. And then the other thing is sort of that you can get, there's an interest in the CASPER community for, in most Byzantine fault tolerant algorithms, we kind of group all the Byzantine faults together. And with CASPER, the exercise is in separating out those Byzantine faults and then taking different actions based on the different types of faults that there are. So from that, you can also sort of get better guarantees about performance, even if you're under like a 51% attack or some of these other states that normally a proof of stake algorithm wouldn't operate under. Can we dive a little bit, because I'm kind of confused myself, but can you explain a little bit more on the whole concept around sharding? Yeah, I mean, I think there's a couple of different sharding proposals, and there's a lot of work going on sharding. But conceptually, it's just you have one blockchain that sort of has the primary chain. And then as in the CASPER model or in the proposed and future Ethereum sharding model, which doesn't really have a name, as the network will dynamically create sub-networks, they'll create, if you have five validators, two of them will split off and they'll maintain consensus amongst each other and then periodically publish that consensus to the larger network. So it's very similar to sort of more traditional scaling solutions that you see just in databases. And so in traditional databases, you have a concept of a database shard concept, where each individual shard is smaller than the total parent network. They have information that's local to them. Some of the challenges are availability. So I mean, that's kind of the big challenge. I mean, since we're being brief, I'll just mention this one, which is I'm on a shard. I tell the parent node available via by committing a hash to the blockchain when that data is unavailable and why is it unavailable? And how do we punish people for data not being available? How do we make the data available across shards? There's a lot of questions around, in particular, data availability across shards. Interesting. So does that new product affect how EVM is currently structured? Absolutely, yeah. So it depends exactly on what we're talking about. But so you can imagine that you can change the consensus algorithm and not change the EVM. But if you're talking about sharding, then you probably need some sort of model for namespaces. You need a way for an application or a transaction to know which validators. Like a user has to know which set of validators to send a transaction to. And usually, that means you need some sort of way of routing and naming, routing messages between the shards and then naming and identifying the shards and then also figuring out which application is running on which shard. So how far are you guys on deciding what type of protocol you guys will pick for the sharding system? Well, I know that Vitalik's been making a lot of progress on that lately. This progress is right now. It's definitely a top-down approach where, since everyone sort of figures out which applications go on which shards, validators don't really know which shard they're on until they're on it. There's some other desirable properties. But I think, again, that's just for the sake of brevity. Can you talk a little bit more about the staking itself? So I assume there's a minimum of ether you have to stake to become a node? Yeah, again, Vitalik has numbers in mind. They're pretty big numbers. OK. And obviously, you have to tune it and figure it out. So yeah, so to become a bonded validator, what you have to do is you have to register. So there's going to be a new genesis block for the proof of stake system that's going to be published to the proof of work system in parallel for some period of time. And then as validators bombed with that new contract, obviously get locked up in that contract. And then they can start participating in consensus. And then when they fail to participate in consensus, part of that bomb gets slashed. And if they equivocate them. So again, for a little bit of time, it's going to be a hybrid version of POS with proof of work. Yeah, but it's not going to be. It's more like two parallel chains where one is reading the state from the other. So basically, the proof of stake network will be reading state from the proof of work network. But the proof of work network probably won't be reading state from the proof of stake network. OK. So that eventually you can turn off the proof of work network and have all the state from that network into the proof of stake network that's already running. And then you guys are first launching this on Testnet before Mainnet? Oh, yeah. Of course, there's going to be several Testnets. There's going to be more than one. So like during your research and during your discovery mode over here, what would you say is the biggest hurdles for, let's say, making this proof of stake system actually work? Oh, so there's two major problems. One is how do you have a consensus algorithm of this type resistant to griefing attacks? I think that's a major issue. And how do you make it? And then related to that is censorship resistance. How do you make it censorship resistant and have the strong censorship resistance guarantees that the Ethereum community, Vlad and Vitalik, kind of spearheading desire? So that's a big challenge. And then the parallelism, composability, multi-threading stuff is a really big issue. So the existing EVM, the existing Ethereum network is effectively single-threaded. It does everything sequentially in order and everything is in it. You need to do that in order to have a single ordering of the transactions in the blocks, but that doesn't scale. So what you want to do is you want to have multiple threads of processing happening in parallel. And you want to be able to know at compile time, actually, how to separate out those processes. So you want to be able to say, oh, these two dApps never talk to each other. So they can be on two shards that are very far away. Whereas if you have two apps that talk a lot to each other, maybe they need to be on the same shard. And then if you have some apps that talk often, but not all the time, maybe they need to be on closer shards. And so figuring out how to do all that multi-threading, figuring out all of the logic behind that is another obviously pretty big challenge and a pretty big shift from what the EVM does today. How many people are currently working? Like you, Vlad, Vitalik, how many others are working on this? I'm very part-time. Vlad and Vitalik are very full-time. I mean, they're way more than full-time. Greg Meredith works, contributes. He has a team of people who contribute. Carl, whose last name is Escaping Me. He works on it full-time as well, implementing Casper in the PyEthereum code base. So you can go to the Ethereum GitHub. I'm pretty sure you can find his work there. And I think there's probably two or three other people that come in and contribute. A lot of the contributions are kind of part-time stuff because people, it's volunteer stuff. But I think those are kind of like the main, I don't think I'm leaving out any main contributors. Apologies to whomever I'm forgetting. I'm pretty sure it's fine. Let me ask you this. What would you say are, I'm gonna play a little bit Devil's Advocate over here, but what would you say are the main skeptics attack, I wanna say attack, but worry about this proof of stake. What's their main about going forward? Yeah, the main issue that people have is the problems that were solved years ago on proof of stake. So the term, I think, is sort of saddled with early implementations that simply didn't work. And so they were susceptible to nothing at stake attacks and long-range attacks. Both of those issues are resolved pretty easily with just, you know, bonds and, yeah, with bonds. And stake grinding is the third attack. But all these attacks are addressed and have been addressed within the community for a number of years. So Casper has its own solutions to those problems. When I read people's criticisms of proof of stake, oh, and I guess the other, so those are sort of the three illegitimate complaints. And then I think that there's another category of complaint that I did, but is much more legitimate, which is that it's a different security model than proof of work. And I'm like, yeah, it's a different security, ultimately a lot of arguments distilled down to that, where people are like, but this from proof of work or that from proof of work or this, and I'm like, yeah, that's all true, but this is a different security model, apply. And I think that you have the option of having higher security with proof of stake. I mean, again, it depends on, it's a pretty subjective thing, actually. I mean, there's the facts that you can sort of break down. And then, but then your risk profile is a very personal thing. So maybe you're more comfortable with the risk profile of proof of work than you are with proof of stake application or community or whatever, but that doesn't mean that proof of stake doesn't work. Okay, so let's talk about this. Let's say it's implemented. Let's say it goes live right now in a second. It went from test.net, main.net, everything works. The existing DAPs of a built on top of Ethereum right now, will they have to change how they had their initial set with Ethereum? I mean, that's a complicated question. I think the short answer is that existing apps will be supported on the new chain. And because it's kind of like a hard requirement, right? Like to try to modify that code would be extremely complicated. Just from an operational perspective, especially in a decentralized context. So I think that the existing code, the existing byte code will run. And I think that will take the existing high level languages and generate new byte code for new contracts. Cool. And I know you can't really, you couldn't really figure out the timeline, but still on track for at least starting to implement Casper at the end of the year. You mean deploy, there's a lot of code written. There's a lot of repos available that people can look at and see and progress is being made. Yeah, I mean, I think whatever the existing timetable is, I think we're probably hitting it or a little bit faster. That's really good to hear. Yeah, I mean, I say a little bit faster. I mean, a very little bit faster, right? But yeah, as far as I'm concerned, it's moving along quite quickly. Well, because Vlad's correct by construction model, once you sort of get everything done, it's all done at once, right? There's not a lot of incremental steps. There's not a lot of milestones. It's like, oh, here's the algorithm and then everything kind of works. So, I mean, basically Vlad just started talking about that a couple of days ago that he basically got a lot of algorithm, like basically the whole algorithm nailed down at this point and then they need to implement it, but they've already have a partial implementation that'll probably cover, almost certainly will cover the majority of the full implementation. So then obviously an enormous amount of testing and an enormous amount of integration occurs after the algorithm is solidified. Cool, awesome. Well, I think we've got that. You know, I just want to thank you for answering all my questions on Proof of Stake and hopefully some people have learned something over here. If people want to get ahold of you, what is the best way to contact you? Twitter, probably, at AF Dudley Zero. And I'll just type that to you in this thing, so. Make sure that goes in the show notes. Yeah, that's probably the best way of getting in contact with me. Then the next best way would be email. Yeah, this isn't really secret. That's probably the next best way of getting in contact with me. Yeah. Awesome, well, Rick, thank you so much for coming on the show and talking with us and have a great day, brother. Thanks, Amir, bye. Cheers.