Merge Community Call #3

Transcript

all right welcome everybody to the third merged community call um [Music] there's been tons of progress over the past month month and a half um moving towards new test nets fixing old ones and we're going to share a little bit about that and just generally talk about what validators users and the general community can expect when the merge actually happens let me grab the agenda again there's a list of things that we've gone over in previous calls and i think there's a few new things on

there um but yeah does anybody have any topics that weren't added to the agenda that they wanted to bring up uh that they just want to bring up now and then i can mark it down and we can get to it later if not we can have tim jump into some stuff have we already talked about randomness in previous call i don't remember yes but i can quickly cover it the difficulty thing basically yeah if we've already talked about it that's fine i just wanted to make sure it gets one of these calls okay yes um i do feel like now there's no way we can't cover it

[Laughter] um i guess unless there's anything yeah maybe just to like quickly recap application level changes that matter in the merge and then we can go into like what happened since uh since this call uh like like mikko was saying there's there's only a couple things that really change uh in terms of like on-chain for applications um one of these things is that the difficulty value gets replaced with the random value from the beacon chain so if you are running an application that uses uh difficulty as a source of pseudo randomness um this will still work uh it will just be a different uh

random value that we get and uh one thing to note is that the random value is much bigger than the current difficult difficulty value uh if if i have the numbers right i think the current random value the current difficulty value is about 64 bytes and uh the difficulty is 256. um so that's also a neat way you can check at an app level if the merge has uh oh bits sorry so if the yeah if the the if the value that's returned i buy this up code is now 256 bits uh it means you're you're in a post more post merged world on chain and that's one of the big changes uh the other changes anything

else that has to do with proof of work uh so things like uh the uh anything except the difficulties of things like the mix hash the the list of uncles and whatnot basically all gets zeroed out um at the application layer the random value is the only one that kind of gets added replacing the current difficulty value um there are talks where i just saw yesterday there was an eip published to start uh specking out withdrawals from the beacon chains um it's quite possible that in the future the the the values that had to do with uncle blocks get used for something like uh i think they're state routes in the

beacon chain or withdrawal routes uh i'm not sure quite what the term is but basically that we use this this uh that we use we use this displays in the block header to just pass information from begin chain receipts and then the last kind of big thing that changes um from an applications perspective is that block times go from 13 seconds on average with a lot of noise under work to uh 12 seconds exactly under proof of stake um and the the one thing is uh if there's a if there's a proof of stake validator that's offline they miss those plot so that means you know you you get the the chance of a block every 12

seconds exactly it does not guarantee a block shows up um but if it does it will be kind of a 12 second increment um and right now we've only seen less than one percent of blocks not not uh show up on on the beacon changes because the letters are offline or things like that so those are the high level changes that you can expect in the merge there's a bunch of links that trent has as has put in the in in the college and that dive more into that and that's that's basically it i think if we want to quickly like chat about stuff that happened since the last of these calls uh so right before christmas we launched the kinsugi testnet uh which

is basically a new testnet that's uh running the post-merge version of ethereum so it has both a beacon chain on it and an execution layer uh execute some transactions we did find a couple issues on the network uh mostly uh basically in in uh we found a couple of initial bugs uh we fixed those but that led to the network not finalizing for a while and then we found some more issues that only happened when the network was like in a deep state of of non-finalization and we're in the process of fixing this some client teams already have and we have basically a new spec for a new test net that's called kiln um and we expect kim to be the last test net that we launched

before forking the existing test nets like gordy and robsten and whatnot um so i think one thing for applications that's uh really worth doing uh both on kimsugi that's live today and if not on kinzugi absolutely on kiln when it goes live is making sure that like your entire tooling workflow and deployment workflow works um it should and there shouldn't like and we've we've tried with like a handful of applications already and and things kind of work as expected but i think uh you should really see kiln if possible kenzugi has like a dress rehearsal before the testnets fork um so if you can deploy kind of a staging version on that uh there is an

and like uh an infer sign forever there's like an rpc endpoint you can you can just point to you don't have to like run your own node if if if that's not something you usually do for your application um on the ethereum foundation blog there's a blog post announcement about kitsugi that links up those things and there'll be another one for kiln uh well yeah i think it's really important to stress this like this is kind of the time to find out that like your uh you know your your contract deployment script doesn't work for whatever reason uh and or your ui is actually weird for whatever reason like these are the things we're hoping to find out um

