All Core Devs - Consensus #108

Transcript

[Music] foreign [Applause]

thank you

Danny Ryan: okay we should be live this is condenser call acdc108 issue 771 on the PM repo um we're starting at number three today apparently it says the markdown um deneb then some general stuff discussions and then awesome time for

any other discussion points people have um let's see so last call both in the execution they're called in the constellar call were kind of like trying to shuffle towards um a final feature set for deneb seems like we're getting close on this end so a couple of updates and a couple discussion points um Alex is not on the call today but 4788 is CF wied on the execution layer um there's a lot cfi'd so it's not 100 clear exactly what's going to make into the final list um but I think we will be moving forward

with the 4788 building into the deneb fork given that signal so we'll have testing and other things like that um it is on the consensus layer on the minor range but we'll work on getting that built into the fork and and release relatively soon let's see six had a summary let me scan real quick to see if there's involvement stuff okay yeah so there's a little bit of discussion on the execution layer how that actually uh shows up but he also comments that it's pretty sure for us it's there so

any any questions or comments on that or on the process or how things are moving forward here

great okay um the other item that two weeks ago there was General consensus on this call this is not a cross layer feature to get into NAB is that slash validators copy proposers which is a minor change to the proposal shuffling function um we were able to greatly reduce the diff with like a slightly different

place and where this was being called that is in that PR 3175 Mikhail did open up a corresponding EIP that's still like in a pretty early draft status but now the number 69.87 uh Mikhail do you have any other comments on this one nope

Mikhail Kalinin: um yeah the pr um I think that we should settle this down into the features and directory to make it a proper um like change to the um CL IP mentioned this in the um in the EIP as well

and as you mentioned that for the footprint the um the div of the changes has been reduced which is great um it's great um suggestion on the way to do it testing is also kind of ready so it's just about like more stuck in more shape in the stack in the battery now what's what's left to my observation

sounds

Danny Ryan: sounds good um both on this and 4788 we'll keep things moving such that it gets into the denab full Fork build and tests soon any questions on these two items

okay great there's an open PR uh that's had some active discussion this is 3338 on the consensus specs repo essentially techniques for potentially allowing additional slack in the blob constants on the consensus layer such that you don't have to do a cross layer Fork when updating the gas and we're on the execution there um does anybody want to give an update on the status of this conversation it's been a lot of back and forth

Gajinder Singh: yeah I can give a little bit of update

okay

Gajinder Singh: so the original proposal was that okay you know we keep Max blobs per block a little higher on the execution API so that El clients can basically increase their data gas independently and henceforth increase the throughput of the blobs and so basically you know over the conversation it was discussed that uh you know putting it to a much higher bound like 1024 was not a good idea so maybe 16 block 16 blobs uh by block was okay uh so uh even over there we have some uh discussion

going on uh but what has one other thing that has come out on it is that we should have another variable like Max commitments per block which basically and keep it to a high level like 1024 which basically means that the Merkel proofs there are generated even now uh would be valid to a point when for example we get kick up the blobs per block to a high number in charting so basically the block inside the block we have the list of commitments uh based upon this high high value but we still basically uh have 4 or 16 blobs right now

that the Claire can handle and depending upon what we feel like I mean maybe we want to kick up the current Max blobs to 216 I mean that that is an independent question from Max so these are the two discussion points being discussed in that PR

Danny Ryan: okay so we get uh yasik proposed an additional variable that gives us the shape of the block the shape of the Merkle tree with respect to the block that would be forward compatible and then an additional constant to bound uh the actual amount that we're willing

to accept currently and that could be uh synonymous with the value that's in the execution layer or that could have some growth baked in like up to 16 up to two megabytes if we wanted to give a little bit of elasticity to the execution layer without the consensus ironating of work that's that's where we're at yep okay great thank you um yeah I I just want to bring this to people's attention um this is something that has had active discussion and might have tiny changes with respect to constants and how they're configured um are there other discussion points on this or questions on this

otherwise if you are interested in this topic please jump into this PR um I think this is one of those Minor Details but one that we should get ironed out maybe by like the next call um and maybe the next the next release that might include some of these other minor Futures that are going to get in Direction okay check it out three three eight Mars can you mute I'm mute

oh somebody else all right um great so those are our general denab discussion points um are there any any other items we want to discuss with respect to them the ongoing um issues or any updates with the test Nets anything devnet

Barnabas Busa: uh basically uh this morning when Mario started the year we saw some uh problems unfold Aragon is uh crushing with some very massive print statements and another

