All Core Devs - Consensus #101

Transcript

let's transfer it up [Music] um welcome to consensus lyric Hall

Danny Ryan: 101 this is issue 702 on the PM repo a lot of minor capella discussion points some status update name discussion for 444 and then some uh like client endpoints for the beacon API to discuss um I just before we get into technical discussion um as we approach interrupt in a couple

of weeks what's our capella test net status update Harry or Barnabas

Parithosh Jayanthi: hey um yeah so we had uh we thought that tool launched yesterday there's a couple of bad blocks that need to be figured out but I think I mean different ethereum JS but otherwise we seem to be doing good uh we're testing withdrawals Etc and everything looks okay so far um we're gonna be launching a bigger more public version of today's devnet next week and the ideas that general public can also start getting involved trying out

withdrawal tooling and hopefully we have some documentation and some deposit guides Etc um up there in time and another testing update is that we got the first withdrawal Shadow Fork working earlier today so I was able to Shadow for sepolia into a mini withdrawal test map everything looks stable and good so far um thank you for HDM and Marcus for some debug support there uh I still have to try it with all the clients so I just tried it in a small amount so that I could test the tooling tooling seems to be good so now I'll try something a bit bigger so we should be good for

a midnight Shadow [ __ ] in a couple of weeks I think that's all the test net updates we have

Marius van der Wijden: so quickly going over the issues on on Death Note 2 today um I started sending some transactions like hand written transactions that should trigger stuff on Shanghai and uh there were two bad blocks created by ethereum JS one contained a transaction with uh um that that triggered like the warm coinbase and the other one the other block contained a transaction that had a

huge amount of init data um init code and so yeah should look into that another thing that I wanted to talk about is on the fog monitor um these so on the fog monitor we have these these bad blocks um right uh we like some of the nodes collect that blocks and we can display them on the fog monitor uh what's really interesting to me is that there are four bad blocks seen by piece of notes that are not seen by any other notes and so it would be really interesting for

really important for the bisso team to look into why they see those those bad plugs that no one else saw and apparently I have no idea they are not part of the canonical chain and so that's why we don't have a consensus issue there so they might be reoped out beforehand but it would be good to investigate from the Visa team and then the ethereum JS team is already working on the stuff that thank you

Danny Ryan: thank you Iris any questions for Perry or Marth okay great thank you um I know there's been some discussion about this both on the concierge call two weeks ago on uh all Core devs last week and on the chat um essentially the way that the commitments for his roots work across the consensus layer and the execution layer for both transactions and now withdrawals uh do not allow for simple support of um because that's a Slayer like client kind of inserting a block or block

header into an execution layer without additional information without downloading essentially the header to get that information so I'm not caught up on where people want to land on this compromise I do you know I want making the withdrawals commitment and SSD commitment on the execution layer is one thing I do think that it would be quite Hasty to change the transactions commitment given that tooling and or smart contracts might be relying on that and we don't have a good handle on what we would be breaking but that's my take without having dug deep into the conversation does anybody else want to provide information or where kind of the decision Point seems to be

standing at this point

Terence Tsao: I can give an overview view from prison side although working since it's a client so maybe we don't have much to say in this but like I think our children consensus is just like if this the language you are then our vote will be a no distance like I don't feel like we don't feel like right just keep adding future towards the end which like you guys will draw and that's just our point of view

yeah

Danny Ryan: gotcha uh is anybody else want to weigh in I mean obviously there could be to resolve this in a pork in general the work can either be uh changing the consensus structures to include the execution

layer commitments or to change the executionary equipments to be that of the Native consensus circumference um or some combination of those I did I did catch one that there was some eagerness to change the withdrawals commitment to SSD does anybody else have the status update or read on that well sorry there's some hands up please get your hands up go

Andrew Ashikhmin: um yeah so on behalf of Aragon we I agree Danny that we shouldn't tackle transaction route in in this release but I think for withdrawals through to we

should switch to this exactly the same route as in CL so that probably entails uh switching to Gray and also to an SSD commitment instead of rlp plus Miracle so that makes sense to my mind and in in Aragon we've already started working on uh some Co code we have uh light client CL embedded into Aragon so and we have some assets uh Zed code so for us it should be relatively easy code wise

I

Danny Ryan: got it Mark

Marek Moraczyński: I think it is generally a bit too late for changing the coding uh because we are passing all Hive tests now we have worked in that net basically all or almost all the pairs of clients are working fine and withdrawals are much anticipated feature by Community I don't think that technical debt that will we will introduce is square feet delaying withdrawals and about we now we have a SSC Library developed by us but the main risk for us is is that it is it wasn't the battle tested on the contrary another libraries are used by CL clients uh it was developed a few years ago and