a special uh special eye i think is towards like tracing so the applications we've we've deployed already don't really uh use like extensive tracing so if if you are an application that does um and you're listening uh if you want to try deploying on on kinsugi and kiln that would be great uh and if you find issues uh if you can if you can't share that feedback that'll be super valuable and oh and yeah the the last thing uh i think that i have is uh the agenda the idea of outsourcing uh to a web3 provider your execution

client is probably not going to be possible after the merge so right now it is possible if you run just the beacon chain node to outsource your uh kind of it's one node to to say infer our alchemy because you're only just getting kind of information from the from the deposit contract um but after the merge basically uh if you're a validator you need to produce blocks and you get paid to produce blocks including transaction fees which are like immediately available to use um and so because of that you actually need to run your own uh your own node on the execution layer um yeah so that's something that that people should be should be aware of uh

in the future there'll be some cryptographic uh incentives to to or not incentives but like disincentives to rely on the third party i'm not aware today of third parties that are going to propose i'm kind of outsourcing execution clients after the merge um but yeah i think as a violator basically you are kind of risking a ton of revenue by doing that um yeah so just to summarize if you are currently a validator on the beacon chain and you're not running your own execution client and that means deaf or neither mind or anything one of those clients you're going to have to

start running one before the merge and then the other thing you go ahead oh i was just going to say yeah we there there are a bunch of like ad hoc guides to do that right now like for kintsugi but one thing we are planning for like kiln is to have a bit more like detailed guide for like hey i'm running a beacon node how do i add an execution node or vice versa if you are running a node on on the proof of work ethereum network today you're gonna need to run a beacon node uh post merge to get the head of the chain so we're gonna try and just flesh that out a bit more and like what do you actually need to do how do you make sure that you've done it right and so on yeah and the other thing you touched on

which is a bullet point in the agenda as well which i'll go over again is that when you uh i guess the bigger point is at the merge withdrawals aren't enabled that's going to be in the upgrade afterwards which we're probably going to call shanghai but if you have either staked in the deposit contract you won't be able to access that or exit from the beacon chain at the merge that happens later but as tim mentioned you will get transaction fees those will be immediately available and actually i'm it was the call yesterday um paul from the lighthouse team was talking about how you know getting that process started about how to design the

or standardizing the flow of allowing validators to designate which address receives uh transaction fees from the execution layer so something to be aware of again ethe isn't unlocked but transaction fees will be so you won't be able to withdraw but you will have some sort of income if you are validating or uh liquid income let's say uh there's a question marius do you want to just answer that in chat or on voice if you're able yeah so um the the current spec allows for the el to override

what it gets from the consensus layer so the consensus layer passes the the coin based address to the execution layer but the execution layer like the spec allows for the execution layer to [Music] to to ignore that and change that and uh so what like might happen in the future if the consensus layer does not provide an address then it might just take the configured address of the execution list right and for the recordings it was being asked do you want to what do you what do you

think was being asked michael uh whether or not it's possible to set up uh multiple execution clients that are backups of each other so that way if you need to upgrade like the os that your execution clients running on you can fail over to something else and i don't know if we have the tooling for that built anywhere centralized um is the person who asked that question able to just clarify which of those interpretations is correct either in the chat okay the second micah's interpretation so i don't think we have someone correct me here um marius may

know or timor trent i don't think there is any tooling that is built by any of the core devs or anything for automatic failover from one execution client to another so the idea here is you have one beacon client and two extrusion clients in that way if you want to turn one of those execution clients off it'll fail over to another one so that way you can like upgrade the hardware or whatever underneath it and as far as i know that is not built uh yeah so we didn't do something like this yet um wouldn't it just cost supposed to be used like standard um lot balancers that

supports jsonpc or some kind of this stuff sorry what speaking two being clients and one execution client is bad or two extrusion clients one vegan client is bad one of those put you in a very bad situation i don't know which one it is do you remember marius or well it like it doesn't really matter as long as you only have one validator signing um yeah but if you have two beacon nodes that send conflicting set heads then your execution plan gets confused yes yes so uh you yeah you can run

