The Merge (Part 1) - with Danny Ryan, Tim Beiko, and Hasu

Transcript

welcome to uncommon core where we explore the big ideas in crypto from first principles this show is hosted by suzu the ceo and chief investment officer of three arrows capital and me hasu crypto researcher and writer hey welcome tim baiko and danny ryan to uncommon core we are here today to talk about ethereum's huge upgrade the transition to proof of stake also colloquially termed the merge yeah let's start by introducing yourselves um starting with you danny and then tim so please introduce yourself where you work what you have done so find crypto and from a high

level why are you qualified to speak about the merch hi yeah so my name is danny ryan i work with the ethereum foundation um technically on the research team so i do some research around protocol upgrades i also do a lot of spec writing i do some testing and i do a lot of like communication and coordination with engineers working on protocol upgrades as well as people beyond um i've been doing this for a while you know i got involved in 2017 because proof of stake was just around the corner and um i thought i thought there might be some interesting opportunities there i began to work on testing and doing various things related to proof-of-stake to help it get over

the edge and i'm still doing that today honestly it was a bigger project than we expected a lot of meandering paths and turns i understand the system i helped design the system so i guess that's why i'm qualified and the system is kind of in production today in some capacity so i've helped steward that into production and now i'm helping steward kind of its final phase well it's most important phase coming yeah so i'm tim baiko also at the ethereum foundation i've joined the ethereum foundation uh late 2020 but prior to that i spent a couple years at consensus on one of their ethereum

client teams and i i got interested in a different way and ethereum uh so in like i've been following it since about the dao but in 2017 there was this ico kind of kind of craze on ethereum and i remember as a user there like there was a crazy ico and the network would get like congested for days like the mempool which is not clear it was it was absolutely terrible and that's kind of what made me want to work on the protocol like it felt like this was clearly there was demand for this thing but um it could not meet it and like the the base layer was not yeah it was not in a good spot enough to to meet all the demand and so over the next couple years i i joined consensus as they were starting up a protocol team uh helped build one of their ethereum

clients there and then gradually got more and more involved in protocol work and now i lead the core developer calls uh working on the what we now call the execution layer but basically the proof-of-work ethereum chain well amazing i already have two things that i want to dig into so danny you said you joined in 2017 when proof of stake was just around the corner so what happened since then like what paths of the gamete quantum core did you explore that turned out to be unworkable on on the road to proof of stake and what makes you confident that this time is different so in 2017 there were a couple of different so their proof of stake had been in a

very much a research phase and not a lot of production engineering at that time because there were fundamentally hard problems to solve so there were a couple different parallel research tracks in which casper ffg kind of coalesced into a formalized algorithm and paper in 2017 and that that began to be kind of what we were marching towards ffg is like a proof-of-stake finality gadget that can layer on top of some block proposal mechanism so at the time we thought uh we might to layer that on top of proof of work you know as the tried and true block proposal mechanism and then eventually swap that out for a an underlying stake block proposal mechanism so that was the path that was being

followed in 2017 that coalesced into an eip called eip 1011 hybrid casper proof of work proof of stake um and that's kind of what people were working on at the time some of the engineering teams at the time where we're doing some uh kind of early testing and test nets of that a lot of the logic was inside of a contract so actually it would be kind of like a system level contract of those finality rules and the voting that validators do and stuff but at the same time we were also trying to solve um some other problems so sharding and other scalability upgrades but kind of in the parallel track it became clear in 2018 that these are not disparate problems and trying to

solve them in two places does not really get us where we're going and makes ultimately a very complicated uh system and by having two you call them two validator games in two different places to stake in two different places to to be uh doing things for the protocol having them in competition was also kind of bad and weird and the two things are sharding and block production oh yeah define these things so um in any consensus algorithm we need to produce blocks so there's consensus participants that produce blocks miners improve work validators and proof of stake these people generally have some amount of capital that they've dedicated to the system either in the form of mining hardware and energy consumption and proof of work

or the in protocol asset itself ether and proof of stake that gives them the right to play this game and produce blocks and then the other one was oh sharding essentially we're beyond trying to make the the protocol more secure and more sustainable in this this proof-of-stake migration we also would like to make it more scalable and designs that try to get more out of the consensus mechanism we often in the ethereum landscape called sharding these are there's lots of different flavors and explorations in this domain but you know essentially can we take the same amount of crypto economic capital and the same consensus participants to company consensus on more uh interesting yeah i personally have never like looked too deeply into sharing and i would assume that like most of my listeners haven't either so i i was interested in

double clicking on this idea that charting is something that you know that the block producers do because i don't think most people have this mental model right and you could imagine like having a different set of participants like the block producers of the kind of l1 chain and then some other consensus participants that like go and do this other thing to try to like scale out in these other scalable zones but uh those designs kind of having them disparate in the designs does not make for elegant designs so that's something that we were doing in 2018 is we kind of had these two different in protocol games the proof of stake game and then kind of like the sharding game and that wasn't very nice as well as ep 1011 the minimum stake to be involved was 1500 eth and which was not really great from

a decentralization perspective from like a allowing you know hobbyist home stakers to get involved and with some insight from justin drake and some others uh being able to leverage bls aggregate signatures we were able to kind of like go into a different design landscape that was a bit more radical than the ip1011 to reduce the participation threshold to 32 eth and we went into a totally different design landscape where we're kind of re-architecting the ethereum consensus not as a layer on top of proof-of-work but as this like totally separate thing that we're operating in parallel that then happened for a while uh that consensus mechanism the beacon chain was

released at the end of 2020 uh with a number of new teams working on it so you know the classic teams gaff parody they kept kind of the charge on that proof-of-work chain kept refining it and optimizing it whereas some new teams came in and built out this consensus mechanism called the beacon chain launched at the end of 2020 a meandering path of refining the specifications and getting this thing into production and testing that took a couple of years that's it in production in parallel with the proof of work chain and now we're bringing it together yeah you touched a little bit on the process and both of you are working for the ethereum foundation so maybe tim can you give us some insight on like what is ethereum foundation's role in protocol development and and for like a complex

