All Core Devs - Consensus #104

Transcript

foreign [Music] thank you

[Applause] four

Danny Ryan: this is issue 738 in the PM repo

um looks like a relatively light schedule at least as planned capella deneb um some spec discussions Around The Verge and then any sort of closing remarks and a quick SSD shout out um Okay cool so start with capella um I believe Gourley is imminent is it Tuesday so call it five days um any announcements or discussion points around capella Tim

Tim Beiko: uh so we have the blog post out which has all the client releases except Nimbus I believe uh so expect an update

to the blog post remembers and if they haven't released out maybe they can give it a shout and then on Monday uh at 15 30 UTC we're gonna have another Community call uh to answer people's questions about capella Shanghai um if a couple folks on the clients or research slash spec team want to show up that's always great people usually have uh client related or spec related questions yeah that's pretty much it oh I'm sorry yeah it's stakers doing a live stream um this is in the blog post as well but uh so it's at the 10 25 p.m UTC on

Tuesday each state is going to start a live stream at uh 10 pm UTC for anyone who wants to watch the actual upgrade on

Gordy

Zahary Karadjov: and the number series is being prepared as we speak it's likely to be out today

okay

Danny Ryan: okay great we'll update the blog post then um and maybe tweet it

the guy

Ben Edgington: um asked a question about BLS change credentials and if there are any plans to uh blood the network on Gurley at the change or do anything which kind of looks like what we expect to happen on mainnet

Danny Ryan: um not in a concerted effort not playing

considered effort um the teams could spam a portion of them if they want I don't believe that the devops team has

Parithosh Jayanthi: yeah we don't have any plans to do this on girly um we have done so in devnets in the past and haven't noticed any real issues but if there's concerned then we're happy to coordinate that for

curly

Danny Ryan: yeah I guess it's a if it's possible why not especially Corley probably has more nodes than um the networks we've run so a little bit of different gossip pattern granted I would withhold some amount

just so that we don't have forego the ability to test further real life changes in the future um other capella discussion points for today

Terence Tsao: um I have questions about Builder and relayer Readiness but I don't see the relevant parties here so there is a MVB boost Community Club um an hour after this end so if you're a builder every layer you have questions feel free to join that

code

Danny Ryan: thanks Terence is there a link to that

Parithosh Jayanthi: and just following up on that one we did have a couple of Mev related scenario testing so we had uh Mario's mock really running on maina Shadow 4 2. and we asserted that the circuit breaker works with taking the relay offline a circuit Global block production having X number of blocks missing in a row or in an Epub and having the relays of invalid data

Danny Ryan: fantastic thank you Perry okay great other cappella related discussion points for today

okay

moving on to the nib um we did have it seems like one of the most um Lively discussion points still is getting these Beacon apis lob signing PR emerge Sean we did discuss this on Tuesday is there a status update

Sean Anderson: yeah so I think on Tuesday we were thinking we would have blobs just blinded by default in both um uh both current block production endpoints um but further discussion on the pull request some other like use cases were brought up for having like the full

block signing flow also include full blobs um and that'd be for things like uh like that would be good for a vouch that would be good for um like separating a beacon node you want to use for proposals versus like a beacon node you want to use for verification um and also like broadcasting signed blocks to multiple nodes so I think there's enough like uh of a desire to have unblinded blobs in the current full block flow that uh updated updated the pr uh to reflect that um and then yeah so is that

Danny Ryan: does that mean

um you can optionally have them blinded

Sean Anderson: so how it is right now is like we have uh one endpoint for full blocks and that will now include full blobs as well and then the blinded block endpoint also includes blinded

bugs okay okay so you have like the stateful endpoint for blinded and then

Sean Anderson: yeah

kind of like stay okay

Sean Anderson: um and then the other thing is uh I think people are on board with having just like a single um request to submit assigned block and all assigned blobs as opposed to like splitting up that request just because it reduces like the complexity around

