Merge Community Call #2

Transcript

welcome everybody as per usual we'll give everybody a minute or two to trickle in and then get started [Music] are you aware that the event in discord does not have a link to this zoom call oh you mean the like the discord native

one yeah the discord native event doesn't like if you click on event details it does not actually have a link it just has a link to the uh ethereum pm repo okay well i just it's in the awkwardness channel so anybody should be able to join there okay and maybe another

30 seconds one minute while people join okay we can probably get started

um hello everyone welcome to the second merged community call i'm trent i work with the ethereum foundation doing ecosystem work talking to stakeholders running things like this very glad to see all these new faces and some familiar ones so welcome to the call um tim's gonna be doing most of the talking uh and then i'll probably uh tap in a couple other people maybe marius if he wants to talk about people helping with test nets or i'm sure there will be other people i asked to share something um but yeah let's get started i put the agenda in the chat and i'll add it again i

don't know if new joiners can see it but um yeah we're just gonna go through this and um if questions come up please just uh i think you can raise your hand in zoom and then i'll uh unmute you actually i think everybody should have the ability to unmute which shouldn't be the case but um yeah uh tim is there anything you want to start with or i'll just jump into the agenda uh no i can jump into the agenda yeah go ahead cool um here uh trent did a great job posting like some pre-call links uh so i i strongly recommend people kind of

read those if they haven't uh yet just because we tried to make it clear you know what's going to change uh at the application layer what's going to change running a node and whatnot uh related to the merge i'll i'll go over them pretty quickly but um yeah those are the three links under pre-call resources everyone should read them ideally ahead of this but you know now we're here so add that to your list of tabs and tim will give you a quick uh overview right now yeah and i guess hopefully i can use this as a way to like highlight what's in it and then you you all can kind of dive deep into what happens to your specific project um at a high level you know the merge should impact

applications built on ethereum too much but there are some changes you want to be aware of um you know first of all kind of obvious but after the merge there will be no more proof of work blocks so uh basically the contents that's currently kind of the core of appropriate workblocks so all the transactions and the metadata around you know the block cache the base fee and whatnot um all of that will be part of the beacon chain box um so that's kind of the first big change relatedly all the fields in the proof of work blocks that uh that basically relate to proof of work or to uncle blocks or over blocks are going to be set to zero um

we're not going to remove those fields from the block header uh just to not break any tooling or whatnot but uh basically omar's the owmer's hash and the owner's list the overs hash difficulty in the nonce are all gonna be set to zero um and the one thing that is not being set to zero was actually changing in value is uh the mix hash value um and the reason for this is a bit complex so bear with me for a second but um at a high level we have this up code on ethereum today called difficulty which returns the difficulty of a block it's a pseudo randomness uh value that people can use and a lot of smart contracts use for different reasons um it is not like perfect randomness it's biasable by the miners

um but obviously if we if we went from setting that to like some pseudo-random value to zero all the time a bunch of applications would probably break so what we're doing instead after the merge is we're selling this value to uh the rendao uh the rendal value so basically uh the difficulty up code which is opcode0x44 is not gonna point to the difficulty slot anymore um but it's gonna point to the mix hash slots and we're just gonna rename mix hash mixhash random and also rename the opcode to random so if you're a smart contract kind of using difficulty for pseudorandomness you know nothing should break um and uh yes you know you shouldn't use this for actual randomness but people do

uh yeah so you know we just want to minimize the damage there um and one thing that's neat about that too is uh the size of the op code will change uh so basically you know if if the value is greater than two to the 64 uh you can kind of query that on the block and know that the merge has happened uh so that's kind of a neat trick uh that's exposed to an op code um yeah so if you want to know in your contract where the emergence happened again you know this is a bit uh more complicated hopefully the article itself explains a bit better um other other kind of noteworthy change is the block time will change after the merge um and we we saw in the last community

