Merge Community Call #4

Transcript

okay let's try this again all right sorry about that everybody um i'm getting rusty i used to do this for you global and we had this problem a lot but uh i've forgotten my large call management skills but um now everybody's muted uh and we should be fine going forward thanks trent um okay so let me repost the two blog posts um and and quickly kind of go back over it just want to make sure we have time for a bunch of questions so um we announced uh the robson merch transition earlier this week uh the first blog post i link has all the client versions uh that uh that are compatible with the upgrade as well as

like a couple notes for node operators and stakers um i think the first one of those is uh that obviously if you if you run both uh you need to run both an execution layer and consensus layer client to participate in the transition on robston um and there's a new api over which these two communicate called the engine api and this api requires jwt as secret for authentication um most clients will generate it uh upon starting but you're gonna need to pass it from basically the el to the cl or vice versa so that's something you should pay attention to when you're kind of setting up your um

on the staker side this is probably the most important thing is um after the merge stakers are the beneficial beneficiaries of uh priority fees on the network so all the transaction fees that currently go to miners uh go to stakers after the merge and in order to receive those if you write a validator you need to set what's called the fee recipient as part of your consensus layer client um so different clients i have like different ways to set this up but whatever you're using it's part of their their documentation um so that's something you want to look into and this basically asks you uh for an eth address where you want transaction fees to be sent to when you propose a block um and it's worth noting

that this is just like a regular ether address so those fees are not locked on the beacon chain uh they're like immediately accessible to you after uh that block is is confirmed um so um uh so yeah please do set that up to make sure that uh and test it on robson to make sure that you can actually uh get transaction fees um and then finally this is the second blog post that i linked uh so the merge is like a two-step process first you need to activate and upgrade on the beacon chain called bellatrix which basically starts listening for the merge to happen and the way that it does that is it listens for a specific total difficulty proof-of-work value to be hit on the on the network um so like it just

constantly paints the the proof of work network and asks it you know have you exceeded this total difficulty if yes it runs through the transition if not it pings again um so when we uh when we put out the releases earlier this week we selected a really really high terminal total difficulty and the reason for that is because the hash rate on robstin is super low and it's easy for people to kind of mess with it at a fairly low cost and we wanted to make sure that the bellatrix upgrade on the beacon chain was was ready prior to uh choosing the actual terminal total difficulty and so last night uh that happened and so this morning we just published a second blog post which has uh the kind of actual

uh terminal total difficulty value at which we expect the transition to happen um and so all you need to do there is you need to pass this value to both your execution layer and consensus player client and the blog post has literally the flag that you can copy and paste for every single client um and i'll just post the actual value of the chat um so if you're already running something and you know how to do the override um you basically need to override the terminal total difficulty to this stop um yeah i'll stop here to make sure we have like time for plenty of questions um yeah oh yeah so if anybody has any questions

related to that just put them in the chat um unfortunately i'm gonna stay away from audio questions for now okay and yeah while we're waiting yeah just worth noting um we do expect uh to hit this uh this terminal total difficulty value and for the merge to happen on roxton uh late next week probably around like wednesday or thursday it's really hard to predict this because proof of work on test nets is very unstable um but uh i would strongly suggest uh just running this ttd override either today or early next week so that you're you're good when the merge happens um and one final note also for folks who

folks have only um used the beacon chain um one thing to note is that for when the merge happens you want to have a fully synced consensus layer client on the beacon chain and execution layer client um if you've only ever used the beacon chain you will think that sinking is quite fast and you will be disappointed when you try to sync on the execution layer side uh so please be mindful that it takes uh it can take up to a few days to sync a note on robston uh and so if you want that by the end of next week i would i would suggest um i i would suggest getting that's started either today or early next week and it's fine also if you're if you're syncing

your node um and and you still don't have like the merge client versions uh that's totally fine you can start your sync update your client and then um and and then finish your sync with any client um okay and now there's like a ton of questions so i'll just start going through that um what's the best way to determine transaction finality on each one execution after the merge using the standard json rpc is it possible still um yeah so basically uh today there is no way to determine a transaction finality on the execution layer uh under proof of work all you get is like probabilistic finality where as more and more blocks accumulate the odds of a reorg uh get much lower

