 Okay, good morning everyone now everyone can definitely hear me Let's see if I can okay. Here we go. Okay. Yeah, so finality gadget will be Okay, yeah, so the finale gadgets and research we've been looking into to use the beacon chain from ETH 2.0 to enhance the security of The ETH one that chain So here I will explain what it is. You might have heard of it in like a lot of different contexts So we'll just kind of go through it I'll try and show you why we want it. Hopefully there's like some fun reasons Then we'll talk quickly about how we get it And yeah, then we'll wrap up by seeing how you can help So yeah, this is like super high-level TLDR Like I said using the proof of stake beacon chain from ETH 2.0 to enhance the security of the proof work chain we have today So you're like well, what's going on? There's now there's more blockchains like how does this work? Here's this little picture. So again, because this is gonna like couple these two systems together There's like a lot going on. So I try to be clear like there's this 1.0 blockchain, right? So this is like the proof work chain we have There's the 2.0 beacon chain and I'll explain a little bit more what that is exactly and then this will become clear later But essentially this this is like showing finality extending from the 2.0 chain to the 1.0 chain We'll go into a lot more detail on that So I'm sure you've seen this like a thousand times by this point very briefly. We'll break down ETH 2.0 There's a beacon chain. It's a proof of stake blockchain completely new chain from the existing one and It's gonna build out this new shorter system that we'll have very soon The way we do that is we have this beacon chain, which is like sort of the system chain It operates and manages validators in the system Then from there we have all these chart chains, which are all these little circles Let's say there's like a thousand of them. That's where user-level transactions will happen and Ultimately we'll have phase 2 then we have like all of the fund-apps we know and love on these chart chains Hopefully with like much great much greater scalability So yeah, then the question is always okay. This is great You might have noticed I keep saying phase phase 0 phase 1 phase 2 because the system so complicated We're like breaking this out into phases. So it's just easier to get right to have like discrete chunks we can kind of go and deploy one at a time Then of course I was like, okay, when is this happening? The short answer is like when it's ready We don't want to like rush anything and there's a lot to get right. There's a lot to get wrong So in the meantime you can ask, okay, what about the chain we have today? Then we have this whole bundle of initiatives to Ethereum called Ethereum 1x again, you've also probably heard a lot about this over the past couple days It's a like bundle of features to improve the theorem we have today. Keep it going So like Alexa has been looking at state management and like state growth on the chain and like deploying some sort of state fees To help with the growth there Updates to the VM So this is for example would be like the point you wasn't pre-compiles to accelerate certain parts of computation on chain Protocol economics you probably heard of EIP 1559 which is changing how transaction fee markets work so that they're less volatile on things and Then finally another one of these is the finality gadget, which we'll look at now Okay, quick diversion. We're gonna talk about the finale gadget for the rest of the talk But I just want to take a moment to like communicate that We can actually get tangible value out of each phase of this e2 deployment With phase zero we can do the finale gadget, which we'll look at soon with phase one We can actually think about using the shard chains Is this like data layer for the existing chain and that let's us do cool things like plasmas UK roll-ups ZK ZK roll-ups, which is an idea Vitalik had anyways all these like cool layer-to-scaling ideas that we can leverage these shard data chains for Once they're deployed Then finally phase two Again, there are a lot of ideas around how to like move each one into e2 and Yeah The main point the main takeaway here is that you know, it's it's not that this all this cool stuff is like far many years Way with each step of this deployment. We can like get something really cool On the theory of today Okay, so back to the finale gadget Like I said, we're gonna have the two a chain. There's this process of the consensus on the beacon chain called Casper Part of Casper is finality and finality are essentially a set of rules that say once validators in the system have made So many statements of a certain form Basically, you can't like fork the blockchain from we'll call a finalized block Without burning like a ton of the validators bonds and that's how you keep the system secure So like in theory you could like make these bonds arbitrarily high. So you get arbitrarily high security We then want to say, okay, let's use this security on the the preferred chain Finality at it. So like breaking it down. There's like two key pieces or like mechanisms, right? So we'll call it the finality engine, which is like how we get this finality in the first place then Hopefully I made it clear like these systems are like very uncoupled and so You know finality is happening here And unless this part learns about this part, then there's no way to finalize this stuff It's like whatever's up here could be finalized and then it's just like kind of floating out in space We needed it. We need a way to learn about the if one Chain That's why I mean to be heard by if one data. So the first bit is the finality engine So we'll quickly go through this finality thing again, here's a blockchain It doesn't really matter which one proof of stick block chain, you know blocks blocks have links to their previous block So the idea here is that these arrows are indicating that The proof of stick validators in this system are like making these these messages these as test as testations is a term You may have heard they're like, yeah, I think like this is the next block in the chain and and That's kind of one of their main duties in life as a validator is to like make these messages because as we'll see in a second We can kind of look at these messages and figure out If we hit our like security thresholds or not So the the next bit of finality is this process called justification and these are these thresholds. I was just talking about So what we're gonna say is that you know, let's say there's like You know a group of validators if two-thirds of them all Make an attestation or this, you know this claim that this next block is in the main chain And if two-thirds of them do that then we're going to say that it's justified and that's why I'm indicating here by this gold arrow You see down here. This one's still blue so like maybe we're at the head of the chain and Validators are working on it, but not everyone has like made their attestation yet, right? So we're not quite there Something also to note is that you can actually like, you know skip blocks here. So like this would actually suggest there there are no messages made no attestations and That's okay. You can just keep going as you see now. We get to the fun part finality There's like this very special rule that you just have to learn and basically it's the rule is if I justify On top of something justified then this first one's finalized and this is just the pattern that you have to like apply and I'll show you in a second how we get security out of this but essentially, you know, so we can say okay justification on top of this one This is finalized Justification so the thing is it's not just justification sort of in sequence, but like direct sequence meaning this this block is not finalized because There was not like a direct descent of this that was justified Then we see down here. We like skip some blocks. Maybe there's like just somewhere network latency rate and Then we keep going so then this block was justified from back here We justified directly on top of it So this one's actually finalized and then we have this situation where like we're trying to build finality on the head of The chain down here Now we get to the bit where the security comes in you've probably heard of these slashing conditions And these are rules that basically enforce really this year what it's saying is that as Long as some like conditions hold in terms of like these patterns of justifications and voting's you can't finalize two conflicting blocks So let's let's say there's a fork here, right? These blocks are the same height You can't finalize two conflicting blocks without either Well really without at least a third of the validators losing their sake So that's what I'm trying to show over here. We like burned a third of the ETH that was validating not good And we can actually prove this there have been that like mathematical proofs There's work in sort of formal verification of these systems all this good stuff And really I just like sketch the intuition here like as long as we haven't had one of these attacks We haven't you know had one of these events where all these validators were slash Then We have sort of one single history and like here. We see this is like what's supposed to happen Even if there was a fork sort of broadcast on the network What still happens is that you know two-thirds? Majority of the validators went down this fork They did not go down this fork and so as long as you know who the validators are you can actually determine this Based on the messages on the network and figure out the true chain and to give you some sense a Healthy amount of ETH that might be validating and eth2o is say 10 million So then for one of these attacks to be successful, right? That's a third of the ETH has been burned 3.3 million based on numbers yesterday. That's over 630 million dollars And this is sort of per attack. So quite expensive Okay, that was a very compressed explanation of finality We'll now talk about how the beacon chain learns about eth1 data and then we're going to do Is as we finalize the beacon chain which learns about this eth1 data will end up finalizing the eth1 chain Hopefully that's clear So how this works in practice is that? We'll deploy this beacon chain. There'll also be what's called the deposit contract And with this deposit contract the idea is that anyone can then make a deposit of ETH to this smart contract on the eth1 chain The eth2 chain is then essentially a light client of this contract and is watching this contract And that's how validators enter the system. So, you know, it's sort of trustless in this way You don't have to like go to ethereum.org and like sign up to be a validator anyone can Sort of permissionlessly join the system Yeah, and then as a key part of this any validator in the new system then to for example make a valid beacon block has to include Sort of their latest view of the eth1 chain and that's how you get this light client functionality So here are some diagrams to that effect Basically what I want to show is like there's a preferred chain right up here beacon chain is up here the system's operational It's going in all this basically in some block We have some data right so like this block has a block hash There's like an address to this deposit contract There's a root of all said deposits that have been made to become a validator and then essentially to enter into the Validator set here you can make proofs against this right so I've already claimed that we're essentially a light client of this contract What that means then is that we know sort of this special route in the contract We can in the usual way make markable proofs to figure out. Okay. Was this deposit included or not? That's what that says Great so Yeah, so then Really this ties it all together I'm just gonna kind of keep moving so we can ask questions at the end. Hopefully I realize this is a lot quickly But basically what we then have right is beacon chain learns about each one blocks as We finalize the beacon chain We implicitly finalize these each one blocks, right? So for example, it's like, you know by this block We said hey the head of the each one chain was this block Then as we finalize this beacon block Because essentially, you know this block cash is written here and it's finalized We know that via reference This is now finalized and then because of the chain nature anything before it is finalized so then we'll like keep increasing suffixes of this chain as We finalize more and more beacon blocks and then just to you know, flavor the point What that then means is that you'd have to have one of these huge burnings of all this validating eath to actually have For example or a version on the 1.0 chain Okay. Yeah, why do we want it? Essentially again, I'm trying to make this argument for better security There's this quote. I've usually heard attributed to Vlad, which is like with the proof of stake attack It says if your ASIC farm burned down with every attack What this means is that you know, let's say when they're for work chain if I want to attack you I just have to get like a bunch of hardware, right? And I just like throw us hash power your chain and then suddenly there's like a competing fork the only way to really like stop you if I don't know where you are is To Change our preferred right which we know can be tricky so With proof of stake you can actually because you have this like reference in the protocol this like representation in the protocol of this Like consensus objects you can basically just say hey We're gonna like coordinate as a community to say delete this part that's attacking us and you can just keep doing this You know as you need I'm gonna show on time. So I'm gonna speed through some of this bit Again security security security This is another one people are really into is that we can actually reduce issuance, right? Because with the security of the beacon chain leverage to the ETH 1 chain We actually don't need to like we don't need as high a mining subsidy and Yeah, take away ETH 1 loves ETH 2 we can like do a lot of cool stuff wait before we have this like nice shiny awesome like future execution environment system And again a lot could go wrong It's coupling these two systems in like a very Intimate way and so we definitely need a lot of like research into like what could go wrong and how before we like kind of move ahead So that's about where we are now We had like there's a working group. We had like our first call some time ago. There's this link here I'll share this on the internet later a Current kind of open question is that a lot of the beacon chain like kind of infrastructure It's kind of been delayed to phase one so they may like defer when and how we can do stuff here Again, there's like active research into that at the moment Here's the link to the working group on ETH magicians. There's a telegram group and I want to get to questions So I'll speed through this Yeah, this is me on any platforms are Alex Stokes and I have more writing on this stuff Yeah, we have maybe one minute for questions Yep Sorry to ask Hey, thanks Alex. Can you can you walk us through what would happen if? The ETH one state is finalized on the ETH to beacon node and then there's a reorganize one if the so we finalize an ETH one block So the certain a certain ETH one block is finalized on the beacon chain But then all of a sudden in ETH one world that block is no right So yeah, so I actually didn't make this clear but part of the goal here is not just to like Have the beacon chain do this thing and like for sort of finalized block ashes But we'd actually want to go one step further and have the proof of work chain change its actual consensus to respect the finality And so again a kind of wrench around time But that's where like merging the systems like it's tricky because like you're actually changing the proof of work consensus To say okay if a block has been finalized we can't revert So then it's like fork choices go to the finalized height of the proof of work chain then proof work from there, right? I'm related to this So you talked about how like if you have the finality gadget you might be able to reduce the mining subsidy One thing I don't understand about that is it feels like the mining subsidy is like most useful for the most recent blocks Because you don't have like really deep reorgs and there will have to be like a delay from the beacon chain to finalize ETH one So can we actually reduce the mining subsidy significantly and and why is that secure? Last question. So that's actually a good question I This again, this wasn't clear for my little diagrams, but basically there's effectively like effectively like a follow distance between What the beacon chain considers an ETH one block and the actual head of the ETH one chain? And that's actually quite big right now The idea is like if we can deploy all this stuff and it all is happy and makes sense Then we can actually shorten that a lot So the question is like yeah, how how short can we make this follow distance? It could go I mean theoretically just a few blocks behind the head and then it's much more clear like yeah We can probably lower the subsidy Okay, right of time. Thanks everyone. I know it's early. Hopefully that was helpful