All Core Devs - Consensus #100

Transcript

foreign [Music] [Music] Jesus

[Music] [Music] [Music] foreign [Music]

Danny Ryan: okay welcome to the call this is consensus layer call 100 also known as AC DC 100 all Cortez consensus um this issue 688 on the PM repo we have some capella items which is primarily our withdrawals upgrade and then 444 items which is our add some data upgrade this will be the last call of the year we'll pick it up I think it's the second week of January getting into it there is a a release it was made yesterday at least since the

specs this is named goat star check it out I know a number of people were looking into test vectors and I believe there were a couple of problems are there were these test Vector release problems I didn't get to catch up this morning or are they um where there's some little client issues or configuration issues chaway or anybody familiar with this is potas on the call okay well if we don't have anything to talk about on those

um I will Circle back with a couple people after and make sure that we're in a good spot um anything else on this release thing okay okay uh Perry wanted to discuss the what would be the first Shanghai chestnuts I know there's been some withdrawals testing it but this will bring kind of the unification of um the larger

features that Perry

Parithosh Jayanthi: yes hi um I've just posted a link in chat with what would I guess be the spec for joining the test net and there's a couple of discussion points there but I'll start with what

um what's already settled um so it's going to be a test net that includes stamp stamp based forking withdrawals warm coinbase push zero limit and meter init code the Test match will start post Genesis and the tools back versions for joining so the El spec as well as say the CL spec and the withdrawals spec version or the commit has been listed in the document um there's a couple of discussion points for example what do we want included in the engine API do we want to version release um what do we not want included we can start with that one I guess and make our way down the list

so

Danny Ryan: there are a couple of things

um pending in the engine API um that coder could not go in like client or Mikhail do you have any perspective on that and if we can maybe cut a pre-release on this soon

Lightclient: I'm happy to cut a pre-release I'm sorry I haven't been keeping as close eye on it and been focused on the eof stuff lately but happy to review some stuff today tomorrow and make a release

Danny Ryan: okay

Parithosh Jayanthi: um so that would also include

um I guess EIP sorry uh PR 314 which is

get pilot which is WTI down one

Danny Ryan: hey somebody's not muted

so

Parithosh Jayanthi: um would that also include three one four which is get payload V2 in Block value format um I know that it was posted about in the interrupt Channel yesterday and I think uh 18 years from Tech Will said he has no issue with it but it would be nice to get consensus from the other CL teams as well

Danny Ryan: the block value comes from the execution

layer correct that's a return value

Parithosh Jayanthi: yes as far as I normally posted a more verbose message about it last week

okay

Danny Ryan: but this this induces more work on their side than the consensus layer yes

Ben Edgington: I think Adrian's point was uh we could just stop that so that they return zero to us all the time just so that the plumbing is in place but uh it doesn't evolve actually returning the the real value from the from the execution engine so it would be work because I have to put the plumbing in but they don't need to do all the work

Anderson

Danny Ryan: yeah I think this is a pretty important component so I would I would like to see

it get in there um I don't know if anyone else has an opinion to Echo here and I guess the zero the zero is uh works fine because if you're not using that boost um then it will be the highest value thing and if you are using web boost you would default to anything that came in from web boost as you already are today so it's it doesn't change anything until you get the the actual value coming in

Jacek Sieka: I think the earlier the better and like the zero idea for whoever uh doesn't have time to to implement it

Danny Ryan: okay um are there any

I'm not I've been following this issue are there any like major unknowns other than the zero value being okay here and getting this

merged

Marius van der Wijden: can we just return the normal value if we have it already

Danny Ryan: certainly

Marius van der Wijden: okay then I'm fine

okay so

Danny Ryan: uh um I'll Circle back on this uh see if mikhail's around to do kind of a final review and put this in whatever ends up being that pre-release the next day or two

yeah

Parithosh Jayanthi: awesome the next one was PR 146 and pr218 that's um get payload payload bodies method and get payload bodies by range V1 um these rough consensus seems to be that the cl teams don't need this right now so we can just leave it out unless there's a contrarian opinion here

Danny Ryan: okay so yeah the duplication does is being done by some clients through I believe the API um I potentially deduplication might be elevated as important with 4844 so maybe

it's good to consider this in conjunction with 444 and keep withdrawals

