All Core Devs - Consensus #138

Transcript

for [Music] J [Applause]

okay we should be live

Alex Stokes: everyone welcome to ACDC this is call 138 I just put the agenda there in the chat and yeah let's go ahead and uh get into it today so uh first Electra uh we just launched upnet one a few days ago very exciting um I wonder if there are any updates uh with with the latest there last I looked it looked like uh participation was quite low and there were a few Forks of the chain so not looking super great uh anyone here have any more to

share

Parithosh Jayanthi: yeah maybe I can give a short update um so Philip set up the network earlier on Tuesday and um I think Aragon had some issues around Epoch 64 and haven't been participating since but I think the team is aware and looking into it and then some external users started sending transactions some point around uh slot 1,800 or so and then the for uh chain forked into about three parts and then it looks like there's an EIP 7702 transaction that caused a split but we haven't been able to fully debug it um nether man and bezu seems to be building a consistent chain re and get seems to

be consistent to um in their chain but these two chains have a lot of forking and rearing amongst themselves and ethereum GS pairs are not proposing um since a while so yeah I think that's the latest status but um yeah I'm just getting caught up as well

Alex Stokes: cool thanks um so yeah sounds like uh there's some fun debugging on the horizon um yeah nice work though it's exciting to see Dem that one up and yeah we'll just keep iterating from here uh anything else to say there it sounds like yeah clients are busy

figuring out what's going on with the

devet

Parithosh Jayanthi: uh yeah in case Cent teams need something for debugging please text on the interrupt chat and we're happy to help get you whatever you

Alex Stokes: cool thank you okay uh we can move on to the next item then uh let's see this is uh from potis and essentially I mean maybe he can chime in a bit more but it sounds like a suggestion to move some of these

request data that we're introducing pectra outside the execution payload type in the beacon chain in the S broadly uh and yeah it sounds like there are some reasons to do this is produs on the call let's see looks like you're here would you like to give us a

sum

Potuz: sorry I just I just logged in it seems that on time are you talking about this uh the issue of the execution payload and a container

Alex Stokes: right and the request yep

Potuz: okay good so let me quickly describe the issue uh since Bellatrix oh since shangai uh the Bon block contains inside it Bon block body the full execution

payload that uh the block itself is broadcast and is transferred on the cons on the P2P layer for the consensus clients and the consensus client gets this payload it sends it to the El for verification capella introduced a new thing which is that the fact that the payload has withdrawal that were honored in that payload on the execution layer and at the same time this withdrawals needed to access the beon chain the beacon state to honor the deduction of those balances from the beacon State uh so this was the first time where we actually had to synchronize information uh that was H some some

State transition that was happening on both layers at the same time however since Bellatrix and this was not modified in Capella the consensus clients uh would get this full block would send the payload for the execution layer for validation and then they would completely forget about this payload they will save in their in their DB in the database will save the full block minus that payload because that payload anyways is being saved in the execution layer database in Capella when we added this withdrawals uh in principle we could have saved the payload I'm sorry not the

payload but the withdrawals part of the payload but since the withdrawals are deterministic from the beacon State this didn't present any problem you could grab an very old Beacon State a very old block without the payload and you can perform the beacon State transition function without ever getting the payload Electra changes this in Electra the execution payload is needed on the consensus layer to perform the state transition because the requests that are included in the execution payload are needed as input this are external input to the beon state transition function in the consensus layer uh this was again I repeat this is

not the case for withdrawals even though withdrawals are in the execution payload because the beon state already knows what withdrawals should have been in the payload so what I am proposing this presents a problem now for consensus clients because consensus clients often times have an Old State have an old beacon block and they want to perform the state transition to get the new State uh in the current status either the consensus client saves this information in whatever schema for the database they want to do uh this information meaning the Electra Fields there are new fields that the consensus client requires to perform the state transition function

or uh uh or they uh don't save it they send the payload as we do now to the execution client and then later on when we need to perform this state transition we request the payload again this makes it very inefficient and clients will not catch up if they need to sync a block that requires this Old State transition functions so my proposal is to transform the way that the consens to two changes one is on the consensus side the structure of the pon block body another is in the engine API the structure of the message that is exchanged between the consensus client the execution client what I'm proposing is that the Bon block body on the

consensus layer contains an envelope in this envelope you find these fields that are required for the state transition on the consensus side this meaning the requests and a payload the the execution payload but this execution payload doesn't include again these same Fields so this means that the consensus client would be able to Hash the payload and just blind it and just save that this will make it compatible forward compatible with ssz when the execution clients move to SZ because then the hash that we're going to keep for the pay would be the actual hash for the block If eventually the consens

client move to SZ uh on the engine we will need this change that the uh pay the C for get new payload and the Cs to inform that uh to notify a new payload would send this full envelope and then the execution client will need to add this fields from the container to the payload to compute the block hatch so that's what that's I think I hope that it was clear what the problem is

Mikhail Kalinin: one clarification here as far as I understand you don't drop the entire payload you just uh store keep keep the payload header anyway otherwise you will yeah actually chatting about

this in the chat I mean yeah I'm gonna have to read that chat yeah so this this is because you have to serve requests from other peers to get the full block um and uh you can get can use get pay law batties to uh to get transactions and withdrawals if you need withdrawals um from from e but the header should be kept in the database

yeah

Terence Tsao: yeah that's right we keep the header right and then today the issue is that do P2P request we only request from the Y through P2P

for but but for State transition we're okay but at for but then for like but then for like Electra now we also have to request from the e uh just for State transition and we are worried about the performance penalty here

Mikhail Kalinin: yeah sure so uh if yeah let just imagine if we don't have this uh envelop at all um so what then would you have to do in the database would you need to introduce execution payload without transactions

Potuz: you would need to you would need whatever you do because these clients would handle this in a different way each client but whatever you do the