multiple like easily run multiple execution clients off of the same consensus exactly yeah the other way around is it more difficult and from a configuration standpoint does the user just need to connect to execution clients and point them both at the same beacon client and that's it like everything should just work or is there like they will they need to do some sort of special setup for like for the execution client no just like the special setup has to be in the in the in the beacon client in the in the consensus layer client there you have to specify uh these this your url for the

for the for the execution client and uh just another url for failover let me jump in real quick um if people haven't realized that we're moving into sort of open discussion so if anybody does have a question that isn't addressed in the agenda or isn't coming up naturally just raise your hand or put it in the chat um otherwise uh we could talk all day about random things if you don't bring it up keep going micah whoever was talking pari could you expand on that and voice if you're available on how a user might set that up sure usually most speaker nodes have a

concept of a failover rpc and currently you can specify that in a flag so you have your main execution client and then you have your failover rpc client for any reason if the main client is missing then the beaker node switches to the failover rpc um the same logic would apply in the future so if you have two execution engines you should be able to target the main one during regular functioning and the backup one later on as far as i know this is an untested feature for the execution client it's a very stable running feature for just deposits like right now how it is in the kitchen um but with the execution engine i don't think it's a really well tested feature

yet but it's something that will be tested by the time the march happens and while you're running in that mode if you've got a primary execution client and a failover execution client will the beacon client or the consensus client keep the failover execution client up to date like will it be sending it said heads that's what i'm not sure of so i'm not sure of that of that right now but i think it should send it to both places because currently uh the beacon node like queries um both the failover as well as the main one to know how many healthy nodes it's connected to at all times um so i'd assume in the future it would just send

a set head message to both okay but you'd have you'd have to ask cl dev about the exact behavior thanks guys uh remy your question for the recording i'll just read it out how will validators choose the ethereum account for their transaction fees go into the transaction fees they will gain from proposing a block i think paul mentioned that when you start up the node you will be prompted with uh your users will be prompted to enter an address and i don't think i think what he mentioned was that you won't be able to move past that without entering and tim is unmuted and he's going to swoop

in with some info yeah so that's basically it you need to provide it to your node upon startup but one thing to make clear is you get the transaction fees yeah you only get the transaction fees and not like any uh i guess fee for proposing the block itself so like the the fee that you get for actually proposing the block accrues on the beacon chain but then the actual transaction fees accrue on the execution layer hopefully that makes sense but yes you just enter it at startup and in this case does startup mean

like with what would that look like for somebody who's already running a setup like when they install new software like when they update to the latest release it'd be a like a cli flag or environmental flag or however you configure your client um config file cli flag environment variable depends on each individual setup there's another question in the chat asking about downtime in case of network degradation um i don't have a specific like percent loss but

the network is pretty forgiving when you're validating um you're not going to be you won't be slashed for losing connection um slashing is usually when you're doing something malicious like proposing an invalid block or something like that but for simply disconnecting from the network the the leak is actually pretty small and anybody feel free with more specifics you can jump in yeah it's like point zero zero zero zero one eighth or something like that per uh block you failed to attest from correctly um the time it really ramps up is if lots of people disappear at the same time so if there's like a major network partition like across the

internet or an actual attack or you have a large section of validators that all try to collude and drop at the same time that's when the leak will start to ramp up much faster and so for most of the time you know if your computer just shuts down your local power or whatever it's not a big deal if like your whole country goes offline your country consists of you know 50 of validators that's going to cause all those people to leak much faster so it really depends on the specific scenario but for the normal case what transcend is exactly right you're probably not even going to notice that's one of the reasons why it's important to not correlate yourself by using the same software same hardware if you're validating in the cloud same cloud providers because if any of those things

fail for a large majority of the network you're going to leak a lot faster than if you're using you know less than majority used software and hardware microsoft's clients go ahead definitely um there's just one more thing that is important all validators come with the database it's called the slashing protection database if for any reason you need to migrate follow all the procedures for migration um but in principle the slashing protection database make sure that the validator doesn't sign anything that it could get slashed for so you don't have to worry if you're