like um when the beaconode uh responds to a message about whether it's published a gossip or imported the block um it simplifies that um and then one other point that's been brought up on that PR is generally like should we keep in mind like means of providing blobs from like a remote source that isn't uh P2P and like design these apis um and so there's still active discussion around that point maybe we should move it into an issue somewhere else but um the idea is that

yeah yeah the idea is that like um obviously like homesteakers who at their limit with bandwidth might not be able to follow via gossip so having like a remote blob server might help these cases even though it's it's obviously better to be participating in Gossip um maybe a remote blob server is something that's like uh uh better than forcing homesteakers to exit the validator set

Danny Ryan: or do you mean a remote server to get them for production

Sean Anderson: so I think both for production and for

just following the

chin

Danny Ryan: okay but that should be relatively independent of this

PR rate

Sean Anderson: well the an idea was brought up that maybe blob provisioning like or providing blobs shouldn't be a beacon node responsibility maybe it should be like a separately defined API that a beacon node could implement that was the question

sure all right

Danny Ryan: I guess to keep the devnets moving I'd love to get this version shift that to an issue uh it seems like a deeper discussion Point than

just the base signing here

Sean Anderson: yeah

Dankrad Feist: what's mean by providing blobs

Sean Anderson: uh like just an API to like a for example like if you want to sync a node you could add a like a remote server that sends you a blob for each block route you request um so to a beacon node for following the chain and to a validate a client for producing a block

Dankrad Feist: uh yeah

okay so like providing but I didn't understand that part because it's still the beacon node that verifies the availability of all the blocks so I I so like the big node needs to get all the all the blobs but I guess there's a question of how do they get to the big road right so that could be an internal functionality we might have kit here or an external blog provider is that what you're saying

Sean Anderson: yeah it's it's about like should we keep um I guess remote servers in mind when designing the apis for like how you retrieve blobs for different roles

Jacek Sieka: I would say probably no

like we have an interface for getting blobs right already but the other point is that we're in parallel also investigating ways to minimize the bandwidth impact of blogs in general so like I'm hoping that most of the additional bandwidth will be able to regain through optimizations and then blobs and blocks aren't like the biggest consumer they're big but but like at the stations take up a lot of bandwidth as well those are those are the most problematic ones so I mean

for the purpose of producing a block I think we have to assume that the beacon node has the blocks and blobs and then we're designing this particular API for the purpose of signing uh a new block and blob so whether or not there exists a separate facility for downloading blob somewhere feels kind of orthogonal really and then point

Gajinder Singh: I think there is another aspect too where we basically say that we cannot can link up to an external service to download block which is basically not processing the block so there are two

kind of data notes which are being proposed as of how in this particular functionality is that from Beacon notes we will gossip the block PC protested in the gossip and the other speaker notes which will not and which will then use this external service to pull the block so overall reducing bandwidth for them because even if they pull from external drops and they still have to drop it then some benefit concern doesn't go away so this is I think the additional concern that is operate in the pr command regarding not getting the blocks from an external service

Danny Ryan: so I'm of the mind that

the parameters here given uh in addition to the optimizations available should be turned such that home connections can use this and that if we're Beyond those limits then we should be rethinking those limits and the optimizations available rather than hacking a centralized server into here I will also Echo to uh yeah six point that the Block Story root and blocks by range requests I already do allow you to get blobs from an external server um obviously that's generally tuned to the P2P but you could have a service that relies on that you could have

direct period connection that relies on that and so um it seems like reusing that is actually the appropriate path rather than having this creep into the Beacon apis or am I missing something

so in the external uh configured block provider basically there will be a few big accounts which might not participate in the gospel of the block so I changed the main thing in that particular profile

Danny Ryan: so even in such a case um you could not be on not that I'm advocating for it but you could not be

on the uh blob topics but you can still publish into them uh and so you could publish to one peer into them or a couple of peers into them and not be on that topic and still participate they're still still push out so I again I don't know I don't know if the beacon apis needs to be handle that facility I do think we should take this to an issue um because this is certainly a departure from assumptions and design and I think a lot of people have Insight they want to weigh into Sean would you mind opening up an issue