um at the merge we're going to include a new flag in json rpc called finalized which you can use when querying your block just like you use latest today and that returns the last finalized block on the chain and this block cannot be reverted unless there's basically a major attack on the network um so if you if you uh if you want to determine basically finality uh yeah just my pc will have a flag for that and it returns it returns a block in the last slot that was finalized basically um okay and then there's a second question about uh the paris upgrade on the el and what does that do and how how how does it work alongside bellatrix um so these names are really confusing and that's

why you should try to call everything the merge um but basically um if at a very high level uh the merges this pro is like this entire process which has different parts so the first part is for the beacon chain to start pinging the execution layer chain and asking it you know are you ready for the merge and this is what we basically call bellatrix so like the beacon chain kind of becomes aware that uh there will be a transition that it will need to include uh specific payloads which contain user transactions at a certain time and and uh starts kind of pinging the clients for that and obviously runs through the entire merge once that happens um on the execution layer side we also have changes which happen at the merge

and we've called those paris um and it's a bit it's a bit weird because unlike a previous hard fork these changes don't apply starting at a specific blocked number they apply only when we hit this terminal total difficulty value and so in practice you know what those changes do is uh first they start you know uh handling uh engine api calls from the consensus layer they stop listening to proof of work as a way to get the next block and then there's a small a couple of small changes uh for example the difficulty op code and now becomes the prevrondao up code so and and some parts of the block headers are are now zero going forward um so there's like all these kind of

changes in behavior caused by the merge and and that set of changes on the execution layer is what we call paris um but basically paris is what happens on the execution layer when ttd is hit um but it's a bit confusing to call that paris and not just the merge so we've we'd mostly use the merge but paris is just like the formal name of the specification for executioner changes when the merge happens uh are we safe to keep mining on robson for that erupts in either should we switch off uh the current hash rate is it's fine on robston um we're gonna increase it early next week uh in order to hit the merge sometime next week but if you were already mining um

yeah and that's that's fine there's no need to take it off um um and like next question is kind of similar around like uh how how much hash power um i i i'm not sure the exact number but um i think if community members want to start helping to mine i i would ask that you kind of hold off until like late monday or tuesday um just because uh it gives more people time to upgrade their ttd uh how long does it take uh forget node to fully sync in archival mode i actually don't know the answer to that question uh you don't need a full like

archive node by the way to run as a consensus layer client you can just to run as an executioner client uh on the merge you can just run basically a snap sync on geth um snap sync takes on the order of like hours uh assuming you have a good internet connection i'm not sure quite how how many exactly um but uh an archive note i i don't know it would take you probably more than a week just to do a full archive sink um i don't know if there's anyone from guest on the call who can answer this um anyways oh if so i'll try to find them and i need them

is the expectation to hit june eight nine uh ask me natural hashtag uh or do we need to rent rates so again we're going to need to rent a little bit um um i've seen that both the consensus client that the consensus client has its own database is it recommended to run both on the same server um yes like yes they both have their database um i don't know i see a lot of people like from client teams here uh i see frederick from like the ef uh does anyone like from either a client team or the ef want to like maybe take a couple minutes and explain how they set up everything and and what you all think the best practices are

and if you raise your hand i guess trent can unmute you the short answer to the question is yes but i think it might be helpful to get like someone from a client team to kind of walk through how how they set it up and um i mean i'm gonna have to unmute okay oh person thank you not a client team i just run notes professionally that's

perfect so what we're doing is we're running cle combos on one machine we typically have this be something relatively beefy for the storage like in two terabyte nvme and then you know 32 gigaramas so 16 is fine too so short answer yes you absolutely can we expect the same amount of resource usage as we see now pre-merge as long as there's both a consensus layer and an execution layer client running on the machine and there was a second question as to can i still run my valve data client somewhere else and point it at wherever i want to go yes absolutely still works