mine monster unable to propose blocks we had a short period of uh on finalization also

Danny Ryan: and this was a transaction buzzer you said

Barnabas Busa: but it was not working correctly as far as I understood

Marius van der Wijden: yeah so um I I have no idea what I did I basically just started the fuzzer and um because I was not using my own node I I don't know how many transactions uh I send I don't know what transactions I sent and um uh I'm also not sure if this is actually me um uh causing chaos um I'm I'm going to set up if I'm going

to set up my own node so I can better see uh what's happening and and what I'm actually doing what my code is actually doing um and so yeah it's very fuzzy at the moment but I'm I'm glad that there have been some issues uncovered already

yeah

Danny Ryan: are you okay Marius

kind of but yeah I think

Danny Ryan: um okay cool that's exciting uh good to see that stuff now rather than later um okay any other on the devnet um Tim did threaten to hijack a portion

his call to talk about SSD um Tim do you want to give a status update or any any uh time on that

Tim Beiko: uh sure so basically the status with SSD and 4844 is that um as I think the El client teams have started to implement this um there's been questions around is is is the amount of SSD we're introducing would 4844 um actually helpful to getting yes towards full SSD on the El and if it isn't um then does introducing sort of partial lessons Z now and not being able to

fully leverage it um actually make things worse than simply sticking with rlp to encode uh the 4844 type 3 transactions um and I know that uh like client uh Roberto and uh Ethan have been discussing this a lot on the Discord so I don't know if either of them have an update

yeah yeah so if we're right

Danny Ryan: now SSD kind of like flat hash is kind of in the worst of Both Worlds like we add a new dependency and don't really make it look like it's going to look in the future um so then the question becomes try to make it look like it looks in the

future or move to ROP to not be in this unhappy medium

right and I think uh Ethan had changed his EIP uh 6493 I believe you know based on part of that feedback I was just gonna

say I think this is one of those things where it's hard to make it look like what we think it should look in the future without having an extremely clear idea of what the future should should slashes go into look like and I think in the past we've done this thing where we think we're being forward compatible with the world but then the way we understand the world slash the world changes a lot in the one to three or four years it takes to complete the

thing so yeah it's just really hard for us to actually put SSD here in a forward in a way that we know is going to be compatible and I think like the reality is is that it's almost certain that we'll either constrain the design space in the future or we just have to straight up change what we choose today

Danny Ryan: and I will make a quick comment that this does primarily affect solely affect the execution layer um so we don't have kind of a full consensus of people that might be interested in making discussions this is a bit more of a status update but we can have more discussion if anyone has additional

plans

Tim Beiko: actually what the I'd

be curious to understand better xiaoway you made a comment in the chat about how this would affect the CL specs if we move completely to rlp do you mind maybe just sharing a bit more on that uh yeah so in the the net uh equipo steak we have a function to access the block version hashes so right now it's SSD and we used to SSE logic to access to pass the bytes into and to found the version hashes so last function has to be changed if we use the full IOP

transaction

I had one idea I'm not sure if this is possible but if we were able to have the uh version blob hashes of the um in two places whenever it's being propagated amongst among CLS where we have it represented in the ROP transaction and then we have it outside of the ROP transaction and a structure that the cl can understand and what we could do is then we could verify the blogs and all the information against these uh version hashes that are outside the ROP transaction um once all the checks are complete we

give the rlp transactions and those hashes to the execution layer over the engine API and the like first thing that the execution layer does is it just checks to see if the ROP if the hashes in the ROP transaction match the hashes that were provided outside of the ROP transaction that way you don't actually need to do any kind of ROP work on the CL

Danny Ryan: and an upgrade to the encoding would be opaque to the seal at that point or transparent wherever the word that is Meaningful there but we wouldn't have to do anything

yeah it's slightly more complicated but it seems like that would allow you to

avoid having any ROP on the CL

for its

Jacek Sieka: compatibility argument I mean if uh two things first of all like with rlp we're definitely not forwards compatible um and the second thing is that SSE kind of brings features today already right you can build Nice Market proofs over them and stuff like this so it's not like

not in the way that we're using it now we're only serializing the SSD you know Supply so there's no there's no hash tree roots

I mean

why are we doing that anyway like the arguments for that seem rather weak to me

I think there's just like more like strange things to start end up happening like if we use the hash tree root then like what goes into the Merkel Patricia try is it the um type transaction prefix with the hash free root is it the SSD like the transaction hash comes out of the fact that it's like the hash of the transaction that goes into the Merkel Patricia try and so we start opening the box of all these like weird things that we have to figure out

