The Merge: Switching to Proof of Stake - Marius vd Wijden - [Toronto Ethereum Developers Meetup]

Transcript

um but up next um we have an honored guest uh from the ethereum foundation um guests from the ethereum foundation have a long history in chainsafe's virtual meetups and in-person meet-ups including previous appearances by the likes of tim bakel and alex stokes when vitalik when they ask hopefully soon marius you can make that happen right just kidding um nevertheless um i am incred incredibly grateful to have one more from the ef joining us his name is marius vandeweiden from the go ethereum team or known in short as guest marius is a software developer that has had quite the story background working

in blockchain including stints as an open source developer on each miner sm squared network as a co-founder and roles in bulb ug and proven network more recently he has played an important role for the ethereum community in testing the merge um uh which is ethereum's eventual switch over from proof of work to proof of stake as the merge will require uh like a conjoining of execution layer clients white gut with consensus layer clients like lodestar building compatibility between the two and ensuring extensive testing is done we'll keep our beloved network running and all of its requisite value it's on

top of the chain safeguarded today he joins us to give a presentation on terminal total difficulty something i have no idea about what it is why we use it and uh what the next steps are for the merge tm so without further ado i'd like to introduce marius now onto the stage into the screen and marius feel free to take it away yeah thank you very much it's a bit hard following patrick after this one i didn't really prepare for today i have a couple of slides that i'm going to show but yeah it's not

not easy follow following the the professor um yeah so entire screen [Music] i'm sure it'll be great green yeah can you see my screen yep yes we can perfect perfect yeah um um as i said so i was introduced uh my name is marius uh i've been working for the ethereum foundation since 2020.

before that i worked on payment and state channels basically scalability layer 2 stuff and since i think 2021 for you know i've been focusing more on the merge um i think all of you are probably aware of the merged switch to proof-of-stake from proof-of-work um a little bit why we do this uh um oh by the way i uh i cannot see the um the question box um so if you have any questions you can

just like unmute ask me questions uh we can have some some some dialogue uh that some discussions that would be really great um why why do we why do we want to merge why do we want to move away from proof-of-work or why what why do we have proof-of-work we have proof-of-work of course like the consensus protocol the for civil resistance uh basically we want to um the proof of work is used um to decide who is going to propose the next block um but we can

also do this with proof of stake basically the idea behind proof of work for the not familiar is um we want to have some assurance uh like we want to limit the set of people that can con that can create a block um and we want to make sure that the people that actually create a blog have some incentive to be part of the blockchain either because they [Music] because they uh uh in improve of work it's because they they bought a lot of mining power um they bought a lot of hardware and they bought a lot of energy they used a lot of energy to solve the proof of work

puzzles so indirectly they used a lot of capital and we can like let people directly use a lot of capital and that that's what we do in proof-of-stake basically stakers set um lock uh 32 eth and for 32 east they basically get a a lottery ticket in this huge lottery and if they win they uh they can propose the new the next block and for that they get some some get the transaction fees and they get some some

some issuance um and the problem is that the the transactions the fees and the issuance on ethereum is pretty high and so it's it was around i don't know 10k 15k per block uh it dollars per block and so a lot of people started adding more mining power to the network and we have this big energy problem right now ethereum uses uh roughly as much energy as uh island um and this energy most of the energy is just used for the proof of work

and we want to get rid of this and with proof of stake we can reduce it by 99.95 by the way um just as a number ethereum right now um uses uh produces 80 you know 20 000 tons of co2 every single day and if we can get get rid of this uh it would be really great oh we got to stop that yeah yeah we definitely got to stop it and like it because like i used to do mining software and i was involved with some miners and stuff really pains pains me to be part of the system and

um and like i really want to get rid of it you know back then i don't think it was such a big problem because people were just starting out it was a small thing and now as it's blowing up you've got so many people all over the world pushing in like you said using the power of an island that is insane that's nuts exactly and um but we that's that's not the only the only thing that we want to do with the proof of uh stake the other big thing is security um basically if you invest 100 into proof of work you will will get a lot less voting power than if you invest 100 million dollars into proof of

work um like uh percentage-wise because in proof of work you have this huge economies of scale basically small proof of work miners go to the local like um electronics shop and buy it by gpu but these huge money companies go to um [Music] like the the gpu builder themselves amd intel uh go to the hardware manufacturers and buy them in in bulk and get like 30 off or something and so they can buy way more stake uh in in the network

and um with proof of stake that's not the that's not the the thing like if you input 32 eth you you'll get exactly the same uh percentage um as um someone who puts like 32 000 e and um so it's it's less centralizing less economy of scale um and we already talked a bit about the gas fees uh it's an it's an issue um proof of stake in itself will not have a direct impact on on gas fees but what it allows us is to know basically we have a committee of people