uh proposal like proof of stake how does it go from idea to production what parties are in charge here and working together right it's funny to think of proof of stake as a proposal in a way because it was always part of the ethereum road map right and the reason i say this is there's things that are actual proposals like say eip1559 where there's a big part of the the process that's like getting community consensus around this and making sure that this is actually like a change that people want and i think with proof of stake like we haven't really had to do this because it's been it's been part of the road map i think also because ethereum classic exists and i think that like it was much earlier on but it did give

kind of an off-ramp for people who are not on board with like the whole migration to move away so like for for basically everything else you know i think making sure that like the client developers and researchers get the right inputs from the community is a big part of the job i think in this case not as much the thing that ef ends up doing a ton of is like cross-client testing and infrastructure so um as danny kind of mentioned and again if your viewers are not familiar with ethereum this this might be relevant ethereum does not have like a single implementation like bitcoin right like in bitcoin you have bitcoin core and this is basically the protocol

ethereum instead has like written specification uh which is the yellow paper on the proof of work chain and there's an executable spec on on the beacon chain so we do a lot of work you know maintaining those and then providing testing infrastructure for the different client implementation teams to then write their implementation of the spec and so i think the other thing we do is just generally kind of provide momentum in a way where you know we get all these teams together and calls every two weeks both danny and myself uh and and kind of you know make sure that we're making progress that we're like finding the biggest issues and blocking those we'll organize you know some research workshops get everybody together in person to do

different things and historically you know the ef did a lot more like hands-on kind of development um the get team being like the most kind of notable example where they are still kind of developing their their client today but on the proof-of-stake side for example there is no ethereum foundation client right like like they get codebase so i think over time yeah it's definitely moved much more from like having to write all the code because literally no one else was doing yet to then having to maintain kind of this core infrastructure that the different teams contributing to the protocol use and then ideally even over time we'd like to get more and more of those teams to contribute back to this common infrastructure yeah yeah we spend a lot of time probably

coordinating and helping people kind of see the options available and come to decisions and things like that but we don't you know the ef rarely is even in the position to be able to make a decision um when it comes to like what gets to production obviously i think the ef has a number of strong engineering talent or strong researcher talent and so like they write good specifications they have good ideas but at the end of the day because there's so many different teams involved and because of the way the kind of community works is you know if the ef tomorrow said we must do x it wouldn't necessarily happen yeah and one note on that you know vitalik is always complaining he's had eips and pending for like two years to remove self-destruct and stuff so i

think this is like the one part where like you know from the outside people think maybe like vitalik can like single-handedly put a change in and if you want like evidence that he cannot you just go to the eip's website look at the like draft ones and how many have vitalik's name in it and are not in the production um that'll give you a good a good gauge yeah so danny can you describe what blockchains need a consensus engine for and what is sort of the the difference here between how it's going to work in proof-of-stake versus proof of work from a higher level right so something has to tell us what the state of reality is in a blockchain right and that is the

like something has to order our interactions usually called transactions and allow us to agree on on you know what the end result of that is so abstractly you know if we're just in kind of a accounts and balances like we i want to know that i have two ether and you have one ether and not that you think you have two ether and i have one ether because of different perspectives on reality and um so a consensus mechanism ultimately you know in these decentralized environments allow us to do that without you know visa or a bank or someone sitting in the middle of it and what i like to call these you know proof of work proof of stake and maybe proof of some other kind of stuff you know the

crypto economic consensus mechanisms and they allow us to agree on the state of the world assuming there's not some large enough economic actor attacking this thing in proof-of-work you know we make a claim that if not more than 50 of anyone on the network has more than 50 of the mining assets and power and burning of energy uh then you know we can we can generally assuming that we've seen all the same types of blocks um agree on you know what the state of the world is so more concretely in proof of work we have people that want to show up they want to make some money they want to play an economic game

they buy they take capital and they want to participate in this crypto economic consensus mechanism so they convert that capital into the asset that allows them to play that game in mining that is mining hardware in ethereum that is a generally done on gpus and other mining algorithms like bitcoin and others there's different types of hardware that you might invest in to do so so you need hardware and you need the ability to kind of continually demonstrate that that hardware is dedicated to the network and so you do that you solve these kind of hashing algorithm puzzles through the burning of energy and so you're kind of constantly dedicating economic resources to the protocol in doing so

you get the right randomly every once in a while to make blocks so the whole point of me doing that and dedicating all these economic resources to the protocol is to make blocks and the protocol incentivizes those that get to make a block they get some sort of issuance so they get new assets uh some new ether in the in the form of uh ethereum um and they also get to get transaction fees or other types of privileged things related to making blocks maybe mev and others but we get not to get in that now um so crypto economic consensus algorithm uh i post up a bunch of economic resources uh in the form of mining and for work and i get to make blocks i get to get some value and the byproduct of me

doing that is to make the network more secure under certain assumptions so the more you know crypto economic capital that shows up in mines the harder it is for any one actor to get that those amount of assets to kind of take over the network so this is mining crypto economic consensus protocol i have capital i buy mining power and i run i run uh computationally hard puzzles in proof of stake i take it's very similar idea i like to call it proof of dedication of scarce resource to the protocol it turns out proving that you're burning a bunch of energy on on mining is an easy thing to demonstrate to the protocol through this kind of asymmetric hashing but there's another thing that's easy to do to prove that you've dedicated to the

protocol and that's the end protocol asset itself ether in our case so instead of taking my capital and converting into mining hardware i take you know this capital that i want to participate in this game with i convert it into ether the base asset of the platform and instead of having to burn energy constantly to prove that i've dedicated it to the protocol i can just lock it so i can have an in protocol mechanism to lock it to deposit it into the consensus mechanism to pretty much elect hey i'm playing this game now i have i can now either maybe get some reward if i do well in the game or maybe i can lose some money if i don't do well in the game and so now instead of burning energy and kind of proving with hashes that i'm dedicated to the

protocol the protocol itself can say okay you're in the game so every once in a while the protocol randomly say hey you you validator you can produce a block and so instead of this kind of random extra protocol process we have this pseudorandom in protocol process and similarly i get to make blocks and the reason i want to do that is i get some reward i get to order transactions and get transaction fees additionally in proof of stake there are other kind of responsibilities given to you in the ethereum proof of stake protocol so not only do i make blocks every once in a while which are made for every 12 seconds very frequently i'm called upon to just say hey what's the state of the world what do you see as the head of the blockchain we call this an attestation