moving okay

Parithosh Jayanthi: so it shouldn't be important for this decimal thing um the next one is we wanted to have um just some consensus from the other side uh that the Genesis Jason has Shanghai time as the field just so everyone's using the same key but doesn't really matter but just is it nice to have um and I guess a bigger discussion topic is do we want to include the fork ID logic or not as far as I know Marius wrote up the EIP for that but I'm not sure if the teams want to have it or not for this test net of course

yeah I'd

Danny Ryan: put it as a nice to have but we don't need to put it as a dependency here

Parithosh Jayanthi: um yeah the remaining things are um just a landing on validator set size um so Jim from a test and vouch was saying that spec limit sweep to uh it has a limit at 128k validators so it probably makes sense to have a testament that's bigger than that so we can test this assumption

um the limit is at 16 000 in the universe okay so and it

Parithosh Jayanthi: is anyone has a preference on how big the Test match

should be

larger than that 160. yeah we'll

Parithosh Jayanthi: I guess we'll just try to aim for the same size as a skin tsuki then so roughly like 100k by details and 50 to 60 nodes

yeah

Danny Ryan: to that end um I would recommend once we do have a stable test net to turn off 40 of the validators fifty percent of the validators to um put everyone into a leak uh such that balances go below 32 eighth across the board such

that that's maximum sweep does happen uh that would be there's a an interesting Edge case that will be hard to hit on our public test Nets and would maybe never be hit on mainnet but that we want to test

Parithosh Jayanthi: okay yeah that should be doable um the next one is is we're planning on just setting all validators is ux zero withdrawal potentials and Genesis and then we just um do the BLS change for how many hour we want 0x01.

um the main limitation is that the Genesis tool right now can either do it in either or so all validators at Genesis have to be 0x0 or 0x1 and thought it makes more sense to do 0x0. um is that okay

Danny Ryan: yes if we do in the future it would be nice to have a test net that has some mixed but even mainnet Shadow forks and stuff will do that by default so zero zero and being able to test the change operations makes sense

Parithosh Jayanthi: perfect and the last one is PLS change as an array versus individual um I know that there was some discussion

on the Discord Channel about this but I don't think that was a final decision

Danny Ryan: array in what context

Parithosh Jayanthi: I will have to attack Barnabas on that one

Ben Edgington: this is on the API I guess right we've been discussing whether we because the the spec until recently has been you can pass just a single message change um execution credential change message uh to the API uh and there's been a lot of discussion about being able to pass an array largely because eth do will output an array of Json and then you can feed it straight in um and I think that's been adopted in the API spec now but correct me if I'm wrong but I think that's now been adopted as the standard so we should all

have it at some point

okay this

Danny Ryan: is the beacon API so that you can give a bigger node the message to put into your mempool and gossiped

great but

Parithosh Jayanthi: I guess uh um has the EPA change been implemented on any client yet or I guess this is also something not all clients have to align on right like even if one client accepts it it's enough

Gajinder Singh: yeah lots uh has implemented uh this change so our new image will have it

Parithosh Jayanthi: awesome so we can just submit our arrays to

Worldstar

Barnabas Busa: because it you can also just submit it

through the strategy Beacon so even without any client support it would work

Ben Edgington: yeah that's correct um thank you thank you also Sports an array um now as well

okay perfect awesome

Parithosh Jayanthi: I think that's all the points about the test net then um ex I guess you guys can expect some more Genesis information Etc later this weekend we'll try and aim for Genesis sometime next week um is there some timeline on when clients feel like them already for this or do you think you're testing pre-Christmas is okay

yeah

Danny Ryan: so the big thing was to get this sweet bounded Suite feature in order um which I think I've seen a couple had already implemented before this was even merged and then I think there's PR's open across the board so what's the status or is that going to be relatively done in the next few days or does that need longer okay does anyone think they can't hit a test Net bill next week okay

let Perry know in the event that when they're doing this if your client is not ready but it sounds like I think we're generally a good spot okay thank you Perry thank you marvelous moving on there are a couple of spec items these aren't necessarily Capel spec items they're not related to withdrawals but they are items that um could potentially go in here I know we're a little bit in the late Zone but um both of them are relatively small um the historical batch revamp proposed by

