All Core Devs - Consensus #86

Transcript

[Music] okay

the call should be transitioned this is consensus layer call 86 and here is the issue issue 521 on the pm repo uh we will focus on the merge as much as there's an appetite for it do a little bit of client updates there's a couple of things that have come up for discussion topics episode and builder api and we'll go from there okay to kick it off we did have a merge testing call on monday i believe um so if there's anything else in addition to what we covered on that

call that we'd like to cover today um we can cover it now in the testing section i know that there was a main net shadow fork number three today does anybody want to fill us out on the details yeah hey everyone

Parithosh Jayanthi: so we had minute shadow fog three today i think we hit ttv around 1pm um so pttd we were at something like 99.8 participation we were seeing really healthy block production i think the only issue pttd was sometimes prism bezu was missing a couple blocks missing proposing a couple

of blocks and i think the bezel team already had a theory before why that could be but yet to be triaged um post ttd we were at 97.6 percent so the same prism bezu that had some issues before was then dropping off the chain post ttd a while later we noticed something with prism nethermind as well um marek was looking into it but it's also not like a static issue it like that combination a test and proposed for a while then dropped off and i think came back again but there was also um someone looking into it and there might have already been a fix so it might just

need to be updated i'm not sure so all in all i think it was a great um shadow fork we were almost bugless this time and we're still seeing really healthy block production i have like a monitor enabled on tekku i don't really see any blocks being laid so we're seeing blocks produced on time um besides that there was an additional test done this shadow fork i just post the result of that test as well um essentially what we did was we spun up a couple of nodes we allowed them to sync up the head before gtd about one to two hours before we paused either the cl or the el to

simulate them having to sync and the moment ttd was hit we unpaused them so this is before post ttd finality the results were kind of mixed i think the prison guests and lighthouse get combo had some issues syncing up but prism nethermine lighthouse nethermine had no problems they seemed to be synced up perfectly uh this is still new so i don't think any of the client teams have had a time to look into why this happened but yeah that's setting the overall status update congratulations everyone

thanks jerry

Danny Ryan: um any other comments or questions about

the mainnet shadow fork great thanks um cool the next thing i wanted to talk about uh and i believe some of you are on the call or at least you're aware of some discussion last week on the uh awkward call around the difficulty bomb um i just wanna do a quick status update and get everyone on the same page there on the execution side the proof of work side still it was discussed as to still attempt to not defuse the bomb but to revisit this

um on the next call and the call after um given status with testing maintenance shadow forks and things like that um i think essentially in may we need to be either making decisions about forking public test nets and dates around those or making beginning to make a decision about diffusing the bomb much discussion ensued um tim are there any other relevant points from that discussion you want to share here

Tim Beiko: uh no that's that's pretty much it it's like we're in this weird spot between where if everything goes well we might be able to merge without delaying the

bomb but if we have some delay in the merged and what we'll probably have to um and and for for everything to go well we kind of have to start looking at uh at moving to test nets in the next couple weeks yeah

okay

Danny Ryan: cool um any discussion points around that obviously it takes two to tango um you know if we're having issues on the consensus layer that would cause the delay the bomb if we're having issues on the execution layer that would as well um so i don't mean to say this decision

because it wasn't necessarily a decision uh was made without y'all it's a kind of a we're in this phase in may where we really need we're monitoring whether we're on go or no go to the next testnet phase speaking of the next test that phase um robston sepolia and gourley are planned to be go through the merge um i believe robson is at the beginning of that list although that might be up for discussion um and to do a robson merge we have to make

a robston beacon chain or you know parallel to robson make a beacon chain um so i think to be prepared for that and maybe to give that beacon chain at least a couple weeks of activity before doing the merge we need to have that conversation now um quick question is robson to be maintained after going through this fork or will be deprecated i saw in like the og council there was some discussion of deprecating it after the fork but i hadn't heard of that prior

Tim Beiko: i think the idea is uh we would we being the client devs would like to no longer maintain it not necessarily you know the