awesome thank you next question is there a consensus client recommended by you uh short answer is no uh so uh in the robson blog post uh we linked that but um client diversity matters a lot on the network especially after the merge so um we recommend that people run a minority client uh if if they can um just because if there's a bug in any of the clients you don't want that client to have more than ideally a third and especially not two-thirds of the clients on the network um because if there was a bug in a client with more than a third of those on the network you could stop the network from finalizing and if it was

more than two-thirds it could finalize something that was wrong um and that's really a situation we want to avoid uh so we yeah we we really suggest that people random minority client and in the original robson blog post uh there's a there's a link right above the client versions table that shows you what's the current uh mark basically network share of every single client so you can make a decision based on that and there's also a really good post by bankrupt that's linked right next to it which goes into like technical details about what are the actual risks if uh there's a majority client that has more than a third or more than two-thirds of the the stake on the network um so i guess

or my personal recommendation would be a minority client but i i don't have a strong one beyond that um okay and then the second question was the next question was answered um then nick had a question how different is implementing the merge on robson versus other test native emergency success on robson should be pretty confident the next couple test nets um the short answer is uh i guess there is no short answer uh the answer is uh we're doing robsten probably a bit earlier than we otherwise would in the process and the reason is because it's such like a big change relative to other upgrades for node operators we wanted to make sure that

people kind of got to try it early and then if stuff goes wrong with your setup uh you have you know plenty of time to fix it and so obviously robson going well is like a good indicator um but we do know that there's like a bunch of tests left to fix uh clients still have some issues here and there so um it's not it's not a given that just because roxton is the successful then like two weeks from now we move to the next test steps um i think for the next one we'll want to have things a bit more polished um but yeah we thought it was really important to uh to give the community like a an opportunity to run through the merge kind of asap so that uh we can find any issues uh before we move together test

nets um okay yeah good question about tesla deprecation um so uh to confirm uh the two test nets that we intend to maintain long term after the merge are gordy and sepolia uh gourley and and basically the parador beacon chain that's associated with it which uh will merge and kind of call algori afterwards um but that combination and uh sepolia which is a new testament that we've recently launched etherscan has just added support for it um and and and that will be maintained uh kind of in the medium to long term as

well so for the other test nets you have roxton which we're obviously running through the merge now we intend to deprecate it after the merge i'm not sure exactly when but you can expect some time before the end of the year we have another test net called rinkeby which runs uh proof of authority uh contest algorithm this one is not being run through the merge so if you have stuff on rinkybee it means that once the merge happens on mainnet rinkeby won't be like a good copy of mainnet for you to test on uh for smart contract developers it shouldn't change too much except for this difficulty op code but if you're if you're testing more like infrastructure and stuff then it'll be it'll be quite different uh so rinkeby again we're not to shut it down

overnight it'll probably stay up until like late this year but um as of the merge we basically consider it to be deprecated and then lastly uh there's kiln that's mentioned so kiln was the new testament that we spun up basically just test the merge uh we launched it in march and the goal there was to get some birdie testing from the community about you know does do these nodes work together and like can you deploy your smart contract and and kind of use ethereum post merge uh so we've we've launched it then and that was always the purpose was just to test the merge so uh i suspect we'll leave that one up until the merge on mainnet and deprecated pretty quickly after um so just to summarize you know rinkaby is

just not being transitioned and will probably be shut down by the end of this year kiln is already beyond the merge and will be shut down shortly after the main net merge uh roxton is transitioning as we're talking about today and will be shut down later this year and then gordy and sepolia will both transition and and will uh will carry on medium to long term um um oh uh okay yeah phil i just put a a link to a big summary from afri in the uh the chat if people want to read a little bit longer about that and yeah phil if you want to jump in now that minority clients yes yeah hey everyone uh yeah so for minority clients