attestations kind of get to give continually crypto economic weight to blocks i think every every like six minutes all about every each validator is called upon once to make one of these attestations to kind of like give weight to the chain the summation of these attestations also allow us to finalize so cryptoeconomically finalize portions of the chain and you don't really get this in proof of work and proof of work you kind of get this like the deeper the block is the more likely it's not to be reorg because it's very costly to do so whereas in proof-of-stake we get these points at which we can make stronger claims that are you know unless one-third of all of the capital is willing to be burned all the capital that is staking at the time then you

know there won't be a conflicting chain that with this chain so similarly we get to make kind of these arguments about certain size attackers and uh the ability for them to kind of rewrite history or double spend but in slightly different ways uh but with some similar goals so we want to make blocks and we want to make claims about whether those blocks are true and canonical in both i think yeah one way i've like also thought about it much simpler is you're kind of figuring out what's the way to decide who the next block producer is without like a central party right like and you need a way to to decide between you know various entities who gets that right and proof

of work you get this as a proxy of your hash rate right like where you know you can just increase the difficulty based on the hash rate and then you kind of get this fair you know lottery across all the participants and then proof of stake because we can shuffle the validators in the protocol means we can then just ask them for kind of a fixed ticket size and shuffle that and it's like a lottery as well i think that for me like again if your listeners are not like protocol researchers it's kind of the the thing that helped get it where like yeah you can without a centralized third party shuffle the block producer set and get kind of a fair weighting based on your your stake or your your hash rate and then obviously you want to have a high amount of resources on both sides

to make sure that it's secure against attackers coming in going to the economic resource you know allows us to make it less gameable right like the right to make a block is really valuable ideally i can game that lottery and be able to make blocks disproportionate to other people but the way we bound that to you know a scarce resource improve work and improve stake makes it so that it is it is not gameable i mean it is it's only to the extent that you can apply more resources and so it is kind of bound and in reality yeah i think i in particular i like this framing of blockchain needs next leader who gets to propose the next block how do we elect them both systems prefer to run a lottery

instead of just saying you know the wealthiest party gets to append it or whatever and uh proof of work like the rotary is run via hashing and that provides sort of the civil resistance and in proof of stake sort of you could also say oh like everybody who participates in this lottery gets to this randomly drawn or some you know on-chain algorithm but this is just another way of saying like proof of x right because people will do whatever it takes to provide more tickets and so like you want to create a way to prove costliness and to create civil resistance that you know doesn't reside in you know infinite negative externalities and it's as fair as possible and equitable as possible and you know access to the blockchain's

native asset i guess yeah you could do you know proof of car but that's really hard to demonstrate to the protocol that's right or proof of personhood might actually make a reasonable consensus protocol but like that's also that's not like an easy problem to solve you can't necessarily prove cryptographically that you are you know a unique person and not gaming it as being another unique person yeah i think it's like it's a good exercise i think to understand like to new people coming into the space i always recommend try to like reverse engineer what these different parts of a blockchain actually supposed to do and then you know just try to like think of a better way try to like replace them replace proof of proof of work with proof of personhood or with

proof of car or whatever right or proof of bank account and then tell me like does this achieve the goals better or does it have any drawbacks and then i think it's very easy to see why a lot of blockchains have converged on either proof of work or proof of stake and why other proof of like x algorithms are usually like they have very large like drawbacks and are not really you know on par with those two tim why do we like the proof of stake what do you think is that the main uh the main reasons why we want to switch in the first place i think this has changed over time right like now if you take like a non-blockchain native view you know people talk about the environmental impact and i think that's that's obviously like a big one but it's kind

of like something that we see now based on the scale of things that i don't think was kind of a huge motivation like almost eight years ago when like these things were much smaller i think some very early blog posts uh mention it as a motivating factor i mean it's been known that there's this thing that scales with the amount with the value of the platform that's not very nice right yeah yeah so that's definitely a big part of it right then like again it's like people are trying to quantify this but i almost feel like it's like more of a qualitative difference like you go from literally raising the amount of computers you need to secure the network as like forever um to not requiring any kind of excess

computing resource beyond just running servers which any single website or web application does so that is like clearly a massive difference given like the scale of mining today i think the other thing it gives us is like resilience against large attacks in like an iterated way which you don't really get in proof of work so in proof of work if somebody picks up 51 of the mining power and starts attacking the chain you have like two options one is like you create more mining hardware to then you know get the the good guys 51 again but then that's very kind of weak if i if someone already has half the hash rate so the other option you have is you can change the hashing algorithm because

um both ethereum and bitcoin have kind of hashing algorithms which are optimized for certain types of computers so if you change this hashing algorithm to something else you can make all the current kind of computers useless and then move to another another type of computer the challenge with that is that at bitcoin and ethereum scale there's like a limited number of computing devices that already exist in the world at the required scale to like provide the security uh that these systems have so bitcoin's a bit easier to think about because it's mostly asic mining now but imagine someone gets 51 percent of basic miners and like clearity is going to maintain that then you can either keep the chain operating under this like weird sensor condition or you can choose

to change the mining algorithm so if you're bitcoin the only other type of mining algorithm you could consider is something where there's general purpose kind of computers available to mine this uh so this would probably be like a gpu intensive mining algorithm so you do this you know you have this very controversial hard fork in bitcoin you've moved from asics to gpu mining in that process by the way you also burn all of the honest miners because you can't discriminate the good guys yeah you can't discriminate between them at the protocol so now you've moved to gpu miners but what if your attacker had taught a step ahead of you and they also have you know 51 of mineable gpus under their control there's just literally no other kind of computing device you can move to and

you're kind of stuck in that in that world where like you know the attacker has maintained control over proof of work ethereum would basically be the same thing but reverse because like we start with like a gpu friendly algorithm and we probably even less credibly could quickly move to an asic friendly algorithm because asics needs to be produced but there's maybe some ways where we can roughly kind of damage mostly gpus and there are ethereum a6 and like kind of nudge it towards them but it wouldn't be it wouldn't be as clean but then again attacker thinks two steps ahead they already have half the ethereum a6 and you know there's nothing we can do there so this is like really bad because it's like you know there's a pretty kind of short steps that some actor can take to like make the consensus algorithm just not