consensus client will need to save in the database in whatever schema this new Fields the these requests

Mark Mackey: yeah so like usually you have just the header and you don't need any of the objects that go along with it because you have the usually only need the root of these requests but now you need actually the requests and usually we're just storing the header so we'd have to have some either some sidecar pattern which makes the code quite unesthetic um or but yeah you you'd have to you'd have to store it on the consensus side or request it from the e every time you want to do a state transition

Potuz: exactly that's the point yes

and and it seems to me that the change of just the changing the structure into an envelope it's a very simple change

right yeah go ahead M

Mikhail Kalinin: yeah I have another question so um you mentioned that whenever you validate the payload you you then drop uh the transactions from it so it it happens even for non-f finalized blocks right

Potuz: correct

Mikhail Kalinin: okay I see I didn't realize it was quite aggressive as that yeah but makes sense

Mark Mackey: because you don't yeah the whole reason we have the payload bodies method is so

that the Cs can drop the bodies and just have the headers

but

Mikhail Kalinin: yeah for sure I was just you know kind of like under impression that it happens for then the finalized prefix of the chain so if it happens for every payload then I see show problem uh okay what okay so what what if clients introduce exe execution payload without transactions I know it sounds ugly but would that solves the the problem

so you can

Potuz: I think it's it's not so it's the other way around for me the the problem

is not about transactions or not the problem is about what information each client needs to perform their state transition so anything that the consensus layer actually needs to perform transation should not be at the same tree level as a that tree level from things that the consens layer does not need so anything that we do not need if we keep it one level Below in the hash tree we can just hash that thing keep the hash of this and only save the objects that we need that the total hasht root would be the same

Mikhail Kalinin: yes I can understand that but as far you have this U header anyway so

it's like header plus uh two new Fields with requests that I maybe more in the future

Mark Mackey: like if we don't change this on the P2P layer and we just try to do it internally which we can kind of but the problem is you you'd have this extra object that has the extra information that you need but it needs to Hash to the object without the extra information because because that's not on the you know that's not in the specs so like that turns into something really ugly where like the thing you get from the network is different than the thing

that's not complete uh I don't know the ways around that are quite difficult to deal with

Mikhail Kalinin: right

Potuz: but also Misha why is it that I mean what what worries you about having this in an envelope the envelope comes with the block itself so what what what is what is the the the the push back against having an envelope

Mikhail Kalinin: yeah I I'm just trying to understand how big uh the problem is I'm not against this change it's just you know uh we used to have the execution payload uh representing all the fields uh and containing all the fields that are required to recreate uh the execution

layer block now we want to break this

uh at this no no

Potuz: no I do not want to break this the envelope call it call the envelope payload if you wish from the point of view of the El the El will get the envelope not only the payload the El gets the envelope and if they want to Hash it as SS they can just hash it immediately if they want to Hash it as rlp they need to move the uh requests alongside the rest of the fields and then hash it

Mikhail Kalinin: yeah yeah I see I see I can understand that okay um okay if if I would say that if this problem is common to all CL clients

then we should probably you know do the change or this is the change to the API and uh clients will need to change this

yeah I don't it's

Potuz: it's not only the the the API I'm I'm proposing that the beacon block body structure changes

Mikhail Kalinin: yes that's correct I see because we kind of already have the envelop right which is called execution payload now and we need one one another uh abstraction level here

Potuz: that's correct

Mikhail Kalinin: so yeah I understand that but I yeah let

me think on it could you please I don't know could you please um outline this in the issue

Mark Mackey: I mean I pasted it in the chat but yeah that I don't think the the actual proposal has been like laid out somewhere other than maybe in Discord but yeah I pasted it from what pus had sent me that

I can open

Potuz: I can open a CL repo issue because anyways this pattern is already used in my PR for IP 7732 because it's then is mandatory to have the envelope uh so so it's just repeating what we already do on

abbs

Terence Tsao: we also need changes for the engine API as well I presume the C issue will also talk about engine API changes

Mikhail Kalinin: yeah we would need those this why I I just want to see the proposal so we can discuss uh it there

um synchrony

Mark Mackey: yeah I think it needs more discussion than a proper proposal but um yeah I think it's good so far from what I've seen because we didn't have a way of dealing with this either that was at

all I I know the problem that he's talking about and it was something that was missed in Dev Net Zero because technically M boost is broken right now on every client um if you include if you test am boost with the transactions that are in in Electra we just haven't tested it but we would find that if we did and this is the problem that awaits us

Mikhail Kalinin: right but I just want to mention that pix in math boost uh does not sound like an appealing argument for me to make a change to to the court protocol structure

Mark Mackey: it's broken because of this problem whether boost is there or not

yeah yeah

Mikhail Kalinin: yeah and actually this proposal can help to solve the this problem like it will introduce

a structure that could be used by me boost and will be kind of like yeah but anyway MEF boost could be fixed without this by introducing the same structure in the Builder API level right

yeah

Mark Mackey: yeah technically this issue is actually just caused by the fact that we dropped the payloads but it AR it arose it was easy to see with

M boost anyway y got it

Alex Stokes: okay so to summarize the CLS prune the El data

because generally they can uh but given the way that we have these request structures in pectra this is no longer sufficient I think that makes sense uh the suggestion is to essentially solve this at the type level um if only just to make it sort of clean to still drop the payloads while having the request data you need for the state transition at the SE yeah I mean when I first saw this I was thinking like you could just pull out the request and just put them say in the DB next to the payload or rather the um but it sounds like everyone would much prefer this actual sort of you know more specific SS structure does that sound

right

Mark Mackey: yeah it all just comes down difficulty of having something that has extra information that doesn't get hatched in that not having to do that makes it way easier right okay um yeah pus if you don't mind an issue I think that's uh a good Next Step here

Potuz: already typing it I'll I'll paste it here before the end of call