i mean great thing that you mentioned modestar is you know robsten ready so for people who do want to set it up we actually have a pretty cool merge script that is basically like a one line command startup that'll start up a a load star beacon node alongside the execution layer right now it's uh you can choose between gath nethermind and baesu so you can check that out on our github page uh github.com chain save load star and then under the kiln folder under devnets all the instructions are there you can also find um all of that stuff in some of our chain safe blog posts we do have setup guides and some

videos for you as well which i can post into the um the issues uh for this meeting afterwards as well in terms of hardware specs it's not um that's uh nothing fancy just like a normal like even 16 gigabyte ram uh pretty modern type of processor will be able to handle it all and um we do recommend that people use docker with load star um in terms of um preventing you know like npm type supply chain attacks and stuff like that so if you do run docker you shouldn't have a problem setting up load star okay do any other

minority tribes want to take a minute or two to shield their clients i'm happy for us to make the space for that i see some nether mind people here uh yeah oh thomas go for it hey hey sure yeah some of the mind tests all the robs will be maintenance ready it introduced recently the snap sync that gives you something like around three three hours to sync and uh snap sync mode with the mainnet uh and you can use it on practically all the network that will be going through the for the merge testing it does sync with all the shadow forks test nets and so on

um so yeah like you're really encouraged to run it let's uh also have a look at the documentation and docs that's nevermind.io this one is being updated constantly now we have two or three people working on the new docs there's lots of examples of how to launch the client in different configurations another minds team is also running and practically all the other like combination of nodes as part of our own validating staking so all works and you're invited to ask us questions join on discord share on twitter and so on much appreciated thanks of course thank you uh and matt you're

from basu yep that's right um similar story to what uh was just said we are a minority client with baesu um we have a lot of great features that we'd love folks to test out as well like snapsync and our bonsai storage format which we're eager to get folks using especially on these test nets so that we can of course make sure that we're even more merge ready um but we do have stuff up and running on robson right now uh so we would love for you to check us out try us out we have you know support for a bunch of different platform types so whatever platform you have will likely be supported uh with native support so you can get great performance there uh

and of course always want to see more and more participation and more and more usage of these features reach us on discord give us some feedback uh let us know how everything is going um you know and we would always uh uh of course we're going to be participating ourselves so we'll probably have some results to share after the actual merge and we're looking forward to putting out some more material around the merge as well so you know of course you can find the docs at baysu.hyperledger.org and you can find a lot of material on the hyperledger discord and the consensus discord and different blog posts on twitter and consensus.net thank you um i know guess death and prison are also

here so if you guys want to give a quick shout also please do i it feels it feels wrong to like not allow it um with the with the disclaimer that they are the two majority clients um anyone from geth or prison wanna give a quick update they can talk but they only get seven seconds oh oh i got a thumbs up from parents is that you want to talk to you oh marius okay varys hey

um yeah we're happy that other clients are having so much progress and you should really try them out and see [Music] how it works out with them and you're also happy to to try out gap um yeah that's it seven seconds awesome thank you i just wanted to add that all the clients are great so definitely try every single one of the combo and give us feedback at the end of the day like those feedbacks are very important so if you have one client better than the other client um please do share that with um with the other client i just

want to add that yeah great point um any other client teams here that i missed or just i need to like scroll back and forth the zoom participants but last call client teams i think that's that's everyone we have okay i'm just i'm scrolling through the questions and i want to make sure we're did we answer this kiln question no that i was gonna get to that yeah okay perfect okay so we're at the same spot go ahead yeah so uh sea monkey asks about uh whether it's still worthwhile to have uh validators on kiln uh or should he shift uh or should they shift i guess

their their uh resources all over to robsten um and there's there's an answer from thurston already in the chat like uh kiln is the only network where we're currently testing any v boost so there's obviously value there but with regards to just kind of running a bunch of elevators and testing there i i wanted to say that it makes sense to to move to roxton rather than kiln um but if anyone on the client or testing team is here and disagrees with me can you please speak up my my instinct would be yes but i would confirm it in the r d discord just in case there's something i'm missing that um yeah that that means it's still valuable