stable under proof of stake uh like danny mentioned earlier you know once you get a third of the stake kind of committed to attacking the chain uh they might be able to do things like revert previously finalized blocks or propose an alternate history for those finalized blocks and that's again also very bad for the stability of the chain but the thing that we have is those validator ids are basically encoded in the protocol right like so we can uniquely identify kind of the colluding validators directly within the protocol and we can choose to apply as a social kind of coordination socially coordinated hard fork some penalties to those validator ids

right and we could you know on the most kind of benign of cases you could just forcefully exit them from the validator set and this is maybe a world where imagine you you have strong evidence that those validators are just offline you know maybe they're just like not attacking the chain but like you know so you could you could choose to just have a hard fork or we say well these validators are just forcefully withdrawn and then you could go all the way to the more extreme case where if this was a an attack on the protocol you could remove those validators from the validator set and basically kind of delete their ether and again this would be like something we have to socially coordinate so it would be probably very contentious but not more contentious than moving bitcoin from asic mining to gpu mining right

it's on that level there are versions of these of attacks where you don't even have to socially coordinate right there's an in protocol mechanism called slashing where there are cryptographically provable you know nefarious things where i essentially contradict myself and i can lose my capital by contradicting myself and the extreme you know where an attacker is is not only strong enough to to create contradictory histories but is strong enough to censor you know then you might even you might need to do kind of these social coordination but in in either of the events i would argue that your proof of stake has better recovery modes in these extreme scenarios these are not scenarios that you want to be in in proof of stake or proof of work like these are disaster scenarios but you know this there ends

up being a very uh concrete cost and ability for the network which is you know the network community applications to kind of pick the pick things up and move forward whereas in proof of work it's not so clear that there are good recovery mechanisms in the event of disaster right and i think that the mitigation on proof of stake is also stronger because if you did end up in this absolute worst case scenario where there's some harm being done to the protocol which you can't identify you know in protocol and you need to socially coordinate to resolve then you say you know you go all out you literally remove those attackers funds they would have to then buy up a third of kind of the staking supply again

or acquire right like i think you know there is also a case where the attacker can just steal the supply or whatnot so like but they would need to then do that twice uh and you know put all those new validators through the staking queue have them activate on the network have them become validators and then kind of do their hostile takeover again but then at that point we can just repeat the same exercise we can socially coordinate another hard fork slash those validators again and we can do this over and over and over we're so there's no kind of end to the iteration and everybody loves burned so right um but but just the fact that we can do that over and over i think it's like a much stronger like deterrent to an attacker because also you would think those hard forks get socially easier to coordinate

like the first one will be extremely hard and what not but then if if the same attacker does the same thing three months later it's like we already have the playbook to run through this and yeah there is like no limit to how frequent you can do that versus in proof of work after like two iterations of this game if you're a large market cap asset you're basically over um so i think that is a very nice property yeah and again you don't want to be in the scenario where you're doing this you don't want to be in this area where you have to like socially have consensus to like burn a bunch of capital because there's an attack so it's best as a discouragement it might have to happen at some point in the future of this consensus mechanism but it's not something to be done lightly and it's

not something to like be done in light circumstances because you also don't want to kind of degrade the mechanism you don't want the pitchforks to be able to come out too easily and uh just be burning capital willy-nilly because that's the degradation i think in the model okay so tidr basically in proof of stake you you can uh if fraud happens and the attacker isn't bigger than x percent then the protocol can automatically cryptographically prove that byzantine behavior happened and and slash them which means to confiscate their funds and kick them from a valid data set above x percent the same entity can also censor the fraud proof if you will and then you need to socially coordinate but

both are possible because validators can be individually identified and targeted in protocol and unlike in proof of work where you have this like amorphous mass of cash power that's sitting off chain you can either target all of them or no one yeah yeah and then the last thing you'll add is proof of stake is also cheaper than proof of work from like a protocol issuance perspective so like in proof of work you need to basically issue enough coins to pay for people's high fixed costs of like buying these computers and expanding this energy whereas proof of stake we basically provide kind of a reward on people's capital and we don't need to kind of have that reward be high enough to cover their fixed costs and on

ethereum you see this where like the issuance of the proof of stake chain is about one-tenth of the issuance of the proof-of-work chain right so we don't need so it's like not only is it like stronger from the security perspective but then it's also cheaper like from a protocol right expenditure perspective i think you can argue it is cheaper because it is more secure but it cannot be more secure and cheaper like those things being sort of orthogonal to each other right like proof of work has no fixed costs it's miners only spend as much money as they can earn and they have no real fixed costs either right miners have a couple of things that they're paying for right they're paying to burn energy right so they need to get

some margin on top of paying for that energy consumption rate so it might be five or ten percent as their expected kind of equilibrium margin whereas the protocol has to pay for that energy to be burned and then some margin on top of it whereas in proof of stake the asset doesn't have an ongoing cost to be sitting there well i don't think that's really true i think in both cases you start from the incentive that the protocol creates and then you in both cases you have miners or stakeholders chasing that incentive and spending as much money as possible so i've long said that people sort of think that that seekers have no no costs no ongoing costs but if you think all the way to the end this couldn't be true because if it was actually free then stekkas would just continually like

acquire more capital and stake more and more until some equilibrium point is reached and i think we see that today with lido where leverage shaking is extremely popular and like stekka start to have you know spend all of their like all of their income on borrowing more money so they have these you know costs of capital basically these financial costs to acquire more capital until the point where sort of it is not actually cheaper to borrow and stake more money than the income that they already make from staking and i agree with that but i would argue that assuming that there's x percent x ether issued then you know why capital is going to show up to get that ether whereas in proof of work why capital less some margin

some some like fixed cost is going to show up so like the amount of mining hardware is going to be for that same amount reduced because there's also expenditures in the energy well i i think in either case like the amount of hardware that is produced and purchased is in response to how big the incentive is and the protocol yeah and i think this is maybe also an ethereum specific thing like i think i see your point has to and like in but in ethereum's world it's almost like we have clearly this demand like the incentives are so high that you know people are are kind of expending all this energy to come in mine and because of this move to proof-of-stake it's like we have like this one-shot