offline for a bit the validator wouldn't automatically get slashed uh yeah just a clarification on the terminology uh slashing usually means you're actually being actively penalized this is different from leaking so there's leaking and they're slashing so leaking is just like if you go offline you don't show up to a test you're not going to get penalized you just like fleet a little bit of money if that makes sense can i be even more pedantic about the terminology uh here please so um you are penalized for being offline you receive penalties they're about the same as the rewards you would otherwise receive so if you're offline for a day then you're back online for a day you end up even

there is a leak this is happens when the whole network is not finalizing and that you receive more severe penalties for being offline so we call that the the leak specifically and then slashing slashing is punishment you're not punished for being offline you're punished for breaking rules um and that's uh very severe you're basically ejected from the network and you lose some of your your stake uh it's very hard to get slashed you have to be um uh you have to screw something up in your in your setup to uh to get slashed you're not gonna get slashed in the normal course of events i'm sorry so to clarify um so initially someone mentioned that

if there is a larger number of validators that go offline simultaneously that causes uh something called a leak and that should uh aggravate the uh penalty that uh offline uh validators will face uh how is that um yeah uh it it's complicated and i've written about it and i'll drop a url in the in the chat but it's never happened on the beacon chain so far so we have never had a leak um on the on the beacon chain uh in the like 13 14 months it's been running it should be an extremely rare condition if

you are online 80 of the time or more during a leak then uh you end up even you you don't earn any reward but you don't uh get any penalty so uh even then um but if you're offline more than 80 uh more than 20 of the time during a leak then you can be quite heavily penalized but it's still not slashing slashing is something else thank you so much just one more clarification on that um does the validator have to always re-authenticate itself with its uh originating ip address or so i'm i'm imagining some water for load balanced infrastructure where you've got

failover band links where if one goes down you use the other uh does that really matter and uh would it uh be not too hard for this thing to be able to uh you know publish itself from a different uh uh ip address uh yeah ipaddress is more or less irrelevant in the gossip network um so yeah you can come back you may if you start if you lose your database and you lose your ethereum node record then you um might have it might be slightly slower to find new peers but we're talking minutes we're not talking um hours for that so basically yeah no no problem at all

i'm going to throw out something wrong here in hopes that someone corrects me um i believe if you want to be very careful with failover validator clients because if remember correctly if you have two validator clients running on two different machines and they're both trying to validate that is one of the conditions where you can get slashed is that accurate uh yeah that's a classic way to get slashed i think every single instance we've seen so far of slashing has been due to um people having funky failover mechanisms and not minding them carefully basically having two validators running in different places at the same time yeah so in general the advice that i've heard given out is you're far better off just running one validator and eating

the downtime then you are trying to set up a failure node unless you are really really really really careful and so like either spend you know months of engineering time to set up failover that is very careful to never go wrong or just accept that you'll have some down time because the downtime is much less punishing than double signing yeah i think this is one of the things one of the misunderstandings about validating is um and i'm not quite sure where this comes from maybe it's we just need to be more explicit in documentation or how it how things are communicated but a lot of people often have the

misconception that you know any sort of downtime is an immediate penalty or it's as severe as slashing or yeah even using the term slashing which is like kind of a catch-all term for penalties um when in reality they mean different things and have very different uh outcomes so it's it's very common but um i think for anybody on the call just understand that uh having your validator down for a little bit is actually very very minor in in the grand scheme of things obviously you don't want to you want to get your stuff back online as soon as possible but if you're running a setup you're not going to lose lose

a major portion anything else related to slashing or penalties or inactivity i have a question for some essays going on in the chat here yeah is there if if you're offline when your validator is due to propose a block does that affect your uh your your penalty somehow or does it not matter uh only to the extent you don't get the block reward or any transaction fees associated with that so uh yeah indeed that would be unlucky to be offline when you you're a block proposal but there's no penalty for

being for not proposing a block you just miss out on the block reward and the transaction fees got it thanks that would be like salt on the wound if you got extra penalties for missing uh missing your slot because you're offline and just generally i should have mentioned this at the beginning but if somebody can respond verbally i know everybody is maybe not able to but if you can uh ask or respond to a question verbally it helps because this is being recorded and then it'll be transcribed but the chat is a little more ephemeral um but yeah i appreciate everybody who's asking questions and