call that this would affect some contracts so basically right now blocked uh blocks come in on average every 13 seconds there's a lot of variance on that because of proof of work after proof of stake they come in every 12 seconds exactly except in the cases when the validator who has to propose a block is offline uh so then you basically miss a block can go all the way up to the next one so this currently happens less than one percent of the time and in practice it still kind of comes to uh about once one second reduction in average block time um and so the the use cases we've seen um the the use cases we've seen for this is like stuff like staking uh reward cards or like uh liquidity mining reward contracts and whatnots that like try to

to send out tokens every block or you know kind of make an allocation every block uh those tokens were gonna be are gonna be kind of streaming out slightly quicker assuming the contracts aren't upgradable last but not least um [Music] last but not least a safe head so right now uh under proof of work and just an rpc when you ask for the head of the chain uh you get basically the or if you want to get the head of the chainsaw you can ask for this latest block um and it's it's expected that like this block can reorg under proof of work um so you know like applications relying on that

should kind of assume that there's uh there's you know gonna be a reorgs and in practice the way they do that is they use the concept of confirmations so they'll kind of get a block and then wait you know six blocks or something 30 blocks or something and and once those blocks have passed they'll assume that whichever kind of latest block which has had those confirmation is unlikely to be reorg under proof of stake we can actually get some slightly better guarantees so we have this concept of a safe head which uh there's a full presentation linked here that explains the entire theory behind how the safe head is calculated but at a high level it's a block that we expect not to be reorg under um normal network circumstances so the circumstances under

which it would be reorg is if there was like an attack on the network or a large network delay um so it gives you kind of slightly better assurances than basically the the head of the head of the chain so we're going to be changing kind of the json rpc response for uh the latest block to point to this safe head um which in practice should come within like four seconds of this this start of a slot so it's not going to delay things too much um if you still want to use the absolute tip of the chain for some use cases we've created this new label called unsafe make it clear so this will return you the you know last seen block on the on the beacon chain uh regardless of how many at the stations

and whatnot there is uh so uh you know you should expect this is you know somewhat likely to reorg and then finally uh because uh with the beacon chain uh we have the concept of finalization uh we're also gonna be able to return the last finalized block under json rpc which can serve as a nice and stronger kind of substitute for confirmations so if you're say like a crypto exchange or something that just you know usually has this logic where like you're waiting you know n confirmations um you can probably move to using like the finalized block uh and and basically the condition there would be like a major attack on the network where you'd have two-thirds of validators you know trying to finalize a competing chain uh and that would put a third or

more of this stake at risk of being slashed which is over 10 billion dollars a day um so um so yeah that's you know kind of a useful way to get kind of a high security guarantee from the network on a certain block so uh oh sorry i lost the agenda now because i think i just clicked through it um so i think it i don't know it's probably worth pausing there and it's oh and sorry yeah there's one more thing um okay yeah it's probably worth pausing there and just discussing i don't know if people have questions or thoughts about like the application layer and then you know there's a couple more things we can say about like

more on the like running node slides um what changes um but yeah maybe let's just pause and see if people have like questions or concerns about the application layer before we move on to like the actual node architecture yeah anybody uh if you want to talk raise your hand and i can meet you okay oh micah you have your hand up is that a question or i just wanted to add a brief comment

if you are going to use the random op code make sure you understand the attack vectors against it it is not a perfectly random thing so just don't don't think that just because we're giving you a random op code and you can now you know write a dice game naively you really need to make sure you understand the caveats and the restrictions and the constraints right that's a good point also also the the the random op code um like if you if you right now call difficulty uh in solidity then you will get the randomness problem is

at least for gas if you call it in a view function then it will still return uh the difficulty uh so it's uh it's only implemented uh correctly um if you like if you like use it on chain uh but uh calling a view function does not trigger transaction and so we don't uh have the correct uh randomness there it's just a buck and gas right now but we should be i should like i'm going to fix it soon thanks for sharing marius