we we just started touching it again I think like moving to SSC infrared for forgive us time to verify uh this Library correctly and check with existing tests and give us better confidence about the code

Danny Ryan: got it thank you and Matt

Matt Nelson: yeah so from the basic side you know we were weekly in favor in terms of kind of delaying in terms of putting the SSD encoding in we feel like we can have it ready for the interrupt we again weekly in favor of being forward-looking and reducing kind of detected around this for this short term because you know we we're not sure that we won't be

making the changes again anyway in Cancun so focusing on the withdrawal route to reduce that kind of the need to support that weird piece of history between the two forks is kind of what we're we're looking at on our side um you know we're not again to Echo the other point we're not thrilled that it's kind of the week before interop that we have an invalidation of the all the prior testing a lot of this other stuff but we're not too concerned about us what we see as a small delay but we're only weekly in favor of of adding the SSC encoding for the withdrawal to match

about

Danny Ryan: it do we have a specification that works here because

it's not only way but it's also I apologize Little India um so has anyone actually kind of like gone through the specification work or worked through what this looks like in terms of the encoding like you sound very far away I believe it was you speaking

Mikhail Kalinin: it's just a copy of DCL spec right nothing special

Danny Ryan: correct

um I mean it's using using the SSC

encodings make a

Mikhail Kalinin: um yeah I just want to pay attention to one detail if we are considering switching El to Gray and we are not doing it action high but trying to do it later um then it might be more difficult to do because everyone will represent them as everyone will read those amounts as always and yeah that's gonna be a bigger change then um of now well there's two people I mean like everyone but

Danny Ryan: one is to encode the withdrawals as guay and the other is to encode just the representation of the withdrawals in the commitment that's great and I don't know if there's consensus on which to do there one one thing though it requires more change than the consensus layer to send it in that way

Mikhail Kalinin: yeah having a um differential presentation of withdrawal just for commitment purpose sounds like you know really dirty but I don't know right can't say that it's really bad or yeah

photos

Potuz: sure um I just wanted to point out that this is not really an implementation issue uh it may sound that it's easy and it's actually easy but there are designed decisions to make like you just mentioned this issue of like having way your way at different layers this involves also on the sealed side whether or not we are going to change the encoding because we change from weight to weight to send it and engine is to send it and this is going to be have to be changed so depending on which design decision you have then you're going to have changes on both sides or only on the yield side and this has to be tested uh I believe that this if we switch to thinking of this as a design problem not

as an implementation problem we should be taken out of Shanghai because we're not at a stage we're designing the fort we're implementing the port already

Danny Ryan: right and I am I'm sympathetic to that um given given the different edge cases and things you can think through here I'm not convinced that we have kind of both end in sound design um Andrew your hands still up

Andrew Ashikhmin: uh yeah I think um of um I actually think that uh we should at least switch to a gray because uh then uh as Mikhail

um noted the other way around if we say okay it's it's way in Shanghai then switching the other way around is heck heck here because then uh we I guess uh so there will be tools that we'll expect withdrawals to be in way and switching them to Grays is as a nightmare so I would at least if we don't uh go if we don't do an SSD I would at least switch to to Great uh it's a very simple change uh technically the only complexity is synchronization across um like test tests and cl and DL and so on so it's true that it requires changes

both on CL and El and in the to the engine API but it's a trivial change and it it ensures that we in Shanghai we both on on both sides clnd and DL we have a encoding of

withdrawals in Gray

I'm okay with switching to gray for us the main risk that we see is SEC encoding so a gray makes a makes sense

Danny Ryan: is the indian-ness in the way the encodings work here a problem like would it need to be way in little Indian

to actually be relevant

Andrew Ashikhmin: we should keep I think we should in the engine API we should keep the the encoding what is uh required for uh what what is the case for other fields like base fee I think it's it's big end you know in in in Json isn't it in in the engine API I don't think we should change that

Etan Kissling: yes engine API is Json so it's an ASCII string and the only thing that water changes before uh sending withdrawals to the engine API thecl would no longer

have to multiply by that billion for the

amounts

Danny Ryan: but on the on how things actually land in the block header it would be in the block header

Etan Kissling: it's just a commitment it would be rlp with the current spec so it's a big engine on the uh like nothing there would change it's just the amount it would be larger I would push back a little bit against the fact that this is design work if we go with only withdrawals because the withdrawals are already well defined in the on the CL side and we're just

replicating that in the uh either way this goes anyway uh on the Nemesis side we do have a branch that implements the necessary changes if anybody wants to look at the size of that diff and on the CL side it's really small

Micah Zoltu: Micah