answering them in the chat as well uh i'm trying to skim through and catch up were there any new questions and someone asked if the network will be down at the time of the merge and the answer is no it will be just like any other worker in the past yep yeah and this is kind of related to a bigger topic that concerns users like in reality users applications um they're not going to notice any difference leading up to at the point of the merge and directly after you know this is like uh updating some sort of app in the background once you open the app it kind of just works

you're not going to really notice anything the services will continue just the same um you won't have to like more broadly you're not going to have to transfer your ether to a new chain you won't have to or if you're a developer your contracts aren't going to have to be migrated you know what we're trying to do is make the make this as seamless as possible and you won't really have to do any sort of transition or migration um everything should be the same one thing to note though i guess for um for like say exchanges or like any application that also deals with like

offline or off-chain funds and whatnot um i think what what you probably the way you probably want to think about the merge is um we have this terminal total difficulty uh which triggers it on the proof of work side so that means once we once we reach that point um no block basically there can only be one set of like children blocked um that exceed this terminal total difficulty but there can still be multiple ones so like different competing uh forks at that block um then one of those will be chosen uh uh basically by the the proposer from on the beacon chain for for the next block um and

two epochs after that that first kind of post proof of work block will be finalized and that's kind of the stage where you know that uh everything is kind of done um and i think mirrors had a comment about that with uh finalizing the rpc that's probably a good segue but like when you see the first when you see the first block having been finalized uh on the beacon chain after like the last uh the last book for work one is kind of when you know that the transition has happened successfully and that this first block is not going to reorg um and say you're in exchange you can kind of like accept a deposit or like reopen deposits or whatever um yeah marius do you want to take like a

minute or two to talk about how this is exposed at the the uh the rpc layer yes sure um so we have a lot of calls that that you can either specify a block number or a block hash or you can specify one of three different keywords uh latest pending or earliest and what that gives you is for example the pending block is the block that hasn't been mined yet so we we try to apply some of the transactions that we have in the transaction pool on top of the current block to predict

which tran transactions might make it into the next block this is called the pending block and you could you can query your note for that in order to see for example uh if your transaction gets properly executed um or not um [Music] or like the receipt of a transaction if it would be executed uh and we also have the current current uh block uh which is you can specify latest for that you get the current block that the best block that the node has seen at the moment

um that we also have to state for and what we will add in the future or i already i think i already added it but the idea is you can also specif specify final finalize now in these calls and these types of calls and this will give you the last finalized block so um basically finalization in in these two works or in post merge works that uh 164 blocks have been executed on top of a block um or 64 slots no it's two times 64

slots have been have been passed then the then the block gets marked as finalized um so it's it's it's not the new block the news block but it's uh some block a bits further a bit of time ago but you can always be sure that this block will not change except for very very like yeah no it will it will not change so um that's the difference in in how the new world works um you can be sure that uh stuff doesn't change so we

make sure to expose this behavior to the user for example for for um for exchanges to say okay once a transaction has been included in a finalized block or the the block that had a certain transaction was finalized um then we will accept the payment or whatever and um so yeah that's basically every call that you could specify pending or latest tool will now also accept finalized that's it

if you're subscribed to blocks in some way um will there be any indication um or if you ask for a block is there any indication in the response whether that was a finalized block or not no get get blocked by dash get blocked okay not yet so uh and also like lots of this is not not really specified right now but we implemented it already just to make sure that users can can use this and a a minor

uh contentious point in addition slash correction to that so finalized means that it will not the no execution client will automatically reorg no excuse client or consent claim will automatically be ordered past a finalized block and so the only way to reorder past final items block would be with some sort of user activated hard fork and so this good yeah you need two thirds of the validators to finalize the competing a competing chain and that implies that a third of the validators on the network would be slashed um so you know the cost is like same order of magnitude as like a large scale 51 attack on ethereum

so it's it's like possible in the same circumstances that like a deep 51 attack on ethereum is yeah and the the key here is that if in order for a reorg unlike with the bitcoin or proofwork ethereum today or proof of work networks they can automatically reorg you know back if someone does launch 51 attack an automatic bureau can occur and the clients will reorg back however many blocks it can be up to infinite or up to genesis i guess um the caveat here is with proof of stake we do have the ability to launch a user-activated hard fork which can reorg past the finalization point and this