Mikhail Kalinin: perfect yeah great thank you a little bit yeah sorry one one more thing a little bit of push back that I have is that we are trying to solve um implementation complexity with um changes to the protocol which are just you know not

necessary for the protocol itself this probably why I have a kind of like a push back on it and want to think more

Potuz: yeah but but I would argue the other way around I would argue that the current design is just uh philosophically wrong uh the current design mixes in the same level in the same message data that is needed on the CL for the state transition that is purely on the CL side with data that is not needed in the C at all so I would say that the current design is just wrong and we're trying to fix that mistake

Mikhail Kalinin: right it's not drawn I would say it has just different philosophy because yeah it has all data that are uh comprising the L block and that's it that's the basic stuff that we had

before but yeah I I I I completely understand your argument

Mark Mackey: and the the other reason that we didn't run into this with the version hashes was that we put those in the CL block um but they technically came from the the the execution layer and so yeah it's it's what pus said like they removed one layer higher in the tree and so it worked out nicely but since we'll presumably be adding more cross elcl transactions in the future we should have them at the correct level

Mikhail Kalinin: yeah that's interesting maybe we we probably maybe we can really as gajinder suggest just have those requests um in beon Block

body and you know um send them

Mark Mackey: yeah that other proposal that you made on the engine API moving everything into the beacon block body would have also worked but it does have those Corner cases around new payload

Mikhail Kalinin: right you mean like those that are related to optimistic sync edge cases

Mark Mackey: yeah yep in not sending new payload to for every payload that is the only reason that we found at least that not to do that but this is actually a strong argument to do that if we don't do what pus is saying

Mikhail Kalinin: yes

but uh I don't actually sorry

Gajinder Singh: I don't actually think that there is a

problem in optimistic sync because when uh CL sends an FCU basically you construct the chain based upon a trusted uh uh latest Trot so basically the entire chain before that is all trusted and when you're are sending new payloads then you obviously are sending the data for that particular uh route to be very F so uh I mean I don't really see it as an issue with respect to optimistic sync

Mikhail Kalinin: yes I I agree with that so as long as El has El block has all the data uh to sync you know and to verify we are

not removing these requests from El block we just sending these request to e in a different way so it should it should work they will be H they will be yeah they will be um checked by the block hash anyway

Alex Stokes: okay yeah I I will what Mel is saying like it seems like there are a couple different ways to solve this uh pus has one solution um yeah so I think if we get something written then we can continue the conversation there anything else on this

topic okay cool uh next up we had an item for an engine API update uh this is from like client for devet 2 I haven't had a chance to look into this detail um let's see

my client and

Lightclient: I think this is similar to this question that we've been talking about okay so I don't know if we can really make a decision before we decide where the requests actually need to live

Alex Stokes: okay that would influence this uh PR you have here

Lightclient: I mean I guess like you could still have the request encoded in the similar

way but it sounds like we're probably going to have some sort of are people wanting to do this like Union of requests or will we still keep them separated at the CL

Mark Mackey: generally makes it easier to deserialize when they're but that's I can't say for sure

Lightclient: basically I'm proposing that over the engine API the requests are sent as an array of the requests uh as a request object not like the individual type because right now on the E we're converting the list of requests that

exists in the E block into individual lists of individual request types unfortunately this adds some requirements to the E to understand from just a sing individual block whether a request type is enabled or not because if I just give you an El block and there's no request of a certain type and we've added like you know we're three or four Forks down the road and we've added some more types of requests like you can't tell just from the Block anymore if the request is enabled or if there's just no request for that block and so I think it makes

the engine API on the execution layer side a bit more annoying so I'm basically proposing that we send over the request object as it is on the E and if on the CL you use the union of that then that would kind of directly pipe into that data structure if you are separating them out then you would be able to just separate them by reading the list of typed requests and deserializing them into the list that they should go to

Alex Stokes: okay so this is related but it sounds

like we'd still possibly want to do something like this even if we end up changing the structure on the

see

Lightclient: I think they're related but yeah it it is it can be done either way for how wherever it lives on the CL

Alex Stokes: right so yeah

I mean my proposal is

Lightclient: my proposal is for the requests to come through as a single list of all of the requests and for the type of request to be identified by the type Json field just as it is with type transactions currently

Alex Stokes: yeah that makes sense uh right

like we have these set of cross layer features and we need to figure out exactly where the boundary is across e JCL um that makes sense you have your hand up

Potuz: yeah so uh I mean these problems are related but they they seem to address a different uh a different area different problem itself which is we currently have C A type on the CL a type on the El and then we have this messages that are being exchanged on the engine API uh what my proposal was was about the type on the CL and this is this doesn't contradict Ma's proposal I would still suggest that the type on the CL has this level structure and then we put

in that uh on what level the requests and this requests can be uh can be a list of requests can be a union can be separated I don't care on the E side it seems from what Matt says that it would be better to have the type one request object which is a list of unions which may have different type of requests list of lists uh this this would be fine as long as the engine API puts them at a different level this already solves my problem and then the object that goes in the level up we could handle it either the E has the problem of trying to interpret it and separate them or the CL has the problem of trying to interpret and and separate them it seems from what

mat is saying that it's better for them if the CL interprets them and separates them in different objects that's fine by me well we already to know what those objects are so I don't see any problem with what mat is suggesting into putting out on the envelope one object which is requests

Alex Stokes: yeah that makes sense

Mikhail Kalinin: yeah one of the aate arguments that PL client made is like uh let's just have on the API level the data structure that maps on the core data structure to avoid potential edge cases in the future one

one I don't know if it's a problem or not but now CL will have to if this this proposal accept CL will have to kind of um handle request mapping from different lists to just one but it it's not it does not seem like a big surface for bugs and those boxs can be found easily

Mark Mackey: um it's I think it's just that the different types have to be I think carefully thought of if we have different kinds of requests such that it's not