gossic um now over a year ago uh yeah so can you give us the quick on this and discuss the kind of relative complexity here

and um I don't know I guess

Jacek Sieka: um yeah I mean I think we had a brief discussion like a month ago and there were no real objections raised uh against the current version but um there weren't any strong supporters either I'd say um since then I've had a few comments about it which were which were supportive

um the complexity is uh minimal I'd say like the biggest impact is that we change the beacon state shape so if we want to stick this into the current test then it's kind of messy or we have to scramble on the other hand changing the logic is ridiculously simple because it just uh moves one hashtri function to another place more or less or maybe yeah something like this um I don't really know what else to say it's a good time to put it in there it was a good time a year ago as well but

um I think we've sorted out the complexity of the upgrade by saying that maybe we'll um maybe we'll provide a backwards compatibility patch in the next hard fork or maybe not that this PR is completely independent of whether we want to do that or not um other than that it's it's a nice PR

oud

Danny Ryan: okay so if this did go in this would be a release in the next couple of weeks and this would be an additional change that would go into test Nets in January um

it is very small it has been pending um the remind me the primary is this to just this reduces the um proof length to get into either state or block or provides direct access

now

Jacek Sieka: yeah the most important thing it does is that when you have a block or rather when you have 8 000 blocks and you want to be able to tell whether they belong to a state that you have or not um currently you need to compute the state

routes and you need to compute the state routes because we might have empty slots and those empty slots have unique State routes that are not present anywhere else in the protocol so in order to verify blocks today that they belong to the state you have to basically run the state transition function and uh Advance the state one by one on the off chance that you hit an empty slot with this change you can just take it dozen blocks hash them together and you can verify that they belong to a state all the way back to Genesis so this is great for uh you know archive nodes that just store the data long term

they can quickly prove that a block was part of the state and therefore they can decide to store the data um on that alone without any more processing

Danny Ryan: okay I need some engineering perspective on getting this over the line

I

Ben Edgington: think our techie view is um slight caution about the unbounded

state growth but it it just on principle I mean it is um small

Danny Ryan: is that that's that's that exists today

Ben Edgington: it does exist today but yeah it doesn't um I don't know if this adds more or if it replaces the existing um State growth but just on on principle caution about that but I don't think we see any any difficulty in implementing it and if we were to decide today to implement it it could go into Shanghai compeller as far as we're concerned uh we like the kind of two-phase um start the new scheme at the at the upgrade and then later come back and potentially um make it um Backward Compatible by converting the existing state just freezing existing

for now and later in a further upgrade um convert that to the the new format but yeah decoupling that is good

enough gotcha

Jacek Sieka: so the state growth the state growth today from the historical root Fields is 10 kilobytes per year after the change it's 20 kilobytes per year it's double because we store um yeah both uh block root group and a state route

Danny Ryan: right and the you know this is what's called like a double batch Merkel accumulator which is does grow Unbound but in a very small and

at least years ago decidable decided as fine way for the accesses that it provides but yeah so I don't think it changes the fundamental assumption here by that 2X

Micah Zoltu: is that 10 kilobytes 20 kilobytes including all of the structured data like uh like in practice that's 10 or 20 kilobytes or is that just in theory

you can

Jacek Sieka: practice okay I mean there's a real relevant there are two relevant developments here right uh

one is uh the portal Network and they will be very happy when this goes in um they every portal now that runs as a seed node needs to know that talks belong to data to a chain that it's allowing onto the network so that we don't get spam um the other thing is that both Techo and Nimbus at least will start pruning blocks very soon um so the lock history will not be available from the b2p anymore um as per the spec where we only need to keep what is it five months of block data around so since these features are going in

having a way of verifying this this archival data is is very nice like there are other ways as well but they're just more expensive messy slow and so on so this is this is a cheap change for a nice enabling feature for those use cases

Danny Ryan: yeah I don't I don't want to block this given the we kind of wanted a year ago and we pushed it out and that we kind of want it now or more than kind of wanted especially with the the use cases here but uh so I I'm leaving it to others too uh

pushback if this is not should not go in now show away on the order of what do you expect the kind of testing overhead to get this PR in order are you speaking I can't hear you can anyone

here show away no another Mike Dow situation

Danny Ryan: two days she says

