All Core Devs - Consensus #134

Transcript

[Music] you than for

J [Applause]

transition that doesn't yeah okay I don't is anyone watching the YouTube stream I feel like it should have zoom up but there might be an audio issue does anyone know stream is uh uh pre meeting audio and video okay yeah

okay um as far as I can tell it should be streaming the zoom screen maybe I can try this let's see what this does it is no yeah okay let's try this it's a little uh wonky but I think this will do so yeah

Alex Stokes: good morning everyone let's yeah this is going to be annoying anyway let's go and get started um I can try just to do

this so there's the agenda uh this is consensus layer call 134 and yeah we have quite a bit to talk about with Electra so let's just go ahead and dive into it um actually let me just check one thing cuz what I don't know is if this is stay on Zoom yeah okay this is just really lagging h

okay sorry everyone yeah but okay anyway we'll go ahead and get started I guess this is what I want to know okay that's going to be weird but that's okay um yeah the first thing is just to recap Dev zero um and all the things that enter up so maybe just to get started uh we had an open question with EIP 7549 um essentially how to handle attestations at the fork boundary and after discussions with the various client teams we just decided to uh keep that as is so that was pretty easy um let's see next up uh we can go ahead and move to EIP

7251 so this is Max CV and yeah I mean I think generally things went pretty well um you know there was a de Net Zero I think all the seel client teams joined and they went pretty well given it was the first evet um that being said yeah there were like a few things to consider uh with maxb one of them being consolidations so we kind of said originally we were going to aim for El consolidations um I don't know if anyone has thought any more about this or how we want to handle this um I think later on the call we'll discuss Fork scoping and I think some people have even

suggested taking consolidations out um obviously that makes the feature a little bit less useful but that's an option on the table um yeah does anyone have any thoughts here on this one just having El triggered consolidations I think sorry I think Lighthouse had some Alpha implementation that Mark was hacking on um I think he had an yeah um yeah he had a fork that had the apepi as well but I'm not sure if anyone else tried tackling consolidations

Sean Anderson: um yeah I I'm not sure

Mark's status on it but uh I know he did like a ping of um applications to see whether they prefer eel or Ste triggered consolidations and it was definitely support for e um and yeah I think we should include if we can

Alex Stokes: okay sounds good uh so I don't know if we want to aim for devet one for that or something later but yeah let's just keep that in mind

Mikhail Kalinin: um I can briefly provide the status for from the side so we have the smart contract for trigger consolidations

Works um um one one question uh kind of the next natural step would be to outline the elel pack for them and before doing this uh I'd like us to come through the um through the proposal of treating El trigger request as a side car to make a decision here because it can affect the this pack of of this thing on the out side so this kind of an an agre critical path to outline in this spe for consolidations and for consolidations in general I think that was a great that we want them and we want them trigger it from

y

so

Alex Stokes: yeah sounds good does someone have maybe an overview on how complic ated the El triggered consolidations would be from um I don't know from a CL or El implementation perspective

Sean Anderson: like so I haven't worked directly on it but I think it's about as like it's very similar to any other El operation um so since we already have like an idea of how to do this it's not really that much extra work

Alex Stokes: all right so we'll need the logic

for consolidations either way assuming we have the feature and then the source if it's e or CL doesn't make too much difference I think if anything e is simpler okay so let's move on to something else then sounds like we're pretty much in agreement there uh the next thing just to round up some of the de zero stuff was uh this let's see so there was a question around

handling deposit finalization with EIP 6110 uh let's see if I can grab the link to this comment here again there were like various conversations at interrup and male summarized I think generally the path forward here uh and this comment I just linked in the chat so yeah update is just generally uh we move forward on that some and you can check out the comment for the the details so from there let's see the other stuff is going to be additions to Electra was there any other Dev Net Zero things or stuff from the

interrupt that people wanted to bring up um kind of around the existing stuff

Sean Anderson: um yeah I actually had something it was um related to the get payload bodies requests in the execution engine API um so the V1 and V2 versions of these are both fully backwards compatible so I was thinking we might as well just extend the V1 rather than adding V2 um yeah just a thought

Alex Stokes: is that in line with how we

usually handle this I'd have to go look at the comment to say more

Sean Anderson: um well with this particular endpoint we use it during sync and the like types we're getting are going to change at forks and be better not to like switch at boundaries um so I think that's why it's specified as fully backwards compatible um with other end points think we usually do actually Inc the version as the type changes um so it's kind of different in that sense um I guess from my point of view though like if this

one's specified as backwards compatible we might as well not increment the version

Mikhail Kalinin: yeah so um adding a bit the context on on this um we usually BMP the version as Sean said and uh makes sense because usually either the new fork and the New Logic should be applied the New Logic is implemented by this new version or the structure um yeah it's just yeah it's just the mostly about the fork but with this method it's kind of fork agnostic and used by SN as Sean mentioned already so it's we can

actually we could bump the version we could add a new structure but the structure would have a couple or three more or three more new Fields uh that will just be set to n um for those blocks that do not have withdrawal requests for instance so probably just be easier to to keep the same version and just extend the structure

Alex Stokes: yeah that makes sense um great if everyone would take a look uh just go

ahead and chime in on the I think this is a PR there yeah 545 in execution API repo okay so from there there were a number of agenda items ra is uh for Electra essentially either changing the eaps we have um yeah and even some new ones so let's just start with the ones that were changing the existing included eips uh so first up we have this PR here it's 3768 in the consensus specs and

essentially it's just changing the order of the fields uh of the new committee bits so let's see I think who rais this ton I don't know if eton's on the call I'm here cool do you want to give some uh just a quick overview