that can vote on blocks and what we can do is pretty easily define sharding things where we sample some of the people in the committee so we take some of the people in the committee into a subcommittee and the subcommittee is then responsible for short and uh so implementing charting is way easier under proof of stake than it is under proof um so what what happens with your client in improved stake basically right now we have gath we have uh the the execution layer client um that has the mining it has the the chain with the transaction pool we have

jsonpc and all all of these other stuff uh all of these other um components in in gas and post merge we will remove the mining module from gas but instead have the consensus layer client i think most of you are familiar with load star because it's from from chainsafe javascript consensus layer client that is following the beacon chain so um we will basically have two chains or we already have two chains in ethereum we have the execution chain which has all the transactions and the state and everything and we have the beacon chain

which basically comes to consensus on empty blocks it's like it was started but it's it's pretty useless and it only becomes useful when we merge these chains together and that's why it's called the merge and so we will remove one module from us and then we we will you will after the merge you will have to run two different clients gath and lodestar or prism nevermind lighthouse um yeah so what are the responsibilities that are still remaining in geth we still have to maintain the state of the network the state of the net network is basically all the accounts

all the smart contracts smart contract code all the storage slots in the smart contracts and we have to maintain the state try uh which is so right now in guth we maintain two different views on the state we maintain the the flat view which is just everything like in a flat format and then we have this at the state tribe which is a merkel patricia try um that we maintain in order to prove um modifications to the state and the root of the mercury patricia tries included in every block we also have to maintain the

historical blocks for now we hope that we can can get rid of that at some point we will provide access to the the state and the historical blocks for nodes that join the network um we will not uh so new blocks will not be sent uh will not be distributed by gas anymore but they will be distributed by the by the consensus layer client but we will still maintain the transaction handling and the mempool and basically the idea is the the consensus layer client

now becomes post merge becomes the leader and basically tells gath here execute this block or please create me a new block that i can assign and send to the network and yeah so that's basically how we divide up the responsibilities between the execution layer and the consensus layer so what happens at the merge um as i said we have we have right right now we have two different chains we have the proof of work chain and we have the beacon chain the beacon chain is empty and the proof of work chain is full of full of transactions and

post merged the execution layer blocks will be included in the beacon chain so the proof of work blocks will be included in the beacon chain and someone could could um uh could mine on the proof like continue mining the the proof of work chain but we don't care about them that's just like proof of workforce that will most likely happen but as long as all the users uh and all the the capitalists is on the on the correct chain them chain that we maintain that the client teams maintain then everything should be good

and so we use something called the total terminal difficulty t to determine when we schedule the merge and [Music] i think i have some slides for that yes exactly so we want to usually when we schedule an update we schedule the update by block number we say okay add block three the london rules will be will be um will be available and uh block that is not based on the london rules will be

rejected this is usually what we do when we when we do a a heart fork in ethereum um so that we basically we schedule on block height the the the problem is um someone so uh yeah with the proof of work we also have a difficulty for every block basically the difficulty just means how difficult was the proof of work puzzle attached to this block and so we we can see uh here's some um some blocks where we have the we have

the blockchain um in the end we have uh like two sibling blocks block five uh these blocks are sibling clocks they have the same parent and uh what we can see here is someone trying to [Music] trying to attack uh the transition basically what if we say okay the transition is going to be at block six what someone can do is instead of following the the big chain the heavy chain um they will create their own chain in secret which is which has lower difficulty but more blocks and so they will at some point publish this

this chain and we will go into proof of stake but the problem is that all like this block which is under proof of work rules would be the better block than this one um this and all the transactions in it will get re-yorked out and so we don't we don't want to do this so what we um what we have instead for every block we also have not only have the difficulty but we also have the total difficulty basically the total difficulty is just uh the summation of the the sum of the difficulties beforehand so for for this block it's

four because this block has difficulty four and the total difficulty of the parent was four for this eleven because this block has difficulty 11 and the total difficulty of the parent was 8. and so yeah and and by scheduling the the merge at a certain total difficulty we can always we always know that the block that reached this uh total difficult the terminal total difficulty um this block was by proof of work rules the the the best block

and so if we for example set a total difficult total terminal total difficulty sorry of of 19 then the this block with a total difficulty of 20 exceeds the ttd and we can start building our proof of stake chain on top of this so this is basically why we use terminal total difficulty and if you follow some of the discussions on all core devs or the consensus layer calls or like the calls that we have to about when we want to schedule the merge

then we will always talk about terminal total difficulty instead of block number uh of blockade that we usually talk about yes and then some uh yeah we started with all of this in in greece in the first week of october increase some of the some of the chainsafe people some of the lodestar people were also there um and five like all the 10 client teams attended so we have five teams for the consensus layer and we have five teams for the execution layer and um