um right right okay then what we're going to do is spend some time over the next five working days to kind of clean up the uh two days of summer um add the tests ensure the existing tests work um and circle around with client teams for a final thumbs up if we generally do not have any sense at that point we will put this in the next release January test notes um but we will give teams

this next week to um speak up here There's issues about complexity or anything else cool great um I do have this next item also under capella because I believe that's the spec that it's built off of right now although um it could go anywhere depending on what's decided so baton um there's can you give us the download

on this item the El block header versus the CLS execution payload header fields and the issue at hand

Etan Kissling: uh yes can you hear me

Danny Ryan: yes

Etan Kissling: okay so I just uh I have one slide I can try to put it in into the doesn't seem that it works but I have linked it so that's all right um in the execution layer we have a structure called The Block header and in the consensus layer we have a sort of matching structure called

the execution payload header and most of the El block header can be reconstructed from the execution payload header but there are two fields that are encoded in a different way um and that's for the two Fields where the CL [Music] um keeps separate structures for the transactions and for the withdrawals and then puts them into a list because for those on the CL we have SSC format and on the execution layer we have the hexary tree format so a use case here is for light clients

such as wallets smart contracts if they want to for example prove that a certain transaction exists or that a certain withdrawal exists they get the proof from the East API the execution API but they don't have the matching hexary try route so they cannot verify those roots right now those two use cases are not that popular the most popular One is using the state route which is luckily in the correct format but we will have this problem every time there is a new field that is sort of a list so it's sort of important that we decide how we want to

tackle them and I see two options basically one of them could be that we extend the engine API so that we get those hexa retry routes from the El for transactions and withdrawals and also store them as part of the header the same way how we already store the stage root and to receive through or the other way around that we change the El so that it stores SSC tree roots instead of the hexury trial routes for transactions and withdrawals both of these approaches would make the

same data available in the same encoding for both El and cl there are also some mixed approaches for example instead of exposing The hexary Roots inside the execution payload header they could be recomputed by the CL um if they are not using split block storage they still have the transactions and withdrawals so technically they got they Could reconstruct them but um overall the trend seems to be to move away from hexary tries and rlp format so it would be a big step backwards if we require every cl to

support verifying and creating those Legacy formats um again so yeah that's what I wanted to bring up to discussion here

Danny Ryan: and the light clients just essentially having proofs to into the execution header does that is that not sufficient

Etan Kissling: yes but um it doesn't like currently the execution header um cannot be reconstructed from the execution payload header and what you

get um over the CL light client product called this the execution payload header because that's the only thing that is signed by the sync committee so um if you only get that one you would have to query the network a second time to get the El block header and basically doubling the amount of network traffic by hitting the nodes again while before you could just follow the gossip and get the latest execution payload header like passively you you don't need to request anything actively assume

and another use case is if you if you want to confirm that two execution payloads or El blocks um are part of the same linear history you need to be able to compute their block hashes so that you can see that one of the block hashes is referred to by a different parent hash and right now you cannot verify those block hashes either I mean that's a minor problem because like client protocol trusts the sync committee but yeah it's another issue if this is used in different contexts

so

Danny Ryan: specifically this is to add this adds

two fields to The Exchange execution payload header and the execution payload so they retain the same um root and same shape

exactly um four

Etan Kissling: bytes to each block it's about 150 megabytes a year um of extra data

yeah

Danny Ryan: and the engine API would need to respond but these two Fields additional to the um a couple like the the block hash that I think is also responded in there right now so it's it's a change both to

the structure of the sealed data and the engine API which puts a little bit of requirement on the execution layer to return those but it has those values regardless

Etan Kissling: yes um payload would provide those two additional fields and new new payload would then verify that the computed values match those that are provided or alternatively in the El we could also use the SSC format and it would also be the same data in both

Words

Danny Ryan: which would be a much deeper change to the application layer tooling

and other things that use these right

Etan Kissling: I mean as I said transactions withdrawals they are not the most important use cases because the challenge there is knowing if a transaction is actually in a block that's relevant for you but then we will have this exact same problem with every single array that is being added um so the change on the application would be that it needs to um do the extra Network to hit the network again to fetch the yield block header and for like a reason that's not really technical

Danny Ryan: uh any input from teams on this both in