uh I'm gonna say the same thing I always say which is that I think we should be prioritizing the long-term health of the ecosystem and clients over the short-term gratification of users today I think that we should be thinking about do we want to deal with the tech debt of having this weird transitionary phase for the next five years versus just telling people to wait for two months for the drills I really don't think we should be prioritizing you know rushing anything

Mikhail

Mikhail Kalinin: I just wanted to say that probably we can try to do something about it during the interrupt and if we're Satisfied by the result we can make like by the result of design and phase and by the

result of implementing and testing this particular piece we can you know make the change to the spec after that once limitations already like having this like a stretch tool or interrupt just as a as an idea

Danny Ryan: right given the multiple design points here and given what seems to be a lack of consensus I haven't trouble synthesizing this into something reasonable to move forward from the call today um unless I'm reading this incorrectly and everyone's on board with something

and I I am not parsing that I think you're correct

there are many opinions and they none of them align s

Potuz: I think perhaps to advance we can probably agree on something on whether or not we want to have SSA in the future or at some point and try to commit to that and then we can decide when this happens

Andrew Ashikhmin: um I would still Advocate switching to way because if we don't do it now then later it will be a much harder change it's it's like right now it's a

technique it's a trivial change technically but later because so some tools will be with the Shanghai with the with the release some tools will be enshrined having way instead of way and it will be a nightmare to switch so I advocate doing that bit ethereal technically now does that only touch the engine API uh the engine API and the execution layer so in the in the El how I see it there will be only two places when we actually uh add withdrawals to the beneficiary we have to multiply it by 10 to the ninths and also uh in peer-to-peer when we serialize with

those I would also when we exchange blocks I would also have withdrawal amounts in way so maybe a couple just a couple of trivial changes so actually for if we keep the amounts in grade and the peer-to-peer will be a no change and only one one line of code when we add the amounts to the to the the balance

Danny Ryan: is anyone willing to handle the specification proposal for the gray change so that it can be discussed starting next week and into the execution layer call on Thursday

Alex Stokes: yeah I can do that

Danny Ryan: okay um if we can have that on Monday so that we can begin discussing it and talk about it on Thursday I think that's a reasonable compromise given the status here if anyone wants to do the full specification of switching everything to Z so that we also have that up for discussion um and a like end-to-end bound well-designed way I think that's also probably worthwhile I think I'm going to stick that on at the moment

Micah Zoltu: is anyone against the G way change and I think it sounded like most people were in favor of that one at least right

Tim Beiko: but there's no specs I think yeah

assuming people are are roughly in favor if Alex can have respect by uh next Thursday's call um we can agree to an actual spec and ideally you debate it you know about the Specter next week that we come on the call Everybody's reviewed it on the same page and agreed to that um yeah

Danny Ryan: yeah definitely if we can have it Monday or Tuesday that would much help the conversation I'm not following the chat very closely uh is there anything that people want to surface from there

Etan Kissling: just is it a separate spec or is this part of four eight nine five like the withdrawal

tip

Danny Ryan: I think this will be a diff to 4895 oh

and any other relevant components like the engine API and to bundle you know a couple of PR's um or discussion

Etan Kissling: okay so it's this spec change to Giga way and then a separate one to change um withdrawals commitment transactions commitment and to received commitment to SSC right

Danny Ryan: um I do not believe that uh we're in a good spot to even discuss changing the transactions commitment given that we don't know what it would break so I think this is more are we going to do the the extended spec would be changing withdrawals between the decency there's also this is going to have to

touch in the engine API and as someone said I believe the networking spec okay so so both are with Alex then I guess okay cool um and Alex I'm very happy to uh discuss and review as you're working on this great okay thank you um any any final comments thank you uh good discussion um there is an open

pr3176 on the consensus specs repo um from Mikhail this is I believe round two or three and um a proposal on how to handle a gossip Edge case for BLS execution changes around the epoch boundary I think it's a relatively minimal change it's a ux Improvement for stakers and I wanted to get people's read on whether we're willing to put this in there and Mikhail if you want to give us a quick uh tldr on

that

Mikhail Kalinin: yeah basically the idea is

um using capella Fork version for before capella and yeah and fall back to the normal logic after Cabela Fork the capella Fork ebook is taken according to the system clock to the local system clock and yeah so that prevents through messages from being rejected um yeah if they're sent on the um um on the gossip subtopic that is not related to Capella so it's a kind of like Stock

app

roaches

Potuz: so prism already implements this uh if you send us a change and we will put it in our rule before capella hits but we are struggling to see when we are going to broadcast these changes uh there's a race against hypers I guess some people are pushing to to try to broadcast these messages early and it's not really clear to me what is the right uh point to broadcast I would have guessed that is at the pork but then this hits the problem that other nodes might not have their head stayed or their wall clock at their work so what I want is a commitment from clients that