ambiguous on which kind is to serialized into

Lightclient: well the type the type fi should disambiguate what Val like what um type to Der serialize into so even if some fields are reused across different types then you can just look at what that type value is and then put them into the correct SS object

Mark Mackey: okay so there's a bite or there's a is there something that marks it you said a type value

Lightclient: yeah I mean it's the same as how we represent transactions over the RPC so if you require a block with transaction values filled in then you'll

get a list of the transactions and the fields are sort of reused in this like generic transaction but there's a type field that says whether it's type one transaction type two transaction type three whatever and then you can use that to differentiate so that way you don't have to just like look at the fields and infer based on the presence or non presence

Mark Mackey: as long as we got something like that I think would be fine

Lightclient: okay

Alex Stokes: Terrence

Terence Tsao: I guess one thing to note is that when we get payload as a proposer that we also have to parse this request on the CL side right because we have to

put those on the envelope or become B body ourself depends on what the uh depends on what depends on what the decision is

Mikhail Kalinin: small comment here I believe that CL while sending those requests to e may not respect the order of uh those requests by type as it is in the EIP I guess this is true

Alex Stokes: I don't yeah I don't if there's an order

on spec

Lightclient: I mean the order should be inferred just from the engine API message so as you're pulling out the values you can just keep it in order and the E would have placed it in the order that it was already on the execution layer

Alex Stokes: right but is it is it sorted by the type

bite

Lightclient: it would be sorted by the type bite and then intra type bite like each proposal has the different way of ordering and the EO will have already ordered all of that so as long as you take it from the engine API and interpret it as it's ordered from the

engine API it should be the same

right does that address your concern M I was just

Mikhail Kalinin: yeah I'm just thinking that c should respect this Auto or not yeah but that's detail maybe not worth talking about it

Alex Stokes: well the order is important at least int type yeah so definitely should go in the same order as given

I'm

Dustin Brody: I'm wondering like um what is the simplification on the El side

here

Lightclient: when El converts the block into an ex an engine API message it doesn't know from the block data how to fill out the presence or emptiness of a request because in the request object on the E it's a list of typed values and so if in a future Fork we add another request type then I can't tell from the Block itself whether that request type is empty or if we haven't activated that request type yet on a fork so propagating that information in is not that simple we can do it but

it's kind of weird for us to represent on the engine API this data in a different way than it's represented on the execution layer I think that this is just like a much better simplification and the CL can much more easily differentiate whether the request is empty or whether that fork is not active

Dustin Brody: you you don't know what your what Fork you're in or what the block for fork the block was it

Lightclient: yeah I mean usually we don't Plum the fork work information through every code path in the engine API it's kind of at the top level of verifying

like the method that's coming in but then when we're dealing with the block itself the block doesn't have the concept of this is a Bellatrix block like on the CL I think you guys are very good about separating the different types of fork blocks from each other but on the E I think this is how pretty much all clients have implemented it we have one block that represents all of the block types and we use the presence like the nullness of a value to sort of determine if that thing is active and so this is again like part of the reason why requests were added in the first place uh in this format was to take advantage of how Els have been built

historically and this is just a continuation of trying to avoid rearching a lot of the client or doing things that might be like bug prone just to represent things in a certain way on on the engine API

Dustin Brody: okay fundamentally this is a fragile eristic um the the idea of and I don't think this goes against anything you're saying but the idea of of of uh checking for the presence or absence of specific Fields look we in nimbus it for certain things too unfortunately because yeah we have to but but that is one of the worst parts

of reading certain of these Json objects um because it is a heris stic and I would say build doubling down on that is maybe not super great

Lightclient: yeah I mean we're like 12 Forks into this design so it's a little bit difficult to just like turn the ship around and change how we have AR protect the block so I agree it's fragile but I don't really know if there's much that can be done at this point unless some El's also agree that they want to like sit down and change the way that they represent the block it seems like this is not a difficult modification to the

engine API and makes things simpler for all of the

Ys

Alex Stokes: can you not infer which Fork you're in from the engine API method version

Lightclient: I mean you kind of can

Mark Mackey: but like that those are decoupled

Lightclient: well I think now they're sort of coupled again like now we're pretty strict about checking what Fork the person is requesting so if you call like Fork Choice updated V4 with a

non uh Prague block I think it should return error so I think that you can kind of infer now

Mark Mackey: uh I think we do oh I'm not sure

Lightclient: no with the parameters like you can't build I don't think you can build a Cancun block with for Choice updated V4 I might be wrong on that uh but nevertheless propagating this information down into like our block type is different I mean if other execution clients don't have this problem at all or think this it doesn't make any sense then you know maybe I can go look at it some more and figure out

but I think that this is the case for a lot of different teams

why is

Potuz: why do we really need to care about typing here on on the API why would it be it sounds from what you're saying Mt that it would be fine for you if we send you for example a list of lists which are just interpreted as row bites and then you make the interpretation and change into your into your internal type and we constructed that Leist from our internal type would that work well

Lightclient: then you would need well if you send a list of bytes and we would need to figure out what the bite structure is and then it would have to probably be RP because we haven't done SS yet so it's like you have to interpret

the data like the actual data not just the bytes so it's different from the transaction data

Potuz: so then then probably it might be an issue for us because I don't think we have unions correctly implemented in ssz

Lightclient: I mean you don't have to implement ssz unions I'm just saying that if you happen to implement the ssz union then this format would map very closely to what the union like you can still during D serialization of the engine API message determine where in like the individual Fields like the list of withdrawal request the list of consolidation requests where those requests should go from that message that's not a problem I'm just saying

like if you wanted to have if there was a desire

you

Potuz: wouldn't be against like we keeping them separated in our internal type

like the

Lightclient: yeah it's not for me to say like whatever you feel is right on the CL I just think over the API it's simpler for El's to just send what the block data already is rather than doing some interpolation of the block data and combining some Fork logic like we can do it