Etan Kissling: yeah it's uh about stability for generalized indexes so when we add a new field in the middle of a container it means that the subsequent Fields get assigned a new index which breaks proofs based on EIP for 788 um in the

El and it's also a bit misleading the way how committee bits originally were placed before the signature it sort of suggests that the Signature Signs over them but that's not the case the signature in the attestation only signs over data so that's why I suggested to move the new field to the end to avoid both of these problems and there is also a comment in the same PR that suggests that we should also consider a new name for the aggregation bits because we changed the length on that list and if we reuse the old name but change the

type it can lead to subtle bugs in implementations that forget to update one of the usages or um like still consider it based on the Old Lang so yeah it's a small thing mostly um for interoperability and forward compatibility

Alex Stokes: yeah I love to comment that it kind of breaks this like schema pattern we have of having the signature be after everything else um but yeah I think generally rational makes sense so um yeah take a look at the pr and uh but generally yeah I think it sounds

like a good idea

uh I'll add just a little note to that which is that for attestation maybe it's not the most important thing but broadly uh adding fields at the end of an uh of a container allows you to use a trick where you read the common parts with a single distalizer uh and this is useful we use that in blocks for example to determine the slot so that we can determine which this which concrete serializer to use so it's kind of like always good practice in ssz to add things at the end um not just for the miracle stability but just for General ease of use when when when

trying to upgrade from from one object to from one container to the other

Alex Stokes: yeah that makes sense uh so the next one this was I believe it's suggesting to change how we are handling shuttling all of these e triggered requests from the eel to the CL uh this is PR 551 on execution apis uh male you open this would you like to give us an overview

Mikhail Kalinin: yeah sure um so this proposal thanks accent like client for the

idea and this proposal is about to remove um deposits and withdrawal requests from the um execution layer block and instead of that uh the execution layer client will uh surface these requests U into response to the get payload method call after that uh the consensus layer uh will include these um requests into the Bon block body so they are moved kind of like from the El block to the CL block structure structure-wise uh and then uh when the

new payload method is being called uh the requests are dropped are passed to this method call um as a separate parameters kind of as a side car uh parameters to the payload and and uh if the E has fully synced so it's it's online um and can fully execute a block uh it will need to execute a block um obtain those requests from the Block execution and ensure that the requests given from the CL matches the one that are obtained from the execution of the block um it's kind of uh the the way it uh it's supposed to work is kind of

similar to block kg commitments where we obtain them from the get pay Loot and uh send version it hashes in the call to the new payot uh the major difference here is that the requests can only be uh validated when El is fully synced um but it does not introduce any new assumption uh in terms of whether this uh whether the CL can or cannot apply deposits and withdrawals uh during the withdrawal request during the um optimistic Sy um with respect to the optimistic sync uh actually nothing is changing uh this proposal does not

affect anything um yeah that's the um the description of of what is proposed and it yeah it would be great if we think through this um and whether we like it or not on the consensus and execution layers side in my opinion it's it's really um quite nice design solution which simplifies the part yeah and I forgot to mention that this basically an alternative to um generalizing uh requests in the execution layer block so I'll I'll stop here for any

comments or questions

Etan Kissling: I commented on it before like I don't yet understand how um like how the optimistic Sy would work in this new proposal because if you only have a CL alone how does it know which of these requests are legitimate if they are not part of the El block hash

Mikhail Kalinin: um I don't think it's it's it changes anything El block hash is basically Al an e um commitment to the data contained in a block in this case we just move from El commitment to the CL commitment so we'll have them as a

part of pick and block body and it does not change anything

you receive

Etan Kissling: when you receive a block and it contains a couple of these execution layer triggered requests how do you know as a validator whether these requests are the Ed ones whether they are legit

Mikhail Kalinin: if you if you're in in the optimistic sync mode you can't know that for sure and you don't you can't know this that for sure even with the existing logic

Etan Kissling: with the existing logic you can recompute the MPT and check that it is part of the block hash and eventually

when the e um syncs up it can tell you that this chain is invalid

Mikhail Kalinin: um actually yeah but you you can do the same that the chain can be invalid um even when you're yeah even after this change I I really I don't maybe I'm over seeing something but I don't think that it changes anything because today you can't execute uh you you can't validate that deposits that or withdrawal requests that you have in the execution pay lot are are are the same uh as it would be obtained from the Block execution during

the optimistic sync and when when the sync is over um so you can tell that again the block hash commitment does not a malicious party can produce valid execution payot in terms of a block hash but with invalid withdrawal request included into

Etan Kissling: yeah I'm I'm not seeing it yet but maybe we can follow up in the thread of that PR

Mikhail Kalinin: I also understand that if we accept this proposal then it it would probably require some um decent amount of engineering

efforts to switch from from the the general request to this approach mostly yeah on the L side

what would the E need to change

Mikhail Kalinin: well they would need to drop the deposits and withdrawals from from the Block structure and they would need to surface um this information in the response to the get pad and also would need to accept this data on the new payload and uh do do this match in after executing a

block

so

Alex Stokes: okay um yeah I haven't had a chance to look at this PR uh I will soon and I suggest everyone else to do the same if you have a few moments

Mikhail Kalinin: yeah since this change is kind of like really um important for how do we handle requests it would be great to have it sooner than later if we even want it if we want it then um yeah then we can just you know proceed as this but from my perspective I I don't know if it worth discussing on the call as well but if anyone from the CL side or

elide who are listening to this call um Can can think on it and comment out if they're opposed and or not that would be great

Alex Stokes: yeah feels like something we can make a decision on uh on the next sale call cool um let's see so from here the rest of the agenda items are discussing new things that we'd want to put in Petra which is going to te us up for a fork scoping conversation which is