day after the fourth but like you know call it a few months after uh to then only have gordy and sepolia be like the two clients maintain long live test nets um yeah people don't like when we deprecate test nets so there might be some company that like chooses to then maintain robson but um yeah i guess from our perspective we don't want to the maintenance burden anymore

right so

Danny Ryan: we have two vegan chains to make one for robson one for sipolia i think we should make a plan for them i think primarily our options are low validator count high validator count

permissioned or unpermissioned permissioned we can use the the erc20 variant of the deposit contract to essentially restrict the set of validators and make it you know it's not clique but clique-like in the sense that there would be very known entities and operators that have validators or you do the other where you you open it up for more public testing gourley and piermont based off of it is does serve that function but you could argue for essentially doing that here as well does anybody have opinions to share on the value of doing beacon chain

structures in one way or the other for either of these tests

Micah Zoltu: just to make sure i understood correctly um gurley will be unpermissioned right detective correct yeah i don't have any opinion on the

others

Danny Ryan: yeah so i think for robston um i think it might make sense for us to also make it unpermissioned but for us to have a bunch of the validators just so that if

others want to get in on practicing the transition and running validators they can do so but we also don't care if it becomes unstable eventually because we don't plan on maintaining it so then the question is on sepolia do we want permissioned or unpermissioned um given that gourley would be kind of the unpermissioned one

in general

Tim Beiko: one thing we discussed like a few months ago when we were talking about this is like if we have a permissioned one it's easier to actually test some like chaotic states like you know shutting down half the validators for a week and seeing what happens and things like that

um and also we probably don't want to do stuff like that on a test net which has a ton of end user applications um gordly obviously does um so i think it probably makes sense versus

a bunch of end user applications

Tim Beiko: no not today and like yeah today basically none um so so like i think it might make sense for us to use the polio as like a consensus level test net and people are obviously free to deploy it as well but um yeah this way if we decide we want to shut down the validators or part of them for a week or two and see like how the activity leak happens or long periods of non-finalization um

i don't think we should do that on gordy because it affects a lot of people's applications but yeah sapolia might be a good a good fit for that and then a permission validator set makes it easier to to control those

things yeah

Parithosh Jayanthi: i think that i'd like to add on that point um i do think it makes sense to have support as permission in the end if you use the permission contract it'll be token gated so we could still like make it unpermissioned but people are not um using bots to steal like the underlying asset so we're not like people don't have to fight over seboyea ether try to rather would fight or whatever token we create um so it might be a bit easier to

avoid wasting the base player test net tokens

Danny Ryan: yeah makes sense i mean we in permissioned meaning large operators could run validators if they wanted to and if there was demand for individuals to be able to run a validator or two we could set up one of those uh faucets although those are always ridiculously gamed um okay is anybody opposed to keeping validator set on the smaller side you know on the order of sixteen thousand fifty thousand something like that and keeping it permissioned okay and then on robson

michael jason

Micah Zoltu: and just you you mentioned keeping it on the smaller side is there any functional difference like how much money is at stake here what's around the money

Danny Ryan: and it affects validator state size and some other parameters um but no there's not much functional

do

Micah Zoltu: we want it to be closer to close to main net than if it actually has an impact

gourley

Danny Ryan: and pyrmont um we have been doing so we try to keep the validator set size the same as mainnet so we don't necessarily need that in this other environment and it's a choice something of a chore to kind of always keep the queue running and make sure the

main net doesn't sprint past pyramid so in light of that i'd say try something different here

and not

Parithosh Jayanthi: i guess the alternative argument is we could have something that's twice the size of mainnet something that would take a long time to achieve on charter it's just a question of if that brings us

anything

Micah Zoltu: idea being that we would see a failure there before we see a failure on mainnet if there is a failure related to size

Parithosh Jayanthi: exactly um and also people can test

their optimizations that are suited for twice the size of mainnet already whereas of course we can achieve the same thing with tata but it still requires a lot of people making deposits all the time

Danny Ryan: yeah i'm okay either way um does anybody feel strongly and i'm also kind of implicitly assuming that the entities on this call client teams and otherwise would help run nodes and validators on this new sustained test net um

