Merge Community Call #6

Transcript

welcome everybody to the sixth merged community call we're very happy to have you here um we're going to go over general updates about where the merge is at any announcements related to mainnet timing if you haven't seen them and there will be time for questions as always and yeah we can get started i'm just going to do a quick survey through the members just to see what client devs or researchers are here tim do you want to kick it off with uh yes i wanted to chill ladies and gentlemen here sorry yeah someone in the chat says they can't hear but can somebody else confirm that they okay remy already confirmed that the sound is good can somebody else

confirm that they're here the chat okay perfect yeah yeah okay thank you um yeah go ahead and i'll just try to grab links for whatever you're talking about or if you have them handy and throw them in the chat sure um i guess the first thing uh we can cover is basically the the the last test update and uh mainnet and um yeah uh what like how we how we get there um so as people may have noticed uh gordy which is the uh most used test network for

applications and and and uh stakers uh moved to private stake earlier this week um good question by trent was there a gordy retro um yes perry had a dock looking at the various um issues we hit the the main one uh was that one of the client teams who run a lot of validators uh had had an issue updating their nodes um and that's been fixed then since then there were a couple uh issues uh with some of the client implementations uh but they did end up kind of reorging back and and uh and uh kind of being on the main chain um so given

all of this uh client team still felt comfortable moving ahead uh with setting a date uh for maintenance and so yesterday on the consensus there call we did that um we've now got an epoch for the bellatrix part of the upgrade um let me see if i can pull up the number real quick um the epoch is scheduled for september 6th i don't have the exact number uh maybe someone can find it and put it in a chat so september 6 is when we expect belatrix to hit on the ethereum mainnet um oh actually yeah daddy just posted his his link in the chat his he put up a blog post today with all this info um so if you run a node validator or else uh

other type of node um you wanna upgrade before september 6 both your el and your cl client we expect to have a blog post with all of the the the proposed uh versions for these clients out around august 23rd um we do want to reconfirm that uh the ttd is right next week on on the alcord s call but um there's very high chances that it's it's not gonna it's not gonna change uh but this is kind of the the cause for like the the lag there so next friday uh next thursday we confirm the ttv on our core devs a couple days after that client teams put out a release on the 23rd uh expected blog post um on there'll be something on the ef blog

but you can expect announcements across um you know the various clients themes uh communication channels and whatnot um if you can download these then you want to have upgraded before september 6th uh at 11 34 am utc at that point uh the beacon chain will upgrade to bellatrix which just gets it like ready for the merge um and then we've set at ttd um dtd value starts by five eight seven five and zero zeros towards the end we expect this to hit around september 15th uh ttd is a function of uh the difficulty on the network which is a

function of how much hash rate there is so if there's a kind of increase in hash rate um then we would hit it before september 15th if there's a decrease we would hit it after um so this is why it's it's kind of hard to get an exact date um and then trent shared in the chat at ttd chat ttd tracker um which updates kind of based on the latest hashrooms um and then the last thing i'll say before i pause here is um between like the original announcement like what you expect on august 23rd and ttd it's expected that client teams will put out other upgrades of their release um so you know with either stabilization improvements or or just

new features or stuff like that um so you probably want to keep an eye out um and and uh yeah follow whatever client you're using in in those couple weeks uh because they might put out another release before ttd is actually hit given uh there might be uh uh basically almost a month between the time when we we actually announce it in the timer and when it hits um and then the last thing i will say the actual last thing i will say is because ttd is very hard to estimate because it's a function of hash rates we're in kind of the last innings of proof of work on ethereum um if we saw that the hash rate would like drop dramatically and that instead of

you know hitting ttd around september 15th hashrate drops a ton and now we think it's going to be like october 15th and and and kind of getting later and later we could coordinate a ttd override um we did this on the robson network already ideally we don't just because it kind of forces people to either upgrade their nodes again or run a special command to do this um but if we see that you know bellatrix is activated and ttd is is not getting any closer because hash rate is dropping then we might make the call to to do a ttd override um and so again just please pay attention to either like blog.ethereum or your clients like communication channels um and this is where this stuff would be