probably why you are all here um so the first one I think will be simpler than pios uh it's EIP 7688 this is essentially using part of the stable container EIP um we had a conversation about this at interop and the basic rationale was essentially we're making these breaking changes with the attestations um you know if you want this sort of forward compatibility with respect SZ layout we'll have to make more breaking changes in the future and so the argument is essentially to make all of the breaking changes now at one time so you know that makes sense what it implies then though is that everyone

needs to go and like add this new s functionality into their Library uh which is not a huge ask given the scope of this particular ssz feature but it's definitely non trivial um so yeah Cayman or Eton I think you you guys were kind of leading the charge on this would you like to say anything further

Etan Kissling: sure came in already posted into the chat a link that tracks implementation progress um I hope that I have collected an exhaustive list of all the relevant s libraries there um I think the biggest uh challenge is on on the go one because

fast SSC um was a bit of a concern there about its performance and maturity that the teams there considered making a an entire new library instead of just patching theable container support into it um but uh yeah let me know if if if anything is missing or if you need any guidance we also have a PR in consensus spec report that adds a lot of TCH test like SSC General tests and there is also the remarkable implementation which also has a PR with even more tests so um there's that there is uh Grandin with a

hands up

Saulius Grigaitis: yes so Sol from Grand team so one question we have um regarding the particular implementations of um of stable containers so we we are thinking because of the rust language and essential of the nature of the rest language we're thinking to keep uh version and containers um at the application um at the code essentially so so then in this way we can keep the code safety because otherwise uh all the like or most of the

fields will be optional in the struct and uh I just wanted to ask so for more Dynamic languages it's probably not an issue but for more static languages uh was there some some research or or some uh you know some different attempts to to implement different way uh this and is there are some you know some conclusions on that because once we we get to this stable containers thing then the structs you know it becomes struct full of optional uh fields which is not very good in

terms of safety that compiler can ensure so I just wanted to ask maybe there was some conclusion on on this thing there

Etan Kissling: like you have two two new things one is this merization layout which is indeed full of optionals but then you also have these profiles um like have all the fields that are required as required Fields all the fields that are no longer used are completely gone and you can also keep them as optional if you want like um sometimes it makes sense for example a withdrawal request when you want to request full withdrawal then just omit

amount so in the implement mentations I know what you mean one approach that could be used if you want to avoid copying is that you just wrap it like you have the internal memory layout which is full of optionals but then you have a type save wrapper that just provides accessors that access directly into this um optionals like into the backing store but uh the types that we are discussing here are quite like small like you don't have to convert them between profiles a lot and it's more like comparable to when you

read something from Jason into SSC like you you first look at what fields are there and decide dynamically which type you need and load it in there so yeah would be interesting to see how the different implementations evolve I think in in typescript ironically they they don't even have this um type that's full of optionals but just provide a bit Vector that sort of tells you how many holes there are in like in the merization so there are different approaches that can be used

Saulius Grigaitis: okay so so currently we we likely will go with the approach where we will

keep this uh version containers uh and we will see how how it evolves because at the moment seems that it will be the smallest change needed right now for us so we can keep um keep with this version of containers like we did before but we are on top of that we are the we are the stable containers here so so we will see but if if anyone from more statical languages uh will have some conclusions on on these approaches I'm happy to hear

Sean Anderson: I just posted in the chat an example of um what Mac from our team has

been working on in Rust um it's it's got like the stable container struct with optional Fields but then like eight th mentioning the profiles are no optional Fields yeah so take a look if you want

Etan Kissling: um what is the progress right now just to track like what implementations have already started um for the like that that was the rust um the ethereum SSC right that Library

Sean Anderson: that's what we use in Lighthouse

Etan Kissling: okay and Grand I guess as well started looking into it

Saulius Grigaitis: yeah we

have our own SS implementation and we started to look how to add uh St container that's that's why I was asking here

Etan Kissling: uh what about uh the TECO library and fast s or the one that prism is trying to build

uh te

Enrico Del Fante: we haven't started yet planning to do it very quickly

Etan Kissling: okay and the prism

I I

James He: I don't think we've started yet uh Casey would probably be one looking at it

Etan Kissling: okay yeah there's another uh thing where

it will be useful for veral for the optionals there but um if we are considering for 7688 for um just to do it now to avoid breaking the smart contracts all the time then um that will be before work so they can also take advantage of that for the optionals that they need okay another thing that we have to think about is to go through all the containers that exist right now in in the beacon chain like uh there are not that many

maybe 50 and to consider which of thems uh do need future extensibility which of them could benefit from optionals like for example deposits there was a discussion at the interrup where this activation eligibility Epoch would no longer be useful in the validator struct so for example making the validator struct also a stable container would allow to deprecate and remove the those unnecessary Fields um yeah just think about what containers need extensibility because if

we don't do these moves now then when we later decide to extend them then it will break again right so yeah

Alex Stokes: right I mean the one caveat is we might not know today which needs that in the future you know

Etan Kissling: sure which is totally fine like um it is always possible to just remove a field of a type right and and to add a new field like we did for um previous Epoch participation in alter where we stored full attestations before and now we switch to these bit fields or um the historical roots that got replaced with

historical summaries so that happened a couple times already and um if you use just a new field it is possible with the stable container to just replace the old field with a hole so that no indit say get reshuffled and then introduce a new field at the end that's that's that's fine

Alex Stokes: right and I think this conversation just highlights so you know if you are curious about this EIP uh we should probably start doing implementation work soon just to surface any of these things like Solas is talking about um so yeah please take a