the context of doing it in general and also doing it in the next upgrade

have

Ben Edgington: we decided which one we're doing um either to change the execution side to SSE or change engine API to return these things I wasn't clear that we'd search on

one

Danny Ryan: my my intuition is it's a deeper Rippling change to change in the execution layer but we will probably need more input there I mean my my gut is that we're not in a

place to make this decision for capella um even though it might be nice to have and that this needs to be a deeper conversation across the layers to find the right solution here um but I am willing to hear otherwise where is this conversation happening and where where's like a succinct place for it to happen after this call

Etan Kissling: the pr 3078 currently has the proposal to put it into the payload and I think that's the most canonical one to proceed discussions

Danny Ryan: okay and so far it seems like there's been so good back and forth to new and Alex but not a lot of other input here um uh there's a couple people I I think this is something to get right we need to be talking the execution layer as well um so it would be good to get some input weight in there um and the next call for the execution layers on until January so I think we

should pick it up then okay anything else on this one four eight four four Xiao a protocol upgrade name and suggestions so your mic might not work okay so um seems to be generally agreed upon on all core devs and I believe on this call as well that's 4844 would be going into the

next upgrade after Shanghai cappella uh chappella I don't know we have the unified naming yet um and support before right now is just a kind of like feature inside of the consensus specs and it's probably time to begin constructing the next upgrade holistically um as a set of features uh so this would need a a name we need a star name we need a star name that starts with d uh Proto did suggest hey d-u-b-h-e um This is My Strong preference to the star named after capella it's the traditional

such formal name of alpha or statement joyous also known as the Big Dipper and Great Bear the ideal name to close to Proto's opinion a bear Market with um lasts for the A and B names I think we did a public poll or c I put a placeholder and that seems to be the name um shall we should we do a poll is this something we can do over the next couple of weeks we can't hear you I apologize but if you speak in the chat I will say what you say to Charlotte I feel that people

generally agree I agreed to keep using Defcon city names for El and started for seal but we might need to choose a better name to describe the hard Fork when we were talking to the media later right um agreed media and otherwise uh I think in Tim bako's magician thread there's a number of proposals I believe on how to handle the fact that we have two names I think there's uh some people are something I'm trying to talk um maybe smashing their names together when the forks are at

but TBD Barnabas I do not know nor will I claim to have a good proposal but um in terms of what do we do in Dead pen city names run up host more devcoms but check out the magician's thread I do think barring some great realization and change we will need a d name regardless so let's Maybe pop up a community poll like we did in the past and uh anchor on that D name okay so shall we would like to check one our CL people happy with star name

with the specific starting or any ideas other than dub a if not I can see for Community feedback after the call um any other suggestions deneb is that a is that a star name okay shall we if you can handle

this out glucose yes it's astounding okay

Danny Ryan: well we have two contenders now um shall we if you can take charge on this one and figure out what this D name will be with the help of devs and community that would be excellent

a little bit

Barnabas Busa: just possible to have one instead of two

I understand

Danny Ryan: one star name or one name

Barnabas Busa: yeah just just one because right now

it's also a bit very confusing for the community that the Shanghai and then there's

the capella and yeah I don't wanna

Marius van der Wijden: I would also like to go into a world with unified Focus between el and seal and my suggestion would be to drop the ER name and only go with the CEO naming scheme but I think that's a discussion for a different day

Danny Ryan: yeah I would please ask you to check out the magician's thread and if you have a proposal to um put it there uh I the fact that these things can upgrade and might upgrade independently is

definitely an argument for two names uh although often they might be upgraded together they're starting with one name maybe there's a compromise here foreign something on our end um and let's keep moving forward with the Stars until something else is yelled about on those magicians

speaking

Jacek Sieka: about that uh did we decide what to do with the sharding fork because we do have some constant column charting something or at least we did a

few weeks ago and they happen to coincide with EAP uh 4844 in the first attempt which made a mess not not a big mess a small mess

Danny Ryan: are you talking about

it's like shouting forkeepak and something like this

Danny Ryan: right which is would be kind of an experimental feature

Jacek Sieka: yeah exactly and it had like Fork version four which is pretty close

Danny Ryan: um placeholder and experimental and