phase transition where we can go from like suppliers who have a cost basis to suppliers who don't and because the incentives are still like eighth denominated we can like drastically reduce kind of the total amount paid by the protocol but i don't yeah i i'm not sure this would hold in a world where like you're starting from proof of stake from scratch versus starting from proof of work from scratch i think i may be seeing like where actually like you're you're going with this which is in proof of work it's not actually possible to mine profitably unless you're in unless you're like really competitive but in proof of stake if you if you own ether then you can like you can mine even if you're like half as like if you're way less

profitable than right then like the best steakhouse yeah or maybe another way yeah to put this is like say i don't know what mining mining margins are but say they're 10 right it's like the proof of work incentives on ethereum today are able to pay for like that 90 fixed cost plus 10 reward and that's like whatever the market's agreed you know is the right amount and obviously if some miners come in and they have lower fixed costs and like i'll compete the others but in practice you know we're pretty mature on ethereum because we have gpus and like an asic market so like we say we've settled as equilibrium well if we move to proof of stake it's like we no longer have to pay that 90 of fixed hardware right like we can just as the protocol kind of remove that

portion of issuance which we basically have and then because kind of the network values is already kind of established and the incentives are already kind of worth something which is different than like a much more nascent proof of work or proof of stake chain i think we get to like do this protocol level cost reduction in terms of security spend but i don't think yeah i i think i agree with you that it's not clear to me that would be true if you started a new network on proof of work versus proof of stake um that yeah you would get this like cost saving well the way i always visualized it for myself is that issuance can be reduced because proof of stake has this these better security properties where you can actually identify and slash

individual attackers and so you know we can set the sort of the threshold for when they get slashed much lower then we could improve of work because we can you know do it without disrupting the protocol and sort of the incentive for misbehavior is lower right let's actually uh get out of this rabbit hole i want to hear maybe from you danny or also from you tim how will the merge actually happen as an event like how do we go from the last block on proof of work to the first block on proof of stake i like to think about the existing proof of work network as as two things kind of the the valuable bits that users care about and interact with we might call it the execution layer or the application layer this is the state this is uh the payload of transactions the

state routes the various things that go into a block and then we have this kind of outer shell of that execution layer and today it is it is proof of work it's kind of this proof-of-work seal it's this cryptoeconomic kind of like home and carriage for the valuable bits of ethereum in parallel to that proof-of-work chain today we have a proof-of-stake consensus mechanism called the beacon chain operating in parallel and what is it it is a consensus mechanism what is a consensus mechanism good for for company consensus on stuff so from a high level the merge is at point a the valuable bits of ethereum the execution layer being inside of that proof-of-work carriage and at point b

it in a kind of a continuous way moving into the beacon chain for its kind of new outer shell of proof of stake and the nice thing here is that that execution layer kind of self references and back links to itself and as it moves through proof-of-work and then moves into proof-of-stake and still continues and has this backlink so it has kind of like a continuous nature into the proof-of-stake um another nice thing there is that the kind of the application layer is undisrupted so it becomes very transparent to users so what is actually happening there is that the proof of stake validators are watching the proof of work chain and waiting for some terminal condition to agree upon and begin in the next

beacon block to kind of reference whatever the terminal proof-of-work block was as kind of the parent of its execution layer and then begin to put the valuable bits of ethereum to begin to pack transactions and reference the state route and other things like that in our case that terminal condition is a total difficulty so we call the ttd the terminal total difficulty and that's essentially the validator is looking for some end cryptoeconomic weight um on proof of work to kind of do the transition and take over the fork choice and take over the valuable bits of ethereum and anyone watching for this transition is watching for hitting ttd and watching for a proof of stake chain

taking over from that point and the thing is we want the validators to kind of strip the power from the miners as soon as possible and so any proof-of-stake chain that references a valid terminal total difficulty and is valid in its construction has a higher weight you know so i'm going to follow any such chain higher than any any proof of work chain and so that's pretty much what happens i think one interesting thing to note here is that this happens singularly it happens on one proof-of-work chain not on all proof-of-work branches simultaneously like most upgrades for ethereum and other chains happen at like

a block height so like adding an op code happens at block in but it happens that block in simultaneously on all potential branches on all different forks you know which is nice like it's cool like on the canonical chain i get this op code if there happens to be a competing branch i also get the op code and so we just kind of have this signal where when you hit block in you get the op code on all possible chains um all possible futures whereas because we want the validators to take over we want them to take over just one thing we want them you know whatever they say to be canonical so we want them to take over the canonical thing and not to take over many simultaneous branches or to

accidentally take over a low weight branch because it's actually it's pretty easy to kind of construct a false but not very cryptoeconomically heavy chain in proof of work so i could get to block in maybe faster than the canonical chain is going to get to block in yeah and i don't want that to trigger my validators to take over because i want the validators to take over only once i want them to take over what is canonical or at least really close to canonical because it has this heavy weight ah i see so you were thinking about different activation mechanisms and something like block height is you know too easily it because it doesn't say anything about how valuable the actual like fork was to

like how costly it was to produce right yeah like in a normal fork that's fine somebody makes some like really unvaluable chain that gets to block in before the canonical chain and it gets the new op code but nobody really cares right so we want to make sure we're doing something on kind of the heavy valuable and secure canonical chain is there any sort of code that's already for switching that's already deployed and the clients that miners run today or is there no need for anything to happen on the miner side ideally not only on the vendor that i said yeah so there is a world where like uh this is kind of based on the difficulty bomb assuming we don't have to touch the difficulty bomb we can not have miners upgrade their existing code and what happens from like the

everyone else running a node is that all of the validators or also all of the non-mining or non-sticky note to days they add kind of the missing part right like so today if you're a miner you just run say gather or basu or something and then at the merge if you're running one of those kind of execution layer nodes you also need to run a consensus layer node like prism or lighthouse and parallel to it and so that means you're like post merge ethereum node is really the combination of these two pieces of software and because everyone else say except miners kind of adds this consensus layer node on top they all agree on what the ttd is and then at that point they kind of choose to listen to each other to get like

information about the head of the chain and just not listen to minors anymore the the one thing that's also kind of neat here is like using this ttd is also robust to like short attacks from mic miners so because we are using the heaviest chain any competing block which exceeds the terminal total difficulty but whose parent does not so like the first block past that is like a valid last proof of work chain and then the validator who's like set to produce the next block can just choose from any of those and like kind of go on and and build on that block so it's kind of neat where like you know miners can like it's possible both through malice but also through like