look and yeah otherwise nice work on the devet and yeah is there anything else on that otherwise uh we can move to

pios

Alex Stokes: okay um peros so there was a ton of progress over interop on PLL which is very exciting to see uh is anyone here on the call who was closer to that and can give an update

Barnabas Busa: I could uh say a few words about per zero so we launched uh P zero during

the interrup event since then we have reached an on finality event and we have about 14% participation I think lots of clients have discovered lots of issues in the first DEET and uh you could potentially relaunch anytime when we have something substantial

Alex Stokes: okay sounds good I mean I think especially given how early it was and it being the kind of first Dev pios that's to be expected um yeah I think that then just kind of teas us up into the next big

question which is you know do we want to include PS and Electra and generally thinking about the scope for the fork uh I think we'll all be happier in the future if we can finalize Electra as soon as possible possibly even today uh so yeah does anyone have any thoughts on including pios given the reset progress there's some stuff in the chat let me

take a look um but yeah I mean maybe to Kickstart the conversation like I think there's a chance that we could ship pectra this year um kind of as is but then obviously that probably means that we'll do peros in the fork after and then you know that could be sometime into 2025 um otherwise we could say Hey you know maybe it's like a bit more of a lift but we could reach and include pios in Electra uh that would delay pectra some amount of time but I think it might be worth it um yeah does anyone have any strong feelings about this

Nishant Das: yeah uh had a question wasn't the

plan to like decouple the pias fork from Electra so you would you know set Electra Epoch X and uh you know ped us like two months into the future but we would have like a point where all clients agree that this particular Epoch is when pias gets activated

Alex Stokes: right so you mean like a CL only fork

Nishant Das: yeah exactly

I mean that that's the same as including it just with a delay doesn't really matter like the point is that all the users have to upgrade before that point in time so we'd have to decide it with the hard

Fork

Etan Kissling: well there's also the eof stuff and there are the ssse transactions which also um they could be combined with Pier do so that it's both e and cl right

Alex Stokes: right but then that kind of opens the fork scope quite a bit and that almost suggests that there's a fork after Petra where we do all of this which I think was kind of the original thinking uh the question is just yeah what are things do we delay and how quickly can we get to this next Fork after Petra and all these types of questions

Etan Kissling: do you know from the El's whether like how how important is it that they do veral in isolation without

any other changes like as I understand veral only touches the state try and some consensus uh tracking there like some data structures there but are they willing to add orthogonal features or is it like if we have verle um it has to be alone and everything that's not in there in pectra has to come after or what's the sentiment there

Alex Stokes: I think that's generally the sentiment that bur would be an independent thing gam you have your hand up

yeah

Guillaume Ballet: um yeah the thing is for example UF can definitely not ship with ver

because it touches the exact same okay some of the state that is being touched by by veral will be uh will also be touched by um by by us um when it comes to um what's the name uh when it comes to SSD roots that doesn't really matter because it is indeed completely uh completely um orthogonal um same thing with spear by the way if it doesn't really touch the state it doesn't matter as much

Etan Kissling: so the only thing that would have to come before is eof or like if it if it's not in there before then it would

be after ver right

Guillaume Ballet: exactly I mean it's not the only thing but it's one example of such thing that either has to go before or after

Alex Stokes: yeah ATD

yeah so uh my broad feeling is that the stuff that we currently have planned for Electra are kind of unexciting and not worth bothering you know everybody's time with so I'd be very interested in getting padas in just to have something interesting to ship in it um a lot of the work is also kind

of feels unfinished at this point um almost every EIP that we've done for the dev zero it felt janky and undeveloped um we did a lot of discussions and changes in Kenya to them where we changed really quite significant things about them or should at least in order for them to be good aips um so I think throwing padas in there is in line with like polishing the existing eips polishing piras and then shipping like a really interesting artwork that users will be happy with it rather than just you know uh some cosmetic changes like ah

where do withdrawals come from

Alex Stokes: right I mean the one caveat are pushed back I think to that is just max CB as as a big thing um I personally lean towards including pios and Electra myself just because I think we'll be happier down the line even if it delays pectra by a bit um that being said Petra is already quite big just in terms of a variety of cross layer things and that means you know more risk uh much more to test maybe not so much a complicated roll out but definitely increases like Security in testin scope so that's something to to keep in mind for sure um Dragon you had your hand

up

Dragan Rakita: yeah uh yell I just want to say that uh y clients are mostly positive about inclusion of UF inside Prague but having two forks seems okay uh just want to say I'm not sure how much complexity is there we have it two forks in regards just having any everything inside prag just pushing it for like three months just want to mention that

thanks Nan you had your hand up

Nishant Das: yeah so um I would also be in agreement with you know adding pias to

pectra um I I feel like it's quite separate from the other eips that we have so it's easy enough to test separately also you know um I I don't think this Fork is going to be small so uh adding P us which we have already had quite a bit of work on I think is fair

Alex Stokes: yeah I agree

yeah I agree with that it's kind of separate um I would say that having one for two months after the other is kind of insane uh if if we're going to coordinate everybody upgrading their clients we don't want to coordinate everybody upgrading the clients again to

months down line that's like not enough time to even you know go through a release cycle often so that means that um all the features that we would have in the plus two month work is they' already have to be there in the previous one and then it's just the technicality whether we call it a work or not everybody like I don't really see that working

Alex Stokes: right uh S I think you add your end up next

Saulius Grigaitis: yes so so if if there is strong consensus on adding piras to uh

to Electra then I just wanted to to check temperature uh maybe it makes sense to remove the attestations factoring but which exactly a it was the one that mov the index makes everything makes a huge factoring so uh because I think it also falls under this uh not so exciting features uh which was previously in this chart in this call discussed