shouldn't have an impact on what we're doing here but it would definitely that's kind of like for it before and that it's just a feature name rather than a fork name but do your proposal on what to do with that kind of experimental feature name

Jacek Sieka: uh we could just give them high versions I mean the thing that happens is that they end up in some databases and then when people upgrade uh and forget to wipe their databases you get like these funkier errors when they're reading them it's just a support issue it's not a serious issue it's just if they have like High versions or 4844 could have as its

version 4844 until it's actually included somewhere

Danny Ryan: right that's what we're usually convenience features that are not scheduled for Forks should have certain configuration values that make sure that they are not uh dangerous or conflict with real things in the future

Jacek Sieka: exactly

Danny Ryan: yeah I think that's pretty reasonable um definitely on new features that are built out we should be pushing that direction and we could do a revamp on this sharding feature although I expect the whole thing would be will be reworked

before it's actually utilized okay says the sharding port version was deleted from presets and configs um which is also something we should be careful about just experimental things making it into what ended up being Mainline configurations okay uh there's this issue that we I wanted to make a decision on today data availability on historic blocks I

think the name of um the PR's consider old finalized data available question mark um I believe that the moderate consensus on this is to be on the pruning window if you haven't already checked data availability on some block that you assume that is dataville available is false would be the uh the conclusion here um the this is certainly safer this does not really change the safety

uh or the ux assumption that it's not safe to be sinking from outside of a few weeks window um due to weak subjectivity uh and I believe that this reduces the potential complexity here certainly reduces it compared to having an on down window if things are not finalized um the alternative the two Alternatives is do you have an Unbound window if you're not finalizing uh so you can do data availability checks which has clear impact on node requirements and times and openality and the alternative from there is to instead of assume false you assume true

um which then does allow you to kind of switch between these branches but then has especially an educated security scenarios some issues where for example a uh malicious majority could potentially get you to switch after a time no finality to a uh finalized chain that you then don't check data availability on uh which you know especially if you had collusion with an L2 or something like that could have sash for security implications I think one thing to note is that this 18 window in almost all scenarios we expect if things weren't finalizing it's because

of some technical issue or even if not a technical issue social consensus would likely jump in um so this is really like the edge case of the edge case where um something could not be fixed or there could not be social consensus due to some reason um and this window is hit so very important Edge case but um almost very unlikely to be seen um in the wild Micah

isn't uh they were

Micah Zoltu: missing something but isn't this thing you're calling Edge case and if an attacker attacks the network and is willing to just leak out

like because they felt the attack was was more valuable we would not step in to fix it we wouldn't change anything we would just let them leak out right for 18 uh how long long it takes the week out is that correct

Danny Ryan: that does seem likely right so in that case this may be one of the more practical scenarios that it could happen

Micah Zoltu: yeah so I feel like that's the one we should be focusing on not the the case where there's like a bug that we have to fix because like you said in those cases we just we'll deal with that you know socially um whereas if there actually is an attack we want to let the system self-heal from it the way it's designed to so I feel like that's the case we should be thinking about which I think is still okay in this case

Danny Ryan: yeah and to be clear if your node's online you would on the branches that you were following have done data availability checks you know it's it's a matter of something either you weren't online and are trying to check things past the spinality window or something past that window a depth of fork is revealed you know past an 18-day window and known penalty and you at that point would say well I can't tell if that data is available and I wouldn't switch in the in the return false suggestion foreign I am I think that we should go with false

I would like to hear any opinions uh else otherwise

uh well I

Sean Anderson: I think false is maybe the better option because this is such a like education Edge case um but I guess the other side of it would be like I don't really understand how you would like resync in this Edge case um it seems like

if any blocks past 18 days we are unavailable if we're ever past 18 days with finality like I don't really understand what recovery would look like so it seems like it might be more difficult yeah so weak subjectivity though isn't a checkpoint per week subject to be always finalized like we we don't have a mechanism for like starting at an unfinalized point and populating like four Choice backwards to a finalized point that makes sense

Danny Ryan: well the the fine finality in that case right because if I say this is this is certainly in my canonical

chain regardless of whether any validators are refinalized it in terms of like bringing a state in a block that's essentially what you're telling the node is that this is finalized so I would imagine I I'm not John are you stating that if I say there wasn't final finality for two weeks but I got a block from a week ago um and I gave it a block in a state and I said hey this is my week subativity checkpoint um would that not be able to be processed into lighthouse