obviously if i'm incorrect in that assumption please speak up okay um i'm going to open up i'll open up an issue about in the pm review about the three beacon chains paramount which already exists and we'll take over poorly one to be created for robston which we can discuss how we want the genesis of that to be um and that will be un permissioned and then a permissioned one for sepolia

which it seems like there's a desire to go for a larger validator set and we can um take that to the issue though and i do think that we should launch these by the end of may if not a little bit earlier to just be primed and ready for

Tim Beiko: oh i think earlier yeah i think we probably want them launched like in the next two to three weeks which is like in late may but not like four weeks from now

Danny Ryan: four weeks from now is

uh yeah but yeah yeah like

Danny Ryan: in two or three weeks why i mean definitely before the end of may is

there going to be oh yes network before the end of may

Tim Beiko: no the world would you i assume you want this thing to be live for more than like a few days before we have maybe not i guess yeah that's the essentials just like you maybe want it to be live for more than a couple days and if there's a fork in

say june

Parithosh Jayanthi: we could also do the two separately for example the robson one we could have it small so it's not too much of a task for client games to spin up nodes even if it's cost ineffective and just have that in like two weeks from now whereas if we want to have supplier twice the size of mainnet i think it might take a bit longer for

client teams to find a place to run them um and that could be like three four weeks maybe and that also kind of follows the order in which we're gonna fork the actual test nuts like drops would happen before sephora anyway so we should have that extra couple weeks of leaving it just comes at the cost of coordination i guess

Danny Ryan: yeah that all sounds reasonable and we do have a beacon chain that's running for a long time that at least for one of the test nets if that is an interesting parameter in in these test nets piermont serves

them you may want to create three

Micah Zoltu: separate

issues just so we keep the discussions isolated rather than one issue

Danny Ryan: yeah that's fine i'll call it well and i don't think we need to create one for pure month then but i'll make an issue for beacon chain for robson and beacon chain for sepolia very cool um thank you anything else on that one great um otherwise on merge discussions uh any technical points people like discuss any issues they would like insight on how other people are dealing with things just in general our discussion

Mikhail Kalinin: um i have opened the pr today so just post it in the chat so this vr is about invalid terminal block and the latest valid hash around it uh there was an rfc uh that was mentioned in the pr so basically this vr implements one of the options that is listed in the rfc um i would just like so whoever not seen this uh rfc um previously just take a look at the pr i like to merge it as soon as possible and if there will be no position probably the merged will be merged next week so

take a look please it also uh yeah this pr is not only about replacing ballots uh terminal block with uh like something but it also covers a blind spot in this bag that has been discovered like uh months ago when i was like looking uh going through the list of tracks to the engine api's pack and yeah it also mentioned in the pr

Danny Ryan: gotcha there's also other few pr's open that i believe will be merged very soon um there's a based off of conversations

in devconnect there was a 216 is open which is a retake on the engine timeouts and there's a couple of things related to error codes so um these will be bundled into a release but if you're [Music] following them you can probably as they get merged begin to make prs against them other merge related discussions

no comment perry

Parithosh Jayanthi: i mean we did the easiest level figuring out that we need a test net now we have to find the names

Danny Ryan: i have a well i have a suggestion but once you make a suggestion you've now begun bike sharing names so i will probably not make such a suggestion

Micah Zoltu: so you're saying the best way to troll right now would be to make a suggestion to kick off the conversation

Danny Ryan: yeah i think we should sidestep naming them by giving them

just calling them what they are the robs didn't beacon chain but uh you know now i've been entered into that conversation okay um anything i want to talk about with the relation relation to the merge okay onward i know there's lots of conversations that happen in the discord i know there's lots of conversations that happen these issues so it's

understandable that we don't have a lot to talk about here moving on where is my issue okay um any other client updates that people like to share this is going to be an easy call

but i'm

Micah Zoltu: a little bit curious if anyone else is awake besides the four of us i am awake the topics are just too good

yeah i'm awake i can give you a quick

update okay great so we we released version 35 with lots of improvements ssz gossips up this b5 and fixed some outstanding networking issues where we don't score ps with other reason we also enable proposer boost and deploy to mainnet that's it