WR

Potuz: to me no that this sounds correct to me it's it's fine it's just moving that the interpretation that seems to be easy on our side

Lightclient: yeah that was my take

Mark Mackey: just to uh we we do call like new payload and get payload V4

before the fork and I haven't seen any errors from any like I we're running down that one it's fine um and I'm pretty sure the API was designed that way that's why these fields are nullable in the first place because they have to be null uh before the fork so we we've decoupled those I think they're still decoupled

Mikhail Kalinin: at least this back requires the AL so the ARs should

Lightclient: I mean yeah it says engine new payload V4 spec the client must return unsupported Fork if the time stamp of the payload does not fall within the time frame of the Prague

Fork so if you're calling new payload V4 before Prague technically that's should return error

um yeah Mark you say no

Mark Mackey: same with get payload so I don't know right I mean we may not be implementing that correctly but that is like the letter of the spec I think

MH

Alex Stokes: in any case it sounds like this would be helpful to El's and cl's have Liberty

to kind of just take the data and then do what they would like with it so I think it makes sense um from here I think yeah so we have this PR and then the other issue we will iterate on and then yeah um I think just having them all together uh is the next St and then yeah we can go from there but generally it sounds like both of these seem like directions moving uh any other comments on this otherwise we will move

to

Dustin Brody: I guess go

ahead uh that what this this does make a certain style of um Json decoding a little more um a little trickier let's say um so right now Nimbus does the best it can to decode Json and receives uh according to as strict a schema as the specs sort of support in each case and these variant types just utterly rake this I mean we we can't we can then all the usual we read it and figure type is out to new object I assume I don't think there any bistic

alternatives I this is what Json supports because it's not ordered uh but it's it's a mess no matter how it happens um so I mean as long as long as people are basically just upfront that it is it is not particularly less messy for cl's to do this than for Els to do this that's fine this is just a move of complexity and messiness from the El to the CL and it's feasible either place but this that does not moving into C does not solve this problem let's say as maybe how frame it it just moves it

Alex Stokes: sure but then CL clients I think are

more equipped with just the types they have at hand to handle the problem so this does seem like the direction to move into me okay uh next up uh Eton has an update on SSC and stable containers uh essentially he's asking if we want this in devet 2 um there's a link to the IPS here let me just grab a link to this there's a very nice comment here on the agenda so yeah link to the IPS uh specs here uh test and then I believe this is

linked to uh cryptos Network they have running so yeah that's all super exciting to see um the question is if we put it in devet two or not uh you know just like process-wise generally we would formally include these things into the fork uh and then you know devnet would be Downstream of that so if we want to consider uh s a z and the stable container update for pectra that's the conversation we will have to have um maybe I'll just pause there so how do we feel about including these eips um well okay actually maybe iton is there anything else you'd like to add

before we get into that

Etan Kissling: yeah I I have minimized um the eips to the minimum like that I think we should put in Electra because we have this opportunity now because Beacon State reaches a new power of two number of fields so gets reindexed so if we don't do this change now then like rocket pool um mainly but also other staking pools will have to do yet another um redeployment of their contracts every time um that this happens again and also

when we would introduce this table later on so this uh what's in this PR today it does not have SSC transactions or any of the other SSC stuff um I think that the other stuff like SSC transactions can be moved later down into veral so that the veral fork is the one that changes data types more strictly um but we still can do the CL only changes today so that EIP 788 um becomes practically useful I have also obtained support from rocket pool I just linked it this Discord link where

they support the CIP and I can also obtain more similar statements from other taking pools if that's required so yeah um the pr consensus specs is linked in the comment that stalks linked and I have also generated consensus spe tests

Alex Stokes: cool right um let's see I think if I'm interpreting correctly there are some clients teu here uh load star who are saying plus one for thez

feature um any other clients want to chime in

I'll say for prism uh we were ready to say let's try DEET too but I think uh including in specs like merging into pectra is more of a surprise so I don't know if the rest of the team wants more time to consider that

Tim Beiko: um would mean yeah devet 2 is pectra devet 2 right

Mark Mackey: I think he was did you mean that prism is ready for devet 2 but if we had stable for or stable containers it would

take longer

oh sorry no I meant that uh I guess like a there's I thought I thought it was more experimental like a finality of inclusion um but uh yeah so I I I haven't s to the rest of the team on it but um but yeah I think we can do de that too so I don't know if there's opposition to including um stable containers for any other reason but um but I'll say from an implementation side like we're working on it on track

Alex Stokes: right I mean I think the obvious thing is just the Petra is incredibly large already I mean especially if we end up with pios and the fork so you know at a certain point we do need to be very realistic

about how big the fork is and the risk that entails for actually shipping this thing again you know I agree with the justifications uton gave around this feature being valuable and vacuum that being said like uh this is I think the biggest hard workk or one of the biggest that we've ever done and that should not be taken lightly uh Perry had another comment here in the chat that essentially uh okay maybe an eel person can help me here but it sounds like e is in Petra but it hasn't you know been on a de net yet and so that's how well and good um but then with that would mean then is yeah it's like also another

really big change and again just looking at De net one today it doesn't seem like devet one is uh going super well so I do want to caution against kind of yeah biting off more than we can digest so to speak

Mark Mackey: I at the risk of saying something wrong I believe the C I mean this is a CL change and cl has less stuff than the e at this point I think

but

Alex Stokes: right

Parithosh Jayanthi: but I only partially agree with that I think p is still a massive

change and there are a lot of shared resources between el and cl for example we have combined testing teams and I do think at some point we have to get realistic that we can't just have every EIP in and at the same time just keep increasing the scope that is a bottleneck

Alex Stokes: a very real one okay I mean unless someone wants to make a very strong case here right

now I would suggest the following um yeah like let's work through devet one and then I would even say wait on devet 2 and yeah we can reconsider this in the future