announced um but in fact yeah danny's article has like a pretty concise summary of all of this great job tim yeah i think you've covered everything all the updates yeah i think we could probably do just like questions for the rest because that seems like you know yeah so i mean like we have if people didn't uh pick up on this generally the summary of tim's summary is if you haven't been paying attention before now is the time the merge has been the merge ttd has been chosen and this is likely what the number will be it's not saying it won't

change but this is the time where if you're validating um on the beacon chain you want to be tuned in you want to be aware of what's happening and making sure that you're running the right software ahead of the actual merge event so for the next month or so you know don't disappear for a month make sure that you're following uh the client teams that you're that who's software that you're running um we'd hate for somebody to miss it when the actual time comes all right yeah and we can there are some client devs and researchers here who probably can answer questions so if anybody does have questions generally

um i think perry is here i uh perry do you want to like walk through the dock that we shared a bit more and kind of talk about like the implications um yeah and generally just i'll i'll unmute you or find you first but uh generally like what the the the sort of class of issues that we hit over all of the test nets and generally what that means for maine i think i immediately perry let me know if that didn't work yeah hey i think this should work now um i do have another doc that might help with that hang on let me just find that

um that just kind of goes through the class of issues that one might face during during the march yeah so um yeah so we had the girly test night part yesterday and a decent bunch of the issues were just attributed to a client team not setting up the jwt authentication so since so the merge is introducing this concept of an execution layer and a consensus layer so if you guys are used to running ethereum nodes what you've been running so far is now called the execution layer or eth1 node and you would have to add a consensus layer node that's the beacon chain node

and in order for these two nodes to communicate with each other we've introduced a new port that's the engine api port and by default that's port 8551 and that's an authenticated port so you have to configure the same jwt secret on both sides there's a bunch of guides online to guide you through how to set up these nodes as well as what the secrets mean um and they're extremely good i think we even have a couple linked i'll try and find the link for the link um but that being said the client team had forgot to configure the jwt token and once they did that the notes came back online the other issues were due to

multiple terminal blocks and that essentially means the merge had two candidates and the nodes took some time to decide which of these candidates they're backing and we had some failsafes built in and the failsafe kicked in and once they kicked in essentially the chain was okay again but those were like the two big classes of problems um yeah and besides that i'd highly recommend that everyone on the call look through the checklist for the merge it's again not not an exhaustive document but it covers most of the pitfalls we've seen over the over the last couple of merges um especially have a look at the common

pitfalls like almost every big issue we've noticed has been because there was the wrong flag used or the port wasn't configured or the secret wasn't right or people just forgot to run one of the two pieces of software needed um so yeah just please have a look at those and in general the logs will tell you nine out of ten times that something's wrong and i'm happy to answer some questions if someone has something i guess you have just more questions on that we can uh answer them uh in the uh

i guess you can ask them in the chat and we can answer them as a follow-up um and just worth noting perry posted his checklist there and then there's a like similar document on the launch pad as well that i've posted so if you're on a validator uh yeah just running through those um i think we should probably compile all of these links into a single spot just so it's easy yes go ahead yeah we can do that yeah with the with the the yeah with the notes of this thanks uh okay oleg has a question about ttd sabotage um so the only there's two ways you can affect ttd with proof of work one is you stop mining and then ttd takes forever to be

reached um and this the only impact that this has is it makes the merge happen at a later date than it otherwise would um and so if this were to happen and you can think there's many reasons for people to stop mining now right it doesn't have to be sabotage you know people might choose to sell their gpus because um they feel like their return on like the rest of the mining life on ethereum is not worth it um so it's not necessarily like malice that triggers this um but if people stop mining ttd happens later than it otherwise would um what we need to do is basically select a ttd value that is lower than the current one which we would then hit quicker kind of based