we started like building some test cases uh we started building some test networks there and implemented the prototype and so a bit of a timeline we had the pithos test net which was the first multi-client devnet we started that in in greece and then we had the kensugi period which basically was a lot of like six definites launched every every week uh where we iterated over the spec and uh uh created like changed the spec a bit and then since january february

i think january we started doing shadow fox um the idea of a shadow fork is basically we we just copy or no we like we we run nodes on the normal network so we add some nodes to the network let them sync up run them on the network for for some period of time and then we define or like set the terminal total difficulty on them and so they will stop following the proof of work chain and start follow like start the merge process and we will also set up a beacon chain and then the our private beacon chain and the nodes

that we control uh where we set the ttd they will merge and we will continue on with a basically a copy of the network and all the transactions that are valid on the network are also valid on our chain so we can just take them and execute them on on our shadow fork and this is like this is incredibly great because [Music] we can run networks where we have the same state and where we basically get a bunch of test transactions for free because we'll just

execute the normal transactions and so that's like that's the closest we can get to uh like testing in a real world scenario because we basically just ex uh we we just um start um the the the proof of the proof of stake on on on ethereum and um in our copy of the ethereum and so that's a really nice way to test and we also had the kiln test net and um now we are looking into the two to four king robson

merging robson and so the beacon chain for option launched on the 30th and the merge is projected for the eighth the we had one problem with robson we basically we um we published the the clients with a with a certain ttd and someone started setting up miners there and basically we hit the ttd way before the beacon chain was even launched and uh so we had to do a like an emergency update of all the notes that we controlled and told everyone to to update their ttd to make it last longer and

yeah so that was a bit of a show um so this this is basically how it how it will look post merch uh you will have uh guess on on on one side and um a consensus layer client on the other side i think this is lighthouse and so lighthouse will tell us hey this is a new blog please execute the blog please verify the blog for me and if the blog is valid then i'm going to attest to it and send my stations to the network and yeah that's basically it i have i have a bunch of websites that i wanted to show where we

where you can follow all of this um so we for all the um or the shadow forks we set up uh websites where um where we can like where we see all the nodes for example this is the eighth stats page for manual shadow fork six and as you can see uh all the aragon nodes have some problem here uh but all the other nodes are in consensus and blocks are getting produced and you can see the difficulty should be zero two i don't know yeah the the eighth stat is not not really not really working we also have some

grafana pages internal confinement page where you can where you can see the that every node is in sync and we can for example see okay this one node is has like really high cpu utilization but that is the the boot node so all the all the clients are connecting to this one node um and we can like if if we have some memory leak issues we would see on the charts here so that's that's basically how we debug the issues and we have of course a beacon explorer and a in the transaction explorer to see um the network and see which blocks are missed which blocks uh

uh proposed and uh what the percentage of of boxes that are getting proposed problem here as you might already have guessed we are only we're like only 74 percent of all validators are validating right now and this is of course because the arrogant notes are yes i have a question awesome thank you oh sorry eric go ahead uh i might have missed this because i just i ran up to go heat up some food because i'm hungry but i was just wondering why um so i mean in most forks we fork on block

height i was wondering why this is i mean this i don't know if this is like technically really a fork um but why is this measured using the total difficulty instead yes exactly i um i i kind of spoke about that the issue is that um usually the the the fork is just if a certain clock height is is is hit then all the different forks that we have will enable the the the um will enable the fork problem is for the merge we we need a single block that we we can build on and not not all of the blocks are

eligible to be built on and we only want to build upon the best proof-of-work block and so someone could just go go ahead and start mining a chain with really low with really low difficulty right now that is way longer than what we have on mainnet and that's why we do this transition based on the total difficulty and not on the block height that makes perfect sense thank you we also have a question from saeef would you like me to ask safe

hey yeah i can ask um yeah and this is coming from complete ignorance i don't even know how to start calculating this in napkin math basically what i was trying to understand is if we did not do this proof of state transition and and i think this reduction of energy usage is a good thing but if we did not do this transition and the entire finance industry came onto ethereum um what would what would the energy usage of it here be would it be bigger than what the finance industry uses today or smaller um probably way bigger so the the

the energy used in ethereum is not used for verifying the actual transactions so only a really small part of the the and the total energy is used for actually verifying that that the transactions are valid and in the normal financial sector most of the energy is used for actually verifying that that everything like that the transactions are valid that everything works and stuff so for like the the like the real work in ethereum most of and proof of work most of the energy is only used for the proof of work uh which is just just to see

who is actually eligible for creating the next block and people are incentivized to to use more energy for that because uh the when like more people use the network the transaction fees go up the transaction fees of course go to the miner that mined the block and um so they are incentivized even more to spend more energy to be the one that mines the block and is this still true with all these elders coming up roll ups and whatnot as as more of the things go off chain and ethereum is just used to you know