to do it on kiln um okay uh next question uh recently had to delete prism beacon chain data to fix syncing issues it took about three days to sing prism is this normal is this a normal amount of time um parents do you want to take that yeah we do get that feedback a lot so we are actually landing we subjected to this thing in our latest release so please do try that the documentation is all there i will paste the document teacher in the chat so if we if you start with the finalized state or which is we subject the same thing it is much

faster yeah awesome thanks um next question is it possible to test the merge with drops then first is what's a lower ttd since bellatrix is already activated so that's what we did i'm not sure i understand the question but basically the new ttd uh is much lower and this is why people need to overwrite to it and robson will be the first public test net to run through the merge but i'm not sure if i'm actually answering your question gabrielle if you want to raise your hand i can take you off you can if that doesn't answer your question is there a work faucet for robston i

think is the next question oh that's been answered perfect okay yeah oh yeah there was a question about koban and i saw i think martin from gnosis is on the call uh do you all have a update on covant or should we just consider it to be deprecated um i'm not i'm not quite sure what the status is there actually martin if you're able to talk just raise your hand and then we cannot mute you if not the chat is fine yeah

okay yeah and we can get oh yeah sorry um yeah yes the question was about uh copen whether that will or what was the question yeah is is kovan going to run through demerge and as i understand it yeah i know right right right now right so um no it will not because um coven is essentially open ethereum only and yeah after announcing it three times uh said open ethereum is dead i think it's finally really dead um so on our end um a little bit of context maybe so on also formally ex-die now notice chain we will are still planning to do

our merge or we will see but currently targeting to do it yeah shortly before ethereum we are currently developing or well we will do have our own kind of for new testament to test it there as well publish that road map very soon but long story short coven will not play a role in that because yeah the merge will be done with another mind and and aragon and again coven is open ethereum and open ethereum is dead got it thanks for clarifying um okay and gabriel has his hand up uh from the previous question so i've i

think i've unneutered you thanks hi i just need like 20 seconds yes my question is about the ttg because i'm a node operator so we are kind of scary to run some nodes everything on june 8th so we would like to just test that the consensus clan is uh it's working we made a good connection with the jwt and everything is working well before the unit if it's possible to oh yes nowhere yes and you should the teaching yes yes oh uh so we're not gonna lower it uh on robson uh but basically you should by setting up your execution and consensus layer today like you should be able to know that

like they're working together that the cl is pinging the el um that your jwt token is set up right um so you don't need to hit the ttd for that but and you want all of those things to be set up and and working before the ttd hits because that's when you actually run through the merge so you yeah it should be like there shouldn't be anything stopping you from from updating everything today and and making sure that it works and then once we hit ttd they're just gonna run through the merge but you should you should kind of yeah there shouldn't be like a block here before that does that make sense oh

there's if you have another question maybe post it in the chat um but uh yeah i i think you should be all right um first then you wanted to shill your uh automation tool that supports online clients i think we can allow that um okay all right thank you so i'm going to keep that brief i have an automation tool called f dash docker at sdocker.net it supports all nine clients for robston it uses the um official releases from the client teams uh it also supports mev boost but i

think right this very second it's only lighthouse that actually has that implemented and we don't have a uh a relay yet for robston but we might get one so that's it just if you want to try things out switch clients around quickly online clients are supported can you share a link to it uh i wasn't able to find it yeah in the chats that would be great oh i wrote i think i wrote out dash um okay next question was a working faucet for robson there was already a couple shared and there's a link i just shared in the chat that like is pretty good

across all test nets it tells you like what are all the faucets that they have money in them uh and so it's a good just general faucet tool to see where you can find some some testnet piece um okay lots of comments uh have you heard from infer already don't have a robson cl checkpoint sync endpoint i have not is anyone from i answered that one i'm not sure if there's any inferior people here but they confirmed that they will not be doing a robston cl endpoint got it okay how can people contribute to the roughstand merge if they don't run a