on the new hash rates um so every single client has a flag or like a configuration option that allows for this um and clients can also put out new release new releases overwriting this um we've tested this procedure on robson before um and so i'll link to you to a blog post that kind of shows you what it looks like and kind of links every single client's command to upgrade to update this value the other way that uh proof of work and ttv can kind of can kind of uh get get tricky is if there is so much mining power on the network that ttd ends up happening

before the bellatrix upgrade is activated um and this was actually the case on robson on robson we didn't have the case where there was not enough buying power we had the case where there was too much the reason for that is that mining on test nets is uh basically not a profitable thing so the hash rate is quite low and um and so it's quite easy to raise it significantly so when we chose the ttd yesterday um we basically chose a value which um if you wanted to make it happen before bellatrix um i believe you would need the hashrate to have already spiked back to the all-time highest we've seen on the ethereum network and to keep mining at that rate until until we hit ttd and then the closer we get to bellatrix like

with every day that passes you need to then not be at all time high but you need to have an even greater share of hash rate than that um and because this is something we see on the network if something like that's were to happen you know we wake up tomorrow there's like a massive supply of hashrate um then we could do it override which pushes the ttd back uh to a higher value um and then as soon as bellatrix has happened um so which is scheduled for september 6 then it really doesn't matter when the ttd is hit it becomes purely a sort of coordination exercise about like you know making sure everybody has the same uh the same ttd set um but there's no kind of impact or

attack on the merge based on that um so basically we think that like yeah choosing a value where you know we have some pretty like solid bounds in terms of how much the hashtag would have to increase for for to disrupt things um and then having like code and and kind of a release procedure that's well tested uh such that like if this thing happened we could we could counter it um and so far it's not looking like the hash rate is rising like basically the all-time high was like uh something like uh 1100 uh pair peter i'm not sure what the unit is but like oh sorry 11 giga hashes oh sorry no anyways the 1100 something and

then we're at about 900 now so we've dropped since the all-time high by a fair amount it hasn't risen since we've we've chosen the ttd we'll keep monitoring it but then you know a week or two from now you would have to have hash rates that goes past what the previous all-time all-time high hash rate was and i think that becomes quite quite unrealistic and then maybe the there's a so there's a follow-up question about what's the backup plan in the case of merge trails or some series of issues happen so there's no way in which we can go back to appropriate work um once to like activate the merge sequence and the reason for that um first the code does not allow it but

like the kind of design reason is once you move from proof of work to proof-of-stake and even once you like signal that move you can't like assume that if it doesn't work out on the other side you can come back and the hashtag will still be there waiting for you and like mining right like at the assumption from like a design standpoint is just once we activate this you know we we assume that like that there is no longer security on the proof of work side that could like backstop us and we need to uh ensure that like things work out on broomstick um and obviously you know we this is why we do so many test nets so many shadow forks um if there was an issue that happened on

emerge which we did you know which we hadn't encountered so far the solution would be like fixing it on proof of stake on main net as soon as possible um not going back to cover stage um effectiveness uh remy i see you're posting about this in the chat you want to take that question uh i will try to unmute him can't find the account oh maybe it's because i'm a special character or something yeah one second hey hey hey

so effectiveness um is is known to be wildly changing on tests right so i believe you were a illusion you were mentioning that your effectiveness went down after the merge and i'm guessing this is on girly um so it's it's like common to see effectiveness changes on test that because like there's less resources being spent there people don't have any real value or real money there so it's not uncommon to see like effectiveness goes down but um i posted the resources on effectiveness if you want to check it out in the chat suppose by a testant it'll

um enlighten you on like how it's computed i'm not sure exactly how it's computed on the beacon chain that the website um i can't remember how it is but i believe it's like um with your attestation if you're always correct in terms of the votes that you do on source target and head um but on like i mentioned on tests that it it widely changes because uh people are not putting the same resources uh but on mainnet it should be quite stable um i don't know how it'll look after the merge on mainnet but i assume it'll eventually be quite stable

