Trent: all right yeah welcome everybody to the fifth merged community call um we've been trying to have these periodically in between the test nets and um we'll be having probably one more at least in advance of the big event but this is the fifth one and we're very happy to see everyone that made time to join here today if you're uh an at-home validator somebody who runs these for fun or is just a member of the community or you're a client team that's come to help troubleshoot stuff or answer questions thank you for making the time to do this um so yeah that's the intro um we can just jump right into the agenda for tim if you have things that are top of mind you wanted to start with um if not we can go through test net updates to start
Tim: yeah sure um i guess the first thing you know they mentioned on the test sets is um two of them have merged already so robson and sepolia are on proof of stake along with kiln which was our merge test net that we launched a while back um so if you're like a node operator or validator or smart contract developer or infrastructure provider you don't need to wait uh to test this stuff um so you know you can test your whole setup on roxton or sepolia today and you know you won't run through the actual merge but 90 of uh what you have to do and maybe more than that even um you you can you can do on a post merge network so that's the thing i would i would like strongly encourage people anyone who like runs a node um either for validator or or not um this is the time to actually get on the network and and figure out like what exactly you need to set up um some folks at the ef who work on the merge launch pad or sorry that is taking launch pad um they put together a checklist as well um so i strongly recommend just like going through that checklist and and making sure you've got all the kinks worked out um most importantly is probably just like making sure you authenticate your well take a step back most importantly is making sure if you're running a beacon node that you also run an execution layer node uh in tandem with it um so previously and up to the merge it's possible to rely on a third-party provider because you're basically only getting uh you're only getting specific uh data from the from the uh the deposit contract um but after the merge your execution your node needs to validate the actual blocks on the network and to do that it needs a full execution client um so set that up and the the one quirk there is um in order to ensure the communication between uh your beacon chain node and execution layer node is secure there's a a a token that's passed uh i guess an office an auth token that's like an erc20 token um that's passed from one to the other um and that's something you can all like run through today so strongly recommend doing that the link i posted has like extensive uh extensive uh documentation about it um and then similarly if you're a validator there's one more step which is setting a fee recipient um so as a validator post merge you receive transaction fees which currently go to minors so the portion of fees that's not burnt um you need to specify an address for those fees to be sent to otherwise uh it depends on which find you run but either things will break or it'll be sent to the xerox address uh 0x0 address um so you want to specify an address that you control and then you'll get those fees when you propose a blocked uh post merge but you can set all of this up again on a network today if you want to run a validator uh you can do so on robston um sepolia has a permission validator set so it's not anyone who can do that do it there but if you're just running a node that's not a validator node you can do so on sapolia robson or kiln and that should be fine um i saw danny you had your hand up for sex is there anything you wanted to add to that sorry good night
Danny: yeah you said it's like about 90 or even more of what you need to do it's literally 100 of what you do um like if you if you join the post-merge network it's the exact same configuration of software pre-merge it's just that maybe like logs and what you're exactly seeing as that's happening is slightly different but if you can configure a node to run in post merge you can configure a node for the merge it's all 100 of the steps um one more thing is that the um i do believe some consensus layer clients on mainnet releases today allowed you to begin to configure that um fee recipient so it's not something you have to wait for i know there was a goal of lighthouse and some others um but i'm not 100 sure all of them do it yet
Tim: um and then one more i guess final note on the test nets themselves so like i mentioned we already have three post merge test net we have one more uh which is basically gourley and prater merging um those are the two test nets with like the largest community on on them and we wanted to um merge them kind of at the latest possible date in the process such that the releases that go on there are uh you know maybe not final for maintenance but definitely feature complete um and we discussed this on the on the consensus layer call yesterday roughly we're gonna be merging this around um early august um so again the merge has like this two-step process where first is an upgrade on the beacon chain and second there's uh the actual upgrade on the execution chain which which hands over the consensus to uh the beacon chain um so you should expect this to happen early august you should expect to have probably around like seven to maybe ten days uh once like the the kind of parameters are chosen uh to run through the merge um so that means that yeah if you think that you need more than a week to like get set up on gourley uh please start looking at the other test nets now and just writing a note there and that'll get you basically you know the entire setup uh up and running um but yeah gordy will be kind of the last test nets to fork before mainnet and um yeah you can expect about a week to upgrade nodes there and then for mainnet um it'll probably be more like two ish weeks um and the reason it might be a bit short is just because estimating the total difficulty is is a bit hard um so there's like a limited window for which we can do so um so yeah as a friendly hands up you should expect gordy's gonna happen early august you're gonna have notice about a week before that to upgrade your nodes um and similarly main that's gonna happen after gordy and it'll probably be two-ish weeks at most to upgrade your notes uh prior to bellatrix hiding and then the the ttd being hit after that um
Trent: i have a question yep what's the best way for someone to keep track of all this stuff where would they get updates
Tim:* um i mean this call is a good start um so it depends you know what like level of detail you want um if if you like we have the r d discord which is you know like a very granular thing so if you want to follow this day in day out that's probably the right place i think if if you want to follow like at a bit of higher level uh there's the el cordev's calls now on thursdays and the consensus their calls also on thursdays the agendas and live streams are linked in the ethereum slash pm repos and the issues there at the same place as the agenda for this call is so watching those i think gives you like a bit of a higher level kind of basically we summarize everything that's happened in the discord in the past two weeks so if you don't want to keep an eye on that every day that's probably the best place to be and then remy posted uh in the chat blog.theorem.org so i think once we do have like the official releases and you know like a proper announcement that's usually where it goes up first and it also gets shared in other places um so this is kind of like the highest resolution of you know if you just want to follow from like a distance then yeah just keeping an eye out on the blog is is probably the best place we also have a mailing list now where we post the blog so the mailing list is basically i'll send you an email saying you have a new blog post uh that's pretty much it um but yeah uh trent posted the the the link there um so once we do fork gordy and one and obviously when we fork mainnet we'll uh we'll send an opinion the mailing list there as well uh so that's somewhere you can sign up um but yeah i guess discord these types of calls which are on the ethereum repo and blog.ethereum.org uh yeah those are like the three main places yeah and if you want an email directly for these bigger events then sign up to that google that i linked
Trent: cool um we can keep going somebody had mentioned uh the consensus layer client balance um earlier this year and part of last year the concern was that prism was it had too large of a share of the network and i think somebody brought up that lighthouse is now approaching that that 30 limit so um let's see what they suggested well i guess they would just be proposing if you're spinning up new validators um we'd encourage you to use something besides prism or lighthouse is if there are anybody from those teams that would be included in that definition and you want to jump in and show your client feel free um but yeah so if you're a news taker or you're thinking of spinning up nodes just take into account client diversity and how it's important that we have a broad distribution of client types
Tim: yeah i just posted in the chat uh you know sometimes people wonder like why is this important and dankrad uh has a really good post kind of go into the details of um of yeah what are what are all the bad scenarios that can happen if there's too much concentration in a single client um similarly client diversity.org uh has a bunch of guides well first it has some rough numbers um for for different clients um which is good um second it also has a bunch of guides to switch from one to the other um which is which is quite neat and an option to submit guides if you have switch from i don't know guest another mind or prism to nimbus or whatever um yeah and and you want to write like a guide for others to do it um yeah they have a one page button to do that uh but then uh yeah they have guides for like some of the like some of the clients and and how you can migrate from one to the other um so i i strongly recommend having having you look at that um and then one thing i'll add to that is uh it's also good to have client diversity on the execution layer uh there are other exhibition layer clients as well so um yeah it's it's worth uh yeah it's worth uh changing there as well um there's a question in the chat about what's the tech knowledge level required to start solo staking i don't know it's super fizz here because i know he was talking about that on twitter yesterday to people i think remy might be able to jump in yeah remy yeah you wanna you want to take that
Remy: sure um sam um so there's different ways of doing it um if you want to deep dive you can like go through the cli commands yourself follow a guide but there's a bunch of different tools um maybe i can paste all the tools that i usually recommend there's there's tools that are like wizard-like where you just click next next next and answer a few questions and you're done with it um pretty much so all you need is either a machine or a vps somewhere and you can set up your own node and your own keys and your own validators um very easily without much knowledge so let me just try to find those guides and tools and i'll paste them in a chat for you awesome thanks yeah so go ahead now
Tim: i was just going to say the the boilerplate stuff that we usually go over like block times and stuff like that but okay yeah i was just going to say yeah the note on post merge test net so that's also worth noting um um after the merge the two test nets that will be maintained long term are gordy and sepolia uh if you're an application like on other test nets you should migrate um and basically uh the three other test nets kill and robson and uh ring to be will be deprec are considered deprecated now and they'll be shut down gradually over the next year or so so kill and we're gonna shut down basically right after the main net merge um so the kiln's purpose was just to be the first merge test net uh when we were scared of breaking the existing ones um so as soon as we merge on my nets and and have the other test nets merged and it doesn't really have a ton of value um robson will probably shut down some time before the end of this year and then ring could be uh there's like a bit more uh applications on it and um and people rely on yeah uh you know open c still on ranking b people rely on it a bit more so we're gonna give people a longer heads up than leave wrinkly so we expect to leave it up for maybe like a year after the merge the caveat being that we're not running ring to be through the merge so as soon as the merge happens rinky stops being like a good testnet or a good staging environment for mainnet um and that'll be true of all the other networks that are deprecated as well so say there was an upgrade you know this fall ring can be in robson are not getting yet um and and norris kiln um so yeah like if you're still using wrinklebeat network's not going to shut down for a while but it's just going to become a worse and worse uh representation of what's on mainnet um it's not too bad in the case of the merge you know because there's only a couple of uh there's only one op code that changes um you know block times change and whatnot but it's still mostly the same experience for smart contracts uh but say the shanghai hard fork is gonna introduce a bunch of new features uh probably on the on the evm and so none of those would be available on rinkiby um and so yeah the the the delta between like uh ricky b and um and uh maintenance is gonna just keep growing um so now's the right time to like start planning the migration you know you still have a couple months um but yeah before the end of the year uh robson will be shut down and then in the next year ricky will as well and both will not be upgraded or maintained any any further um there's an mev boost question i don't know either danny or if someone from flashbots wants to take it is there someone from flashbacks
Danny: okay what's the question where i'm looking in the chat where so generally the architecture is you're in your consensus node you're on our execution layer client they talk to get they talk together your validator keys are sequestered in a piece of software called the validator client these three things can produce blocks they can attest they can do all that kind of stuff in mev world it is often not it's often more valuable to get the transaction contents for your execution layer from kind of a third-party market rather than just dipping into your mempool because there are various sophisticated searchers in how they combine these transactions and even private markets on getting transactions into blocks where people pay maybe higher fees um so there's an additional piece of software that is in active development it's very much in uh kind of very proactive testing phase and doing some initial audits and people are beginning to run it on these test networks this is called mev boost mev boost is a side car that sits right next to your consensus layer client and essentially gives your consensus layer client the ability to ask this network of builders this network of searchers for valuable blocks so essentially not only if you add this mev boost sidecar you not only can look into your mempool for valuable blocks but you can ask this mev network if they can give you maybe a more valuable block than what you have locally and the the way this works is it does a little bit of a dance with these relays essentially asks for bids if there's a high enough bid it would then kind of sign that bid and then make a then the bid would be revealed and they would get the block and send it to the network the nice thing is that this is kind of a parallel work stream to the existing uh consensus like tuition layer block building and um [Music] it's kind of additive in its functionality rather than kind of a totally totally separate work stream so this is something that i believe some validators will be running at uh the merge uh some might not this is i think the the like full maximal production readiness of the software is still to be known as to how that plays out probably over the next like four weeks i think there's a lot of people working on it there's a lot of people trying to get it ready um but it's probably in kind of like um beta beta plus uh phase in in the next like four weeks um because since our clients are working very actively to ensure if there is a failure on this side car it's a side car for a reason that it wouldn't affect the functionality of the rest of the software there should be a lot of risk in running this software but it is an additional kind of hurdle um you know i'm when i'm thinking about the merge and thinking about um running through it you know to get keep things simple i might not run muv boost um and then maybe like a week after kind of layer that piece of software into my setup but plenty of people will probably run it at the merge so it's totally up to you [Music] any questions will mev boost require more processing power oh micah answered yeah it's primarily just kind of a back and forth um with this external piece of software so like uh sending a couple of um queries to a relay but the amount of processing is negligibly increased
Trent: i think the next question is are the merges fully complete on the test net i'm seeing that the sync tests on robson are still not done any clarification on this uh are they conflating test nets and no i think streets
Tim: yeah i think it's it's asking whether or not we're still doing tests on the merged test nets um and short answer is we are still running tests on them and we probably will up to the merge on mainnet but we don't consider we consider those to be done in that like the network has transitioned and it's stable but we'll keep running a bunch of tests on the various test nets uh yeah until the main net merge but not um it doesn't mean that like the fact that we're running sync tests on robson doesn't mean that like the robson merge is not over it just means we want to test the sync of the various clients in a bunch of combinations in a post-merge context and robson is just a good place to do that now because it's post merge um but we do this on shadow forks we do this uh i don't know if we do it on sepolia but yeah it just it's more like robson is a tool for testing but it's it's merges is complete okay
Trent: maybe they're referencing the merge checklist or something they're singing uncheck box um the next one merge checklist says jwt authentication is important will clients handle this for me is there something i need to do for lighthouse slash cath
Tim: right so um some clients will generate one for you if it's not if it's not passed as a parameter upon startup that said that you do need to pass it to the other client so for example if guess i i'm pretty sure get generates it for you if there's none so if guest generates a jwt token even if lighthouse would also generate one you want to make sure it's the same so um at least one of your components you need to pass it you just passed it as like a command line flag um or a config option if you're using a config file um but some clients if it's not passed to them will just generate it uh yeah by default but because it has to match crossbow slides then you need to pass it to the other uh other part of the stack somewhat related did we did we touch on fee recipient yet or no uh i did a bit earlier but yes fee recipient gets passed the same way by the way so you know if you're writing your your clients there's going to be a flag or a config option called like you know jwt token or something like that and then there'll be another config option called free recipient and um you just need to pass obviously a jw token to the wwt token one and then eat address to the fee recipient one um and by an eth address i mean like an eth1 execution layer east address not like a validator beacon chain uh or like bls yeah formatted address
Trent: right and this is where transaction fees if you if you create a block you're entitled to the transaction fees that miners currently get once we switch over to proof-of-stake so you want to make sure
Tim: uh you're getting your proper reward amount and um setting the fee recipient is part of that yeah um should i start writing a note on gordy right now or join after it's merged um so if you want to run through the merge on gordy now would be the right time to start running a node because that you know you'll have time to uh to get a get a validator up uh get everything set up and then you you have plenty of time to be ready before the actual merge happens um so if if you do plan to run a validator and and run it through the merge it makes sense to start running you know now um but if but that is not a requirement to like run a note on gordy right like you will still be able to start a node on gordy after the merge and on any network um what's the technical reason why infra would not work with a cl client after the merge um the engine api is only running between the proper el node and scl node so the rough idea there is that it's like a trusted uh it's like a trusted endpoint so you want to trust who you're well i guess take a step back uh oh danny has a question but uh yeah really quickly i'll just say like infer is not offering the engine api so it's like you you literally can't get access to it and daddy will walk through why it would be a good why would be a bad idea even if you could get access to it i keep getting muted after admit are we good sorry that was me okay Um
Danny: there are places in the protocol where a validator might be lazy right um you could i mean you could technically offload everything and just kind of sign whatever somebody tells you to do that's probably bad uh it's bad for the protocol it's potentially bad for profitability um but this is kind of the lazy validated problem and the execution layer currently has lazy validator problem you could just blindly sign whatever people say or you could say hey empire or somebody can you just check this out for me i don't want to run it um so it is technically possible to be lazy at the merge for that but there are things called proof of proof of custody of execution that will be layered into the protocol to ensure that there's not the lazy validator problem on the execution layer and so inferior and others are not currently offering engine api because it's not really a sustainable business model to be offering something that will be uh taken out of the protocol it's also not something that they would see as as being good faith actors because they know that it encourages laziness of this component that is will be removed from the ability to be lazy in the future um so essentially validators shouldn't be accustomed to offloading or not processing this portion because one that's bad for the network two it will be bad for the validator as these proof of custody of execution are layered into the protocol um and so infura and at least everyone that i'm aware of right now is not offering this kind of third-party service to allow you to be lazy there um you know in the in the extreme uh if most validators aren't executing this then invalid state transitions could be snuck in and somebody could print 10 million each um that's kind of the failure case there and why it's very important to um not do this and for the protocol to not allow to do this over time execute
Tim: the next question i think is what percentage of uh validators will run muv boost um i'm not sure that it's like possible to know this in advance but one thing that's worth noting is like there are other ways you know for like especially sophisticated uh validators like large capital operators to to do mvv so it's it's not like and just like today you know uh there are other ways to submit med bundles than through flashbots directly um so it's you know yeah it's hard to predict not only because we don't know but also because there's other alternatives um and it might very well be that like people run multiple you can imagine like multiple like pieces of software just like maybe boost that are different builder networks that uh validators want to run in parallel because you get different bundles from them kind of like we see on unproven work today um so i i don't know that there's like a percentage estimate um and even if there is um that percentage estimate tells you how many it tells you how many validators run flashbots and you can like infer maybe how much mvv goes through flashbots but um it's not like a full overview of like the entire mvv landscape either so um yeah i would just caveat that um and the next one is it go ahead it's very good as you say next one if it's related like can you run any boost at the merge um or uh do you need the merge uh to be to be finalized uh so short answer is you can there's nothing like technically stopping it uh we might disencourage it um and if the flashbots teams you know might also also push that um just in the case where if there was a bug at the merge it's easier to debug if you know we can assume that it's just the execution and consensus air client and that the issue does not come from like mvv boost um like danny was saying mbv boost is pretty independent from like the the consensus client so it's not it would be unpro improbable for that to like cause the issue but i think just to be like extra safe um we'd probably recommend not running yet right at the merge and just waiting until it's finalized um but you know you can't like stop people from from running the software basically there's no thing um and there's things like for example you know flashbots maintains a relay on mdv boost and they can shut that down but anyone else could run a relay so it's not like you know flashbots doesn't have single and can't singlehandedly control whether or not people use the software um and you know basically the trade-off there is um you you get like better visibility into what happens if something goes wrong and you get less visibility and like a less transparent mev extraction for that period um so like unchained you might see just like a bit more chaos related to abv um but then at least at the like node software level things uh if things go wrong it's it's easier to debug and run through um and you know in in the in the happy case like we expect finalization to take like 12 minutes after the merge so it's yeah can maybe imagine like an hour or so without any boost being on um
Trent: next question is for the merged networks like robson do we still need the ttd well tdd ttd parameter when bootstrapping the node uh say after an upgrade
Tim: so yeah that's a good question um so you need it and unfortunately there's not a simple answer you you need it as long as the client has not hard coded it uh as part of the configs um so for example and and i don't know off the top of my head who has and who hasn't um but like you would want to look in like the config file of the network that you're running uh so say wraps it in your case and check is the ttd that's set there actually the the real ttd or is it still the fake number like the the extremely high number if it's the high number then you would need to keep that flag and otherwise you would need to remove it or you you can still keep it but you you could remove it um but i've different clients may or may not have upgraded that as part of their default releases um so that's a bit of a disappointing answer but you you just need to look and i suspect clients will have that in their release notes as well once they like update the change um yeah and that might be something actually yeah we can probably uh we can probably like put together just like a list of like uh as the networks merge you know which client version can you run uh and like it will just work out of the box uh in a post merch selling
Trent: next question i see is is there any plan for how to receive stake eat rewards after the shanghai update i'm not sure whether this is referring to like steak withdrawals and partial withdrawals okay um but i don't know what the actual question is um like if withdrawals are enabled they'll just be
Dani: yeah so currently shanghai which is the planned hard fork for after the merge at this point i believe there's general consensus to include withdrawals there is this crosses layers so this is the consensus layer and execution layer upgrade in which there's kind of these two components and an area of the protocol in which these two components speak right now it's expected that exited validators um who then also do a change of cred withdrawal credential operation to make sure they have 0x01 or execution layer address withdrawal credentials then on some cadence would be swept into the withdrawals queue and their entire balance including any rewards would go into the execution layer additionally it looks as though to reduce the incentive to churn the validator set there would be kind of a partial withdrawals function where if you have what's again called an ox01 or execution layer address withdrawal credential or eth1 withdrawal credentials if you have those set up which you can set up with a new message your balances in excess of 32 eth on some cadence depending on the size of the validator set would be swept into the withdrawals queue and land in that address specified in the execution layer so to make that clear there is the functionality to exit get all of your eth into the execution layer back into normal ethereum addresses and there's ability to um on some cadence have your rewards swept into the execution layer there is a link that's kind of a meta spec that references the eips and the different things going on the consensus layer spec and i will find that link and drop it in here but yes there's a plan yes there's some additional testing to still do but yes there's also general consensus on how to do this and it's just kind of doing some final refinements and then going into the whole engineering testing and production phase yeah and
Trent: if this question was referring to staked each derivatives like lido for example or coinbase if if there is anything that coinbase were to offer in the future all of these things these decisions are made independently by those organizations uh yeah i know is lydo is really transferable but if coinbase would offer something it may be a completely different schedule than what mainnet does
Dani yeah and importantly when withdrawals are enabled when partial withdrawals are enabled any of these um mechanisms that essentially we're giving you ious um have the ability to issue you actually the eth that's behind it um but as trent said that would probably require doing and enabling something technical on there and so hard to say what their independent timeline is and one final note
Tim: i'll add on that um so this is all about like beacon chain withdrawals but we touched earlier that at the merge transaction fees are available to validator so if you do hold like a derivative whether it's uh lido or a centralized one on binance or coinbase or rocket pool or whatnot um it is a good question to ask to like the the the party that's that's managing that like what is their plan with regards to transactions needs an mvv because yeah that is immediately available and so you could imagine you know anything from the operator keeping 100 of it to the operator distributing 100 of it as it comes in um and all those things are very much technically possible um so there is no you know if your operator is telling you they cannot distribute transaction fees because like withdrawals are not live that's just not true um and it might it you know it might require like technical work for them to like orchestrate that and manage it at scale um but yeah i think this is uh this is a good question to ask if you hold uh such uh yeah such derivatives cool
Trent: i think the next chunk of questions were taken care of in the chat so thank you people for jumping in there i do think
Tim: yeah the gordy one is worth explaining you a bit more it's a bit tired um so gordy today um runs under proof of authority so that means that there's a limited set of white listed operators who can produce blocks on the network um and then it is merging with the crater beacon chain which is open for anyone to join so this means that at the merge just like how on mainnet miners stop being relevant to the consensus and the gourley proof of authority signers stop being relevant to the consensus and the consensus is taken over by this public beacon chain that is prater and we're all just gonna call it gori after it's merged but um yeah this is what happened so even though you cannot be a validator on gordy today anyone can be after the merge and then sepolia um basically was the opposite so sepolia was running proof of work before its merge and anyone could mine on sepolia and then after the merge because we want to provide like a stable test that basically we've restricted the set of validators on the network so it's it's just like i guess proof of authority like people can join if they are whitelisted and there's like a process for that but the goal is to have entities who like want to run these validators for many years and who have who are like highly dependent uh so that people can use sepoy as like a really uh secure really stable testing environment for uh for smart contracts so it's like yeah it's kind of weird because gordy is going from permission to unparitioned and then cefolia is going from un-permissioned to permission um but it's just good to have both types of test nets because obviously you want validators to be able to test stuff but also um it's valuable to just have a test net where you know the validator set is going to run no matter what because there's no incentive to maintain a test net validator um okay a bunch of questions about inferred that have all been uh answered with no so i won't go over that before the merge can anyone run a note on gordy yes um and even by the way after the merge if you want to run a node on say sepolia which has a permission validator set you can just like on mainnet you can run a node without being a validator and when you do that one you know you can submit transactions query blocks and query history like uh independently of any third-party service but you also validate that the blocks produced on the network are valid um so every single node on the network you know when they get a block they run through each transaction and make sure that it's actually correct so it's almost like we the term validator is is like a bit weird because every node on the network actually validates the blocks whether or not they they build it or attest to it in the proof-of-stake protocol um so there is value in like running your own node even though you're not a validator um you know to yourself because you can just interact with the network permissionlessly but also to the network because this is how you kind of protect against validators including and deciding to change the protocol rules it's by having a large set of nodes outside of these validators um that act as kind of a check on the system uh you know like if a validator creates a bad block um all the other nodes will just be able to notice that um okay there's a question about like the merge state so september 19th uh i would not use that as a merge date um i we were like roughly trying to uh estimate when it could happen um you know it might happen during that week it could be the week before the week after if we found an issue it could be you know weeks after that um i think you know people want this to happen soon and like we are trending well towards like having it happen earlier this fall rather than later this fall um but there's always the risk you know say we did this gordy merge or even independent of the gordy merch say we find a really bad issue tomorrow um we will obviously prioritize like a safe merge over a quick one um yeah so i wouldn't like you know make any uh i don't know bets or like have a large financial stake writing on the verge happening on september 19th um i think it's like a rough target that people think is possible if things continue roughly at their other current base um yep um uh i think that might be it in terms of questions oh uh there's a new one about mev boost unless i miss something okay oh uh yeah okay yeah there's the last question about mvp boost and like yeah you know uh and the sort of um legality aspects of of accepting certain bundles um you know first you don't need to run mev boost you know like so mbv boost gives you potentially more transaction fees and like you know obviously those transaction fees are extracted through mev and there's a whole like spectrum of wbv um including like yeah sandwich attacks which is like front running um so this is why by the way there might be a world where you see like large uh entities maybe not run mev boost maybe they'll run their own kind of mev um maybe they'll run no mev first of all but you could very much imagine a large regulated entity running like their own mev relay which like blacklists certain types of bundles right and they can run analysis on the bundle and say oh this is front running we don't want to do this um you know so we're just not gonna accept this bundle um um or you know and you can imagine this is like a a legal thing but you know there is like this long tail nft mvvs when people like fat finger you know selling their punk for like eight way instead of you know 80 or something um you could very much imagine like some entity not wanting to like be the one who like liquidates that punk uh and and and like allows that mvv to be captured um so yeah different different entities can choose what they what they do um and you know
Dani: yeah i would i would say a couple of things one like the who knows um and who knows and what just jurisdiction and i think anyone who speaks confidently is to knowing one way or the other doesn't know um and then the other is that the way that me beautiful architecture works is that um it it can allows for open relays so there might be relays that are highly optimizing profit and things but there's also kind of a hope that maybe some sort of alternative relays uh exists where maybe there's a relay that does no sandwiching or or no destructive mev and only constructive immunity like pushing the arbitrage of a uniswap market back into place and not not front running that opportunity as well so hopefully we see proliferation of different kind of strategies available through these different relays such that you can make the decision that you want or you can as marius not even run movie boost and use the good old men pool
Tim: and we did see this on proof of work by the way like there were some miners who had different setups and if not based on like jurisdiction so like yeah i think um there's definitely no requirement to run it i think we're all caught up on questions uh now is the time to write it out in the chat if you had something
Trent: you were thinking about um the thursday question what's the thursday question uh christine i thought cl clients were coordinating on thursday's call to figure out how to configure nav boost to only activate after the beacon chain has finalized post merge yeah so it is um there is a muv boost specification item to um say that consensus air clients won't run even though the software is there won't actually dip into the builder network to get blocks until after the merge is finalized it seems like there's general consensus and it seems like this will be baked into clients it does seem like flashbots who will operate a relay will also honor this um but you know there's nothing stopping anyone from modifying software or utilizing alternative relays or whatever but i believe that kind of the majority network will probably that does choose to run me boost will be restricted and you know for a few epochs until finality instability um wouldn't be using this kind of alternative network which i think is as we said before very good for if something goes wrong it helps us kind of isolate that from the concerns a bit so that we can we can debug a bit easier and quicker but we'll see final questions if not then we can we can run through the classics and then to share a bunch of links about where people can keep track of things the first one i'll share is somebody a few people have mentioned it in the chat but the merge mainnet readiness checklist um this isn't update this isn't uh necessarily always up to date but i'd say it's a pretty accurate tracker for what things are happening and what things still need to be done people go through it periodically and add the checklist but this is a pretty good reference if you're looking for things to follow and then related to the date like generally yes there's a rough idea of when this could happen on mainnet but to be clear there's no specific day there's no specific time um anybody who tells you that is is wrong or they're just they have a misunderstanding so um when there is a specific date it will be announced on the ethereum blog and throughout the broader ecosystem there'll be enough time for people to to understand when it's actually happening um what else if you're running if you're participating in validation do not depend on infuria you won't be able to use your infuria execution uh infiera for execution post merge you need to start running your own execution client locally that was an option pre-merge but post-merge it will not be available um these are the classics i was thinking of tim if you have any other ones uh you need to set your free recipient if you're validating we went through that on the call there's some resources um i think in the agenda um what am i missing
Tim: okay so puja had something in the chat i want to highlight uh so um the casper's have been doing these peep and series going over a bunch of different eips for probably over a year now um but recently they've done uh one-on-ones with all the different client teams kind of walking through like how they've implemented the merge what's special about their clients and whatnot um so i really recommend if if you're like you know considering choosing a minority client um there's basically a one hour video with every one of them um and if it's not there it'll be out soon um that you can check out on that playlist so it's really good um yeah daddy you want to take christine's question yeah so
Danny: currently all clients utilize this engine api uh so the question is um is it requisite that you use the engineering api or are there alternatives so there's the kind of the core specs the core specs tell you the state transition they tell you how to talk on the network and that kind of stuff but they don't really tell you about client architecture the engine api is to facilitate a particular type of client architecture and this client architecture the reason that it exists and the reason that it's so pervasive is that the kind of history of there being these clients that are really good and specialized on transactions and evm execution and and that kind of stuff those are the execution layer clients we have these clients and pieces of software that are very specialized at managing the beacon chain managing proof of stake validators balances bls signatures all that kind of stuff and so it's very natural to unify these pieces of software over an interface and that is the engine api that historically is very natural it also would be very natural to look at all these specs and write one big piece of software and call it a client and so the engine api does not preclude that from happening but there is not currently from my knowledge even a project that's very actively pursuing this i know that nimbus does have a very nascent execution layer client and they're considering doing an integrated build with an optional engine api if you don't want to use um one side of the or the other and you know any any piece of any domain that does have clients on both side of the aisle in the same language people might experiment with that in the future but right now 100 of the production clients are utilizing this engine api thing question about the dos post for proposers yeah so validators leak information they make a lot of messages and um it is very likely possible to reverse engineer where the or you know the origin of those messages with respect to ip and kind of figure out where validators live on nodes and then some of these roles especially the proposal role is known in advance so the concern would be that you could actively dos targeted boss proposers there are a couple of so yes this is possible it's certainly possible um and then there are engineering and kind of like the way nodes are set up mitigations and then there are uh protocol mitigations so in the event that this happened if it happened um home stakers would probably scramble to utilize more advanced setups to help get around this um and i know there's some people working on even better mitigations allowed in clients like i think lighthouse is enabling a kind of a century-node architecture some people are experimenting with how to use openvpn and rotate vpns to allow to help prevent dos and other things like that so more like practical mitigations in the event that this happened uh that would you would certainly see kind of a scramble to get the practical mitigations out there are also other kind of protocol mitigations like single secret leader elections so instead of um that proposer being known in advance the proposer knows in advance but everyone else doesn't know and that proposer then makes a proof when they make their block um this is very under very active development uh but it's hard to say when exactly it would come out to mainnet it's kind of one of those like security features that is always competing with user features so it's like okay do we enhance the security of the protocol or do we get out charting or something like that there's there's kind of always a careful balance between those two types of things additionally there's research into more private networking components so imagine land leveraging certain uh types of network constructions like dandelion plus plus where you um pass messages around secretly before they kind of enter into the network and so it's not clear who the origin the message was
Trent: so there's a lot of good research paths along that way but there's also a lot of good practical mitigations um that'll be leveraged in the event of attack we are at time um thank you everybody for joining uh tim you have any like final things that you want to go over i would say if you're so if you're a validator um being on this call is great but if you haven't participated in any test nets and you're currently running validators for the beacon chain you need to participate in gurley don't run your setup on the the main net merge without having participated in a test net merge this is i don't know how to how else i can stress this but you should test your stuff before we go to mainnet um it's coming soon and it will be here sooner than you expect uh if you're not paying attention and trying to trying to test your stuff ahead of time um that was i just wanted to stress that again um if you're a minor part of the mining community please pass this to them i know the merge has been a long time coming it's been a long journey to get here but um it's it's very close if you're a part of a mining community just please be aware of this i think enough of this has trickled out to those communities that it's you know commonly understood to be close but can't hurt to remind people so yeah validators please please test your setups on the existing test nets and the upcoming merge transition and um try to try to dig into the literature that people have made available this stuff that's linked in the in the agenda and you won't regret it and sign up for the um sign up for the google group that's where you're going to get updates follow the ethereum blog emerges soon anything final time oh that sounds great thank you everybody again for joining and for the people that answered questions in the chat and asked questions uh really appreciate it we'll see everyone for the next community call uh maybe in a couple weeks ish we'll see how it goes but again we'll announce it uh ahead of time all right thanks everyone good have a good rest of your day wherever you are
Aug 12 at 1400 UTC
- Danny
- Trent
- Remy
- Tim