Parithosh Jayanthi: but again one point I do want to make um would adding ssz to a devet actually change anything like for example we have SSC Deets so don't we kind of have all the data we need to decide if SS goes into p or not and once we decide if it goes into pectra or not then we can talk about devet scheduling to me that sounds like the workflow we kind of need to have so the question

right now is not when ssse or stable containers is in a devet but rather should it go into pectra or not and what data do we need to make that decision

right

Sean Anderson: so I feel like an important part is understanding like how big of a pain um breaking Merkel proof is for Apper teams we definitely like I've heard from like smart contract uh Auditors at Sigma Prime about how this impacts um their clients and like they're avoiding bugs um I guess kind of narrowly by like

realizing in upcoming Fork is going to break their contracts um so that's like an anecdote that I can speak to um but if it's like easily telegraphed that we can that we're going to break uh roofs for Beacon States in pectra and then like once more for stable containers and that's it like how much worse is that than just having like stable containers in pectra um so pretty much app input I feel like is really important in deciding this one as as far as like work for client teams in Lighthouse we have like a pretty far along implementation the

changes in the client code isn't very large um it's more impactful on the SSC libraries obviously but I don't think it's like crazy um definitely sympathetic to the fact that the Fork's very big and I I want to include PS so would definitely lean towards like would rather PS and non step containers if I were to choose but it's also like they're not really weighted equally like stable coners is definitely smaller than

beard ass

Mark Mackey: would also on that that on that point about messaging like also app app developers are trying to

develop apps so knowing sooner rather than later or telegraphing sooner rather than later is also helpful to them because they know what they can build now and get audited now

Parithosh Jayanthi: would that mean if we have like a public SLC Dev netch would that allow app devs to play around with it enough to know what breaks or not breaks or does it need to be Petra Plus slz for them to actually get this data

Mark Mackey: they actually just want to know what's in the fork because they've been bugging us about I mean uh just an example like Ian layers they're trying to get their things audited and they've been bugging us about whether or not the fields that are in the beacon state for pector right now

are likely to be the final fields that are in the B state but uh that question is irrelevant if we don't know whether or not we're putting in stable containers so it's it's more like what Sean said like it's about knowing what the real for what the real schedule is for when what is going in what Fork that makes it easier on them

Alex Stokes: sure but like we can tell that you know you could look at Vector today without the stable containers and you would know right like I don't just from what you said it doesn't S like they're asking about oh will this be stable forever they just want to know what to Target for the fork

Mark Mackey: I think so

yeah all right

andrio

Enrico Del Fante: yeah I just want to add that so what what's been targeted for be included in Electra is a let's say simplified um version of stable gold implementation which does not cover all the full uh spec that is in the stable container IP so it's also possible that the client team could could implement the the quick version to just enable stable container and then have the full implementation for next

works

Parithosh Jayanthi: so B basally the Cs would like to have it included in Petra have a public

devet so that app devs can give them feedback and then decide if it's actually included in Petra is that kind of the work I'm getting

Alex Stokes: well they can get public feedback from as s ssz Dev Nets right like it sounds like what has been surfaced on this call at least is like the these applications just want to know what's inetra not necessarily that this you know XY Z or ectra and that will be stable forever these are two different things

Sean Anderson: well I I personally don't know which of those is true so like it could be that application teams actually really hate these like uh Miracle proof

breaks that could be true it's more like yeah I feel like we just need more input from there and like maybe other teams have other input for for like um um from application layer uh devs they interact with but I personally like I don't know how critical this is

Alex Stokes: I mean do other CL teams feel that it would not be disastrous to increase spectroscope beyond what it already is like do you not feel that it's already quite big uh sounds like then maybe we'll take

some time to think about that and then how can we move forward so yeah again unless someone feels the pressing need to make a decision right now uh sounds like we can decide in the future again I think we should focus on De net one for the time being uh in the meantime I think we should get more information from App developers to the extent we can and yeah I would recommend each the team to think very seriously again about like Petros scope and what that means for a successful hard workk um every IP we add is just going to you know add more more code more risk for bugs uh generally complicated testing

and you know all the usual bucket of things

Eton

Etan Kissling: uh one thing I'm wondering about Pier does is it's CL spe I think right now it has an optional in there so I'm not sure if that one is still there or but um if it's there it's sort of that's a dependency there because if the pier does is activated before optionals become a thing then that design needs to change as well

Alex Stokes: right I don't recall an

optional anyone else

yeah

Alex Stokes: yeah I guess we should go take a look I don't recall there being one um generally we avoid them again because there's limited support and SSC libraries for them okay uh I think I'm going to call it on that one um I do think we have a few things we can do uh to get a clear picture of as a z um but again I will just call out

yet again uh think very carefully with your client team again about pector scope I know that you know um hard Forks come very infrequently and so it's tempting to try and get as much in as we can but at the same time if it's you know if there if there was a problem rolling a hard Fork uh that would be worse than waiting another fork or two for whichever feature we have under consideration okay thank you yeah Eon followed up uh it's actually a veral usage of optional and not

peros okay

and speaking of that was the next item agenda yeah I can't hear you if you're speaking but it looks like you unmuted oh uh can you hear me now yeah yeah yeah you're good okay

Guillaume Ballet: uh yeah I was just uh going to say don't get out of the way uh to support optionals just for veral cuz we're currently looking at other options uh we would still like to have it but uh yeah we it's not the end of the world for us if it's not there

Alex Stokes: okay good to know um I think we're

early enough in the viral development process that yeah it's there's plenty of time to to handle that okay uh let's move to pios so yeah I think there's a couple of things here uh we do have some time left on the call okay good so let's see yeah first uh I don't know if anyone here has been working on the P stets um if someone has and give a small update that would be very helpful the last time I looked um there were devb nuts uh but they had a number of bugs and generally uh yeah the network was not