so is is there a strong against moving this huge factoring if be do is is is added because I think it's going if p is added and we have this huge attestations refactoring and during the interop there was some good ideas that I agree that if attestations refactoring is done then maybe we should combine that with stable containers because anyway it's a huge change so uh I would like to

hear reasons against not remove moving attestation refactoring if if peros is added

Alex Stokes: right so you'd suggest take out 7549 and essentially swap with

pios yeah yeah that would be

Alex Stokes: right I mean and then you could imagine the next Fork on the SE we do that change along with all the stable container stuff

Saulius Grigaitis: so that yeah yeah that that would be my suggestion because at least for myself it looks just two huge things if we add the beas

and and stable containers at uh at one fork soon

anyone have any thoughts on that swapping us for that station IP

I think the at the station one is like a lot of code and Community changes but it's not really

impactful from a security point of view I I find them kind of worth I know it's just it's just a m pain in the ass and and maybe not that much utility but and that would be the reason to not include it but I don't think it conflicts or or interferes with P in particular

Enrico Del Fante: but in terms of utility I would say that we discussed in trop that there are good uh very good side effect of all of having that included which is much more space in blocks and very better reor handling

so yeah that was the one reason to have it and I agree with that but and

like it's also like a lot of work for for the community

Enrico Del Fante: which uh been well for for us has been already kind of done for probably most of the client already implemented excluding the the apis but if we have it if we have enough time to also include the a stable container with it I see it as a I guess a good thing yeah uh I I my point was more not to link it to paas I would link it to stable container and and do both in one

because they they indeed are very linked um I do think that that change needs a few more improvements uh I don't think it's read in its current shape um I do think that the confusion between Network the network form of attestations and the onchain or in block form of attestations needs addressing at type level and a few things like this but if we do if we throw in stable container I think we might as well do the attestations as well and doesn't add a significant burden

Mikhail Kalinin: um do you mean that we should

rather have uh different ad station type for network and for the onchain

yeah totally and also for the single uh single attestation single uh voter topic uh so that when you create an Nate with just one validator uh signing it we should have that as a separate type because then we can have the validator index there instead of uh the com index in committee which means that we can um redu like increase security of the

Goss of validation or at least reduce like like make it easier to validate those and that's quite a win because we have a lot of attestations to process

Mikhail Kalinin: yeah so you mean you would not need to have a state to compute the shuffling in order to validate the

adest station

yeah I could pick up the public key without without the shuffling and do that before the shuffling and that's always good

Mikhail Kalinin: yeah but what would be the reason to have different uh types for uh Network Aggregate and for on gain aggregate I I don't um the argument the

points on the single attestation but it's the other

they are semantically different so you you you interpret them in different ways uh one of them has a large list the other one has a small list um it's just very easy easy to confuse the two in code flow so when doing security audits on the code base um like regardless what happens at the spec level we we are going to to do two types for them just just to keep them apart and and and there's really no benefit of having the same type for them

like they um the network variant uh it kind of it it it appears in places that are completely separate from from the onchain version so like there's no spec burden it's just uh it's not increasing complexity it's clarifying complexity in my eyes to have two types

Mikhail Kalinin: yeah see I I I honestly thought that if we have the just one type and we can reuse it here and there that will just reduce the complexity but if it's not just yeah sorry Sean

Sean Anderson: I was just going to say uh in Lighthouse we had a few bugs that probably would have been avoided if we

had separate types

I

Mikhail Kalinin: I don't see any um big problem from this fact perspective to introduce separate type mean like to have the the all that station for you know the all that station for the network Aggregates to keep it and to introduce the new one for and

chain aggregates Andre you had your hand up

Mikhail Kalinin: yeah so having a single type I see that is more future um so open open up a possible future in

which we don't have to change the type and we enable earlier aggregation if we change the way we do that I mean we we don't force to have only single committee aggregation in the first place and you could potentially have very different way of aggregating in early stage so the type will be exactly the same

my feeling is that in order to do that we would have to have a hard work and introduce some kind of incompatible changes also because the gossip rules

dictate that we have to send single vote at the at the stations on that topic so like anything that only goes on the network is entirely Emeral and This only affects the encoding of the object on network on one topic I feel that it's entirely discardable this type in any future hard workk like the single attestation and the same really for the aggregate

Enrico Del Fante: yeah I see your point now so the only thing that is really matter what goes in on chain and the other thing is just uh

SSD types that are floating around Network and uh doesn't really affect the validation of block

yeah exactly

Mikhail Kalinin: yeah yeah so to to summarize a bit if we see that introducing the onchain aggregate separate type for it and to not change the um add station data type and use it for Network Aggregates as it is today um would be easier uh would alleviate some engineering complexities and uh potentially reduce the risk of introducing buxs then from my

perspective it it should be relatively easy to do on this back side so if um yeah if we come to agreement on that so I would be open to to do this change

well I'm in favor

I'm in favor theoretically but on practice I don't know how much will be uh the code base of TCH would be affected by such a change might be painful but I don't know at the moment

Sean Anderson: um yeah I kind of feel the same way as in Rico where it's like it seems like it would have made more sense from

the start but now it's like we sort of hashed all this out and we' have to redo a lot of work to support it but I'm not entirely sure I'd have to think on it more

Enrico Del Fante: yeah kind of roll back on some say on some things and then uh um we already have felt the pain of making this working and uh yeah I have mixed feeling

I've thought about this a bit and and this change mostly affects the gossip layer the reason I want to do it is really the single attestation security argument like I really like that

one