thank you hopefully that answered the question from the chat let me scroll up and try to find the next question caleb asks are there plans to allow for a single cl multiple el configuration without a mixer oh a multiplexer um so today it's oh daddy you have the idea to take it let's see can win right there are two danny's lower case danny is ef

no i know well we can but your audio is api is unlikely to support that directly client teams may add support uh but i think uh or some sort of multiplexer sitting in the middle is a better generic solution um gas i think cl client supported it you know if anyone does it'd probably be very okay so short answer not without a multiplexer um

for now at least uh next one will this usage increase faster after the merger can i assume the same size increase before the merge summing up the usage is cl and el client i know there was a thing here about like the blocks being stored on both layers and uh prism i know had like looked into this i don't know terence um can you give us a little list on the cl side like whether the um whether the uh storage increases because you now store the execution paid out as well hi can you hear me yes yes okay so most clients have this feature it's just not only in prism so i would highly

recommend you guys to read the client documentation so the future is basically instead of storing the full payload you store the header and then because there's no point in storing like payloads in two different locations and that's cl and el because el is storing the payload already so then so then the ceo could just store like the blinded version which is just a transaction root and if you need to retrieve the payload you can just get you can just get it from the el so i would highly recommend um you guys to read the documentation i think for prism it's created behind the flag it's it's not enabled by default and then so the compromise of not using this feature is that i think this size will increase by

what like 200 gigabyte per year so if you're waiting to take the hit that's also fine as well so there's yeah so so it's just a nice option here okay so yeah short answer i guess is by default they would increase a bit because the execution payloads get stuttered on both sides but cl teams are working on or already have features to mitigate that to a large extent yeah exactly sweet thank you any other questions uh netermind plus lighthouse after the merge started to reorg um yes we this is

angoria i expect we did see that um i don't know if there's anyone from nethermind on the call here um if not i don't see anyone not of mine if there is please let yourself known in the chat and will on youtube um if not there was definitely an issue uh that was found with nethermine during the the gordy merge um it is mentioned as part of like the dock that perry shared earlier um yeah i i don't know that there's anyone on it who can have more details oh yeah exactly so in this dock uh there are some some issues there yeah um

yeah exactly this is literally what yeah yeah this is probably the issue from the dock where you have to restart and then it's back to normal uh so the nethermine team is aware and they're they're working on this uh right now yeah and there's um yeah there's there's like an hive test uh that's also gonna be added uh to hit exactly this edge case if i'm not mistaken oh they already have a fix harry says any other questions um if not uh

i have a question for it's taker folks um [Music] will there be another validator prep workshop before the mainnet merge and if so where can people find this information um yes so there will be another workshop in about 30 minutes so if you want to learn more about the details of that workshop let me try to find the link here i'll post the link in the chat so in in about 30 minutes um we'll have another workshop and people will be able to join us i believe we will have a summary sat

um giving us some updates about his guide for the merge and we'll do a bunch of um different stuff in in order to prepare for the merge and we'll answer everyone's question there so if you have any technical questions with your own setup please join us and we will be happy to help you amazing and is there a plan to have another one before mainnet or is this the last one obviously they're all recorded but yeah just curious yeah i believe we have uh a plan to have another workshop um maybe next week or in two weeks um let's see yeah okay and yeah link to link that uh in the the comments there yeah

um yeah it's uh i'm not seeing any other questions which is i guess i didn't expect that given this is like even closer to the merge but maybe everything's been answered oh here we go there's another one yeah a good energy boost question um is there anyone from flashbacks on the call or who's like work done with mbv boost i think terence has done some of the prison work for it oh yeah there you go oh parents you should be on youtube

maybe he gave the mic back to danny okay let's wait for parents yeah so we unmuted your turns but maybe there's something on your and hello there you go yes it works okay awesome sorry about that so um with med boost it's little trickier because like every clan does this differently so there's like it's kind of hard to come to like this like cohesive like point like how does