okay so yeah i'll take a couple minutes and talk about like how the architecture of things changes post merge um and yeah there's a note here i just want to make sure i don't forget um you know what we'll cover it uh once we what's going to post uh i'll try to i think i'll make more sense there um so sorry a bunch of stuff at the beginning oh no this is actually the wrong thing this should be the right one okay so high level uh at the merge basically running in the theorem client changes and so what a full ethereum look like looks like is the combination of a beacon node and execution engine uh you'll often hear the beacon node being

referred to as the consensus layer and the execution engine as the execution layer and those are basically the equivalent of what's an eth1 and an e2 node today um and uh so that means if if you are kind of running a node on the proof of work network today you're gonna have to add a beacon node in order to keep track of head after the merge and similarly if you are running a beacon node today or and or a validator node you're gonna have to run alongside that an execution layer node in order to validate blocks one thing that's also worth highlighting is right now a lot of stakers are able to depend on infera because they only need to rip to basically look at the

deposit contracts um and they can return return that data when they're validated on the beacon chain post merge this is not going to be possible anymore because once you receive a block from the beacon chain you actually want to execute the block make sure that it's valid and and you know import it as part of your database and even more importantly if you are a validator and you need to propose a block you're going to have to have an execution engine in order to put together a block based on the transaction pool and then send that out to the network and get rewarded two interesting notes there i guess is um one uh obviously you know doing that as a validator means you kind of get the

block reward um but it also means that you get to decide where the transaction fees go which is really interesting um the transaction fees on blocks will still be sent to column like legacy ethereum addresses so not your validator's address but any kind of address on ethereum um and what that means you know in i guess in like beacon chain language is they're kind of immediately withdrawable right like you they're not locked alongside your validator uh rewards um so you know that's kind of a nice nice property of the system um where if you validate or proposes a block you get to keep the transactions um also worth noting both the beacon and execution layers

will maintain their peer-to-peer networks and their set of apis so whether you're using json rpc on the on the execution layer or you're using the beacon apis uh you know none of those change uh module you know what we just went in with the with the head stuff um but you can still query your node run tracing and whatnot or you can still kind of get your information about the consensus level and then both nodes will also maintain their peer-to-peer network where uh you know the beacon node will be connected to a set of beacon nodes and the execution engine will be connected to a set of execution engines um the only thing that changes at the gossip level is the block gossip will happen at the beacon layer rather than the execution layer um because basically uh

the blocks you know are kind of sealed by the beacon node and then it on the network um and transactions will still be gossip though at the execution layer so that your nodes can kind of run it as it gets it finally uh obviously we need a way for those two layers to communicate so there's an engine api that's been put together uh which just kind of always one directional pane from the beacon node to the execution engine um and there at a high level the beacon node will provide information to the execution engine about kind of what the latest valid head the latest finalized blocks is um and also ask it to create blocks and request blocks you know when it's uh your turn to propose one uh and sorry one last

thing you ask it to validate blocks once you get a block from the network you get it at the beacon level you just send what we call an execution payload so this is the contents which has all the transactions or you know the eth1 block send that down to the execution engine run it in the evm and then the execution engine will return whether it's the xylitor and valve block um it's a very high level this is how it works um again we went over this picture but you know you're going to be in a spot where uh all of the kind of consensus data is is the one of the beacon chain and it contains this execution layer payload which contains the transactions as well as some uh some other data that's uh in the current eth1 block header um

here we kind of go into detail of like the different calls of the engine api i write this has been written like a month or so ago i'd recommend looking at the spec and obviously anything in the spec takes precedence over this but i still think the general architecture is is the same um and this uh basically gives you an idea of how the merge actually happens um so it's quite similar to the the picture uh we had above but high level you know right now we have blocks on the beacon chain which don't have any anything except kind of this consensus metadata in it we have these blocks on proof of work which obviously have some data about proof of work and then have all of the transactions and the merge is triggered by a total