regular operations that we do get two competing proof of work blocks like we get uncles on ethereum right but because basically we have like a clear boundary condition for that then the validator is free to choose like from that small cell of block which would each have kind of the same not necessarily even the same height but they would each be a block which exactly exceeds or directly exceeds ttd what if i run a non-mining non-validating node what do i need to do then non-mining non-validating node so it depends on which layer so if you're running a non-binding non-validating node on the beacon chain today you need to add basically an execution layer node and the reason for that is imagine you're just writing a note on the beacon

chain today you can verify everything but after the merge you're going to have these blocks which contain transactions as well and you need to have an execution layer node to send the transactions to run them through the evm and ensure that uh they're executed as as per their protocol rules right and vice versa so if you're mining on or sorry if you're running a node on the execution layer after the merge you don't know what the head of the chain is right like so you need a consensus error node to tell you this is actually the latest valid block and then you can verify its transactions so this actually speaks to like an unbundling right of ethereum where today sort of the consensus and execution client is one and the same and it would be yes

different after the merge right yeah you can think of like you know what is geth geth is like this kind of like thin relatively simple consensus algorithm called proof-of-work um and then like primarily dealing and handling with the execution layers so dealing with like state and optimization and transactions and like if you looked at their code diff over the past few years before probably like literally has been untouched except for like people trying to introduce progpal and what has been highly optimized and refined is kind of the handling of this execution layer and then what what are these beacon node clients what are the the people that have been working on the beacon chain for many many years now is a highly optimized and sophisticated proof of stake algorithm so you know a client becomes the kind of the summation of the

two so we remove proof of work from geth and others and kind of allow that that execution layer to be driven by this other piece of software and it isn't unbundling and it it wasn't necessarily intentional at the start you know it was unclear when the beacon chain was being getting to be constructed exactly what ethereum was going to look like and how these things were kind of going to come together i would call it a happy accident because these are open source pieces of software because of the way kind of people self-organize to build this stuff it's allowed for more specialization and it's allowed for scaling out the teams and and individuals involved in this this system so you have people that are really really good at proof-of-stake and you

have other teams that are really really good at the evm in doing that like we actually have many more people at the table i think we are allowed to allow ourselves to build more sophisticated software and and to kind of like isolate changes and think about disparate parts of the system because someone who is really good at building an execution client they don't no longer have to be really good at building a consensus client yeah or they don't have to scale out their team to be able to build out you know to build out the expertise which is which is really nice in terms of like components here so all of these new ev2 clients that we are talking about all of them execution plus consensus or are they like just execution or just consensus or how does it work so i think when you

mean that it's two clients like basically what's used on the beacon chain today is that yes so those are these are right yes so like basically prism lighthouse nimbus lodestar taku their consensus layer clients at the merge is kind of what they say you need to choose one of those five and then on the execution layer we have like geth basu nethermine and aragon and these are all execution layer clients and same thing at the merch they remain kind of the same and so you kind of need to pick and choose one on each side and you know we can get into this after but like this is what makes testing the merge kind of this really big endeavor it's like we need to make sure that these 20 pairwise combinations

all work across all edge cases and that's basically what we're doing right now and you need to define a simple but you know robust enough interface between the two so they can kind of communicate and handle idiosyncrasies and things like that why do we want oh sorry i thought you were done i was going to say even even uh consensus the team as consensus sys they have a basu which is an execution layer client and they have teku which is the consensus layer client uh but even them they have it decoupled and they have it actually as two different teams um we might see some like people that experiment with more tight coupling uh but at the merge there is there's no team that is tightly coupled what is the reason that we want or that

we encourage so many clients i understand that this is uh like outside of ethereum this is fairly controversial right it's to make a headache for ourselves i think yeah there's like my thoughts have changed about this recently but like the the real reason like and the most important one i think is because you want the protocol specification to be sound and you don't want a bug in one of the implementations to like alter your protocol right and like for example imagine a world where say we just have get in prison like the two most dominant clients and either one of them has a bug which prints a thousand ether or even like one ether right like or removes one ether

something like that then we need to go through this entire process of like what do you do and you need to wait you know what's cars the protocol more is it like allowing this extra ether or not and whatever the decision is there you know it the outcome kind of affects the credible neutrality of the chain so it's just like a really kind of terrible place to be in and if you have only one client that's basically your only other option when you have multiple clients you can basically say these are the protocol rules and everybody should follow them and then if they don't you can basically kind of fault them in protocol and for example something like this where say uh get printed one east that like was not part of the protocol rules you would have other clients like

nethermine aragon and bezu they would assuming they don't have the same bug but the probability of that is pretty low they would then catch that they would say hey this is an invalid block you know like we don't accept this and like in previous state they would be able to slash the validator who hit that so what if i one question on that like let's say i run besu which is a consensus execution client right and they have a bug that prints one ether to to many or whatever yeah and i run that client so what what happens from my i understand what happens from everyone else's perspective who doesn't run that client what happens from my perspective do i see the right view of the state right so you could be a user or you could be a validator right i'm a user participant or just a user so a user

you're gonna look like you're kind of off in your own little world in a in some sort of like crypto low weight minority chain assuming that it was a relatively low weight client and distribution to the network so say it was like 15 so you would look and feel online but you probably in that event you wouldn't finalize so maybe you wouldn't be making economic decisions and things would look a little bit weird and you'd probably maybe your client gives you some warnings maybe you see a lot of missed block proposals and you go and figure out what's going on you probably run a patch for your software if not maybe run and pick a different piece of software to run that is able to follow the rules so you can still see a live chain but ideally

if one client branches off and you know that client in and of itself would not be able to finalize so i wouldn't necessarily make economic decisions based off of that yeah i mean from a user wouldn't it be better if you know the the change has stopped or like um but the thing is you can't how do you halt yeah yeah exactly i mean um so i'm saying like what isn't this isn't this more dangerous so you do halt with respect to finality depending on the weights here yeah but just not true but from the user perspective i don't necessarily notice that i have fought offer that feels more dangerous than me staying in consensus with everyone else on a chain that maybe has has like a slight problem