and summarizing the discussion up to this point

Sean Anderson: yeah sure um we think I get should I open it on the specs repo because it was brought up in the apis but I think it's sort of a product question

Danny Ryan: yeah that's probably reasonable right because it's it's not just apis it's how to use gossip how do you sync and that kind of stuff

in a low resource environment cool yeah another thing that I

Gajinder Singh: I want to bring up in front of people clarification on is that uh it's quite a clean the blindly trout we use for build a block but more and more like it seems like you know blindly drought for normal

execution blocks would also be a good so good thing so can we sort of add some endpoints or some sort of a flag for that that this is an execution block on the blindly clouds produce let me then published

Danny Ryan: I'm having trouble uh hearing your mic and so I didn't quite catch the question

oh

Gajinder Singh: am I audible now

it's a lot better thank you

Gajinder Singh: okay so what I'm saying is that currently we have blinded droughts uh for Builder blocks and for execution

blocks we use full routes uh now with The Blob uh being full on the full on the execution block routes uh I think it would make sense if we can sort of add another endpoint or some Flags to indicate that we want execution block on the blinded route between in the communication between validator and

we cannot

Danny Ryan: like if somebody wanted lighter weight communication even even if they were the big node had the full blobs is that what you mean

Gajinder Singh: correct

Danny Ryan: that does seem like a reasonable configuration parameter I I don't know would you put that in there

the request itself

Gajinder Singh: yeah sounds good I have added it or in the comments but I'll sort of clearly mention it

or

Danny Ryan: okay gotcha

Jacek Sieka: there is one more related question it's also brought up in that issue which is basically that should the should the blinded uh block endpoint provide uh non-blinded blocks like or other if you get a block from the execution

layer which is not blinded should you should you respond with that lock on the non-line that on the blinded request meaning that the beaker known has to keep it in its state while the well their client is signing we we integer we blinded and then we we cache it because the the response of that API is by Design blinded so the VC is expects it as a blinded yeah indeed and and like we don't so we we had an issue about this where somebody was asking about it and

like the spec doesn't really say that you should do that sorry just just a question what about if the flow is SSD because you don't know in advance if if it's blinded or on blinded even if the Milestone is the same so are you Json based only or what do you what what do you do when we're running a necessity encoded well we have two requests right one one gives you a non-blinded block and the other one gives you a blinded lock and on the non like we assume that the validator client will do the kind of like multiplexing or selection of which

of the Blind and non-bliner blocks to use um so we don't really keep that in the beginning because then the beaker node is stateless with respect to block production it doesn't have to Cache unsigned non-blinded blocks ever

Danny Ryan: right but it does seem like if somebody's using the staple access point the assumption is but you you're saying if somebody uses the state the stateful access point but you have the full block you should just put it in the in the request so that it can be stateless in that in that mode

Jacek Sieka: yeah I mean that's certainly a convenience because then the beacono doesn't have to remember anything like the beacon note is kind of forwarding you know data from either the uh proposer like the block Builders or from the execution layer but it doesn't have a real interest in what happens in between until the block is signed at which point it includes it in its own chain um sort of there's this middle state where where the block has been produced by the beacon node but it hasn't yet been signed so it's

not part of any canonical history yeah so so it needs its own little space and and then right now in my reading it's it's ambiguous whether whether Beacon notes should support this or not

Danny Ryan: would you actually throw it away though like isn't it actually good to keep it because you it has pre-compute and other things on it

Jacek Sieka: I would actually throw it away yeah I mean the at the station pools and so on like when you build a block we capture a snapshot of the other stations at that time and then then the validatory client would sign it and and return it but it could be that the Valerie client decides that it doesn't like that button asks again right and then we would build a

new block or we could have like multiple validator clients and and cases like this it's like that intermediate cache it's gonna I see it as a bit annoying I would have preferred actually a single request that gives you either a blinded or a non-blinded block depending on what the beacon node chooses to produce and then the validator responds in kind so it gives back all the data to the beacon know that we can now give it that would have been my ideal design yeah to have Adam completely unified and