we will not broadcast before the port perhaps or I don't know any any any scheme would work uh I just don't want to be penalized if we broadcast and work too early

Danny Ryan: do you assess this change as simple enough and meeting your requirements

Potuz: we so what what Misha is proposing we already implemented it uh and it's fine for us that this this was the most natural choice for us um what is still up to it's up to discussion and I haven't heard from other clients is whether or not we're going to be penalized or anyone is going to be penalizing peers if they receive

these messages before tapella hits we are not penalizing those messages we're just ignoring them before the court

I don't know what we have in Lighthouse but um I can bring it back to the team and make sure that we don't penalize if these messages are sent early

Terence Tsao: I wonder if it's better to put this special behavior in the stack itself and then with certain time involved it's just so that we're clear

Danny Ryan: because oh does this this PR if I understand correctly allows for the broadcast at any time before capella as long as

the four Persians are correct

Potuz: right so so the issue is it's more on the that than on the P2P this this PR as far as I understand it is is the way we validate them when you your local node you send to your local node the changes to be included in the pool so that's one thing that users would want to do to have these changes in their pool before the fork and then there's this other component which is the b2p network and I suspect that the easiest for all of us to do would be to just ignore any messages that come over the wire until the fork and then at the Port broadcast all of our home and start taking messages

I think this is the easiest for you to implement to us uh I suspect that it would be the same for every client that I don't know

Danny Ryan: so on this PR if system clock video for keypock it'd just be a simple ignore right

Potuz: so right right

Danny Ryan: okay I believe there's consensus to put something minimal in to the gospel conditions to handle this appropriately because do you want to make a PR that represents the logic that you already have if we think that that logic's sufficient that would require less

change

Potuz: I could take care of it uh I'll most probably what I'll do is just

either have it Nishant reviewing it or having him write in it but yeah you can take care of it tomorrow

Danny Ryan: and we're trying to get an additional release candidate out um I guess it's looking like mid to late tomorrow at this point um so we'll try to get that in there um and I'll circulate that amongst teams

Mikhail Kalinin: uh Mikhail yeah there is also a suggestion by Subway which might also make sense to always use Genesis work version for this message type to verify signature so it's always just unconditional thing

um it probably which is probably the last back from if it's also easy to to implement of course

Danny Ryan: I'm less inclined to go that way yeah if the network ports and there are two representations of reality um this would not allow you to do Key Management a different way across those Forks that's not a huge sticking point for me but um that's at least the logic essentially report go replay protection on this message

Hsiao-Wei Wang: and also I think it would be helpful

when we are entering the future folks like when we are pricing from Capital to yeah then the old operations in the pool they might have to be like clear or something else and then the user added the book boundary they might have to send another message

yeah across one fork boundary correct oh

Hsiao-Wei Wang: yeah I mean the new if we use Genesis folk version because right now they have to use the new folk version

Potuz: I mean yeah I know they don't they don't work across uh across portal standing now and uh yeah so what uh what yusion we are suggesting is is actually what we implemented we're just gonna wipe out the pool completely at the port it's it's not going to be a problem in future swords because there's not going to be many changes in future

courts

Danny Ryan: I see okay I'm inclined to just change the

networking spec at this point rather than to change because that's the spec around the pork version of this message um are there is any strong opinion against that

Jacek Sieka: sorry the question will we run into the same issue where a message created you know to Forks back might be useful

Potuz: but if you create the message to chords back it depends on how you sign it right I said so you want to submit a BLS

change signs now but you want to submit it supports in the future

Jacek Sieka: yeah I'm I'm asking if that's a use case

Potuz: no so so I think what we're suggesting is now only for the capella court so it's it can only happen right now Bellatrix to Capella I mean it will never happen again with special behavior so just to be clear again so if you sign a message with capella and you submit this message at the next work at the same the charging port then it will be invalid

Hsiao-Wei Wang: uh sorry that's the new proposal

Potuz: so that is the current status and we are so we are proposing to maintain that status for the next course the only part that is very important is because we're going to have hundreds of thousands of changes is people signing in Bellatrix and submitting

at capella well I I I mean but in the version two send a message correct

Potuz: uh correct and and this is the current status so so it's fine the current status says if you're past the fourth of capella then you have to use

the current fork and if your before Capital then you can use capella

Jacek Sieka: yeah but somebody was suggesting that we would simply sign with the Genesis

four conways

Potuz: oh yeah this is a suggestion of uh xiaoi uh I'm not against that

Jacek Sieka: um I don't know if there's consensus because if we do then we don't have this problem and people can sign their messages now and and store them in some some place and then send them in whatever they want I don't know if that's a use case but right

Danny Ryan: and the main issue that we run into is replay protection in the event that there is some sort of

chainsmith