would be in a very extreme scenario where validators have been shown to be actively attacking the network and we want to make sure they get punished for it and so unlike proof-of-work we can in proof of stake we actually can punish validators after the fact so if we see some evidence of malfeasance by validators by large chunk of validators that the protocol could not identify we can go back and slash them later now this would be you know talked about this would not be something that just happens automatically again unlike proof of work none of this would be automatic this would be a very manual intervention where we tell users hey please upgrade your clients that does this roll back it'd be a major thing so so don't think that like finalize really is it does mean finalized in basically all

scenarios unless the network is actively under attack by validators in some way which is unlikely to happen all right unless there are any other comments on this uh there were some other questions any final comments okay uh back up a ways in the chat somebody was asking about node requirements i think marius responded um can you just summarize what you put into the chat for the the video or the recording yes sure so if like the requirements don't change too much um

if you're currently running both uh the execution layer and the consensus layer node um then you should be good um if you're currently only running the consensus layer node and rely on inferior or some other type of service for for execution layer data then that's not possible anymore so you need to run your own node which will increase uh your hardware requirements um there might be like there might be things coming up uh that will alleviate some of the costs

but in general it's like if you're currently running both nodes then you should be good um there are some some times where nodes start to struggle in times of non-finalization so if the network breaks down then nodes will use a lot more disk space than they use during normal operation but that first of all that shouldn't happen on mainnet and second of all the teams are already

uh thinking about how to reduce uh reduce this the disk space during during times of non-finalization and yeah that's basically great yeah and then another person asked whether they could run for example a validator client or a beacon client on a raspberry pi and then the heavier execution client on something more substantial and yes that's possible um tim do you want to summarize the question about block rewards again just just so we're we have it in a couple different places phrased

differently maybe my explanation earlier wasn't good enough oh word of block so the block the block rewards basically there is no block reward on the execution layer post merge right like the rewards that exist on the beacon change on the beacon chain go and change so you get today already rewards for proposing a block on the beacon chain you get rewards for a testing two others blocks on the beacon chain so that stays the same and then transaction fees on the execution layer stay the same so you know every transaction on ethereum pays a fee part of that fee is burnt the rest of the fee goes to the block producer um and so after the merge validators who

are block producers get the sub of those two things they get their current rewards on the beacon chain um to the same extent that they've already had there's no like increase or anything like that um it's still based on the total number of validators that whole thing um but they also get the transaction fees uh from the execution layer sent to any ethereum address that they want uh so this means that they don't they're not subject to being locked a validator does not need to withdraw or to have a partial withdrawal to have access to those funds they're immediately available this is okay awesome perfect

yeah um thumbs up let's see what else do we got here oh the one thing we haven't touched on yet is what happens to test networks or test nets after the merge and i think tim probably has the clearest picture of this do you want to summarize forever any developers on the call yeah i don't think we're 100 set on it yet but what seems what's going to happen for sure is some test nets will be deprecated what seems likeliest um and again this could change is that uh rinkaby does not transition to the merge so rinkeby seems like the least likely test nets to to make it if your application runs on rankingb only i would strongly suggest

starting to look at other tests that's basically now um robston seems likely to transition through the merge uh but then be shut down sometime after um i'm not sure how how quickly but i think if you're on robson you also probably want to look at alternatives gordy seems very likely to just transition and stick around uh long term so uh if you're if you're on gordy you're probably good and then finally uh there's a new proof-of-work testnet that was launched uh a couple months ago called septolia and the the goal is likely to transition sepolia over uh run the merge on it and then maintain

it instead of robsten uh just because it's a bit of a newer test net and it's it's less heavy um so pldr gordy and sapolia are looking like the best candidates post-merge one thing also is um there's testaments basically have two values one of the values is like a staging environment for applications the other value is like a staging environment for client devs and the things you want to test uh for client devs are slightly different like we'd like to test our client software in cases where the network is not uh not finalizing for example and things are aren't going well and that's obviously not great for for applications you probably just want to test on like a copy of mainnet um so