i think even if you're right like if it's net worth from the perspective of that user the perspective we think is not just like a individual user it's like of the entire protocol so the sum of the users so it's like sure you know if you're the person running base you and you left your validator you know you're about to go for a three-month no wi-fi trip and you know basically hits a bug the day after um it is it is kind of bad for you and that's unfortunate but from the ethereum protocols perspective it also means the chain did not halt and kind of kept chugging along and all the other users you know realistically like clients are able to reach the vast majority of end users with like upgrades and emergency

releases i mean every time we have hard forks on ethereum we literally have to reach to every user and get them to upgrade their nodes and and we do so especially even more so like consensus participants like miners and validators like they literally have funds at stake and so typically if there is like an emergency release for a client like the vast majority of people will adopt it but of course there are cases where like you know that might be like unfortunate for users another important thing here is like kind of the social layer like why can't there be many clients who's saying so who is deciding that there's only one client what does that even mean you know the pro what is the protocol the protocol is kind of just an abstract definition of rules and there being many

implementations of that protocol is kind of what we see is very natural and helps prevent helps like a more diverse conversation around the protocol helps there not being one team enshrined that gets to dictate the protocol rather than if there's only ethereum core then whatever is written into ethereum core is now canon whereas you know if there's more abstract notion of what the protocol is and there's many implementations of the protocol you have one a diversity of voice in trying to decide what actually goes into this thing and two you have a diversity of option in the event that people disagree and so like there's not only just this kind of resilience it is it is more of a network resilience tactic rather than like kind of an end

user singular user resilience tactic in any of these like bad network events um where people disagree there's going to be a user that maybe is hurt or maybe is like at least not live or is kind of confused or things like that but like the network in most of these scenarios we we think is much more resilient but it's also kind of in this like social layer this governance layer this like abstraction of what is the protocol what it can be who is at the table all that kind of stuff yeah yeah and one thing i'll add there which is the thing that kind of hit me recently is i do not think we could have as many smart people working on ethereum if we just had one client my experience over the past years working with many of them is really smart people are very opinionated about

things and giving them like the protocol as like a minimum spec to implement and then having like many degrees of freedom with how they can write their own implementation i think is the only strategy that brings like the really smartest people to work on clients and i was like when i started working on a client i assumed that like the yellow paper would represent you know 90 of her code base it was like you look at the yellow paper maybe you add like a few more things but like that's pretty much it and it's the absolute opposite it's like writing eips is usually like 10 to 20 of the work and like 80 of the work is like optimizing things designing sync algorithms designing database formats layouts and none of that is part of like

the yellow paper or the consensus specs right like we don't care how you store data and and i think yeah if we had only a single implementation like you would not see any innovations happen there and even in practice you know we've seen a ton of things like aragon spent years kind of refining a whole new database layout and achieved basically an order of magnitude reduction on like an archive node yeah so this would not have happened if they would have had to be say part of the get team like under the same management and working in the same org yeah there's well over like 100 people working on this thing and with a diversity of perspective and and design decision whereas we could easily have more like 20 people working on this thing and

not have a lot of resilience and design and exploration and new things and innovation so yeah i think i'm also slowly coming around to it you know this idea that uh you know client diversity has some benefit i i think i disagree with you danny that this is like quote-unquote like a natural outcome i think the natural outcome is one of heavy client centralization but that doesn't mean that we should endorse it right sure maybe natural is not the right word but like in relation to it is unnatural for there not to be able to be an additional client that should be yeah that we should like make it as easy as possible for there to be competition at each layer at each layer of the blockchain stack right including making a client right and i think what

we have in ethereum now with that being such a clean separation between consensus and execution goes a super long way towards that um that like i can focus on being a good execution dev don't have to be good consensus deaf and so on and i would push that even farther with like what we've seen with l2's right like and danny you hinted about like the starting world map way at the beginning of this but it's worth noting there was like a massive change in what sharding means on ethereum in the past in late this 2018 to 2022 period and like the original starting roadmap for ethereum was this idea of charted execution where like ethereum would eventually have like i think first it was six uh a thousand and then it became 64.

different basically parallel evms running side by side which and this is the way we would provide kind of scalability to users is saying like we we kind of add all these kind of copies of the the protocol within itself and and execute them all in parallel and the first the stepping stone to get there was saying well we're going to have these shards not actually run operations but they'll just store data because it's easier to kind of come to consensus across huge amounts of data it's not only easier but data availability is a hard problem in and of itself so solve that first easier is underselling that's right it's extremely hard to come to consensus on this large amount of data and it was like in order of magnitude or too harder to come

consensus on all these computations and so so we had this road map where like it's like okay well first you just start the data and then you eventually start the computations and then in parallel to that kind of this ecosystem of layer two solutions started to emerge and you know the biggest kind of thing there is today you have both zk roll-ups and optimistic roll-ups and they will rely basically just on the execution chain that we have today and they already do so they don't need kind of these multiple parallel evms running they basically become them and this way we can only ship the data sharding where we don't have to figure out how do we kind of

scale started computations at the base layer this kind of came from like it's nice to technically simplify the roadmap but i also think in practice like having different teams with different perspectives work on this problem has led to better outcomes like i don't see a world where like the say it was a top-down ef design process we would not have optimistic roll-ups and zk roll-ups live in production today yeah we would have probably had to like choose one and and kind of deal with that so i think yeah that letting people kind of build infrastructure is is really valuable yeah it's like enshrining execution in state for these you know more scalable zones or shards like would mean there would be one

design period you know and hopefully we coalesce on a good one whereas like leaving that as a as a free degree for other teams to kind of come in allows for a better competition of ideas allows for you know better exploration and more dynamic uh nature of this scalable zone over you know five 10 or 100 year time horizon you could say i i have put it this way before ethereum has deregulated the market for execution yeah i know a guy that's writing he's doing an exploration to try to like think about the l1 as kind of like the federal zone and it has like some federal rules but then has like these essentially like subsidiary states that get to make their

own decisions and get to have a competition of ideas within kind of this federal zone which i don't know we'll see hopefully be an interesting paper but there's some parallels there but yeah it's deregulated the the like it's like in the u.s you have you have the fed but then it's like if you had uh states could be much more dynamic and interplay and compete for space and compete for ideas and stuff yeah i think whenever you have this level of of competition um you just see way better results and uh i think it makes total sense to like if if you find yourself in the position of the quote-unquote gardener like how the ef likes to put itself as well then the best thing that you can do is nurture this competition and and and make the barriers to entry as low as possible to