it work and like how do you know who is working right i think for us it's like we utilize the health endpoint of the mvp boost pretty heavily so when something doesn't work you will see from the error log right away so at startup we call mvp boost to check the health if there's some work and then you unlock the arrow and then before the blog proposing will also check the health status right but at the worst case we also build a block in the background in parallel with the local ee as well so it's so so so like in the event that the map boost doesn't work or or the relay is done you will not be missing blood because

you can still broadcast your personal block that's from the local ee so i will say uh just pay heavy attention to the log and just grab any error that you can find and that is related to to a math boost thank you terence aks uh can you put your question in the chat first before we unmute you okay um doesn't seem like we have any

more questions coming in same were there any topics or researchers client devs is there anything you want to say specifically uh to this audience of 80 wonderful people that we have here i'm i'm actually curious as so i like power bowery hopefully i got your name right um why do you think the gap should be bigger than seven to ten days given that as a solo node operator you sort of have to be ready when bellatrix hits anyway so once pediatrics hits everything should be configured so i'm curious what what's the thing you would like to like have a wider gap

for what's the main reasoning and we can either unmute you or or if you want to answer in the chat but um yeah i'm just curious to understand better what's like the constraint there um and then while i i think i've yeah if yeah i've asked you to unmute if you can but um yeah while we're waiting for that um micah asks us to reiterate the ttd is it final so it's tentative um so um basically if uh yeah we should confirm it on awkward as next week um but then even

then if we see some some like crazy variations in the hash rate or whatnot we might we might change it once more so um yeah please keep an eye out but yeah um okay and then aks has a question about miners turning off their nodes uh much before the ttd target so this yeah this is basically um what we discussed earlier so what would the the first impact of this would be it would make ttd hit much later um so that would that would kind of slow down the merge there is a point at which you know a significant enough part of hash rate leaving makes ethereum kind of not as secure by

by however much uh hash rate we've lost um and so i think those are all cases like both in where we just consider making the lower and kind of pulling the merge forward based on the new the new hash rate levels um there is if we saw like that the the hash rate was going so low uh and and you know being completely unstable or being attacked there's another like override method that we can use where we actually hard code basically a specific work block and and agree on it as the the the final proof of work block um this is really not ideal so um the the the you know doing that would kind of incur liveness failure on ethereum um so we we don't want to get there so you

know if the if the the hash rate goes lower the the main solution is just to reduce the ttd and find a closer target in the chat the ttd isn't final so if for some reason there is a need to do an override just make sure that you're following tim or the ethereum blog as a place to get information about uh what the latest is over the next month and okay there's a follow-up question about like if the if the ttd if the difficulty goes down so much can the

theorem foundation fill in the gaps reminders and the short answer is no like the amount the hash rate that ethereum is massive even if the ef and all client teams wanted to like you know there's no we don't have like this hardware so it's really the the best tool that like protocol developers have is just changing the ttd value rather than trying to affect the actual hash rates on the network um on testness we were able to do that because on testnets we basically you know for like a couple hundred dollars so maybe a couple thousand dollars could like double the entire hash rate on the test net um this is like on the order of millions tens of millions of dollars so i'm changing the dtd as much is much better um oh good question bye bub what

happened is there's multiple miners that find a block passing ttd at the same time um so the way that the merge is designed any block which passes ttd which is obviously a valid ethereum block and who is the first block in its uh in its fork retreat to pass dtd is a valid candidate uh terminal block so it's it's very much possible that you know there's there's two of them or three of them like we see uncles on the ethereum network right now so as long as they meet all those criteria um basically the validator who produces the block uh after is free to choose any one of them and then it might reorg until this block is finalized and like justin

is saying in the chat this is sort of what happened in gordy um because basically like yeah until we've like finalized any um any proof of work block which exceeds ttd whose parents does not exceed ttd and otherwise follows all the protocol rules is a valid terminal block and um this is and so it's possible to for a validator to select any one of them and it's possible for the next validator to select another one and this is why we want to wait for the network to have finalized before we consider the merge to be complete um yeah and ideally you know the network will converge quite quickly on one of them but we obviously want to finalize just just to be sure okay stable coins uh migrations