client yeah running a client i mean so so there's a couple things like one is uh yeah running a client and reporting any issues is really good and and when i mean reporting any issues it doesn't have to be necessarily technical issues like if you're trying to run a client and like the documentation for the client you're trying to use is just like really unclear like trying to highlight that is also useful um so it doesn't only have to be like an actual technical issue and i think the other bit that's really helpful is if you are a smart contract developer uh or just like a tool in your infrastructure provider like running through like a full deploy on either kiln or robson post merge is

really helpful um and and we don't expect anything to break at the contract level or at the tooling level but it's just like because i don't know if you use a bunch of like automation tools or like deploy scripts and stuff like that like there might be weird things that that do end up breaking uh even though the network is stable and finding those issues is really important um yeah and i think that's really the two biggest ones um beyond that like i i think it's just trying to use the stuff on kiln but uh yeah the you know most of the value is really just like either running a node and to be careful when you run a client it

doesn't necessarily mean a validator like you can just run a node and sync it and make sure that that works as well uh so it doesn't have to be an actual validator that's running and then trying not only to deploy a smart contract but more to like deploy an entire kind of application with a front end that's linked to a smart contract and stuff like that and i suspect if there were things that broke it would be in like these like tool chains rather than like the actual code of the smart contract itself on the network um uh okay next question what are the odds that somebody controls the new ttd i mean i i don't know what the odds are but like

they you know it is possible like it does not cost hundreds of thousands of dollars to do this um so um the worst case scenario there is like it would be a bit more annoying for end users who want to run their own like at-home validators who haven't already upgraded or overridden their ttd so uh we recommend people do that as quickly as possible all of the like the vast majority of the the validators though on the network are controlled by client teams and the testing teams and whatnot so all of those have already been upgraded uh so from the network's perspective you know even if the ttd was hit now it would run through the merge and be fine uh from an end user who's trying to like test their validator setup um if

they haven't had time to do the override uh it would be a bit annoying because then they need to do the override they might have to manually set a specific block as the head or as valid as part of the chain um so it's not um it's not ideal uh there's not really a great solution against this because the hash rate on tesla's is just so low and it's so cheap to mess with them um okay some comments about clients uh uh okay uh does get need to be fully call up for lighthouse to be able to talk to

it i'm seeing below an error in lighthouse while get this thinking uh marius do you wanna do you wanna get that yeah i um i already answered chat but yeah so guess doesn't need to be fully synced you um and postmate of course will not be fully synced when you start up a note uh you will you will start up both the consensus layer node and the execution layer node um

and [Music] yeah it might just be a configuration problem in that case but i also saw a bunch of times that lighthouse would just lock this uh error out if something like if gas is sinking so it might just be a logging issue but yeah you should be i believe it's more like a warning yes okay um

oh yeah so aside tracking the difficulty increasing so trent shared one in the chat um i'm not sure the thing is like these estimates are only good if the the hash rate stays stable which uh we don't expect to do because um we're gonna want to accelerate the hash rate uh sometime next week so to make sure we ship this ttd value next week um you the total difficulty is part of the block header so if you go on ether scan you know and you look at the last block you can see the total difficulty um but i yeah i wouldn't trust the estimations too much because um you can basically make it happen much quicker or much

slower uh based on on pretty small changes in hash rates so um yeah we're hoping to have it hit around wednesday thursday next week uh but if it hit you know on monday because someone adds a bunch of hash rate over the weekend that is the possibility so the best thing you can do as like a user is just make sure that you have the ttd override um which is literally copy-pasting two lines uh when you when you start your client um and that'll make sure that you're regardless of when it hits um your client is ready um uh so okay so there's a question about eth1

endpoints fallbacks thurston you you answered but um yeah i guess gabriel if there's any follow-ups you can access them in the chat um next one is the transaction format uh is the transaction format gonna change after the merge uh no basically um no so the thing that does change so transaction formats on the el are unchanged um block header formats are also unchanged but some of the block values will be like set to zero um the block format of the