Adrian Manning: yeah also throw some stuff in um i think everyone's seen this but michael posted an issue about running fork choice before block proposals um i'll put it in the chat just in case anyone hasn't seen it but it looks like everyone has um the other thing that we're roughly

looking at is trying to um we've got a bit of pressure from the community to implement ipv6 so i'm not sure if anyone else is either looking at that or not because i think ipv6 only nodes are kind of going to segregate themselves but anyway that's something in our pipeline i'm not sure if anyone's looked at that

Danny Ryan: what is the i mean ipv6 is great why do your community members want it specifically

Adrian Manning: well we're starting to get get coin bounties specifically they're saying that a lot of them have ipv6 only nodes behind um i know some some more involved infrastructure and so they want ipv6 support but um i'm not entirely sure how that how that's going to play out especially like when you're discovering other nodes that

are mainly ipv4 and can't communicate wb6 so a lot of them have dual stack so there's this kind of complication we have to kind of add into the lower protocols which is what we're working through

yeah i think charming as well so um release version 2.1.1 this has the merged the the so this has the merge support also has web design and support we also have experimental which such thinks support as well he also never proposed a boost and has a bunch of nice uh batteries uh but batterized shot 256 optimization so yeah that's pretty much from us

Zahary Karadjov: all right we are quite focused on uh much in the shadow for test nets uh but we are shipping one interesting feature that i'd like to share uh nimbus can now work with in the web3 signer setup in such a way that we connect to multiple remote signers and we obtain parcels partial signatures from them which are combined this is similar to the secret shared validator setup and it was actually requested by some staking pools which have this concern that a lot of employees have access to the validator keys so this creates a slashing risk from potential rogue employees so in this configuration it's possible

for the staking pool to set up their infrastructure in a way where no employee have access to a full validator key so that's a quite interesting feature i think it's possible to extend the key manager api for example to add support for this type of configuration

good thanks all right

Danny Ryan: any other um client updates before we move on to some discussion points

Enrico Del Fante: some optimization in the backlog

around the transition [Music] calculating applying the transition so we are the next release will uh will include some some optimization there we are currently working implementing the builders apis and um on the merge side they're just uh minor minor things to to to improve not nothing nothing important

let's see just solos

Saulius Grigaitis: from greninja teams over optimizations we

we worked on arm 64 support and also like some other teams on the signer support and i would say people have all the initial functionality of web signer both designer support that's all

Danny Ryan: got it okay moving on there's a couple of discussion points but in the chat uh age would like to discuss

a potential upgrade for gossip sub called epi sub uh age what's the status on that spec is that actually a well-defined spec or is there r d to do to actually get it to an implementable place

Adrian Manning: yeah so they're like from two years ago i think in like 2019 there was a planned upgrade from going from like flood sub random sub gossip sub and then this final thing called episode and i've been looking into just the bandwidth that all our clients are using trying to minimize it which we've had discussions with various people about um in particular i wanted to try and make like some of the mesh parameters a little bit more dynamic or because we're seeing we're seeing quite a few

duplicates but anyway the the concept of episode is to make the mesh more efficient without having to um change all that much about gossip sub the i talked to visor who's the one of the main authors of gossip sub um and he is essentially saying there's very minimal modifications physics so he essentially explained the modifications to me i i won't go over them in this call but they're something they're they're very minor so there's some small changes we can do to gossip sub that would be backwards compatible that should make our meshes and stuff more efficient um the reason that it hasn't been specced out or built in limp p2p yet is because gossip sub seems to work for for file coin and ipfs and everyone else using it

um and no one really has the i guess the interest to kind of reduce the bandwidth so i think the current plan is uh given what uh visor or what virus and i discussed is for me to either give an implementation of these metaphor modifications that we can then spec and ideally i'm chasing hopefully a go developer to um either mimic the implementation or copy or help me i guess um i guess yeah copy copy whatever we build or in rust and port it to go because they have a lot more kind of testing infrastructure and go so we can test this thing out before actually chuck it onto test nets so it's

it's it's essentially there's just some very small modifications to gossip sub that we can do that hopefully could have a big impact to our bandwidth usage by minimizing duplicates making the mesh more efficient