Hsiao-Wei Wang: just using Genesis book version will reduce some ux problem uh for example the if we want to sign the message offline then we don't have to choose which Epoch which for version to use

Danny Ryan: right and I find that I find that compelling

Potuz: yeah I think it's it's a minor change to us to move from capella to generic uh to Genesis for person so it's fine for us

Gajinder Singh: um I'm sorry I didn't get why shouldn't the default version because it starts at capella and we can

always find for the with the future for I don't understand what is the opposition to that because that seems to me the better solution than I think it's because it gets rid of the edge case and it ensures offline signing

Danny Ryan: um ux can be simple and you know the tool that you installed two years ago would still work rather than having to bring in extra information about the current Network

Hsiao-Wei Wang: um also like uh I think it depends on how the clients to uh manage their preset and configs like if we are at uh Pediatrics do they have capital for version or not

because if it's in the exude the price break then when you are at Pediatrics we don't have any kind of big accessible uh if we don't do some tricks uh if you want to access the capital population it's just a little bit more and how to manage but so using Genesis could be easier

Gajinder Singh: but the tools should anyway have some main net conflict based in them right

Danny Ryan: yeah I mean not

they should uh they could but also when you're talking about offline cold setup tools you don't necessarily want to update them frequently so you might have some sort of stale config that if it was just Genesis it would still work fine

Gajinder Singh: so then Genesis a signed version will work and post Capilla then it will be normal flow that's what we are talking about

I miss that can you repeat yourself

Gajinder Singh: I'm asking that the Genesis sign uh withdrawal will be valid till and on Capilla and post capella for example on charting it needs to be signed fresh right

Danny Ryan: no the intention would be essentially by signing Genesis uh version it works for all

fours

Hsiao-Wei Wang: uh it is just like the how we handle the deposit operations right

Danny Ryan: there's a bit less of an issue on like again the only thing that is an issue here is repeat protection but I don't know if prepaid protection is that valuable the deposits you know get native kind of Replay protection because they come from an execution layer that has a transaction that has that

that's that's it

Protolambda: not just works like deposits deposits can be signed offline and then

can there can be like these electricity schemes built around them or something that's science will always always be valid And if every draw is restricted to a single Fork they cannot really pre-sign veterans prefer theaters anymore and then you have to resign and you have to basically stay connected to the to whatever surface you might be using if you're if you're trying to agree on like

Returns

Danny Ryan: the alternative is to just use the execution layer address and start if that's your scheme that you're using today but I'm slightly in favor of using Genesis 4 version

um if no one's opposed I think that it does simplify the ux quite a bit and is very minimal and gets rid of our uh networking

would that uh this other folk signed versions would be would be coming valid for example Studio

Danny Ryan: they must be in that scheme they must be Genesis 4 version

Ben Edgington: just to clarify the scope of this we're talking about the BLS credentials change message right not yes not voluntary withdrawals which then become a bit of

an anomaly because they are not signed correct with Genesis right but for the scope of this conversation we're just talking about the um BLS change

Danny Ryan: yes show where can you open a PR with the suggested change

Hsiao-Wei Wang: uh yes of course um by the way uh we might have a standard release tomorrow or and we can try to make it included to use how do you guys feel about making

it ready

to interrupt

Danny Ryan: I mean I at this point I hope that we're only making extremely minor changes and that we get them then as soon as possible whether that be a release tomorrow or if we need to delay till Monday um that'd be my preference to get in whatever we plan on getting in okay okay you have a number of engine API uh PRS that you put into the agenda a couple of them are now merged can you give us

uh

failure

Mikhail Kalinin: yeah sure so let's go over what has been merged into the spec already um the first one is unification of failure mode when the structure version um is not compatible with the actual structure content so this PR is here um so basically um yeah before the merging of this PR this back like um had a discrepancy on how to handle this kind of situation for instance for a new payload V2 if you pass withdrawals um say before

um Shanghai so withdrawals aren't no be Fortune high in this case or vice versa withdrawals are filled uh um yeah withdrawals are new after Shanghai is enabled in this case the invalid payload status had to be returned which is abusingly valuable status in the first place and and yeah the discrepancy here was with the full Choice updated version two where we had to return the error when payload attributes have failed with withdrawals when they don't meant to be thrilled with them so this PR unifies uh

this kind of stuff and if the if the structure version doesn't match the um what what is expected according to activated features uh this VR particularly use use it uses timestamp to denote this to denote for configuration as yeah this is applicable to El side and TL uses timestamps and in both in all cases and I think it should be like a practice for future upgrades as well the error should be returned as specified

the pr so what does it mean actually currently uh Newberry World V2 and the vocray is updated with you they support V1 and V2 versions of respective structures and in the future we might deprecate a new payload we want at all and use new payload V2 for example for to pass operation high and position High blocks into it and so forth so that's about it and the change to your clients and to CL is I guess is about this switching from invalid to the