consensus layer does change after the merge and so that's something that if you are basically using these apis uh the beacon apis uh that will change but um on the execution layer the the block format and transaction formats are the same um are there any plans to not publish the main fttd to the public until about a week left from it um so yeah that's a good question it's um it's hard so so there's different approaches we can do here um what the thing we want to avoid is the ttd being hit prior to bellatrix being activated on the beacon chain um

if uh so one way to do that is we can activate you know bellatrix on the beacon chain quite early on mainnet and it basically does nothing uh in terms of functionality uh until the ttd is here so that gives us a chance where it's like we could have just a first client release with bellatrix and have like a ttd of basically infinity and then um and then we can we could kind of choose the actual ttb in terms of how much of a heads up we give people we i would personally prefer it to be longer than a week for people to upgrade because it's mainnet um and it's also worth noting on maintenance the risk is like a bit different so um on mainnet in proof of work we have the assumption that nobody can double the

hash rate overnight because otherwise they would be you could 51 attack the chain um so you know if we're happy with like the safety properties of proof-of-work we we already have this like assumption that 2x of the hash rate is not going to come up so that means you can never hit you know the the hat the ttd like more than twice as quick as you expect and even in practice the the like hashrate punctuations are much much uh smaller than that the thing that might happen though on mainnet is that uh because the merge is happening hashrate starts to drop from the network because people sell their gpus um so that would mean that it would take us longer to hit the ttd so there's a world where imagine we say okay this is the v value we expect it to hit in two weeks um but people start to sell

their mining equipment that maybe we hit it in like like three weeks instead of that because the hash rate has has gone down on the network um if it were to go down like to the extreme you know so say instead of two weeks it's going to take us like 16 weeks to hit it then we can basically do another override to another even lower value and and and kind of and and kind of not wait that entire time would like to reduce security on the network because of a really low hash rate uh for months um so yeah we haven't quite decided the rollout plan for for maintenance yet like uh we but but for sure like we want better tricks to be activated well before we hit the ttd and it's usually much easier to make sure that

happens because uh it's highly improbable that a massive amount of hash rate just shows up out of nowhere uh on a chain that has like ethereum's level of hashrate already um is there any reason to expect apps to have more difficulty with the merge than any other hard fork uh such as fifteen bit nine uh for smart contracts no uh short answer i think uh for infrastructure and tooling providers the merge is probably a bit more complex than than 1559 um especially if like you you only cared about either the beacon chain or uh the application layer before um so for but like for smart contract developers and whatnot i i i don't think it is and there were two changes

mentioned earlier in the chat where one is just the block time goes from like 13 seconds on average to like always a multiple of 12 seconds it's not necessary that there's a block every 12 seconds because a validator might be offline but you kind of get like a change in like the block time dynamics so if you're doing stuff like calculating apys based on the number of blocks or stuff that will be affected um and then the other thing is that this difficulty op code changes to prevrondow so it's still a pseudo-random value so if you're using difficulty for pseudorandomness in your smart contract it's still going to keep working the only difference is the size of the value so um off the top of my head i think the

difficulty value is like two to the 64 whereas the prep randall is two to the 256 um so that's the only thing that kind of changes like the size of that return value um and this is actually a neat way to know as a smart contract if the merge has happened you can just call this up code and if if the return value is like a 2 to 256 sized then you you know that you're in a post merge ethereum okay bunch of lighthouse configs uh orson do you wanna just uh read out what you shared in the chat for the recording that question

okay what am i saying someone had asked whether they could just skip the test nets and uh yeah yeah yeah um it's it's really dangerous to do that or risky at least sorry sorry i'll read out the question first read out the question yes okay sorry sorry sorry so the question is validating on the bc i'm assuming that me speaking chain can i simply stay on the bc main net and not try out the test nets and wait for the merge to happen on mainnet um so taking it literally sorta kinda yes as long as you adjust your config to have a fee recipient which is really important and

to use the engine api once att has actually been announced on mainnet authenticated on typically port 8551 with a jwt secret now that sounds like a change right it is if you don't test that your configuration works beforehand then chances are your configuration won't work if you don't make these changes you won't go through merge so you know my recommendation just is find yourself a cheap little vps somewhere try it out learn how to do this how to change your current setup to one that supports merge and then make the change on mainnet when it's time to