difficulty on the proof of work chain so once we hit the certain total difficulty which we call the terminal total difficulty um we basically say that the block after the one whose uh equaled or exceeded this terminal total difficulty will be proposed by a validator on the bleaching chain rather than on proof of work so you can imagine this image you know you have these blocks in parallel then you have the next one the block the second proof of work block is the one which would have hit the terminal total difficulty and that means that afterwards uh the the next block is is fully produced by the beacon chain um so you can see that you know there's no more proof of work uh and then uh all this kind of content which has the transactions and whatnot becomes part of the beacon chain blocks

and then uh it's possible that at this point there are several competing blocks that are like the last proof of work block so uh because you know they all hit they all need to hit this terminal total difficulty if they do their children cannot be valid blocks so we'll get you know possibly a set of competing blocks but the the depth of that tree will be kind of depth of one and then the beacon chain will kind of uh choose which one is the canonical block and at some point we'll finalize one um so if you're running you know say like an exchange or again something that's like uh reliant on um on the sorry on confirmations and and and making sure reorgs don't happen then you basically want to wait for the

first finalized block after the merge you know and at that point reorg are extremely unlikely again except in the case of like a major attack on the network um and and by then the merge is basically over we're fully on the beacon chain and we already covered this um yeah i think that's pretty much it again we'll highlight you know outsourcing uh your your execution engine to infer or another similar provider will not be possible after the merge um so it won't be possible mainly because you just can't produce blocks if you do that and over time we'll also have a proof of custody that's added into the

design which will penalize you if if you did decide to do it so this is really the right time to kind of get to running on uh on uh basically your own execution layer and i think that's all i had uh eip439 we we covered um basically this is just the one that changes the difficulty to uh the difficulty of code random uh there is a merge spec in the execution layer folder uh [Music] so we have a full spec now which only has two ieps but if there are any other eips that come up or whatnot they'll be added here just like any other kind of

network upgrades uh there's a there's a spec um and yeah i guess i can kind of then on this like what we've been doing at the past month is trying to spin up devnets every week uh with kind of delay-less specs and get the different clients to communicate with each other we're hoping that we spin up one more next week and then the second week of december that we can spin up a more permanent one which we leave up and running throughout the holidays and maybe early january so that folks who want to like understand you know and play with this have have something that's relatively stable to uh to use um yes so that's kind of the goal is expect

in the next two weeks just having kind of a consuming network that's uh up and running and uh marius who's on the call has has put together a great guide about you know trying to get uh nodes running on the network and if you do want to help with testing uh some type of things that that would be helpful uh to try and test and i guess just generally also if you run an application infrastructure tooling you know telling us what breaks uh is is really helpful feedback the earlier the better i think one thing that's that sort of kind of stating is um you know when we have these network upgrades we obviously try to leave time for people to upgrade their nodes um and

uh you know typically that's like one to two months uh we understand that the merge is much more uh i guess very different from regular network upgrades and and i think one part where like the community can can really help is by trying stuff early we can hopefully like minimize the kind of delay between when all the code is done clients and like when this goes live on mainnet uh you know i think in the world where like nobody tries anything until we have like a final proper release uh it might be you know several months of people trying and figuring out what breaks and and getting comfortable with it uh but hopefully by having these deadness we're able to accelerate that a little bit and um yeah we'll prove a steak a bit quicker

marius is there anything you want to add there about the devnets he's on the car yeah i think perry is here as well yeah say hey um yeah so just to give you guys a bit of um scope about the devnets so devnet 2 is still meant to introduce testing slash running nodes to the wider community and a lot of clients are still figuring out small bugs or differences so don't expect it to be extremely stable um like tim mentioned we'd have devnet three that would come out next tuesday and a public test net that's coming out on the 13th and 14th so if you're an insta infrastructure provider or if you're running any sort of ethereum based tooling um

please do start testing now and figure out how where all the tooling lies etc i've posted a link in the chat that's a compilation of all the tools we have right now so there's a beacon explorer um regular blog scout so you can check transactions there's a faucet so withdraw some ease deploy smart contracts um also other nice stuff and there's also an rpc if you don't want to sync your own node but we do recommend that you sync your own node just to get to know how things work um yeah please let us know if something clicks and yeah it let mario stop for the testing talk i guess that's a good transition to that