Enrico Del Fante: yeah I like that one as well to have the validator index in there as much better

Alex Stokes: okay uh I feel like we kind of went off on a bit of a tangent on the anation thing is there a place uh we can follow up a sync on this topic because then I kind of want to jump back to the chat um if you're able to make the pr I can commit to making the change in nus and then everybody can look at the code

and see how much it changed

Mikhail Kalinin: you mean the pr to this back

yeah exactly

Ahad out

Alex Stokes: or if that's too much Mel even just like an issue with the change that you can just describe that would even be starting point

Mikhail Kalinin: yeah but I think it should be easy

Alex Stokes: okay great um there was a lot of chat in parallel and essentially we were discussing two Fork sources one uh does someone there want to maybe explain what they mean with two forks like is this

essentially keeping pectra as is and then just putting pios in a fork after or were we talking about something else

Tim Beiko: I thought that's what we were discussing but sorry I thought that's what we were discussing but then people were saying an even smaller Fork than Petra and I'm not sure what that would even represent that's maybe were

Alex Stokes: okay I also kind of lost track through all the chat so maybe people had different ideas of what two folks meant does someone want to argue for a

specific two Fork configuration

Phil Ngo: uh us here at loadstar we did publish um a blog post in regards to a two Fork proposal basically we we just want to keep the um scope of Petra with the most of the stuff that we've already implemented as is and try to ship something within 2024 and then the stuff that being worked on Parallel which still has like implementation details and stuff that needs to be worked on which would delay um having a 2024 Fork would hopefully go into this second Fork is sort of the way that we outlined

it so that will include stuff like

pyos yeah

Tim Beiko: and how about Max CB so I don't have your post ahead of me but oh

I I'll re

Phil Ngo: I'll repost the link but um but Max CB is mostly it's just like slight implementation detailed outside of consolidations I believe that needs to be worked out but that that would get included in 2024 in the first

four yeah

Tim Beiko: yeah and then you'd also want to add some SSD stuff uh but yeah generally keeping in

Phil Ngo: correctly we were're advocating really for stable container to really

get pushing this first for because uh some of the teams like nimus and us have already implemented it didn't take too much work in our opinion so um that's why we were pushing for that to get included in the first

first work

Alex Stokes: okay so then we could imagine essentially pectra as is with the intent to ship this here then there's Petra part two which is really just whatever the you know the start with Saka forz and then that would have pios but you know it might be mid next year or later right and I guess that's kind of the decision to make is like how okay

are we with having pios potentially roll out you know much later much later than what sry uh I just feel like if we said okay Petra this year and then pios and the next Fork the next Fork will probably be a year from whenever Petra ships right

Tim Beiko: we can tell ourselves it'll be six months

Alex Stokes: right and so I mean I guess that's it right but the time between that one and chapella was quite long

I mean in the E they

they I think it was re that raised a good point which is basically that shipping in November is bad so we'd have to ship it before November and and that's night and Paradise is like a really exciting feature compared to pretty much most of the other things MH yeah I mean go ahead one thing uh one thing I do want to mention is that if we are thinking about splitting it into two fxs we have to be really careful that we don't then just overload the next for with new

eips um yeah I have no idea if we're ever going to be able to do that if we can actually commit to something a year year and a half in advance because we're always coming up with new ideas priorities change and so on um so yeah there's also an argument to be if for example we swap maxb and pias so that there's more focus on pias but yeah I think those are all just points I wanted to have

Al

Alex Stokes: right I mean we can commit today to saying hey only pios in the F star Fork but as you point out you know we feel differently in 12 months

I mean I do think having less stuff in one fork is better right so everything is like severely der risked if there's two versus one and that does argue for pectra essentially as this and then having pios in the next for we just have to be okay with the world where you know it's next summer before we get

pios

Tim Beiko: or work faster

Alex Stokes: yeah we should probably always be working faster franisco says that sounds like a pretty bad world says in the chat if Kos is so

exciting we should focus on that so then you know that gets us back to Petra pios and then the question is do we want to make pios smaller by swapping something out and then the questions what

yeah my argument

Saulius Grigaitis: yeah my argument would be that we still have some debate on on multiple Apes in in Petra uh the good thing about P do that it's one thing not multiple so if the Focus would be shifted completely to P then I think P could happen sooner uh but if we if we keep focusing on on

pectra and then in parallel on p d I think this this is maybe something that keeps us dragging

M

Alex Stokes: yeah so onar is basically suggesting we include pios and then reevaluate down line which might be a good way forward

Tim Beiko: I guess from the spec and testing side what i' like to better understand is is it more work to combine

these things and one spec and then split them out if it takes too much time or is it less work to like have them be two forks at worst case activate Lally at the same Epoch or one Epoch after each other um my sense is like untying everything will be much more work than like having two clean separated things that we want to merge um and if we don't even want to merge them we can just activate them you know I don't know if on on the same block probably causes some weird issues but like you could literally do one eoch after um or you know 8192 eochs after or something but have it in a single release from a user perspective um on

the like on the El side we've had bugs historically when we take stuff out um things end up like interacting with each other and it's like a non-trivial amount of work to safely remove something so yeah I I'm not a client implementor but my sense is it might be easier to like spec them as two forks and decide later on if we want to ship them combined

um yeah

Alex Stokes: yeah I think the issue is having like one fork dependent on another I mean the teams please try in but I think that would generally be the catch but maybe we decide it's kind of worth the pain

Tim Beiko: because it means you can't test anything on Petra until you have stable

specs for anything on Pi Das sorry until you have singles

Alex Stokes: yeah any change in the prior Fork is going to impact the fork after