as a data availability there it kind of kind of depends um i think that there will always be um really high demand for us for stuff on the main chain even with uh all of the uh all of the l2s and everything if we were in a perfect world where only l twos would use uh ethereum um then we would still if we want to reach a like global financial system scale these these l2s

will still compete with each other for the block space and we would uh we would still see a lot of transaction fees of course like an l2 can pay way more transaction fees than a normal user can because every transaction on an l2 is uh like all the transactions that the l2 does on on the ethereum on the main chain is the like a bunch of transactions batched together so of course they can uh they they can pay more transaction fees than a single user could

yeah can i jump in quickly um i just want to make a comment on that i think this is one of the interesting differences between bitcoin and ethereum where in bitcoin the long-term sustainability of the network relies on transaction fees where for ethereum it's more to do with a concept called minimal via viable issuance you know so how large does the block subsidy need the beer the block reward to keep block producers incentivized to keep making blocks and so in a theorem the fees aren't really that big a deal they're all getting burnt effects you know the idea that fees should not be a significant portion of the revenue it should just be a way to prioritize what transactions get in a block so this is like a really cool like ideological difference between the two networks

that's true yeah yeah yeah yeah the more people actually use that rely on ethereum security the more we need to pay the miners to uh maintain that security so that we like that that's like another issue doesn't really scale well does it yeah not really well not under proof of work anyway but no that's yeah much better thanks marius thanks ben and then john you have your hand up yeah uh so mario's one a general

question to you because you're on the implementation side i guess and you have to keep up with all the um changes and the proposals the ethereum foundation also like from the research part right comes to you and i would like to understand like how uh how do you interact when you feel like oh this is really complicated or do we really need this is how is the interaction and how is the how is that soft because i know that there's charting bank sharding and then things are changing and block proposal uh proposal yeah so how do you see it it's it's it's a big it's a big issue um but it's getting solved i think so um

the problem is or the problem i see is um the the researchers are are creating really uh cool and interesting ideas uh but those ideas those ideas are fine in the future and some of them might not be practical at all some of them might not be practical right now and there was always a divide within uh within the community within the like the the core depths between the actual implementers the people that maintain the network the people that write this off the people that get up at 3am to fix some bugs because someone is ddosing some miners in

in in china or somewhere and the people that are that are researching and thinking about the direct like the future of the network and um one thing that we that we currently do is try to have more bridges between them because it's like it's very uh i think it's very important for for us to give input into the ideas that the researchers come up with and we had a bunch of uh events like that we had the interrupt event in in greece and recently in in amsterdam we had we had another two two

day event uh for researchers and implemented uh to come together um and uh yeah so the the problem is one of the problems is that like a lot of people are looking i think geth the guest team is actually really in a really great position to give feedback to the researchers because we have some really great people that basically know the whole system and but the guest team for the longest time uh was overworked um i think and uh right now we're like i

think that's like one of my one of my missions is to bring more people into death so that we can take uh some of the um pressure and some of the work away from martin and peter and felix and all of these uh great implementers um so that they can um also focus a bit on giving feedback to the to the researchers um so if you're interested in go development and really want to join the the guest team and you think you can bring something to the table and contact me you're always looking for good people

uh one one can i have one one follow-up question i'm done wonderful yeah so what do you what is your general thought on the um block proposal uh separation is there what is your thoughts on and is it is it really solving something i just yeah um it's solving something yes um but i'm not a fan like personally i'm not a fan of this whole proposal builder separation um you mean you mean proposal builder separation uh yeah exactly so that's um yes

um the problem like the problem is meb basically with the with the rise of me we maybe we've seen uh a difference between the people that produce the block and the people that like the people that like uh build the block and execute the transactions and the people that uh mine it and send it to the network validate it and send it to the network and um what the researchers like we've we've seen that this is something that's happening just give me a second and this is this is something that we've

seen happening that there's a big difference between the the the people who actually like actually choose which trans transactions go into a blog and the people that uh that mind the block and um so this concept of proposability separation came up uh one problem i see there and it like it makes sense it it helps us keep the the proposal part so the validators are really tiny especially if we go to vertical trees and uh like clients and and everything so the validators can only be like only have to be light lines and don't have to store the state they

don't have to store the history and only the the block builders uh have to store the state um there's some issues with like capitalizations of the uh um like mining cartels being built of the of the of the uh builders and uh some censorship um i think surround censorship that i that i'm not fully sure um that that are that great uh regarding proposability separation so um yeah i'm not i'm not a great fan at the moment maybe they can figure something out we can figure something out that is that is great

but yeah let's see