yeah so um i would i would uh like to encourage all of you to start testing and start testing early we created some documents um about how to set up some of the clients not all of them are there so if you if you're really interested in like running a particular client combination or something do that test it and put it in the document and [Music] if you have any questions about testing then just dm me uh either on discord on on on twitter you'll probably find me because of my

really unique last name and um yeah uh happy like we we already have i already have uh like the m's from over 400 people right now that are interested in doing it and we we also i also set up a a page of ideas um what people could work on if they wanted to and um if you have other ideas that we should really test before before the merge then you could just add them to this document that's it thank you perry and marius

not just for talking about your work but actually doing it that's the important part uh let's see if there's anything else left on the agenda i think we we've covered everything so we can open it up to anybody else who has questions we've still got quite a bit of time so if you're shy or unsure of how to phrase your question don't be uh yeah go ahead omar a quick question on the diagram of the execution layer and the consensus layer uh there seems to be a one-to-one relationship between the engine api is that something that's true or just kind of a limitation of the diagram can you run one beacon node and have multiple

execution layers talk to that beacon node yes i believe that is the case uh tim do you want to pull that diagram back up if you can or i can try to do that um yeah so uh you can do that you can not run multiple beacon nodes with the same execution layer that's that's not working with the current oh sorry did i did i mishear it i thought he asked about validator clients but yeah you can you can run one beacon node with multiple execution layers and take the majority vote of them for example so peter has been working

uh in his free time on a client that does exactly this takes take the majority vote of like three or four different uh consensus layer execution data clients for for one consensus layer client is that um the minority client quote-unquote yes yes it's called minority okay did that answer a question right but oh tim's back go ahead i was gonna say i don't i think omar's question was about the validator clients right so it's like could you run n validators on one execution engine is that right

uh it was actually can you run uh yeah one beacon node in multiple uh execution layer nodes uh for that one beacon node okay that's not possible and you can you can always run multiple validators on one big node but i guess you know that yeah it just a few a bit of comment here yes you can uh like guide uh multiple execution layer clients with one beacon node so it's just well it's just a matter of propagating all the messages from this beacon node to wire engine api to all these

extremely clients as possible sweet awesome thanks but the opposite case when you want to run like one execution client to serve for multiple decking nodes it's not supported by the engine api spec and they will not be supported but in theory you can um like if you're there is like one thing that can go into the conflict here is the update of the factory state for that coming from multiple beacon nodes to one execution ray client and in

theory if you're like no if you have like a kind of uh master beacon node that just sends these for choice updated messages and the only one uh but others do not update the factories in theory it's possible to do this kind of setup but yeah it's more complicated and there are implications so this is why it's not uh supported by default by the engineer aspect so that's it which means you'd have to run a custom client so not off the shelf i see so the execution engine both reads from the beacon node and writes to the beak or communicates with the beacon node so it's not just strictly reading from the beacon node

i stopped like writing to the beginner but imagine you have two heads like two bigger notes think that there are two different heads on the chain at some point in time it's possible like because of the message because of the network delay and other factors so the execution layer client will uh like uh yeah it will receive two conflicting functions updated from the to two beacon nodes and it's difficult to decide what to do in this case uh that's why this setup is not supported by default so just to add a comment so we are never

mind we're actually thinking about the use case like that and generally we think it might be possible to to add that kind of functionality that one execution angel will be able to work with multiple beacon nodes uh you need to have like a separate lock uh pointer for pointers for each of them so you need to have like this many to to one relationship and so the thing that is not in the spec you need to have somehow differentiate uh which messages come from which

we can note and so we might experiment with this at some point but we don't have capacity right now so maybe closer to to release another thing to keep in mind for anyone wanting to go down this path is that at some point in the future it is likely that we will start requiring proof of data when producing blocks i believe and so i just want to recommend caution like don't sink a huge amount of engineering effort because there may be changes to protocols that critically break this that sort of setup where you have