Sean Anderson: like the these two uh P Das vers rest of Petra I think are pretty segmented that maybe I'm wrong but I can't think of like inter Fork dependencies there but that that would like typically be an issue but like I can't see it here

Alex Stokes: right so we Petra is and then just for sake of argument there's like the fstar fork in the seals that's essentially off of the Petra stuff and

then of star has pados does any we kind of had the scenario also with uh 4844 and chappella where we wanted to ship 4844 in chapella and then we pulled it out so maybe client teams can say if that was in retrospect a good idea or if it would have been smarter for us to have just waited cuz we're kind of agreeing on doing the same thing right now right we're saying we ship everything together and in a few months decide if we have to rip something out with the caveat that it would be in a separate Fork so it might be a bit easier just to have it

disabled

uh I'm going to put this in real easy terms for everybody which is basically that we're trying to pack a block here right which transactions go in and the way you pack transactions is whether they uh affect each other right and I think pretty much everybody is agreeing here that piras is kind of orthogonal to everything else so like it doesn't conflict with any other of the transactions that we're trying to pack into this block and that's the main reason why shipping it together with this Fork makes sense whereas some other changes that you know have complex interdependencies perhaps should go out that's why we wouldn't ship you know verle and UF and everything in one so so

in those terms I think all the items that are on defet zero plus pise plus stable container nicely uh can be tested almost isolated until they're just put together and and we shouldn't see much risk in putting them together

Alex Stokes: so that's a suggestion for Mega fork and including pectra and then just charging ahead yep yeah Barnabas

Barnabas Busa: yeah my point for testing uh p and pectra at the same time is currently they are being activated at a different activation Fork EPO and we could keep

that potentially even till we hit the pure so what we could do is keep these two features uh absolutely separate uh till the last second and then we would uh just activate it on the same uh Epoch in the end so instead of triggering the P death on uh backra forok we we would just trigger it on its own forok so this way we can even in the last minute we could just decide hey we we are not ready with P death Let's uh delay that and let's not include that in the

pure for book

Alex Stokes: right so is everyone okay implementing it that way where

essentially there is pectra and then there's a separate Epoch for pust Activation and then we can

Barnabas Busa: this is already the case right now so nothing really has to change

Enrico Del Fante: it will be effectively a parameter of the pectra network

Alex Stokes: it could be I mean it could also not be like it's not today right

Barnabas Busa: yeah so I think this this would be the best way going forward we say that we want to include it uh and we see how s teams are done with implementation or they are not done and if they're done by

uh pectra time then we include it and if they're not done then we just delay it I think the complicating part in this is that both pectra as well as pias would be rebased off of dap starting point and both Petra and pias are changing at the same time so one of them would have to be rebased on the other once it's considered complete I guess um so it depends on client teams if that's an easy thing to do or if it's a hard thing to do

Sean Anderson: um since we're not changing consensus types in P ass it doesn't seem hard to me to rebase the two so

Nishant Das: yeah so the same for us um it's it's purely a networking change so it can be cleanly separated or join together but one question there was wasn't uh pias changing Fork Choice as well because there's now sampling before a block is considered valid as opposed to right now the current Paradigm being that you get all the blobs and then it's valid so wouldn't that touch some amount of consensus code and not just networking

Terence Tsao: but the current Electra code or current Electra spec does not touch any for Choice code so that part is completely independent

Nishant Das: well for p d it only touches

justification so um that'll be the only Edge case

Alex Stokes: okay so then suggestion would be to have Petra as is there's now a separate Fork Epoch for pios but then pios is on top of pectra not an up does that sound good to everyone

I think there were arguments

where introducing an entirely new fork in client code is difficult just for one feature so I think yeah

Enrico Del Fante: that's why I was thinking is it was not an actual Fork but actually a feature that enables at a particular point in Electra Fork it was will be something like that for

for

Alex Stokes: okay so it's allti new Fork right it's all Petra but then there's just a different

forky P for for enabling Epoch yes feature enable Epoch P do Epoch enable and and

everything

Tim Beiko: why is that different like the

SE cents

Enrico Del Fante: because when you do and a fork you actually have completely different um domains and signatures and everything everything changes so uh Bitcoin

Sean Anderson: yeah so we'd have to like resubscribe to different gossip topics for example change

and

Tim Beiko: okay got it

Sean Anderson: okay usually change types but since there's no types changing here that's why we can do this

Alex Stokes: just running this through what happens if we do end up putting puros in F star is that going to cause any issues

if we go with this approach that we're discussing right now

Sean Anderson: I think it would be pretty easy to bump bump it out with this approach

Tim Beiko: okay so what you're saying is like you can do um beas as part of pectra with a different activation Epoch this saves you the like overhead of all the new Fork implementation details but then if we wanted to move pias to its own separate Fork the only additional work is effectively that like Fork scaffolding overhead is that right

Sean Anderson: like I mean scaffolding overhead

would be required by the new Fork anyway so it's kind of like right

Tim Beiko: yes yeah yeah so it's like we can hold off on doing that implementation work until we decide basically

Sean Anderson: yeah like from my perspective if we just have Petra as a separate enable Epoch whatever we can either set it to the Petra Epoch or disable it and then just like wait till we Implement fstar on top and then just set it to the fstar

EPO

Tim Beiko: yeah makes sense

Mark Mackey: one thing though is ik I think especially if they do it a fork quickly after the electri defo I I guess if we

don't do it a separate Forge we run the risk of people being able to run a electric lent that isn't P doin by the time the

P Happ

no I mean the code would have to be there in Electra if we I feel as if what we're saying here really is that we want to provisionally put it into Electra but it's easy to pull out if we don't want it in Electra like the story we're selling and from a technical point of view the way we solve that is with a separate constant for paas Activation