maybe introduce some other headers that says oh the bigger node is spawning back with this particular the blinded or unblinded version so even if we are going in SSD the VC can can do the

decoding accordingly yeah exactly exactly like that one unified request um yes

Sean Anderson: is that something we would want to try to migrate to as we're like changing these endpoints for blobs because like I agree it does sound nice and we have actually seen

missed proposals before with lighthouse um in this interaction between like the blinded flow and fallback where like you're switching Beacon nodes and we like assume the beaconode you're talking to has the block cache so the design does sound better

Jacek Sieka: I mean it's an appealing moment in time because we have to muck around with that request anyway

Sean Anderson: happy to make the updates if people are all on board

Danny Ryan: no you're in our opposition cool anything else on this or beacon

apis in general great um other denab discussion points for

Etan Kissling: I mean the SSC stuff is

also

Danny Ryan: you did drop that link um yeah if you want to give us the update on the link you just shared that'd be great

Etan Kissling: uh yes um essentially I was asked to create this summary of all the eips that are

related to transitioning the American Patricia tries to SSC and it is something that is petropy looked at by all teams especially the execution teams just to reveal them provide any feedback I had a discussion with Marios today in the charted data Channel I also linked it from type transactions that's the canonical channel would be great just um so that we could discuss it next week maybe

Danny Ryan: any further comments or questions on

here before we move on

Jacek Sieka: uh I could talk about a PR that I raised as part like um it was mentioned during the 4844 decouple development which is basically that when we receive a block or an attestation we don't know the slot of the parent or block that this entity is derived from right so uh for example when when we receive a block we don't know if the block is building on a parent that has already been

finalized if we don't know the block route of the parent and the same thing for attestations uh we don't know if we're receiving kind of like a block route for a block that was very old um because uh we never transmit the slot only the block route right so what we have to do in order to discover the slot is to download the block and then figure out whether we should keep keep these other things around so there's a PRI open I don't have it in front of me right now so I don't remember the number but I'll post it to the consensus Dev Channel the idea is to include the slot whenever

we have a block route in the protocol so that's kind of like in the attestations you put there's the beacon block route you could also put the beacon block slot in the block you could put the parent slot and so on and so forth um I wanted to guard interest for this it's it's kind of like a small change which enables a few more checks like a few more sanity checks before we allow gossip and it closes a few little loopholes that otherwise require resorting to let's say uglier constructs like bad block lists and and things like this I did not finish the pr in the sense

I provided an example of what it would look like but I haven't really gone through all the possible places where the slot should be if there's like a clear no right now then I'm just going to close that PR and save myself to work if it's a maybe then then I can invest some time in it and if it's a yes then I can invest some time in it with the urgency uh so if you fall anywhere on that scale do let me know

Danny Ryan: yeah I'd love some engineering input here or on that PR to I know that if others see the

similar issues and similar gains here that's three two four nine on consensus specs I certainly understand the motivation um but you all would know better the pain okay if you haven't taken a look at that and have an opinion please do and leave a comment okay other than Ed discussion points

um I believe Guillaume has joined us um there is a The Verge vertical stateless spec draft up in the consensus specs um as a PR it's been up a little bit more than a month um there's been a little bit of review but you know wants to uh give us a quick walk through to let us know what's on this feature

scale YouTube yeah

Guillaume Ballet: okay uh yeah so just uh wanted indeed to make a very quick introduction so there's there's that PR that's called this number um he has three uh 3230 and the idea is very simple uh you just

add uh to the execution payload you add a field execution Witness and this is a structure that is described further down the uh further down the the document so we we don't have to go through every single field um but basically uh yeah well one of them one of the points of bringing that up today was to get your attention uh on this but also um there's a there's a couple questions I wanted to raise uh one of them was that both the execution payload and the execution payload header have the entire structure um and this structure can be fairly big

so I wanted to figure out uh what the opinion was should should the header contain the entire witness or not um if not I suppose the the witness would be transferred a different way through a different uh type of message

Danny Ryan: and how big