the market at each layer of the stack you know be it the client development or building roll-ups on ethereum building bridges to other ecosystems and so on right so how do you prepare or test for such an important upgrade a lot of work and i mean that's that's the bottleneck here right and i've been saying for six months maybe 12 months security and testing you're going to do long tail here because we have to do it right we have to do it fast as fast as possible but even more so we have to do it right you know ethereum's a massive ecosystem securing tons of value and different applications and users so

how do we approach it there's you kind of you you start at the bottom and you work your way up so um on both the execution layer and the consensus layer we have what we call kind of consensus tests built kind of based upon the specification and the consensus that we actually build them off of the specification because it's executable and these give kind of the baseline rules given certain inputs do we have the same outputs you know given a pre-state and a block do we agree on the post state and so we do have a diversity of kind of these types of tests that allow for just kind of baseline conformance and agreement um but there's so much more right it's like it's like imagine like tim said earlier it's like if you just uh had you're able to test the yellow paper essentially with these you can

kind of be testing that core logic but it turns out clients are like 90 other in terms of uh database and network and all sorts of interactions and edge cases so then we go into more of a kind of integration testing beyond that we have some frameworks that we use something called hive where we can write a little bit more sophisticated tests like i have this node i have that node this node communicates that this node communicates that and see if we kind of agree on some of these more complex interactions so we're able to write structured deterministic tests but you know eventually you run out of it's hard to write even more complex scenarios in there so then we have we have test nets where we spin up lots of different nodes under different

test environments and see that they agree and then we actually have this very important thing that we've stumbled upon not stumbled upon but really begin to use in earnest in testing the merge is that we create shadow forks so we take we take a test net so maybe gourley or we take mainnet itself and we spend up a few dozen nodes maybe 30 nodes that these nodes are following mainnet but they all know about emerge they all know about a ttd and they're all kind of prepped and ready to go for a merge whereas the main net itself really isn't all those nodes they're not really paying attention to this so they shadow fork the environment and create a merged test net off of mainnet itself um and

kind of operate in their own little world so they get a main net size state and they get to pipe all those transactions from mainnet into itself so this type of testing has been extremely extremely valuable to kind of get net complications and diversity of interaction and also kind of main net style and size states to shake out edge cases so it's it's really it's a matter of like unit tests integration tests utilizing more interesting integration test frameworks doing these test nets doing these like shadow fork test nets and doing fuzzing doing uh we're using some more exotic tools to kind of test things we're using this like deterministic hypervisor that

like fuzzes on on network interactions and stuff there's it's really like if there is a tool at our disposal and the resources to utilize that tool we're kind of we're doing it at this point you know and some of these kind of feedback into itself so say you find something on a shadow fork you find a bug then you start asking yourself well is there somewhere earlier in the stack somewhere in more controlled place in this testing stack where i can actually highlight i can induce that bug so that i don't have an i don't have a regression here and the bug to pop up again you know so maybe maybe it finds a consensus bug so i'm like okay i need to write a new consensus test or maybe it finds some weird sync edge case and then you're asking yourself can i use hive to kind

of induce maybe three nodes to get into that edge case and it's just kind of this big feedback loop and you're trying to highlight all the edge cases and get rid of all the bugs yeah and maybe this is like the state we're at today right maybe it's worth taking a minute to explain like how we got here because it's literally been a year today that we've started working today like this month that we started working on like the merge under its current design um so obviously like daddy said you know people have been working on proof of stake since way before that um but i think about a year ago is when all the pieces were kind of there where we had the beacon chain it's been up and running battle tested we had the general idea of this design you know reusing the

clients on both sides and kind of keeping that and then transitioning out of proof of work that way about a year ago i think pro lambda was the guy who kicked this off but there was this realism hackathon where we just got all the client teams together and said can we hack together like a post-merge ethereum prototype in a month and we did and this was basically like a network where like you had a proof of stake chain and then this execution layer underneath and it was like validity submitting block from the proof of stake chain to the evm verifying the transactions and then sending them back and i don't think it did the transition didn't do the murder exactly which is a hard part in itself you have you know post merge stability and that's kind of what we we showed but you also the complication of doing

itself yeah so it did work obviously but there was tons of bugs and we spent like all of last summer fixing those bugs and then last fall we all got together in greece for a week with the client teams and we basically spent a week trying to build a test net which would run through the transition so saying like we know well we think this architecture post merge is sound um let's see if we can like run through the transition and we got everybody together for a week locked them in a room and then they did manage to get this test net done obviously again found a ton of edge cases and bugs spent like most of the fall fixing those and like right before the holidays we had a specification for the whole thing we were generally confident in you know

we thought it would work in happy cases and and kind of you know generally be sound so we we set up and we we released the first public test nets called kinsugi um to the community so we we wanted to get like feedback from application developers and just kind of a more broader set of eyes on it and we we ran that for like a month or two and the specification mostly worked but we found a couple edge cases which we then fixed and so now we released this new testnet called kiln i believe this was in march on which we basically expected the specification to be final except for some some minor changes and it's it's been um so it's been running since march and we've had you know infrastructure providers test on it applications

obviously all of the client teams and the ef testing teams have been using it and then now the next step we've had after that is basically the shadow forks which danny mentioned which are taking the existing main net and only a small number of nodes and making sure like can those nodes actually run through the transition smoothly in mainnet's conditions and we're basically kind of all green there we find some minor issues but you know pretty much uh stable and then the next step after that would be forking these existing public test nets and then maintenance getting close it's been a lot of like yeah incremental kind of expansions in complexity but i think it's helped you know yeah make sure that

every part of the process like we we had like a solid foundation to build from yeah yeah and i guess something that i left out is that we're what i was talking about was testing the protocol and testing the software but users have to test right and so that's that's where kiln and that's where these forking of the public test nets is very important so that end users those that run validators those that run infrastructure those that run daps and applications um can kind of that these new setups and see what does need to change see what doesn't change um you know make sure their their apis all work that kind of stuff fascinating unfortunately we are out of time for this one

in the next episode we will talk in depth about the two very interesting topics that are left with regards to the merge first the rise of liquid staking primarily lido and then how does the merge affect the mev landscape on ethereum with map booths pbs flashpots and more so make sure to also tune back into the second episode and we'll see you in a week yeah thanks for having us [Music] you