staple does anyone have any uh later information on that work

Sean Anderson: uh so I talked to Jimmy from our team and he said um on the last breakout call um people decided to focus on just like fix fixing existing bugs and stabilizing clients as opposed to like focusing on another Tex test net for example so I think there's like a um a test net delay while things stabilize clients

Alex Stokes: yeah that makes sense

Gajinder Singh: yeah from on the I was also on the

breakout call and I think we also discussed that uh maybe we want a more uh cleaner pack in the sense for example we would want a metadata uh PR that is out there to be included in the next devet so that we can have a devet uh which has sort of all moving Parts together rather than uh Missing data where we assume something and then we don't have a very good pairing so I think yeah so for now we also want to focus to get the spec right and to sort of make sure that uh we have everything that is required to have a very stable Network

Alex Stokes: yeah

certainly um right and so kind of on this note um taking that all into account and again myself and you know others in the chat here like there's very broad support for pios as soon as possible uh as soon as possible here means imp pectra so the question then becomes can we ship here aetra um if it becomes the case right that there's difficulty with uh PS is specified uh I did want to bring up an alternative in terms of simplifying the initial pios roll out so this would kind of be like um let's say like a modification to the road map so to speak uh I'm talking with Fresco and a

few others and I think we've we've at least identified another path um and so yeah let me let me summarize that so with pectra uh or sorry with pios there are kind of three like core functions that the client performs right so the first one would be distribution so that's taking you know at the very beginning you have a block with many blobs the blobs get split up in these columns The Columns that are gossiped in pios this is the distribution phase uh there's next then a sampling phase where you then in turn ask your peers for these samples um that then gives you sort of your availability sort of you know um

evaluation or assessment of a given set of blobs then this third part of the pipeline is reconstruction uh which is required in the event that there is some issue with distribution or sampling so right now the way pios is specified in pectra is that it's essentially doing all three of these task distribution sampling and reconstruction and uh my intuition is that uh this middle part samp plane is going to be where most of the complexity is um it might even be good to hear on this call if clients think otherwise but essentially uh the suggestion would be to drop sampling from the initial

periodos rollout uh this should essentially yeah I think there will be a few other parameter changes to maintain the same security level but it would be possible to essentially just have the distribution phase along with the Reconstruction and then we could drop sampling and the idea here is that if sampling does become this sort of you know hairy implementation um concern uh then we can get to a place where we could you know very realistically consider increasing blob counts with this reduced or like modified periodos scope in pectra okay uh that was a lot do any clients have any takes so far or can I clarify something from what I

just said any responses oh yeah

Gajinder Singh: yeah I just uh I think that is a good thing that we can basically later on uh add sampling or uh basically we can also initially launch with having full custody of all the data columns uh because the blob count has not increased and so there is not much data and bandwidth blow up anyway uh also uh what I want to wanted to add was that uh the pr in which we are able to the CL can specify the blob Target or blob count I think we should also get that PR in

Petra if it's not already in the scope and uh we should basically include it in specs or and

inevidence

Alex Stokes: right and so I think the actual numbers would be some of dependent on what peros looks like um but yeah I agree that's a good point and yeah I think it's time to yeah do that very soon um right and yeah something that I think would be helpful there's a question in the chat just yeah essentially asking for a written down version of what I just said um I'm happy to put something together and I can elaborate a bit more and uh make this more of a proper proposal for consideration um essentially this would

just be a way to hedge like again like development uncertainty of of puros um it could be the case that we do periodos as specified uh and it's all in time for pectra and everything's good um this is just an option worth considering especially we feel like the peros implementation is not moving along as far or as quickly as we wanted to uh so yeah something to get on the radar now

Mark Mackey: just want to I think a while back we we're still considering pios might maybe make it in before Electra and that was maybe why we decided not to rebase it on top of the

electr spec but I don't remember if that was the reason I think that's something yeah

that I think was I mean yeah so that's slightly different thing but essentially that was to just simplify development if luur is going be Target um then it makes it harder to then rebase pios on top which is moving Target so they were left separate um for for example for the dead nuts that we've had so far we will at some point need to yeah put peros into elect proper to that I would just point to the previous conversation around again it's the the sooner that we can finalize

really the sooner we can finalize the the spectroscope uh that we have the better um at least if only to unblock puros which again is I think everyone agrees an incredibly important Target to aim for

Gajinder Singh: and we also need Petra uh Deets running smoothly without any Forks before we decide to rease because then the debugging for p would become difficult

Alex Stokes: right

Etan Kissling: for pieras um they like the current design I think still has this special activation Epoch like to make it a here as not a

fork um if Pier do is actually enabled on Electra like at the same for keog um it also allows me to like make the stable container PR even more simpler because right now a lot of the changes in there are because the blobs side cars need to be updated because the beacon block body gets reindexed and and if pias activates on Electra there is no more blob side car right so so that inclusion proof doesn't break um so it's if if we can align it it it makes it more simple as

well

Alex Stokes: okay yeah I mean that's good to hear um right so then yeah I mean maybe we go ahead then and we well yeah there is a bit of a chicken and egg here um but yeah cuz essentially we we want to have like enough confidence in P do that we can then put it on top of Electra but we also want Electra be stable enough to do that so that was kind of the the issue and that was also why we had this sort of special eoch activation idea um but yeah I mean if everyone's on board then yeah let's go ahead and just go for Electra and move from there does anyone feel opposed to moving ahead

with that right now

Parithosh Jayanthi: would this mean we do combined pias Electro def Nets in the future or do we just want to activate an Electra for E would keep the keep like the branches used Etc separate

Alex Stokes: yeah that's a good question I mean I think the simplest thing would imply yes it's together now

Parithosh Jayanthi: considering we haven't had any stable cabinets on anything I think this is going to be really really hard to debug