Danny Ryan: is there anywhere that's a good source to read about this

Adrian Manning: uh yeah so i think the answer is no i i went through and read all the previous specs for episode and then reached out to vizo and in the call that i had with him he's just kind of like i don't know every don't worry about all that we just have to do this this this and it's all kind of small so um i can i can write up some documentation that people can read about if if there's interest

just okay sir

go ahead mecca

Mikhail Kalinin: yeah just to confirm it's not what is proposed on the earpiece of documentation in the p2p i mean you you want to try some uh particular mechanics from from this pack it's not like implementing the spec because when i was like reading it i was under impression that it's it's not yet like it's yet in an active research and was not implemented or is there any reference implementation for

episode yes

Adrian Manning: so the previous research was quite involved and i think i've seen like there's some pr's or some issues around and also a different kind of spec

version i kind of read through all of these and the the modifications are kind of scattered and convoluted let's say the the actual changes that we would need that create what uh advisor calls the episode is essentially we just add an extra control message i'm not sure if i want to go into these details but but we keep the mesh the same size and if we start seeing a number of duplicates from some particular node we we send like a choke message so that they stop sending us on the mesh and they only send us gossip sub gossip messages so it's just um it's more of like throttling the mesh not changing its actual size and this is just adding a single control message um the

this is not written anywhere that i've seen on the internet uh it was only after the conversation that i had with with advisor that this came out

yes thank you i would be interested to stay in my list

Adrian Manning: okay maybe if there's people that are interested in this in particular go a go dev either just reach out to me because i'll probably start doing a little bit of work on this because if we can make it backwards compatible then at least the nodes that are running this can can get some bandwidth saving

Danny Ryan: cool thanks age any other questions or comments for age before we move on

and i presume once we got this into a go implementation we might want to run it through the gamut like custom subv11 was under all those different attack scenarios

Adrian Manning: yeah yeah that's the main reason i want a go version and a go dev to kind of help out because we don't have that in rust yet

Danny Ryan: okay thank you moving on um like client wanted to discuss the builder api status light clan can you give us a status update

Lightclient: yeah so a couple update points and then a few questions we talked about the builder api a bit on

all core devs last week and i wanted to get an idea of how important it was for validators to still control the gas limit that they want their blocks that they'll propose to target even if they're not performing the production of the block and the overwhelming answer was yes so we extended some of the signed messages to also sign over a preferred gas limit that the builders should adhere to and there was a small discussion within that about whether they should be siding over the gas target or the gas limits because after 1559 the actual independent variable is the gas target but because most clients today still take a gas limit to target what the size

of the block will be we ended up going with the gas limit there we've had a lot of feedback in general on the builder api pr which is in the execution apis repo and i think a couple things have come out of it most notably some teams started implementing it and they felt that there was a lot of work going into redefining the serialization schemes for beacon types that need to go over the json rpc methods that was originally proposed and there is a request to to pivot that uh api to the http rest style that the beacon api is using

so it seemed like all the people in the block construction channel were okay with this pivot and so i've started rewriting the api in that style and hopefully have that done the next couple days the core logic will be the same but you know people who have a lot of experience working in the beacon api in the open api format would love to have some feedback to make sure that the style is consistent with the beacon api and all those other things so i'll post that some more information about that in the next couple days when that's available um a couple of questions one is right now these things have been living in the execution apis repo it doesn't really feel like that's the

right place and i don't know if anybody has an objection for this living in its own repo maybe the builder apis repo under the ethereum organization is that something that seems like a reasonable home

Danny Ryan: yeah i think so i mean i i think that this isn't necessarily something that like an execution engine or an el client implements right you know it's another piece of software uh you had suggested builder specs instead of builder apis the builder specs repo yeah yes i can probably rename it

Lightclient: oh it does oh okay um yeah i don't know it's like the

builder api or the api's post fix has been used for these specific specs and this specs postfix has been used for like markdown it feels like we kind of need both like there's still some specification related things but we can talk about that offline there's a pending after the phone okay thanks there's a pending pr right now to the beacon apis repo into the prepare beacon proposer method um i'm wondering what needs to be done to keep that moving because it's been sitting now for maybe a week and a half and i think that's like the main thing on the critical path for