Danny Ryan: and the Y it's a flat hash I think if I remember correctly it was an attempt to get SSD in there in a very minimal way um but again in retrospect or maybe it should have been clear at the time it's kind of the worst of Both Worlds we can continue to discuss this I think it's maybe more appropriate that now we've just kind of highlighted that this issue exists and to engage the conversation between now and leading up to the execution layer call next week

where we'll have more of the relevant parties um any other comments on this one today

Tim Beiko: yeah hopefully we can resolve this in the next week or so um it does feel like on the El side it's like the biggest spec issue with regards to

444

Marius van der Wijden: so one thing that like that that kind of like we we have to we have to we have to change uh the transaction types at some point anyway and um I think it would be better to have

like them all ROP until that point um and then figure out something where we can convert all of them and um one thing that like if we were to go this this route of having the block transactions in our ROP um one thing that I would really like us to do is to create this conception that this transaction type will not be there forever and we are going to drop it at some point in favor of the full SSC plot transaction type once we have the SSC transaction route and so because we

suspect only roll ups are going to use this transaction type it will most likely see very little usage and so I would like to if we go this route of having it ROP I would like to state from the beginning that this is like a temporary solution and we are going to drop this transaction type fully at some point

Danny Ryan: essentially a deprecation notice at the creation

yes well

Marius van der Wijden: we are going to like this is the thing right this this transaction type will only live

for a very limited amount of time either way like if we do the SSC stuff or if we do the RRP stuff once we we go to like the full SSC transaction route this transaction type will be changed um anyway so um let's in my opinion it would be way easier to make it as close to the current transaction types that we have so we don't have to have another um like another special case uh when when we do the transition to full

SSC

Danny Ryan: I have a question

um when we plan on for any transaction type that exists um if we're going to migrate from rlp to SZ would that be actually the deprecation of a transaction type fully or a mutation of a transaction type so you know so we take type one and then kill it and make type four or would type 1 mutate is there this might not be specified I just I realize I haven't thought of the answer before

Marius van der Wijden: so we like with the other transaction types we don't want to fully deprecate them because we still want to allow for this use case that you signed a transaction at some point in the past and this transaction should still be valid

um but the integration of nutrients new

types

Marius van der Wijden: uh yes um or may yep maybe we can get rid of them if we provide for example a pre-compile that you can send this transaction to that then executes the transaction for for you something like this um but yeah there are workarounds around it uh but yeah that's that's the basic idea

okay

Danny Ryan: I propose that this active conversation continues the next week and we get all the relevant

parties on the Executioner discussed in one week's time other deneb related discussion points for today okay great uh we have a number of items in the uh specification not related to NAB that we'll go through now um just a heads up the atnet revamp that's been spearheaded by age that was discussed two weeks ago uh will be merged soon after this call and we'll make it into a release this is backwards compatible this does not include the

down scoring uh so that people can roll it out over time and we would add the option for down scoring add a hard fork in the future any final points on that cool thank you age and others that have kept this one moving okay uh is Michael Sproul on the call no I don't think so um Michael Sproul brought up the beacon apis three one seven this is AD broadcast validation uh to block publishing

um this is essentially I think we've discussed this uh now there is a PR this allows this uh essentially allows for let's see for relays to do a full verification before broadcast in light of the unbundling attacks um this helps prevent relays from having to use a forked version of a client which would help improve clue client diversity for this use case um I believe there's not been much contention around this but opened up for

discussion now if you have discussion points otherwise please take a look at this PR and we will probably aim to get it ironed out and merged relatively soon any thoughts here

Terence Tsao: so we have some thoughts right so um so let's just take a step back on why we are doing this right because the first thing is that um having client fourth is not ideal right because now uh prison has its own port Lighthouse has its own fork and then the second thing is that fully importing the blog is not ideal either because the currently we broadcast and we fully import the block by fully import I mean you also do execution

check you import the block to the DB and then you import the state to DB and that's pretty slow and then the whole idea is the relayer wants this out as fast as possible so we find out that hey we can actually skip all those steps we can just verify the consensus side only and it turns out we're able to reduce like 80 of the latency by doing that and therefore um it does make the Builder and every layer very high right and then but the downside with this is that we're behind the line working with the relayer versus like working on insurance PBS first because now like it kind of becomes this like a board game that we're just like keep adding this feature to support