Alex Stokes: acknowledged so then maybe this is a little premature and yeah we should just focus

on D that one

Parithosh Jayanthi: um if it's just about activation I'm I'm on board I we also done this in the past I think for certain features we've had like Electra devet as the activation Epoch we just keep them as separate devet cycles for example a 7702 bug shouldn't then lead to all CL devs having to debug what happened to their Network right so we can still keep the tests separate um we can just change how the features are activated I guess or how they're interpreted by the client

Alex Stokes: right

we we we had some disc the current

oh go ahead go ahead okay the current issue

Dustin Brody: the current issue here with the the fork schedule one one of them is that it redefines denb like so I understand that some CLS apparently are are treating this as a flag a feature flag of some sort or I'm not sure precisely what the the code structure here but in Nimbus um we tend to refrain from these for any longer term usage and the result is the fact that this has to activate in denb this is this is how the Deb Nets are defined right now means

that we cannot incrementally merge this and so I would actually say this T I mean the this tension that that's being brought up about okay well we can have a for testing purposes separate uh devet or combined devet and the separate Dev Nets though is that the separate Dev Nets also create this artificial breakage and it is break bre break sorry breakage it that is a broken Fork schedule I'm sorry but I'm gonna that it just is that that breakage in the fork schedule um is sort of makes hinders that testing in certain way ways

and it hinders it means that even if let's say two or three months from now we all agree yeah p is great you know move forward as quickly as possible and but now it it has had to at least in Nimbus stay outside of that main development trunk because of this broken Fork schedule because we cannot risk redefining to the the production Fork uh for this purpose to have columns like it's not that's non-starter so I mean so I would say it's actually more effective and more efficient for testing as well overall at some point to combine the two so this is is my claim

Parithosh Jayanthi: yeah I agree as well it should be

combined my question is just when we do that um if it's more advantageous to do it right now sure um if there's still open questions for example um deciding some parameters that P still needs to or some parameters that we think P might still change by then we could wait until those are changed and then merge it through but if it feels like it's stable enough then yeah I'm on board for doing it

Alo

Mark Mackey: um in a previous call we discussed having like a puras EPO type parameter and I think we've got a PR for that I'm not exactly sure if the current Dev Nets are just doing p dash from from Genesis or or how it's being done currently but I don't think that was ever decided

either either and that I mean having a p Epoch is one way to avoid that that issue of uh not being able to test having the test get in the way of each other

Dustin Brody: so I'm I'm skeptical of the idea of the the separate Epoch overall but I agree that for testing it's maybe plausible um however I would say in terms of isolating things it would at least be possible to uh separate out

the the fork Epoch so so that it it starts at um in Electra like so so there's sort of separate things here one is is there a delay in terms of I guess my question right so when you're saying like this s activation Epoch one is sort of activating at denb or Electra or or or sort of far future Epoch as a pure testing thing and another is that people were seriously considering at least some weeks ago um well maybe we'll activate uh pios you know 50 epochs after Electra starts so the the first I think is just a testing concern and we can work with that the second I think is is doesn't make any sense

Alex Stokes: okay um that's helpful so one other point that was brought up in the chat is essentially that uh I think many of the periodos impls are not here right now there is an implementation call that they have uh this is probably or rather that's probably the right form uh to get into this further uh we are also almost at time in this call so yeah again I would suggest let's focus our attention on the dev nuts for pectra and yeah it sounds like we're going to need a little more discussion around exactly how to move forward on this issue it sounds like if we have you know if we get a very stable pectra

devet going then I think that simplifies a lot of the decision around yeah do we rebase pios uh on Electra and you know get rid of this activation and all of these types of things yeah P's asking like schedule it during the peros breakout that that's idea okay uh we just have a few minutes um let's see I think dap liion had one last minute

thing let's take a look um blocks Beacon BLX range V3 here's a link to the pr uh is that line on the call

dapplion: yeah I'm here

oh

Alex Stokes: great oh there you are cool um yeah would you like to give us an overview

dapplion: yes uh very quickly uh there is an issue with the c RPC if you want to sync a situation where you want to pull a long Fork of blocks from which you don't know which P consider them canonical or not the current blocks by range route is spec in a way that you just submit a range of

slots and the node will provide whatever the node considers canonical you can query that information with uh status message but that there is some as synchrony on getting those status messages and it forces you to basically pull this status message every time you want to the request if you want to be sure that you're pulling the right Branch this has not been an issue because we haven't had like crazy forking on mainnet but uh if if hit the fun this could be an issue so what block by range B3 introduces is changing the request from just hey Pier give me range of slots to hey Pier give

me give me a range of slots on this specific branch that may be your head or may not be your head in my opinion that makes it much more resilient to the types of uh syn that we are implementing in Lighthouse at the moment for these very fky situations and yeah I think it's an no-brainer I'm not I'm not sure why this was not introduced at the very beginning and and I don't see much downsides I'm just curious for comment if other clients have specific ways to handle sinking long Forks that may not be canonical uh otherwise this route would

be a good addition like as a caveat something that you could do now is use the blocks by root but with blocks by root you are forced to do uh reverse sync and that's really easy to be attacked because you cannot verify uh chain of blocks that you backward sync until it gets rooted somewhere and that chain can be very long so a pi can just give you garbage and dos you um so you need to forward sing somehow that's why this route so yeah if you can check the pr let me know if it makes sense I think the implementation should be simple so maybe you can Target Electra it's not terribly urgent but would be nice uh

that's all

Alex Stokes: thanks uh yeah I've had a chance to look at this yet myself uh yeah thanks for bringing it up and yeah please everyone take a look okay uh we are almost at time and I think that was essentially yeah looks like that was everything on the agenda uh any closing questions comments remarks to wrap up the call okay then let's call it thanks

everyone I'll uh see you on the next one

Sean Anderson: thanks everyone bye

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