consensus layer clients to implement so that they can we can actually get these um non-consensus messages signed by the validator keys

Danny Ryan: is this 206

Lightclient: yeah

Danny Ryan: um i can just review it right after it seems like there's been a lot of comments here um was there anything contentious lingering in here uh i don't think it is i think the main question that's a little contentious is people feel it's weird to have an optional element on this method that was something that came out of the discussion in amsterdam i really don't

have a preference whether this is a new method or an optional add-on to this existing method i just want to go down a route other than that is anybody have additional comments or feedback on the builder api or the timeline that we're on it feels like this is something that should be integrated into merge testing right now and we're still at the specking stage so i don't know if people are worried about this for anything

Micah Zoltu: you said um

proposers will provide a gas target and then the builders should respect that did you mean must

Lightclient: they will provide a gas limit and the builders should adhere to it i mean i don't know the builders can do what they want but the validators you know don't have to build a block if the builder doesn't adhere to

theirs

Micah Zoltu: so it should in the sense of if you want your block to actually be picked up you should probably do this

Lightclient: right but again like if you earn double the rewards through external blocks

you might be coerced into just going along with whatever limit they choose i think defaults are really powerful there but it's something

Tim Beiko: is there a reason to not make that a must to kind of remove that vector of like bribing

Micah Zoltu: we don't have a v well you know sorry go ahead we can put it as must in the spec that's fine yes it's just that there's no way you actually enforced it

Tim Beiko: right right but yeah if you put as a must in the spec and you put it as a must in the software release then it does raise the trickle bar slightly to like yeah provide people this way yep and that's definitely what we'll do

and also if it goes signed we can a posteriori backward slash you on protocol backward slash who the builder

Potuz: well the proposal that actually signed a block that didn't include his uh his limit his gas limit now we can another thing in the future we might

Lightclient: but the thing is is that i could just as a proposer go back and sign some message says oh right before i propose my block i actually updated my preferred limit and there's no way because these aren't posts on chain there's no way for the network to say oh i didn't see that or i did see that

Micah Zoltu: we can say that if

we can assert that if we see two signatures for the same block with different limits that you are in violation and we reserve the right to uh but it's not per block it's the validator basically registers with the external builder network by saying this is my public key this is the fee recipient address i would like to receive and this is the gas limit i prefer my blocks to be built towards gotcha okay

Mikhail Kalinin: also um we should like take into account that the gas limit may be like say 10 000 i don't know gas higher than the current gas limit and in this case what builders should do should probably like increase the gas

limit as much as possible towards the gas limit announced a proposal right

Lightclient: exactly any other general um comments or feedback on the status to the builder api do client teams feel like this is something that they're going to have the ability to implement in the next couple of weeks assuming that we have a spec and some testing infrastructure available in the next 10 days

does this

Micah Zoltu: only need to be implemented

consistently or is there a consensus and execution layer things need to be done

Lightclient: the execution only are things that need to be done is really in the hands of the external builders who you know right now it's mainly flashbots and so they have people working on things implementing that interface i'm working on a testing uh implementation in merge mock so that people who are implementing this have something that can respond uh to requests against but it's not expected execution layer teams will implement this

Danny Ryan: but locally from like a market from accessing the market just a beacon node for a node that has validators on it is communicating to this like market

mechanism and it uses its local el to just be processing things there's no right local el communications to market

Micah Zoltu: i encourage all clients except for prism to integrate this

Danny Ryan: hey the uh the solar problem real fast yeah the distribution's looking uh much more reasonable on one website lighthouse entered the quote yellow zone because it looks like they might be a third of the network

now

Lightclient: so i guess one last question oh go ahead danny no no i'll have a question after

yours

Danny Ryan: okay i guess one other question for me is there is a situation right now where there's no way to compare a block i get from the external network versus my local eo i was just about to say and so i'm curious what client teams are interested in doing about this because i think the right thing to do here is obviously return some value field in the execution payload um that's responded by the get payload i think maybe we're too late in the game to have that change but it still seems something that's important to have some heuristic for cls to figure out if