um error criminal status in case of nuclear so take a look at this one

um the other the next PR what was it uh let me check yeah so a bunch of pin-ups it introduces some cleanups uh which are uh saying that the terminal preferred block conditions may not be verified anymore so it's just like a recommendation an option if clients want to they may just remove this logic um and one of the things here is that invalid block hash status is deprecated and now invalid just in valid status

yeah it should be used instead and this is like a must so El clients must switch from invalid block cache um in new parallel 32 to two invalid status so that's like a substantial thing from these cleanups let's go uh want to take care about okay question so far more comments on what has been merged so the other thing that we have decided to try out to put into Shanghai scope are this payroll body bodies requests

I have just stolen the um PR by yatsuk and the rebased and filled it with the rebased with the Shanghai and yeah did some refinance as well so the spec is here and I was just going to ask el client developers about the status of this and how do they see um can we do this as part of Shanghai or not can only Uncle clients like provide this functionality and implement this as it is specified so basically it's two methods uh yep yep go ahead it is about get

Marek Moraczyński: payload bodies right and the good

payloads by range

yeah yeah exactly two methods skills by hashing

Marek Moraczyński: we already implemented it or release it so if CL clients want to experiment with it they can use

another mind too uh in Oregon

Andrew Ashikhmin: we have not implemented it yet but it should be relatively easy to implement so we can to to do to do it before Shanghai

same on YouTube we haven't implemented

Justin Florentine: doesn't seem too challenging as first time we're taking a look at it

Danny Ryan: okay so I suggest we merge it but also experiment and test with it over the next handful weeks and if we're running into issues or we can't get conformance across the board then we'll uh kind of move it into an experimental place and make it a more mandatory Shanghai update sound reasonable

hotels

Potuz: oh I'm sorry I raised earlier I I want to bring back something uh for shall wait can you call me in a bit

Danny Ryan: yep

Mikhail Kalinin: so on get pilot values we are merging this PR into Dimension High spec and if if any issues we are we are moving it to experimental am I understanding correctly

Danny Ryan: that's my understanding

okay great thank you Mikhail hotels

Potuz: thanks uh so if we go with the Xiao waste version which is fine by me like

using Genesis version I don't think I don't see anything wrong but uh it would be good to to specify when we're broadcasting the messages um because we know that we're gonna see hacked versions of people we expect to see hacked versions of clients broadcasting as early as possible there are changes and perhaps we could agree on just ignoring anything that comes before the capella Fork

foreign

Danny Ryan: right so that would look like a conditional in the gossip that said if before simply ignore I'm not opposed I'm also not convinced

you know you don't know who's the person acting really fast the hacker or the user yeah there's no there's no easy way about this

Potuz: it's just I don't really know what's the right the right thing that I should Implement uh if if we are going to accept messages Sterling then I think I should be implementing that as soon as we subscribe then we send those messages

Danny Ryan: I guess the only thing we can do here is have an even playing field because we don't know if the hacker or the user is going to be racing first so I guess your suggestion does at least make the playing field even so shall we let's consider also putting

um conditional and ignore

the cow

Mikhail Kalinin: yeah just a small question related to it um if you ignore uh will you receive them again uh the same message

Potuz: I mean yeah so it includes some sort of like a perhaps a Dos I'm not an expert on obgp but yes so if you ignore you'll get them again and then you'll just put them in your

book don't you

Terence Tsao: have like a cache that you if you see the same annotation you just drop the message even though it's important but only we do have this but only after we include it in the pool

Potuz: so if we are ignoring that that will never hit the

cache

Danny Ryan: okay we'll get something like this into the pr and circulate it

for review okay four four um I was curious as we kind of lead into interrupt in a couple weeks um just quick status updates in terms of like passing tests I know we have some issues with the tests that are going to roll out soon uh but just where where do clients stand in terms of implementation of uh the most updated specs uh so for Lighthouse we're passing the latest spec tests apart from the one

test that I think is bug um so we're there with the implementation but we haven't really tested the latest spec in like a local test net or interop at all so working on that next in the next week and a half um for Chris um it's very similar to my house that we are passing the current status which but then there's a new one coming so that shouldn't be that hard to pass and then um we're working on some end-to-end tests basically it's pretty cool that we have we're using both these Blog blog utility that enables us to submit a blob and a single bigger node and then download the blog uh from this thing Beacon note so we're playing

around with that but yeah I think we're fully ready for the interrupt and we're also very excited the Lord star is also collapsing generator Spectators just let like so this is who

Justin Florentine: has a number of pieces implemented but we still haven't really started full integration of them all I personally could use some help