Guillaume Ballet: well uh I mean it's in Json um it's like an array of values of uh three values yeah I didn't get uh exact number so we we just by the way I wanted to say we just relaunched calcium with this this format today uh like a couple a couple hours ago um so I didn't I didn't get uh exact numbers I can I can share that uh a bit

after after the call um but we're talking about uh an array with a thousand entries

Danny Ryan: right

Guillaume Ballet: we do I'm talking about the Json itself I don't know yeah

wait why is why is this a Chase because it's black

Guillaume Ballet: I mean that's true there's it's also passed over the network but uh this this field is provided by the execution engine the execution layer so it also has to go over the the Json RPC

Dankrad Feist: but like as a binary

it's like 120 kilobytes for a typical block and up to two megabytes for in the worst case is that our estimate

yep okay yeah

Dankrad Feist: um and yeah with Jason with Jason like probably a factor of like a bit more than two on that

right

Danny Ryan: yeah my question would be do you need the execution payload header like are there things you can do with the execution Halo header where you need the entire execution Witness um or is it if you have the execution payload header and maybe you're doing like client things you just need a portion of the witness or not of the witness and otherwise you'd get the

whole block um so if you if you're a stateful client you don't you do not need really the

Guillaume Ballet: um well actually I mean you you could you don't need that data you can get it from your own state um if you're a stateless client yes you will need the entire uh payload

Danny Ryan: but you'll also get the entire block right you wouldn't just get the header

right that's true yeah okay

Danny Ryan: I guess I'm curious if there are use cases where you'd want the header but the whole witness

Guillaume Ballet: um yeah

Danny Ryan: and that that would help me understand if you'd want to ship this with the header because my gut is to do

the route unless there are some sort of use case here

Guillaume Ballet: yeah

Dankrad Feist: I mean that could be that could be a case for it and some sinking type use cases like where you have a trusted source for us and you just want to update if you want to update your state

using it because it does contain everything it's a huge update stage um but I don't know if but even then you could download the witness yeah but most of the time I think if you want the witness you'd also want the full exhibition Payless

Guillaume Ballet: um okay so yeah I think uh I mean I can

modify this to to be uh just the root in the header and if indeed there's a need we can change it again but yeah I don't see any immediate need for that in the like for the whole witness in the header

Danny Ryan: um yeah that's my intuition cool

Guillaume Ballet: uh so there's a second uh point I wanted address or at least raise um this is the transition when you perform the upgrade um so the execution witness I suggest would be empty because um it's not really clear to me what supposedly before the transition the state is still officially an MPT so it's

quite difficult to potentially not really necessary to have a proof that would be proving a uh diff between MPT and and vertical So currently my proposal is to have two empty fields on the transition boundaries so only have the execution witness after one block past the past the verge um yeah I just wanted to see if anybody had any opinion about this

Danny Ryan: yeah I I it's unclear to me how we would do a different base case here

centers all but if there's a different option I'd love to hear it

Guillaume Ballet: no I mean at least I'm not aware of any other option but yeah if someone if someone is I'd love to I'd love to hear from them

Danny Ryan: like you don't really have the option to even do a pre-compute because that's that block came out on the Fly and you don't have the logic yet so

Guillaume Ballet: well I mean in theory everybody would have a like a vertical ready representation of the

state long before the the transition so you could still provide a proof uh with respect to this state that is not officially enshrined in uh in the in the blockchain I mean um yeah you could uh like in practice everybody will have this this vocal state but in theory you could do the transition at the last moment uh in theory never gonna have work for real but um but yeah no I think I think this is still the most uh yeah sensory coma approach

okay and take

Danny Ryan: a look at it all think about if that like messes up any

proof stuff but I would just probably

go into

Guillaume Ballet: yeah okay great thanks and um there was a last thing um it's more like a nitpick by a depth lion um where is it like he was saying yes so you have those two Fields CL and CR um oh and he actually answered since um but yeah this represents some symbols that are in the in the paper uh the ipf IPA paper uh so it has to be read like your lab tech uh uh feel like C