the relays are just giving you blocks that say they're only going to pay you 0.01 eth and just the basic tip from the el block would be higher that would be a good start yeah it's like for multiple reasons you should always build in parallel because one you don't want to be hosed by the relayers and two you know you wanna you want like a backup in case the relay just fails um yeah definitely you can do the ladder but you can't do the former can you utilize the eth api to actually get this information or is that not

realistic

Lightclient: i mean i think cls can do whatever they want

um right so

Danny Ryan: can cl's get the fee difference via using the ethe api

Lightclient: sure

Mikhail Kalinin: the problem is that it will have to will have to have execute a blog before doing this request

Lightclient: right but it's constructed the block already like i'm assuming it's asking it at the point that it's already received the payload

Mikhail Kalinin: if i understand correctly uh the constructed block is not like added to the chain the canonical chain automatically by l i

might

be wrong

yes you're right

Lightclient: so there's no way to query against that state if it's not in the

canonical chain

um no but you can execute the block as for example trace call or something right

Micah Zoltu: but how does the co like what exactly would that look like how would the cl say execute that block hand wavy you know that one like what does this what does it mean text you that block like thanksgiving block execute the block it received as a payload

from its yell like it's about to propose it's told it in the next in the four choice updated it's about to propose it got a payload and now it's trying to figure out how much is my fee recipe going to earn from proposing this payload and mark

doesn't

Micah Zoltu: send the whole block again just to get the balance

Lightclient: i think that would be the only way right now to get the you know full picture of how much was earned i think you could statically do it by just going through the list of transactions figuring out how much gas each transaction executed and checking the tip but that doesn't account for coinbase payments

Micah Zoltu: sure but even that would require you to

still re-execute everything it feels i mean i don't know maybe execution layers have lots of headroom it doesn't matter if that's you can figure out the gas used without re-exchanging it's already been executed i guess you might have to get the receipts though which is that queries i don't think that's given in the current um return of get payload right so i think what we have right now if the execution layer didn't do anything um like the best case scenario is you would have to execute things again because we don't surface the information that we need right

right

but executing

Mikhail Kalinin: a block will cause a delay and uh there is like if we if acl will make a decision after executing a block variant state it probably will just miss the opportunity to propose timely block like it reduces the uh amount of time to propose a block sure and yeah and disseminate it over the network i would suggest uh the thing that we have discussed on devconnect they have a get payload with two and yeah see how it can be implemented probably it can be implemented even pre-merge or like shortly after the merge i don't

think we need like a hard fork to release this feature so it could be a bit independent

Danny Ryan: yeah i was going to say expect it as a v2 and not have it on the most critical path to get out in the merge assuming relayers don't hose you uh we could also run you know some sort of sentry node to see if the reload relayers are acting nefarious here and expedite v2 if needed

Lightclient: sounds good

currently i think that's it

Micah Zoltu: currently on uh if a cl is unable to reach the relayer today

will it correctly execute its own block okay we're at least defended against that

Danny Ryan: um that that is allowed in this design and i hope that that's how beacon nodes are being constructed like you should always build one in parallel but you wouldn't be able to once you get from the relay and once you get from local to know which one was more valuable um i was wondering if there's any sort of like should we should we give like timeout in second for life for like recommendation if you don't get a reply back within this time you should just go with your own blog versus because it's

pretty easy if you get an error if you get an error then you can just use your own block but then if they take so long to respond like how long do you wait for

it yeah i

Danny Ryan: think it probably makes sense to add recommended timelines there on the order of what we're having in timeouts for like requesting a payload from your execution layer just like one second

Mikhail Kalinin: um it should be a local request right to movie boost so it should be related

really fast right but mbv

Danny Ryan: boost is

making requests external it's making external requests and making a decision on which blockchain right the most valuable and stuff

Mikhail Kalinin: yeah and before it's like we have this delivery from builders over p2p like a delivery of payload heaters headers in advance yeah we can't expect that it will happen immediately right i mean that this request over result immediately responded with

heller

Danny Ryan: that's all i have for the builder api