there's plans to like make one of the the like post-merge test nets more geared towards like client testing where we we regularly turn off some validators uh cause it not to finalize make sure that uh that the client software can handle that um and then there's another one that'll probably be a bit more stable um and and where you know you can expect kind of similar situations to mainnet we haven't really made that call yet uh but it's it's probably gonna be you know gordy and septolia are likely to be like one of each um yeah so that's that's something we'll we'll have better information on in the next couple weeks uh but if you are on rinkebee i definitely suggest looking uh looking at the point of the test nets uh

the other one sorry like coven is the one where i really don't have a view it's a bit unclear what the situation is there um i know in the past uh they've lagged updating it until after may after mainnet has updated i think there were some plans updated for the merge but it's it's not fully clear to me yet so i think um yeah if if you are just on coven you probably want to reach out to like the maintainers if it's to to understand a bit better with the with the premise there yeah somebody asked me about that the other day and i i had no idea what's going on with kovan cool excellent summary

uh any questions about test nets and which ones are going to stick around which ones are probably going to be deprecated if not i think those are all the things i noted from the discussion um somebody asked about incentivizing solo staking i think we touched on that earlier about um their anti-correlation penalties and if you abstract that or de-abstract that uh that would mean if you're staking on the same cloud provider you know if if the majority of the network is all on aws and aws went down that there would be a pretty big

slashing event or no there would be a inactivity leak and that's one way solo staking is incentivized um there are other maybe not incentives but initiatives from people like superfiz and the east staker community to onboard more people and you know remy has also done some work with guides and in helping people understand the best practices for running your own validator guide so there's a ton of community work that's gone into solo staking and that's probably going to continue i don't see it stopping anytime soon because that's definitely if you're able to a really great way to learn about the network and participate on your own terms with your own hardware um

if anybody else has other comments on solo staking feel free to jump in please run a minority client yeah yeah everyone of course what is a minority i haven't decided micah not death and not prism so for your execution client do something that's not guess and for your consensus client do something that's not prison um you pretty much can't go wrong as long as you don't choose those two and this is yeah just to be clear for anybody anybody who's a validator currently or is looking to get into it soon um prism and geth are great clients you know they've been around for years they have great people working on them this

is nothing against those teams but client diversity is really really important um and it's not something where we want to like it's only an issue once once it's a problem you know it's not something where it's causing a problem now but it'll be an issue um once there's uh a failure to finalize or a bug in one of the majority clients so we want to take care of the the problem now rather than down the road when there's actually a bigger problem anything else in the chat

uh yeah somebody asked about timing and marius rightfully answered it'll happen when it happens basically um yeah there's a checklist i don't have the link on me now but maybe if somebody has the uh tim's tim's gonna get it but yeah it it's hard to predict when everything happens and i know everyone is in crypto is used to um things taking longer than they seem that they shouldn't take that's kind of the way it goes but one thing we want to be really clear on is that any upgrades are secure you know there's no bugs and

it's not going to introduce issues if it if it goes live we're not testing in production um so security and safety for the chain stability these things are all way more important than hitting a certain deadline so the the broader answer is you know the merge will happen when it happens when all the client teams are comfortable when there's been enough testing we've gone through the transition enough times and everybody is confident that this is gonna this is gonna go through well and it's not gonna cause other issues oh right there's the link um yeah the things in this readiness checklist aren't you know it's not like they all have equal weight so

uh take that with a grain of salt but it's a pretty it's a good way to get an overview of the things that are being worked on a bunch of great links to the work and um what's left so if you're interested in timing this is probably your best bet for understanding when the merge is actually going to take place go ahead tim well yeah so one thing i'll post this in the agenda as well but uh frederick at the ef has helped set up a google group that people can subscribe to to get like blog posts uh announcements about the merge uh so we will post everything on

blog.ethereum.org and i think there's already uh uh rss feed so if if if you're on rss you can use that um but if you just want to get like a simple kind of digest of the the upgrade news uh related to the merge um let me share the link in the chat here we'll make sure there won't be more than the blog post but you'll get an email saying hey there's a new blog post um yeah so you can just join here if you're not using uh google or gmail you can just if you send an email to this email that i posted at announcements plus subscribe at ethereum.org it'll reply back uh and ask you to subscribe um it did go on my spam the first time so