so um short answer is at at the like at the application level nothing changes nothing is required for applications to migrate to the merge um so if you have usbc now you'll have usdt after the merge and you know you don't need to move them or do anything with that um so you know there's no like applications where you should have to to do an action in the case where there was a separate fork around the merge at the same time so like a proof-of-work fork in parallel um then everything on ethereum kind of gets mirrored on both side so if you have say usdt balance in theory you have a usdt

balance on both chains um but then because say usdt is backed by like actual dollars um actual dollars uh not on ethereum um the the tether like the issuer will have to recognize like this is the chain where um where these usdt's are actually redeemable for one dollar um i believe so far tether and circle have both um like recognized that this would be under proof of stake chain um but yes and like mike is saying this is the case every time there's a network upgrade there's the um you know there's the opportunity for like people on the network to not follow this upgrade um and then what happens is

like everything gets duplicated across both chains um but anything that has like a reference to something off chain only kind of gets uh honored or like recognized on one of those two chains um and for usdt specifically and i believe like pretty much every stable coin this is the the proof of stake chain um and like yeah caleb has an important clarification like you know you shouldn't have to like give out your private key sign any messages migrate your coins um please please be like on the lookout for that um we've seen like some really good uh phishing emails uh and just like fake emails about this uh recently so like if somebody says like you need to

like move your coin or you need to like you know sign in somewhere to activate the merge or anything like that um it's very very likely a scam so please be on the on the on the lookout um okay so damian has a question about uh basically the ttd estimate uh being uh from the hash rate at the current level with september 15th um that's correct and so this is why we tell people um to like uh that it is variable so you know our goal wasn't to reach it exactly on the 15th our goal is mostly to reach it after

bellatrix happens and ideally not too far after the 15th so you can think of like we want to be safe plus or minus a week on each side um and this is roughly why like the 15th was targeted because if you have bellatrix on the sixth um you know you would have to have a massive increase in hash rate for it to happen before and if we get you know to the sixth and like close to the 15 and we see we're still very far out that we would just do a ttd override based on the hash rate levels there or like the hash rate trends um yeah but there is the goal isn't to like absolutely try and get it on the 15th it's first and foremost to make sure it happens after bellatrix and then ideally get it in one go roughly close to the 15th but if

that's not going to happen we can always do an override um any other questions i don't know where the pandas came from made a meme a couple months ago i'll try to i'll find it um well but the verbal description is the execution and consensus layers are represented by a white player white bear and a black bear and the merge is done coming together that's where the panda comes from and people liked it so much it ended up

in all the client software thanks barry yeah yeah that's sweet yes i said white bear i it was technically a polar bear um tldr there was a summary of gurley francis there was a summary of gurley earlier there's a doc if somebody can show that again if you're joining late uh i'm not sure what you mean by resource constraints you mean in times of non-finality i think it's that some of the basu nodes were running on a resource-constrained machine and that caused them to go offline i don't know

justin is that correct i'm going to try and in uh on youtube yeah okay say again uh was it was it basically that had some issues during the gordy merge just because some of the nodes were running on like uh resort like um in sort instances with two small resources not this time that was that was a problem in prior shadow forks okay but we were we were well resourced for really okay i don't know maybe perry do you know i i also have to check i'm not sure which client it is anymore but yeah short answer is i think this

happened on gordy as well but then the situation is just you give them more resources and the clients were fine also resource use tends to spike quite a bit during non-finality and at least on gurley that period was just a couple of epochs after uh after the merge and once we hit finality again resource use did does decrease quite a bit so we even with the previous notes i think i don't even think they had to upgrade but i think it sort of fixed itself once finality had been reached any other questions

now's the time to get him in if you were waiting until a quiet moment and one last uh offer for any client any client types or researchers who are on the call and you want to mention something that wasn't touched on before feel free to raise your hand if you'd like to talk about your client anything specific that people should be aware of any resources that you can offer to people things like that okay