underscore or uh subscript L and C subscript R um but apparently uh in the specs things tend to be lowercase so I was uh just wanted to ask if lowercase C underscore L and lower key

lowercase C underscore lowercase R was sufficient or or not yeah I think the

Kev Wedderburn: uppercase was basically used to show that the cl and CR are just commitments yeah um so it might be fine to have the lowercase if it's according to this book

Guillaume Ballet: well if there's no other uh if there's no dissenting opinion I'll change that to to be like this

Danny Ryan: some Live code review I think you mean colon instead of equal sign here

Guillaume Ballet: possibly yeah I don't know that much python but okay good thank you for putting that out and with that I think yeah that's that's pretty much all I wanted to discuss

to them

Danny Ryan: is this built upon Bellatrix or capella

Guillaume Ballet: right uh so it's built upon the electrics at the moment yeah doesn't have a capella like he's not replaced on top of capella I mean

the code um so I mean the goal is to have it on top of deneb obviously but uh currently it's

billetrix

Danny Ryan: yeah okay cool I I guess keeping an umbrellas for initial review seems fine and maybe letting the NAB uh stabilize and then rebasing on that instead of doing

two rebases

Danny Ryan: great are there any other like gotchas in here or is this is primarily data structures on the consensus side

Guillaume Ballet: it's uh yeah exactly it's primary data structures uh there's a gotcha indeed um it's where is it um so there's this

something there's a bit of a twist for Cal student um I'm looking for the excuse me um I'm looking for the structure exactly um so there are two values in this truck uh well three uh fields in the structure current value new value and suffix and for Cal student we don't have new value uh so ultimately you should have to restate on the post state but for Cal student we just put the

pre-state

Marius van der Wijden: why

Guillaume Ballet: it's just uh like it's just more

maintainable at this point when um when more people join when uh when the code base stabilizes it will be easy enough to add

so you can already compute the process it

Guillaume Ballet: yes

Danny Ryan: okay thank you again um any other questions for

you this this optional list is an SSC do you need SSC unions or just optionals

Guillaume Ballet: so it used to be unions but Mikhail said that now optional was added to the to the specs so yeah it's an SSD optional

it

Etan Kissling: it's still a proposed like a draft but if you don't need the union then I guess writing it like this is the cleanest

Guillaume Ballet: yeah I mean it is um currently at least in uh in the code it's implemented as a union yes

okay anything else

Guillaume Ballet: actually there are no more questions um I had a I had one um so then app is the name for uh for uh for 4844 um and Proto back in in Austria suggested Elektra um do I have the permission to start referring to this as Electra

Danny Ryan: um in terms of the name of the fork yeah I guess as long as it stays in this underscore features directory I would give it like a feature name um because the fork ultimately might be this combined with some other features um and

you know there's a modicum of a process in deciding Fork names um so maybe we should respect that but again like it having something in underscore features as like a star name would I think be confusing and this should hang out in underscore features until closer to performing the fork so we can kick that down the

candle

Guillaume Ballet: no problem

I have a question how ready is this Pia right now like this is still a trap so I didn't go review it but if we want to merge it to the Future

afforder soon then we should make it excitable and then we will found many uh small and big bugs in this process

Danny Ryan: right

what do you think

Guillaume Ballet: um well there's uh so we have a running test net at the moment so I'd say it's pretty ready but yeah before uh before we enshrine it uh this way I assume other clients should implement it um I know Netherland like tanishq has also an implementation of vocal trees I don't know how far along he is from implementing this specific spec but I would say I would wait for tennis well

never mind at least to to catch up to to this pick before we before we merge it

Danny Ryan: thank you Jim thanks okay any other uh General spec and

research discussion points for today okay any other discussion points or closing remarks before we close excellent um okay seems like high priority continue on this Beacon apis uh discussion Sean please ping relevant members when you do the next update um otherwise a bunch of small discussion

points that will continue in issue some PRS talk to you all soon thank you thanks everyone bye thank you thank you thank you

bye everyone

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