please check that uh but generally it should work for any any email provider if you just want to uh yeah uh if you just want a heads up when these upgrades are published someone again asks about whether infura can be used after the merge no you should start getting used to running your own execution client uh leading up to the merge can i just clarify that the trend if you're staking then the encouragement is to run your own execution client infuria is undecided about whether they'll provide that but that's by the buy if you're staking run your own client if you are

running a dap and you're providing a service and you just hook into the normal one apis you don't you can just carry on using infuria or alchemy or whoever you use as you always have done you don't need to get involved with this side at all if you want to run your own node if you're currently running your own eth1 infrastructure for your dap you will also need to run an eth2 client a consensus client alongside that so you've basically got kind of three scenarios there and we should distinguish them um carefully yep yeah that's my mistake i thought he was asking about validating yeah just for applications or apis you

can still use infura or any web3 provider i'm assuming we've got confirmation from inferior that they are planning on starting to run bald ear client or uh because those clients on their back end like they are gonna yeah yeah already dude okay okay um we're down to the last few minutes it's been a lot of great discussion uh and i appreciate everybody who joined and asked questions or if you're a developer you took time to come and answer the questions um is there anything we missed or should quickly summarize this is your chance to speak up

great we've covered everything um so the thing that we've been talking about in the chat the regard to unsafe head and safe head so when by the time the merge goes live the expectation is is that when you ask for the latest block um you will get what's called the safe head and the safe head is about 12 12 seconds behind real time ish 12 16 seconds something like that so just be aware you can ask for unsafe head but unsafe head is very like is likely to get reworked so be prepared so if you ask for unsafe head um i don't think json rpcs are available yet but eventually before the merger should be you have to run safehead that'll give you the absolute latest and greatest so if you're like someone doing mev or something where you absolutely need to

know exactly the latest things going on you can get that just be aware that is likely to get reorg like high probability if you ask for the safe head or latest what you're used to getting you're now going to get blocks a little later than you do currently so they're going to be delayed by 12 16 seconds or so and um but the on the plus side it is very unlikely that those will get reorganized like they'll only get reorgan very bizarre scenarios in almost all cases it's probably going to stick around to finalization so just be aware that things are going to get a little slower if you continue if you just do nothing and just continue this latest and if you want to be on the bleeding edge like you are today in terms of timing then you'll have to switch over to unsafe head and

be aware that the rear chances are kind of high with that great yeah uh somebody asked where this will be recorded or where the recording will be hosted and it will be on the ethereum cat herders youtube where the other calls have been uploaded and i think we've been producing notes for all of them so uh if you'd rather read this then listen to it it'll be available on one of the the repos that we'll link to um as a final final note if anybody on the call was looking and looking to get into validating on their own or just curious about proof of stake generally they want to learn more about participating in

consensus i cannot recommend superfiz and the eaststaker community more than i can't recommend them enough you should definitely check them out they've done great work like i mentioned earlier you know creating tutorials helping people understand what's required of them and uh yeah definitely get involved with that community they're amazing yeah thanks i i does my audio even work i've spent the past hour fighting with uh with my audio so uh yeah it's it's great to be here i can't wait to go and catch up um but yeah so easttaker tries to be a welcoming first and knowledgeable second community and that's a really weird thing for a lot of technical people but

we really just want to welcome people and help them feel comfortable getting into staking we don't have all the answers but we will welcome you and help you figure things out as you go so yeah we'll be glad to have anyone yep and as as marius mentioned we are more than happy to have anybody help us test the merge and that just means you know joining the test net breaking things where they can be broken and then telling marius how you broke it so if you're interested in helping with that join the ethereum r d discord um if you need a link to that just dm me on twitter and i will i'll send you a an invite link i don't have it on hand right now but yeah uh thank you again everybody

for coming so also also uh if you're a depth developer deploy your step on the test net to see if the dap works like the the smart contract should like there shouldn't be a problem there but also uh check out if uh like your back end works if uh like we make some changes to how the the header uh works and stuff like this so it would like i would advise any project to deploy their code and also test it with with their back

end on the new testnets yes test the merge deploy your applications and we're gonna make it we're all gonna make it all right i think we can wrap there one minute over thank you again everybody we'll see you somewhere online thank you