um if we could maybe get a doc or maybe update the eip44844 uh site that has the Consolidated list of all the potential testing resources that are available that would help me Orient the team and get that stuff delegated out so um if that already exists just point me to it please and if it doesn't can anyone own that specifically to look for good resources I'm sorry protesting again

Protolambda: I'll put together a list of the resources we have

Justin Florentine: okay thank you

Protolambda: thank you

Jacek Sieka: I think Nimbus is in a similar spot we have tests passing and and pieces bits

and pieces implemented they need to be put together um I'm guessing we have quite a bit of ux work as well to do in terms of um yeah there are all these little questions left to answer which I hope we'll have time during the interim to decide like how long blobs are stored I don't think they should be whether they should be coupled or not and things like this like all the engineering stuff I think I feel is still a bit shaky

Enrico Del Fante: we are

implementing uh uh started implementing the state non-check and the block production flows are in a good shape yesterday we did our first block production in our interrupt level interrupts and yeah we are so progressing we have referenced this enabled we have to double check if they're all enabled or not in the moment but we are passing definitely some of those it's not

all um yes

Danny Ryan: got it and help me understand are we what do we call these implementations on

the path to what we hope to be production or are these quick and dirty proof of Concepts um that are going to need extensive overhaul post

interop

Enrico Del Fante: for us we we always do not clean in the master Branch so everything is um production rate in terms of quality definitely something to be left out in terms of optimization cachings here there but it's the general approach for us is still always be less quick and dirty as possible right ours is also like a production

implementation but it's still going to take us some time to like fully productionize it like a month two months

yeah yeah I don't

Danny Ryan: I don't mean whether it is production quality today but that it's on that path and that we're not working on

group of Concepts

Danny Ryan: okay yeah so am I correcting generally across the board that's true

Jacek Sieka: I mean we have pieces that work but I think there's a lot of user experience stuff left like you know the database retention like how do you do pruning correctly right

I understand if we're

Jacek Sieka: a good user experience for the rest API

blah blah blah

Danny Ryan: okay cool thank you for the updates um we will have for before call again next week and continue to chat about this as we approach interrupt shall we D star name hey

Hsiao-Wei Wang: so

that's last time we had some discussion about what you win and for the next next hot book in the CL and so one popular uh candidate is the the net if I pronounce it correctly so I saw some positive um Vibe about people want to use listening and I just want to make sure that most people are happy with this uh this choice and we can move on and

rename for example to this and break some links but we will be happier after the big renaming yeah and any suggestions feedback objections on it

Danny Ryan: I think it's probably time um I have no opposition so it's

then app

and so I think we can wait until after the interrupt and then start the big renaming

Danny Ryan: sounds good okay moving on we have a couple of PRS the beacon apis open up um a result can you give us an update here and anything that we need to agree upon to get these things moving forward

Zsolt Felföldi: yeah yeah everyone so um yeah these these two open PRS I have are uh uh well the they are basically

extensions of the uh Lifeline Beacon API and yeah for some context um uh yeah uh I'm I I have a like an almost finished uh uh version of the new uh uh light client protocol version for go ethereum so yeah we don't have a working like client right and now since the emerge unfortunately I uh but uh yeah so I uh so I have a very uh like current use case for these things because uh but I think they are generally valuable uh so

so like if we have this idea that it should be possible to implement a light client through this rest apis and I think it's generally a nice thing because there could always be like use cases that can make use of it and like I would also need this right now and this would be very valuable and um yeah so one of these endpoints is um the beacon State and So currently the beginning the the live client API provides a lot of nice stuff and then it's possible to light sync the consensus like we can sync up to the latest Beacon header and that's nice but

if we want to prove something from the execution layer with that then we also need some miracle proofs uh well at least so the execution block route uh maybe also other other stuff from the biggest state can also be useful so since I want a fully functional life client which also can prove other blocks I I also use this historical State routes and and and whatever so the point is that uh right now it's only I think it's only still only load stuff that has a beacon State endpoint and we discussed this a lot support of it with the Cayman

from Monster and also with other people that exact API would not be really be practical to expect other clients to implement because they have like different in-memory representations of the big state that everyone has like the last 64 States available and so in so so uh instead I specified a new API that I think it's close to being implemented in low star that uh only uh

like defines like so it doesn't uh doesn't it doesn't expect uh CR clients to to to keep all the bigger States so it allows either requesting stuff from like the current head whatever it is or uh it has this subscribe method which is basically just a hint to the client that okay I might be interested uh you know these parts of the state in the near future and and and as you process this box please remember it for a little while so I can request it later uh so yeah there's there's there's the reason and get explanation in that PR so I don't want to go into very much detail and I believe it's uh reasonably it