Epoch

Alex Stokes: right which I think maps on to the thing everyone wants on this call today

Mark Mackey: but then I guess B is that we do rease the on top of the for and then we can decide whether to combine it later

Alex Stokes: essentially yeah I we would just have this activation Epoch and then that could be whatever we want

uh the constraint that that introduces is that PS must come after electr then I think something that's that makes sense

Alex Stokes: well after equal right which is what we're going to have yeah

after

yeah yeah yeah

Barnabas Busa: is it an actual problem though

no it's not a problem I'm just saying that like then we for the fork rules to make sense we would that perod as Epoch would have to be higher or equal than whatever we use in Electro Epoch intestines for example which is fine it's totally fine

Alex Stokes: Terence

Terence Tsao: I think there's one thing that we probably miss that we should be careful of is that when you activate Electra before P does right like which four Choice should you be using should you be using a four

Choice rule that is specified in P does or should you use the four Choice rule today right so that's something that's probably worth thinking about and whether there is risk there by going either way

Alex Stokes: right but don't you only change the implementation of this data available in Spec

I haven't like

Terence Tsao: I haven't looked at the latest for spec I suppose there's changes yeah I I think Franchesco is that answer that

Alex Stokes: say no as in it's not that encapsulated

um yeah I don't think oh sorry uh okay is it okay now with the ech yeah you're good yeah

Francesco D'Amato: uh yeah so

it's not it's not just changing implementation is data available um it's a bit uh more complicated than that but not not really that complicated like I think someone already mentioned before the actual peer sampling part of things is really basically restricted to checking for justifications um so it's it's something that like you have a lot of time to do and doesn't kind of really get in the way the critical path um but there is a change in the for choice so it's uh yeah there is something to consider there I mean I don't see what it would even mean to switch to the pier dust for Choice before does his live because like you're not doing sampling and um yeah I I think it would make sense to just keep using the regular for

Choice until you actually switch to the pias networking

Alex Stokes: okay uh we only have a few minutes Carl

Carl Beekhuizen: gaining here by having it as a separate Epoch off the fact it seems to me we're just assuming the worst that things might not work out timing wise and putting in all the effort of splitting it ahead of time which means you kind of have to just take the loss on um that the the the time Delta to to to implement separating them out anyway it just seems like we take a

pessimistic route or no particular gain

Alex Stokes: well the game is we want to ship pector en like it's like I think all we're really doing is just uncoupling this activation neac and so we could decide that's equal to pectra or we could have it later if we need the option

Carl Beekhuizen: and adding that option like how bad is it to add that optionality because if it's not that bad to add that optionality then truly it's not that bad to add it down the line to me this just seems like a thing that complicates testing and a bunch of client work and stuff between now and then this is not something we've really had before I don't think for any features or am I wrong

Tim Beiko: I think the difference though is

you're saying you're adding like this huge new feature to the fork and the base case shouldn't be it's going to like ship super quick you know not going to cause any issues and going to go smoothly like the base case should be it's going to add some complexity there's stuff we don't know yet about it that we're going to figure out and it's probably easier to hedge like not delay all of pectra because we've added this huge thing um and if we turn out they' be surprised that like it's actually easier than we thought which I don't think has ever happened for any like large feature then we can couple it easily but yeah that does it does seem worthwhile to

have like some separation to not tie the fate of everything else that has higher certainty to this

Carl Beekhuizen: I mean fed to me it doesn't seem much worse than just stripping it out if we just if we reach the point where this is not going to work but if everyone disagrees with me on that that's totally fine

I

Sean Anderson: I kind of get what you're saying and I kind of agree you have like a little bit more flexibility where you can just like uh enable P ass like an arbitrary eoch like maybe that's good for testing or something but yeah don't I get that it's we could just package it in this fork and we can do

this work if it ends up not being able to do this Fork because the work to actually make it enable based on the eot isn't that much

Mark Mackey: yeah like basically doesn't it come down to testing like either we we tie Petra Readiness to having P adequately tested and then we activate P Das or um if we decide that like P Das isn't ready and then we let we don't we don't have Petra weight then we need to implement here as a second for just to force clients to update

SE

Nishant Das: yeah so uh with pias do we also want to increase the target blob count

Alex Stokes: I think generally but that's a whole different conversation okay so summarize pectra as is there's some threads to follow up on the existing EIP set we'll move ahead with PS with a separate activation neoch with the idea being that it will go live in pectra and then we'll see how p impl

goes to determine if you know peros activates rra or maybe some later date does it sound good to everyone

Etan Kissling: I think the 7688 still needs to be added to the list

Alex Stokes: um uh that was stable containers

Etan Kissling: exactly yeah the CL portion of it

Alex Stokes: do we feel confident that implantations will be

I have a working death net

Alex Stokes: okay yeah I mean that to me feels like something we could discuss on the next

CL call we're also at time so we will close soon um I'd probably personally like to see a little more implementation progress across all of the production implementations before including it for

Sean Anderson: we have a lighthouse implementation sorry we have it in the library we use we haven't yet tried to integrate it into Lighthouse

is anybody against including it

Alex Stokes: the concern is just making the fork

even bigger than it already is

that didn't answer my question

Enrico Del Fante: we haven't even started working on it so is a question Mar for us

Alex Stokes: okay uh we're at time why don't we table stable containers until the next C call and in the meantime uh if you want to support the CIP you should work on implementation okay thank you everyone we're at time uh that was a lot of

different conversation but thank you all for joining and uh yeah I'll see you on the next call

thanks Alex Alex thanks

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