lots of beacon clients talking to one execution client yeah it was like just for experimenting with this for now but we'll see yeah i'm not worried too worried about another mind just for for third parties who don't know what they're getting themselves into all right i think we covered that thanks for the question omar anybody else with a question otherwise uh maybe we could talk about what raul is talking about maybe a little tangential but it's an interesting discussion yeah go ahead noam hey um i wanted to circle back to the

devnet discussion two questions here um one during the last community call you guys mentioned that difficulty bombs might go off on existing tests like robson uh i think the timeline there was slated for around january is that still the case possibly we haven't made a call on that yet i think it depends just on how far on the client implementations are um but i think yeah there we we ideally would like to merge robson before um uh before the difficulty bomb goes off on it is it true uh i believe the gef team is going to propose a new test net to

replace the proof-of-work testnets yes sepolio it has already yeah which has already been started but there were some issues with uh like i don't know setting up the servers so we haven't publicly announced it yet but yes we plan to create a new proof-of-work test net um since all the uh other proof of work test nets uh robson um is pretty uh big already and like not really suitable for testing so we would like to create another one and somewhat related to this um

has there been any thought given there's kind of two use cases for test nets right now one is for like eth core devs to experiment on the protocol and then the others for application developers to sandbox development applications has been given any thought to having like two distinct test nets for these two or like not two but multiple test nets for these multiple use cases with redundancy picking obviously we will spin up test nets that are not open to the public uh that's what you guys primarily use for development that makes sense yes anyone else

kendrick go ahead yeah i have a question about where the the block data is stored after the merge so is that still in the execution client data store and that's a good question so uh the block data you mean the existing layer blocks right yes um and you mean the history or okay so the execution layer blocks will be still stored on the execution level client side and they will be accessible in the execution layer network

and there is like the question is uh yeah because the beacon blocks will contain the execution payload as well um and there will be kind of duplication between the layers in terms of data storage but we are looking for the duplication techniques like um like the beacon blocks and the consistency clients for the execution payload headers and fetch blocks on demand from the exclusionary clients this is one of potential solutions for the dead application but in terms of uh like accessibility of blocks and the

execution layer client side from the network and why i just see it's this is not broken and it stay stays unaffected by the merge so so in the short term uh there will be some duplication and eventually it will be optimized to to have less storage yes thank you anyone else yeah sure hi um my question is um is there any change in uh if it makes sense to have consensus and execution there on the same machine

performance wise or bandwidth wise or any recommendation here do you mean existing as the same like monolithic piece of software or the same piece of hardware i mean oh uh i feel like that should be the default i feel like most people already do that i don't believe it's necessary you don't need to have a like crazy high bandwidth connection between the execution and this client you do want it to be low bandwidth like you don't want to like go to the moon and back um because there is time constraints on validators doing work and some of that work requires talking to execution client but if you have like you know two hosts

in the same data center that's not a problem if you have two hosts on the same side of the country that's probably not a problem you have one of your hosts is in asia and one of your hosts is in the us maybe you start noticing you fail on occasion to do things in time mikhail may have more thoughts on this i think you know describe this which is good i i don't think i i'm like um i think the question is about uh how many what's what will be requirements for running the client after the merge right

with respect to hardware bandwidths and sports how many consist clients does require right in addition to yeah so do you need specific like what are the requirements for the connection between the execution client and this client do they need to be like you know sub one millisecond latency or is you know 100 millisecond latency fine between the two i see of course the lower the better but i think that probably under 100 of milliseconds is okay but it depends of course on all of

things but thank you anybody else we should try this by the way sorry we should test that agreed yeah right that's that's true i i'm i'm also just you know trying to understand whether it makes even even makes sense to run them on different machines i'm not sure it is so if you if you run in both

so the the optimal solution would be to run them on on one machine or all like mica had said in like the same data center okay sounds like we've covered most everything i guess just generally to wrap up we got pretty into the technical weeds but if you're a smart contract developer uh we're trying to make it as simple as possible uh basically you shouldn't have to do anything there's no migration you don't have to redeploy your contracts if you're a user listening to the call