should be reasonably simple to implement and it's uh reason of the general purpose there's a very nice compact format for for defining the the subset of the beacon state that and the shape of this multi-proof that we want to request so I think this could be like a nice general purpose Beacon State API endpoint that I think any clients should be able to implement yeah there's also another uh that's even less complex uh PR about uh like this this instant updates PR which is uh so

now now we have finalized and optimistic updates in the lifeline API and the optimistic update is the basically the previous slot so the slot before they had slot because that because because of the syn committee signatures for for each slot are included in the next beacon block body so uh that it is dislike client signatures are always available with one slot of delay and and and and and that means that any like client can can only have access to like uh to the head with a full slot of delay and these uh instant update endpoints

would allow uh like quicker access to the latest heads because there are these partial Aggregates in the available in the network and that's pretty easy to collect them and and and aggregate them on demand and that would only be like I don't know four seconds of delay instead of 12. uh yeah so so so so this is this is like just a minor optimization uh and maybe less critical than the first one because like having access to the bigger State I believe that's that's that should be part of of of of the the uh Beacon API at least once we have uh like endpoints for for

vehicle night thinking and everything and uh yeah and I know that right now people are mostly like concerned about the upcoming foreign so I just wanted to bring this up and uh yeah I it would be nice if uh like to get more feedback on these and and and move this thing forward so yeah basically that's it

any questions result please

Etan Kissling: oh sorry I mean it's just if you

if you um could already get unblocked with the popular use Case by just having access to execution payload header um that one will be a part of the like there is a PR 3151 to extend the current like client data format with execution payload header as well and it will also um get going to the rest stuff but it's it's less generic than what you describe so but but still maybe that one already helps you a bit to get unblocked

Zsolt Felföldi: well uh I mean I mean uh so right now uh if we

are talking about like so so uh forget a 444 for the current get the lifeline design uh well that uses multiple fields and so right now right now I'm I'm working with low star mostly and uh those are also like working on on like uh these specs uh and uh so I think I think I think until others implement it I will get will probably we got live clients will probably use lost star and more exactly the the the full get full nodes who are serving they get

light climates those will probably use those channels because well it's it it provides full functionality we already have the code and everything so so uh I guess for now we will go with that and uh yeah but uh still uh I I totally agree that for many simple use cases what uh you said and what we yeah this is what we talked about at the conference also like in Bogota so uh so this is useful just having the execution payload headers and and and uh and for some use cases this is all you need and and it's really nice to have a it's a simple API and but I believe this general purpose API is also

uh not super complicated and I think it's just uh yeah it feels like it's missing from the API so we have everything as accessible through this and just not this so like that the beacon State and I think I also heard I think it came and also said to me one more often means was that they have some use case for for for uh for accessing the beacon block buddies too so maybe maybe we can we could also recommend the same thing for the for the uh we can block bodies I don't really need that right now but I'm just saying that there's also a possibility but uh yeah I so this is why I'm proposing this

Danny Ryan: um Beacon API maintainers of client teams please uh take a look at these um maybe we can get them unblocked and some discussions in person if not asynchronously between now and then any other questions or comments on this one okay great and then the Shanghai shapella Community call Tim

Tim Beiko: yes

um so next Friday at 1500 UTC we're gonna have a first Community call for uh shapella um basically these are useful for uh developers infrastructure providers wallets and whatnot to come and ask questions about the upgrade um I realized that you know we're still a bit early and kind of the cycle um like we're not on testnets yet but I think it's good to just have a first call where um people can come with questions and we can answer that about you know how withdrawals worked what they should be mindful of as this is happening if not um a lot of people will be traveling uh

during the time but if you're not um and you want to come on people always appreciate it when clients developers or researchers can answer questions correctly otherwise Danny and me will be there to answer people's questions um if you're listening to this and um want to join the call the information is on GitHub and you can post your questions in advance there um yeah that's pretty much it

Danny Ryan: thank you Tim any questions for Tim okay any other discussion points for today's

poll Reuben

yeah just wanted to ask what the conclusion for withdrawal Wilson has regarding this is the adoption on the yield side I don't say we come up to any consensus

Danny Ryan: Alex Stokes is going to work on a simple proposal that has gray as the unit of account but then withdrawals across the engine API be um EIP and the networking spec for discussion and we will discuss it again on all core dubs next week um and then I believe we will also although I'm

about 100 sure who owns this one uh we'll work on actually changing an additional proposal to change the commitment uh to SSE although it seemed like there was much less consensus on that path but again both of these are things I think will come up in the call in one week time but right now we don't really have end-to-end reasonable designs for the things that people want to see so that is the next step okay anything else for today it's cool thank you I appreciate it talk

to you all very soon

bye-bye guys [Applause]

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