do so not now thank you okay yeah we only have like three minutes left but i think we cleared the queue of questions uh anything else any final questions people had uh do you want to yeah show your calls so cat editors are planning separate talks by different el ncl client teams where you can get more information about the latest specs already we are having a lot of blogs going out from the foundation but if you have any client specific

questions you are invited to join the people need tasks with different clients or you can also follow the recording later on catalytics youtube schedule is added in the uh link here yeah i guess just generally like if if you are running a validator and you haven't participated in any of the the other testaments like consu gear kiln now would be the time um obviously you're not obligated to like like thorson mentioned you you don't have to but it's probably in your long-term best interest to have an understanding of how these um configurations get set up just so you know you have peace of mind that you you understand how the merge is coming and uh you're prepared for it

um and then like puja mentioned those calls we'll probably run this call at least a few more times before the merge um for for general questions and and things related to cadence or timing just to make sure we're getting that information out there but if you have technical questions definitely uh start going into the the client discourse that they're going to be the best place where you can get information for technical troubleshooting or the eatstaker discord is also a great great resource as well yeah um and then uh there's one final question but the i just want to touch on this test that thing as well um i think it's it's also worth noting that like

gordy and sepolia will probably happen like much closer to the main net merge uh than like robson i mean by definition but also like just in terms of delay between delays between them um so if you are like just waiting um you know obviously we can't we can't force you uh um to to use robson but if you're if you are just waiting uh and and then you you go just on gourley and and you realize like you need weeks uh and maybe like months to like update your setup um then you know we might have scheduled the merchant maintenance by then so like and i don't think realistically you should take anyone who's already running your validated months to adapt to this um but yeah just note that like the delay will

be shorter there um and yeah jonas asks like better articles about uh running uh validators uh we are working on it there's a bunch of different efforts on that uh on on that point uh so yeah we'll we'll have more of those definitely in the coming weeks and months and then finally there was a question about finality for transactions so basically uh transactions themselves don't really have a concept of finality it's more blocks and today on proof of work there is kind of no explicit finality um so after the merge basically if a transaction is part of a block and that block has been finalized uh by the proof of stake chain then we consider it final

or finalized uh as well so like the transaction that's within that block would be finalized um and basically what what that means is for that transaction to be re-org um an attacker would be willing would need to like have control over uh more than two-thirds of the state and be able to uh to basically write an alternate history and and that's a that's basically the same same level more or less of guarantee that you have uh under under bitcoin or under proof of work sorry with like a 51 attack so for all kind of intents and purposes that's usually pretty final um yeah and then uh again this will be

exposed in the json rpc api so it's much easier for applications to like actually query what's the latest uh finalized block and and and return that information to their users yeah and i just shared um a link to the google group that we're running for announcements um if you're interested in getting notified whenever there's a new blog post released about something related to the merge or ethereum generally but uh obviously these next few months are going to be focused on the merge that's probably the best way to make sure you don't miss something and then obviously you know as important milestones are reached we'll broadcast

them on the typical channels like twitter uh the r d discord uh all the client discords things like that anybody have any final questions um also if you if you like you will you will probably run into a bunch of bugs or you might run into a bunch of bug bugs uh setting up this this stuff and if you do so uh please please please send them to the client teams so that we can fix them and yeah

make sure to to to test your setups make sure to notify us if if something goes goes really wrong and i think we also increase the bug bounties and we will also be increasing the bug bounties around the merge especially for like the much ready software and so yeah looking forward to all you testing our stuff all right if there's no other questions or comments thank you everybody for coming um like i said we'll probably be running this again in the future on a more regular basis so

um however you found this keep tracking those channels i've been tweeting it a lot but uh yeah whenever the next one is we'll be sure to announce it um and yeah the merge is coming soon tim you have anything else no that's it thanks a lot to everyone who showed up all right have a good weekend bye