go ahead i was just gonna say it's not because there's there's like been a couple questions about like estimating the ttd and whatnot and maybe i'll just like add a last amount of nuance on there the reason you know you could imagine a world where we just have bellatrix happen and then we decide the ttd right and this is what we did on a couple of the testaments um the challenge with doing that is just that like you have to get people to upgrade their notes twice and because this is already like a pretty complete complicated upgrade relative to other ones um we opted to like optimistically have people only need their nodes to be updated once and to kind of bake in a ttd estimate for that um usually when we ask people to upgrade

their nodes we think like on the order of about two weeks is like reasonable so like we put out the software put out an announcement then within two weeks usually we can get the community to upgrade their nodes um so if we kind of hit bellatrix and we see it's gonna be way more than two weeks to hit ttd um then it probably makes sense to to coordinate another ttd and have have it lower and have people upgrade their notes again but this is like why there's so much like uncertainty or like yeah wide estimates around it it's just because um we need to predict oh sorry my headphones uh my headphones went off for a second um but yeah it's just we need to predict this value

that's really far up in the future that has like a lot of like unknowns that go in into it um but if we and so we take kind of our best guess for it if we see that this best guess is wildly off um then we can correct it and the only downside is people need to re-upgrade their nodes or run an additional command and this is what uh we'd like to avoid in like the happy case but it's not um it's definitely not the end of the world to have to do it and we've done it on robsten and for users it's basically either downloading one new version of their clients or running one extra command on it while it's while it's going live um and then there's a question about

issuance um so issuance is basically based on the total amount of validators on the network so if there's more validators uh the total issuance goes up but then the the kind of rewards to the validators proportional to their stakes go down um and that kind of targets a specific amount of validator um yeah so so so it's confirmed that it is part of this spec but it's not confirmed in that we don't know how many new validators might want to validate after the merge um and that impacts issuance and i think uh ultrasound.money i believe has like a a nice little like

graph that you can you can you can tweak to see um yeah based on how many validators and whatnot um oh nice yeah i didn't realize they had a adjustable graph this is great all right looks like we're actually out of questions now um besides from some ttd panda ideas but i don't know if we're gonna

be able to include that micah is sad for some reason he would love to keep answering questions um but i think we can probably wrap up here i've done the last call like three or four times now um tim anything else no yeah thanks everyone for showing up well we'll oh we do you want to give the date for the next one because we we've scheduled one more of these before the merge if if i'm remembering correctly i think we were going to plan for uh let's see [Music] wednesday the 7th of september does that sound right

actually yeah there's oh yes so so we said we wanted to do after bellatrix and before mainnet right um so that there will be more more eat staker events before bellatrix uh we can encourage people to watch those um but then between bellatrix and mainnet we will do another one of these um so okay so maybe that's the ninth thing yeah tentatively say september 9th at this at this time so like uh four yeah four weeks from now exactly um okay yeah yeah that will be uh if you're interested in attending that it'll be in the same spot as a a pr in the the ethereum pm repo with an agenda

and um in 10 minutes if you're a validator remember that there's a an east staker call workshop happening in 10 minutes and where remy where's the best place for people to jump into that maybe you can share the link again or direct them a certain place if you already left um just i don't know where i would point you but the e-sticker discord probably is the best place somebody just posted the the youtube link again um yeah oh perfect yeah so oh yeah take your youtube channel go ahead

that's it the youtube link there by bth is the sticker workshop one last question uh yeah i don't know if we can explain replay attacks but i'm not gonna get into like how to financially profit from this uh upgrade replay attack is when you send a transaction on one chain and it can be replayed on a chain that's similar but not exactly the same as the one that you sent the original transaction so aside from that yeah okay

yeah i think we got it um thanks everyone for showing up and uh yes you in about a month for the next one of these all right thank you again to the client devs and researchers who showed up and answered questions i really appreciate you spending time on this so yeah we'll see everybody in a month or in the r d discord or elsewhere bye