um MVP boost or PBS that's out of bed and that's probably the biggest concern here for example because now if they want some sort of like equivocation check to check for slashing and then and then and then we probably have to provide that blah blah blah so that's the so that's so that is the another angle to it so from our end we're pretty torn because we can be like yeah this is nice to have but but at the same time we kind of like would like were slightly worried that we may be moving away from um just doing just doing internal GPS but then I can see the argument of having both working on both at the same time so yeah this is just some two cents

from our side

Danny Ryan: got it thanks James yeah I guess the way I view those arguments is like we live in a world where boosts exists um and we could see some degeneracies in client diversity and usage and other things if there are not some faculties to make it work appropriately um but I I definitely sympathize the the other argument yeah it seems like age on Lighthouse

side uh kind of agrees with the the issues at hand as well um yeah I guess have some discussions with your team to make a some sort of opinion about whether this should or should not go in and whether this path in general should not sure should not continue to be supported um and please bring any comments you have to pr317 on the beacon apis um so we can continue to have this conversation any other points on this one and thanks Michael Sproul for being the

pro okay Mikhail you have um an open PR on the consensus specs send store.finalize block hash to EO uh could you give us an update on this one

Mikhail Kalinin: yeah yeah there is this is a pretty old PR um and basically it states that uh SEO client must use and my must read the finalized block hash from the store uh instead of uh yeah uh to specify this explicit statement uh

saves us from from the case where they had State might be used to read this block hash well send them to El client which in some very very edge cases can lead to finalized block hash I mean like reverted back into the book history which would cause some potentially cause some ux issues so and apparently all seal clients already follows this logic so there is an intention to finish the work in this VR and I would like to just bring it for um on client dev's attention if there are any objections please rise them in

the pr oh okay and that's basically it so the idea is to probably work on the test if it is possible with the current Destin framework that we have to test this particular um thing yeah yeah and let's get it merged in the coming weeks

Danny Ryan: yeah thank you Miguel that's pretty much any comments on this one and I think there's maybe one or two people that are unmuted and I'm having

trouble shooting them um so if you can please mute yourself thanks um okay there's one other danab item that I forgot to bring up um there is not a spec for this already but in process attestation for the security proofs around the work choice in relation to some of

the recent patches and for the I think very exciting confirmation rule that is in the research post right now there needs to be a slight one line modification to process attestation um right now there's kind of this rolling 32 slot window for a given attestation per given slot to get in the modification would be to rather than for the previous and the current Epoch or for n and n plus one where the opposition is from n it has just a rolling 32 slot window that it can be included the modification would be if it's from Epoch in it could be

included up to the entirety of the entirety of epoch n plus one this modification helps with the security proofs and helps with the confirmation rule so that is a one-line change we're going to get us back up for soon this is probably you know the addition of a few tests and modification OG tests on our end so very small on the consensus spec it's security related so I think it should be expedited but I will open it up for conversation if anybody has any discussion points today and then by the next call we'll have a stack up for further discussion

Jacek Sieka: what about gossip there

we limit by the same 32 slots if I remember it right

Danny Ryan: yeah I'll have to take a look at that but you're right um we need to probably make sure those are under the same

conditionals and in the

Enrico Del Fante: in the telegram we also discussed about uh rewards are there on discussion point about making them valuable when including in the block

Danny Ryan: do you have particular details

um is there essentially like a degradation of rewards prior to the epoch that would make them be ignored

Enrico Del Fante: yeah I try to remember correctly at some point though that the station actually become worthless uh and since we we filter out uh at the station that are worthless in the beginning so we are not going to select them when we produce blocks um so I'm guessing if there are impacts also on this area

too yeah yeah yeah then you're

Danny Ryan: you have I think the graph

of degradation of value of attestation and more of the Forefront of your head can you explain where we're at

uh yeah so correct targets um expires of the 32 slots so uh as Enrique said the um attestation becomes valuable that's actually penalized after uh 32's losses equivalent to to missing it gotcha

Danny Ryan: um then we'll open that up as well when we're taking a look at this the point of the P to p real quick

yeah okay it also has the 32 slot bound on the attestation propagation slot range so yeah age not one line nonetheless we will we'll get this backed and try to get a kind of complete view of the necessary changes here it's a pretty important security Improvement so hopefully we can figure out a simple path forward any further comments on this one thank you any other discussion points

great okay thank you everyone take care talk to you all soon thank you thanks guys bye thank you

what's up

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