Sean Anderson: um I'm I'm not sure maybe I should play on with that let's see if it works um yeah I I don't feel like against

um saying this is false I'm just thinking that maybe whatever is simpler for recovering from this scenario is worth doing but I I don't know I haven't thought it through

until I

Micah Zoltu: I wonder if clients should be internally tracking the block they were given as The Trusted sync Point as functionally final internally like even though it's not even if it's not final externally like you never reward past this thing that we got from a trusted external source

Danny Ryan: I think that's I mean it's almost certainly what is done right pretty much the statement is this isn't my canonical chain

Micah Zoltu: um

I agree it's what should be done uh would be good to verify that the clients are actually treating it that way because one can imagine you you say you give a block that's like you know very near head like three blocks back or something like that and you say I want to sink to this chain um but then you connect up and uh maybe it's right around to fork or something like that and you connect up and then your client decides oh wait I say something else that's up here that everybody is saying is the right one I should switch yeah you're right I feel like you're definitely not switch in that scenario

Danny Ryan: you're right and that that it's unclear how clients would be defined in that scenario because they would take that state they would potentially load what

is red to be finalized from that state rather than loading that state into the finality position

Jacek Sieka: we keep a separate Fanatics not for what the checkpoint sync uh what checkpoint sync the user loaded and we never revert that in any direction or rather we update it along that history but uh right we would never switch and it's I think we even put it in you know like the rest API queries we don't respond with the finalized Epoch from within the State field

but rather use

right the checkpoint if you just I would argue is correct Behavior but sorry come on

Jacek Sieka: yeah just like the moment that you start your client with a checkpoint sync the checkpoint is what you get in in all the apis right it's not what it's not a finalized Epoch that exists in that checkpoint state which is presumably usually like to rebooks um earlier

oh interesting so you're

Micah Zoltu: actually when when a user hits the RPC you're telling them this is the finalized thing even though consensus doesn't say it's

finalized but this client says it's finalized is that accurate

Danny Ryan: it's kind of like if if you were at Genesis and you hadn't finalized anything past Genesis you would say Genesis is finalized regardless of what that Genesis State said

Micah Zoltu: right it just means

to say a negative number so it's not quite

Micah Zoltu: it means hypothetically you could have two clients that are following the same chain they have the same head but they disagree on what the finalized block is because one of them may have a faux finality block that they because they checkpoint synced whereas the other one has a finale block from to epics prior and they would agree otherwise on

everything

Jacek Sieka: yes

yeah

Danny Ryan: it seems so okay okay what I would like to do is get this merged so that we at least have the edge case result and in the event that this induces some sort of terrible terrible engineering costs or unexpected ux issue beyond what we've been discussing then we can continue the conversation in January as this is kind

of an edge case of edge cases so we can spend a little bit of time resolving it but I'd like to get something into the spec and I think false is the right thing to get into the spec at this point okay great thank you um the no blob available response code error code resource aren't available in the event that you're attempting to get blocks with blobs that are past either

finality depth the greatest of the finality depth report Fork block or the program window um I believe this was generally kind of agreed upon on before calls and in the issue and discussion um that plan does have this up uh it looks good to me this will be merged soon unless there is any issue okay cool

foreign for discussion today excellent um any general discussion points on Research specifications open discussions in general okay thank you very much uh again we will

let me take a quick look at my calendar uh no awkward events next week no consensus layer call on the 29th all core devs starts on the 5th of January and we will be meeting on this call on the 12th of January um keep an eye appealed for the devnet zero I'm not zero relaunching today what is devnet

zero Barnabas uh it's for uh virtual awesome okay and uh yeah it's a internal definite

Barnabas Busa: basically and I'm planning to remember because right now we have a very imbalanced auditor set so I just want to have a more balanced editor set and see if we can get it working before the

public launches

Danny Ryan: cool yeah so keep an eye appealed for uh comms from Perry barn with another from the team um on the Shanghai capella test net likely next week other than that uh everyone have great holidays talk to

you all soon Merry Christmas [Music] foreign

[Music] [Music] foreign [Music] [Music] [Music]

foreign [Music] [Applause] [Music]

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