or watching this afterwards you won't have to you know move any tokens that you own all of this stuff will happen in the background you shouldn't even notice that the merge has happened other than people saying yes it's happened hooray proof of work is gone but there's no migration um oh right sorry yeah tim tim points out that if you are a smart contract developer and you have a strong dependence on block time in your um in the way you set up your lending functions or how you calculate time for lending rates or something like that then you may need to redeploy but by default if you're

you know most users shouldn't have to worry about things most users or developers if if you are a developer who isn't in a situation where your contract depends on block time you should not just update it to be 12 seconds you should remove the dependence on block time you should not assume that we will keep the block time in 12 seconds it may change to 10 seconds in the future it may change 20 seconds it may change to five seconds like contract should not assume block time is stable over time like you should just use the time stamp field on the block if that's what you care about if you care about time here's the timestamp right it's worth noting that post merge those timestamps are also more reliable than they are on proof of work right so the recommendation is don't use

block times use timestamps all right i think we covered everything and there are no more questions uh last chance for anybody to jump in or ask a question otherwise we'll wrap up okay uh thanks to everybody who showed up um marius mikhail perry micah um this is really helpful to have people to answer questions so i appreciate that um and then we can go a little bit deeper technically to people who have questions about that stuff um so yeah we'll wrap up here this will uh be uploaded sometime today or before the weekend

and um if anybody wants to um listen to it again it'll be uploaded to the ethereum cat orders youtube uh that's it thanks everybody appreciate it uh oh yeah and we will probably depending on the need or how many questions come up we'll probably host another one maybe in another month i don't anticipate there being huge changes or you know a ton of new information that we need to relay other than what's already been prepared um in the agenda but yeah tim do you have any final thoughts yeah it probably makes sense to host one of these sometime in january once like

consuming is out there probably once we have a better view of what's going to happen with roxton um [Music] yeah but definitely not before the holidays and yeah keep an eye on the blog about ethereum.org page uh we're gonna have a post there when the actual like uh i guess final iteration of the consuming definites is up uh i'll make sure to post something there yeah awesome tim you you indicated that you were going to come back to the discussion point number two on the agenda but you never did was that intentional which one the transaction fees yeah transaction fees going to validator i think i thought yeah i thought i mentioned it

i thought i mentioned it but in case in case i guess to reiterate it if i did them yeah so post merge transaction fees go to they don't go to a validator address they keep going to like an ethereum uh call it like evm address um so that means if you run validators you know you can capture those transaction fees basically as they come in they're not going to be locked or anything uh this is also true of obviously any med fees so any of these basically that are paid to the block producer like that i guess in uh today would go to like the coinbase address uh get captured by validators post merged directly no uh they're not locked or anything hopefully this is secure

yeah and that's that's pretty significant especially if you've been validating since uh genesis the beacon chain genesis last year um the unlock for funds hopefully will come in the upgrade after sorry unlock for staked eth or you know being able to transfer it to the execution layer use it in smart contracts use it like you typically do that will hopefully be in the upgrade after the merge but until then like tim said you will if you're a validator you'll be able to use you know priority fees that miners currently get that will be directed to validators or a validator controlled address

on the execution layer as well as any mev and i know there's a lot of people working on um how to integrate med into post-merge clients um specifically the flashbox team is working on that so i'm sure they'll have more releases and and you know as we get closer there'll be a better picture of what that actually is going to look like okay i think we've squeezed all the questions out of people as always um myself tim anybody who answered questions on here is more than happy to

answer further questions that come up uh if you're not already in the ethernet discord that's where a lot of this discussion and testing planning takes place so feel free we we'd love to have you join there and contribute or observe learn alongside us um anything else soon nope not for me all right thanks everybody yeah we'll have a another one in about a month maybe the beginning of january thanks everybody for joining and asking your questions this is great thank you thanks everyone thanks bye