information we'll try and cut a release for this with the http style sometime in next week so keep an eye out great thanks okay um other research spec or other discussion points for

today

Micah Zoltu: i would like to i mean we're out of time but i would like to continue the ipv6 discussion if possible i can discord later perhaps

Danny Ryan: we're not out of time um we can also continue that and discord unless you have something in particular you want to talk about i just wanted to discuss it more so like it seems like a legitimate problem like if there really are people that are running ipv6 only i'm concerned that we could end up with a network partition pretty easily if if we don't have enough nodes that can speak both ipv6 and ipv4 so for example if one minority client implements ipv6 only support anyone else and everybody else's ipv4 only then that could very easily lead to a partition

all

Micah Zoltu: right i believe ipv4 support is a must

in the phase zero p2p spec um in terms of the client needing to be able to be able to implement it um sure sure so the client can support it but that doesn't mean the user on some particular network has access to ipv4 right it's like we're if we are actually to the in the living in the future where there exists people who only have ipv6 access the question becomes do we want them do we want to give them good guarantees they will be able to connect to the network and stay connected or do you want to say if you're in an ipv6 you're on your own you may get partitioned off and we don't care

Danny Ryan: yeah i believe the specs written away that we do care but the actual nuance of how this is

coming out of production is maybe

perhaps

Micah Zoltu: a a starter to the discussion that is just how many clients support ipv6 like just in their client today

Adrian Manning: i mean i think we can you can set an ipv6 like listening address and kind of get tcp connections but is a a whole other thing that we're kind of currently working on

i see so you have like uh you have ipv6 in a sense that like your

your the libraries are using everything support ipv6 but currently discovery doesn't sound correct

Adrian Manning: yeah so inherently with leadp2p and tcp you can you can have an ipv6 listing address um so you can set up tcp connections but yeah discovering nodes um the way the enrs so enough's kind of defined you can have an ipv v6 port and an ip and a udp oh sorry and then an ipv4 port and then i guess you have to decide whether you're going to put them in your local router routing table and advertise them and then if you have one that has both which which do you connect to you have to kind of make these kinds of decisions

Micah Zoltu: any other clients have

ipv6 support in some fashion take that as just the one and which which claim is that age lie house yeah do any other clients have plans on adding ipv6 support

i

Ben Edgington: i believe we have it in tekku but it's not something that we actively test or or anyone is using as far as i know

Danny Ryan: yeah i believe like go live p2p is going

to have a lot of baseline support but um doesn't necessarily play nicely with how discovery is working

Micah Zoltu: so for the merge is this something that we care about or are we okay at merge time uh being kind of under the risk of a network partition between v6 only and before only nodes possible

Adrian Manning: um uh yeah i think we're gonna try and avoid not releasing this kind of stuff before the merge

Danny Ryan: right but i don't know why the point of the merge increases risk of partition here

um age the issues with discovery would exist on the existing proof of work network as well right

Adrian Manning: yeah i i i mainly just because the changes are quite involved especially in discovery so i kind of don't want to make any massive changes just before we do the merge

Danny Ryan: right so status quo is not going to induce additional risk of how the network is structured today but altering it might so we should do it after the merge

Adrian Manning: that's my thinking yes

Danny Ryan: got it

Micah Zoltu: so you probably let the people who are asking for it know uh that at least just set expectations just tell them hey we're working on it but well you may be able to make something work in some client um you also make the partitions

Adrian Manning: yeah yeah yeah we will do um we're still trying to figure out the best way to make some of these just i don't know preferences i guess or biases in discovery before i tell everyone how an ipv6 only node would work on the network whether just it's going to be itself or whether it can like you know find some dual stack thing in and connect but yeah we will inform the people that are asking

Danny Ryan: cool anything else people want to discuss today perry are we going to be doing another shadow fork soon

Parithosh Jayanthi: yep next week um i'll make some announcements tomorrow today

okay

Danny Ryan: okay well in that case we will close the call and take the rest of the discussions the internet thanks everyone talk to you soon

thank you thank you bye thank you [Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

[Music] [Music] [Music] foreign

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.