EIP-4844 Implementers Call #24

Transcript

foreign Welcome to our 24th 4844 call um I guess the main thing uh for today is uh chatting about definite six for teams are at um yeah I had like a separate spec updates agenda's point but I guess we can bundle it all together until and under Dev that six maybe you have to kick us off let's just go over any open issues as part of uh sorry not Barnabas stock

and then we can go over your two PR's kitchen there and then uh any uh client updates well I guess uh yeah so the main yeah the first PR the big change we agreed to on Awkward devs last week was updating the uh blob count to three and six um so I know it was still contentious whatever we wanted to do this on mainnet um but I guess for now just want to agree that like we are including this in the devnet um the pr is still open but oh no sorry yeah the pr that's there is

for the subnets okay sorry my bad the pier is merged I think to the EAP yeah sorry I was like yeah the wrong one okay um yeah yeah okay so this was the subnet one so I guess uh it just got approved we could probably just merge this I'll post a link here so there's that and then there was another one on uh for the engine API which okay no sorry this is done at seven so okay so now that one was the last change um and then seven one two three you also posted about this one but it's merged um what was that one sorry

uh seven one two three was just a clarification uh to how to basically pack uh then um the transaction uh transaction payload in the network payload so basically the transaction so Network payload has four items the first is uh the the normal transaction payload followed by blobs uh commitments and proof and that transaction the normal transaction payload is the original payload that was defined uh on the top of the EIP so people were getting confused how basically that transaction payload was

to be packed and the CIP just clarifies that [Music] okay and so this has already merged in it's not listed explicitly in the specs uh for devnet six but I'm looking at it now does it actually change the semantic or just change the name to clarify right it doesn't change any semantics right here it doesn't change any semantic and it's just a clarification got it okay everything here okay so is there anything you feel is

missing from the devnet 6 spec um beside this PR we just mentioned that's gonna get merged okay if not then uh yeah I guess I'd be curious to hear from the different teams um where they're at in terms of implementing things for the devnet and uh yeah or maybe I guess Barnabas do you want to start with like the current state of restarting them at six and then we can hear from the different teams who maybe aren't already running on the devil yeah sure so the current.net is uh seems to be uh quite healthy uh but this is just a pretty six and we will be

relaunching them at six with the uh three and six uh maximum blobs tomorrow morning so that's the timeline yes and which clients do we uh oh actually yeah uh shower has a question uh why should the subnet count be six rather than the target size of three because there is a maximum of six so in some blocks you know zero one two or three might be sent but in some blocks up to six might be scented so you need the mesh available to send otherwise you'd have to

send multiple blobs on a the same mesh which is not the intent of decoupling does that make sense I'm sorry uh yeah yeah I have another correction which is uh why we have to uh have this uh constants instead of just use the makes stops per block yeah so we have the analog and attestations and we you know the number of decisions events is the

same number of committees but I've actually the needs of the consensus protocol might be different than the needs of the mesh um so for example you can imagine where sending two blobs on per subnet actually is the optimal path given you know the constraints of the mesh even if you doubled The Blob count that said we could have the constant and just map it to so we could have globside cars.net count and map it to the max number of blobs um for the time being to be clear you know this isn't just theoretical like for example with the application subnet count

um I have been considering in light of attestation load ways to kind of map or remap or either have more or less um subnets in relation to committees so again it's something that I think is a nice to have we can just set it to the other constant though right now yeah and so I feel like it should be a tough configuration and we can add the invariant test in the uni test too you know if we want to make them

understand for a while then I'm sorry it doesn't look like a substance to me at the moment right so I would have it as a configuration value and I think having the unit tests that just asserts that these configuration values are the same will help us because for now they're going to be the same and so we'd want to explicitly change that test if we were explicitly changing that relationship um so I think that's okay sounds good to me

okay Enrico you also have a question yeah I was thinking about having those two different values was actually for having two different parameters to play with and it's not the immediate to me that is currently uh the right thing to do is a a rising them in parallel always having them the same because maybe the needs of the mesh is a little bit different by just having more more blobs on the network and maybe you want to lower down the bandwidth uh overhead but still increasing the blobs so I was thinking in the beginning that arising

the maximum to six and leaving the number of uh sublets to four was actually intended so yeah so right now that's not necessary that's not intended um so everyone realized all the blobs so uh having separate meshes and separate Pathways per blob is the default intent unless we had indication that reusing one of the meshes or reusing some of the meshes for repeat blobs that made sense but by default we want them on separate meshes so by default these values will be the same but

having those configuration values slightly separate so that we can we can adjust them if we want to I think makes sense yeah just thinking about the edge case where we want to have let's say 64 blobs so at this point do we really want to have litigated 64 subnets I'm just having let's say eight at that point or 16 and then reuse subnets for multiple blobs yeah and that's why the configuration values are separate so that we can do that um when xiaoi says she wants to add a test to the invariance it's because by default we expect these things to be equal and so we want to catch like the error we had with the release the other

day by default and in the event that we do change it then that would force us to have to change the test because we're no longer using that invariant are we do we want to do a hot fix on this release or what so I missed the beginning yeah are we intending to have this on devnet6 I think it would make sense

I'm sorry I think it doesn't change the test Vector at all so very quick hard things maybe just include this Pia and focal from Master branch okay that's cool anything else on the specs if not um so Barnabas you shared the uh Fork

one uh for devot six so we have teku load star Lighthouse basically get better mine ethereum.js which means we're missing Nimbus prism and Aragon um I guess I'd be curious to start to hear from those teams if you have any updates or uh sort of expected timelines on when you think you can join the devnet so we're working on towards more like production quality code so everything is taking like slower now I mean we can participate in deafness like today but we kind of want to make the code looks uh more more have more production gray before we join so our timeline is like

uh one to two weeks but yeah feel free to start without us I mean at the same time we can also try a hacky Branch to join us well I don't feel very strongly either way so let me talk to my team and I will get back to you guys so yeah we can start on that yeah for Aragon I haven't had a lot of time to update the fork however I am working with others on the I don't know if Andrew's in the call um to start up streaming some of that um my goal anyway was to participate with the Aragon team on the main line on the mainline Branch if at all possible but we're a little bit behind on that uh yeah I am on the call and uh yeah we

we um so uh Roberto and kairat and myself are working on some bits and pieces so we still um have to switch transactions to ROP and then also just just double check that all the small um changes and are implemented and there are no missing bits I reckon it will take a couple of weeks and I I expect that's probably more like definite seven than you'd be joining is that right uh right yeah

cool and then uh Nimbus I think is the other one yeah I'm here um yeah Nimbus I guess we could so still the big missing thing we have is is block proposals um that's made some progress I have a PR that gets us part of the way that's up right now um I think if we want to join before proposals like we did for the previous devnet then we'll be good sometime this week There's a few just small I mean we've mostly tracked all the other changes um so we'd be ready sometime this week I'd I'd want to say well to be safe end of the week but maybe before um so we can do that and then and then add proposals later if

but I don't have a strong feeling as to whether we wait and join with proposals which would push that out to the following week um or if Barnabas if you want to have everyone join the can with or without proposals then we can do that later yeah I would I would push for that uh I would want every clients as possible to join this web net and then you can figure out the proposal later cool okay for finalization so I'm not really worried about this just gonna assign the evaluator keys to different clients

anything else on the devnet or client implementation and if not they might be worth uh yeah reopening up the conversation around the blob count I know thank God you ran some other tests this weekend as well um and we have some time so but yeah before we do that we we would still want to hear from those of them guess possibly for their books all right okay yeah yes yes okay uh is there anyone from base 2 I don't think there's anyone from base you on

oh sorry sorry Siri went crazy on my computer um okay I don't think there's anyone from Basu uh Marius do you have a view on can you give an update on get or Roberto perhaps yeah so we're following but we've I know that we our conversion has a bunch of bugs one of them is that we probably will fail once the precon pile is called um so because we haven't updated the one one dependency yet yeah and I'm also not sure if we can

actually create blogs and some of the engine API changes are not implemented yet um yeah I'm going to take care of that tomorrow morning so I should be done by tomorrow awesome thanks I guess yeah any other client teams want to share an update even some of them already on the devnet I wanted to give a smaller business yeah we are currently in the process of the updating the test the engine API test for three and six blocks so if any team wants to test their engine API

changes in any way just reach out and we can run this test for you that's that's it okay nice and uh yeah there's a comment another mine is ready uh for the next level net or so for the relaunch of V6 anyone else changes and also will be ready by tomorrow we'll give the image to one of us awesome yeah Lighthouse will be ready by tomorrow too

is already just need to update subnet count should not be a problem and yeah the Builder Pro is in progress but it's not uh strictly relatable V6 but this is what we are currently working on and yeah sounds good um anyone else okay then I guess um maybe for the blob count uh Democrat do you want to start by giving an

overview of like the last sort of tests you ran and then Marius maybe uh we can then chat about what you would like to see to be convinced that uh three and six is a good Target for mainnet and take it from there uh yep sorry there's a thunderstorm in the background so it might get a bit loud but um yeah this is actually what you've sounded the cleanest in like the past five calls well but wait for it um so uh yeah I um on Alex Stokes of suggestion I um wanted to run more experiments um at 768 kilobytes over this weekend

um so I did a couple more runs we have dashboards for them I had a cursory log so far I think like all looks fine to me I didn't see any um anything uh crazy happen although what did happen was that unfortunately our our end points uh seemed to have sunk over the weekend so they were less reliable um and so like uh the tests were a bit more randomized so while we did hit the right average I think on the second test um it was more like uh alternating between zero and 1.5 megabytes um I guess which is also a good test

um but yeah I looked uh looked Hollow um okay to me as far as I could see there are also some tests which I had to interrupt early because they went too crazy again because of the sinking notes um uh also with very large blocks um yeah so I will send the link to those dashboards around and you can have a look at this as well um okay and I guess yeah Marius do you wanna kind of expand a bit on what you were sharing I don't know cordov's like what what would it take for for you to be confident uh with three six so I had a bit of a thing uh this last couple of

days um and I came to the conclusion I I still don't like it and I would vote against it but I came to the conclusion that it's not really my place to argue um because I'm not a consensus layer developer and um I think the consensus layer deaths they are doing the the the um the propagation if they think that this is fine then they should go for it and it's on them I just want to make clear that this is not that this is not coming back to me um in any way shape or form I I said

whatever what I what I what I wanted to say and I I still think um we should we should go the safe route and then increase it over time um but again it's um it's a decision that the consensus layer people have to have to do and it breaks it's on the consensus layer and not on the experience oh and and but to add to that you know I think that what you want to make sure when consensus layer devs are evaluating this is the interplay between the blob size and the block size that can be impacted by call data right and and the interplay between these two things you know is does exist um and they might not think about that

uh and so I think your arguments are are valid even if you do then say to consensus devs now make your decision um I also I guess just to point out like at least from the last call and subsequent conversations you know I don't I don't think the decision has been made um by the relevant networking experts at the constant flare on Lincolnton Flair um you know I think their thinking about the data thinking about the implications and other things so I

think this should be a continued conversation rather than a fixed point at this point yeah that makes sense anyone else have thoughts or comments you want to share about this and just one thing maybe you would have been nice to have the b2p announcement in before going live with this so having more efficient networking could help in this area so you say the P2P announcement uh messaging

to have a more efficient Network right okay so but you mean is there an answer is there an announcement to be happening or is there just more discussion to happen around refinements to the spec and look specifically on that but looking at the overall uh benefit we could have on that area uh I see a nice and a nice to have before after going live and definitely increase bandwidth usage so we have uh nice ideas and solution there and having them I see the benefit

right so for some context there is uh I guess a working group of people both on Sizzler teams and some discussion with broader the P2P community on various spec enhancements and modifications to handle um to try to reduce deduplication or to do deduplication and a number of other things um I I guess it would be important to figure out what of those are actually viable to ship soon versus ones that are going to take a long time in terms of conversation refinement and testing um do you have an intuition on that or is that something maybe we could talk

about on the next Circle well not that not yet at the moment definitely something to still discuss yeah I know Anton's working on a doc that compiles all the various things um yeah so we should bubble that up once he refines it a bit yeah definitely we rely a lot on Anton because he's on our side is taking care of the that layer around it working so once everything settled down there uh definitely having our networking layer upgraded to reflect those those specs changes and

uh yeah we could also gone sorry we could also have a at least a simulation with uh this iron one message which is the new one to the P2P and try to see how big blogs blocks and a number of blobs are um reflecting our effect in the network at least on the simulation very concerned about the bandwidth or latency right and I suppose if we are picking a number assuming that people think three

six looks safe based off experimental data and showing that in simulations the spec improvements strictly improve things uh then that would be a movement towards strictly making three six safer but there's a lot of little pieces to do between here and there okay anything else on the blood count um just another uh Point has anyone reached out to ethereum on arm for example to see if they have

um data collected for the call data test durations because I'd assume the main affected parties are going to be um smaller nodes and I don't think any of the EF nodes were resource constrained in any way so perhaps it makes sense to also have some insight into their nodes yeah one thing that uh we do have at least the chain data for is things like attestation correctness um inclusion Etc so we have we don't see exactly arrival times but if we don't see a precipitous dip and um you know correctness and things like that we know that at least validator

nodes we're seeing it on time um but I would certainly be down to talk to them or anyone else that has data yep main reason is well there's there's two things here one is that um at least according to a lot of stats um solo validators comprise like 10 15 ish of the network um which means even this change would most likely affect that percentage so even if we do choose three sixes I'm going to take the network down but at least in the past we've always made decisions keeping these 10 15 in mind is there a way we could try to get them

to run I guess even on the devnet it wouldn't really help because yeah I think the devnet ones won't really help just because there's not enough load um they should have some sort of monitoring stack um I can reach out to them and see if we can get the data yeah that would be amazing any any other comments on the blobs so where does it stand right now so I think we should keep

three six for now um that's sort of what we agreed to even at the end of the call that we would at least use it on the devnet um yeah but we're not like not really being that clear we're saying we agreed to it or the devnet but we didn't agree to it for mainnet oh we merged it's all the specs and now we're kind of it's not clear like I don't I don't like that it was merged to all of the specs because now it's just a lot harder and one two months to undo it so I feel like well I guess yeah it'll be as hard what we're going to do but I don't know that we have like the

data or the like confidence to make that call now right right but we're not going to get it after the devnet so it's just like right but we do have data we did run another experiment and people that wanted to look at the data we'll continue to look at the data and think about it I don't know if we can do much better than that other than have a time limit on discussion and data analysis I suppose yeah I agree I think it's just weird this whole situation with the devnet like there's not doing three six on the devnet is not going to help us in any

way and doesn't move us closer to answering this but instead just creates like a lot of noise around what is the actual value I don't understand that statement I mean for one I mean I disagree that it that it gives us no data like I mean like they're just all running on a couple data server data centers like this is not anywhere close to the actual topology of the network so there's not much useful information we're going to get out of dealing with blobs other than like maybe the actual CPU processing of three six blobs being bundled into the block I mean I I disagree that it gives no

data um like I mean I agree that it's not a test under mainnet condition and that is exactly why I ran these experiments because that is the only thing that I can think of that gives us mainnet data if you have something else that you can think of that gives us better data for maina then please suggest it this is the thing that I could think of and I did that right and I think it was a great analysis I'm just saying that we had a weird thing on the lasso cordoves where we kind of backtracked the decision to make it for mainnet but then we still did it for the devnet well it doesn't give us any networking information on the devnet okay but I mean like I kind of disagree with you here because you seem to be suggesting

that uh the default decision is to keep it at 2 4 and I don't know if that's right I mean we just currently don't have a consensus on which of the two it is I mean 2-4 was the original and we didn't agree it wasn't breached in a consensus in my opinion so I'm not sure if if that really is um a valid thing like in my opinion it was reached in the same kind of process so I don't see like how that's any more legitimate than V6 I don't think it is sure okay yeah I mean 2-4 has been around for a lot longer than three six and this is what people have been expecting and I think it's a lot less of

an increase expected that and I have vehemently opposed um at one of this time to be fair 2-4 was put in as something of a placeholder while we were to conduct mainnet experiments right that experiments never happened um so even before the main experience the docker just conducted I was worried if 2-4 was safe um so I feel like we now that we have that and we should be having the conversation as to what the value is um because we we failed to have that conversation at the start of the year because we'd be able to get the data so right I agree I mean that's I mean yeah

that's kind of what I'm saying is that we don't have a great idea for either two four or three six but I don't think that we should continue increasing it before like this conversation resolved so just pushing it forward to three six it's like why we should just resolve the conversation about what the blob element should be and so far I'm you know I'm still waiting to hear what the consensus layer thinks on this so I guess sorry Asgard you had your hands up for a while is there anything you want to add yeah I would just wanted to quickly mention I I did mention each other as well that I think to me it's very important that we distinguish between uh the average case concerns and the attack concerns because I think before Marius

came on to all correct last call the main considerations were always around average case and being able to basically handle the bot side of things and I think people felt very reasonably confident that 36 would at least be realistic enough to to make it the default and then the kind of the concerns for both basically and the more Tech case came in so what if the normal block also gets really big because people basically use the call data and that was just basically not the main considerations of this it's indeed new concern if we cannot address that then I think it makes sense to fall back to 2-4 again but I think it's just too early in this process to say whether or not we we have good ways to address this I think they are really good ideas around uh just suggesting the quality pricing and

their different flavors of this we will do it immediately do we do it in a related way these kind of questions but I given that I think we're still on track to make three six work by addressing these extra additional concerns um but we're not just not there yet but I think again the goal is still to to get it there I think it makes sense to move forward with it with the understanding that so there's things to be proven for us to not revealed by people yeah I I agree you know we might figure out something is actually wrong on the definite and that'll be useful data um I guess uh oh yeah Terence yeah I just want a Charming right it comes up consensus layer feedback it's

kind of a chicken and egg problem because like consensus layer cannot give feedback until we run like three stages or even higher blobs on like a definite test net or under more stressed environment the things we kind of worry about the most is when the blob doesn't arrive on the subnet then because of that then we cannot import the block to four shows then the node has to manually request the blob by root or something like that but that's not something we can tell unless we have like a definite test net under like more stress environment right which might argue for actually running a devnet with either low

resource nodes so that those code paths for retrieving missing things or exercised or running a devnet for a day with you know 816 or something like that um but again that that's less of can the network handle it that's more of can consensus layer clients when you hit these exceptional scenarios exercise the code paths as intended which is a very important thing obviously yeah I think it would be great to run that on a devnet with that type of would it make a difference if it's a shadow fork or is this just a pure CL definite

I don't think that needs traffic it's about finding for for the given Network finding the blob threshold that is like right on the cusp if not higher so that these kind of exceptional code are exercised got it so yeah we can work on just setting up uh um low resource devnet and I think there's a couple of Linux tools we could use to try and simulate some latency delays it won't be perfect but it'll tell us something also I'd make the case that we should

probably use this to find the um not just the optimal but also the highest we're willing to go and use girly slash hosty whatever test match uh exists as the time as the place we're testing it because even though it won't give us the exact same network partition Network split as mean it it's way better than anything one team could spin up and if it doesn't work out so well on the test Nets then we could always scale it back down and we should probably do this earlier in the cycle rather than waiting later on uh Enrico sorry was mute uh yeah just one thing to

add so we like like Terence uh some days some some probably weeks ago mentioned so the the machinery and the logic in the consensus client to to deal with the edge cases where the client sees partial blocks and blobs not completed so those cases uh needs needs data actually to be to be fine-tuned so we have hard-coded couple of deadlines in the code where we when when we don't see stuff up to that time we try to look up by root and it was it are just hard-coded timings based on

uh yeah nothing but uh just uh pure ideas on the air so having those uh data on real usage uh help us to fine-tune those stuff and also try to to see the limits and and put the numbers like it should be for for mainnet sorry yeah I'm not sure I understand the

suggestion sorry oh it's just a comment on the okay needs of data because right there okay yeah fine-tuned yeah so there's essentially exceptional code paths for when you don't get the expected data the expected times and there's tunings and configurations and different things like that and if we're running on only on devnets that get everything on time because they're just easy um we're not going to run in bills so we regardless of mainnet parameter tuning we need to be in test environments that have these you know push them to exercise these code paths so we can tune we can make sure yeah I think we're all in agreement to

be honest I was looking at the logs during the predefinite six and I saw a couple of the situation where these exceptional code paths has been triggered so maybe it's easier than than we think uh once numbers goes up right okay and there's a comment by Perry that's saying Maybe we can also use Gorly as a like the actual Gordy Fork to test a potentially larger value but that does seem it would yeah

yeah it's not something we can do right now but maybe in a few months where we feel like okay we can't have everything ready for me in that the thing that's missing is a true test of knowing which size we're going with then we can try the worst case scenario on girly and I mean a schedule for the application anyway I think if if we went that route we would want to have a clear invalidation criteria like what's the thing that gory will show us that we haven't been able to see that we could use to make a decision before running the experiments yeah I guess

so then you mentioned a couple minutes ago you know like folks are still reviewing the data from the test and like want to look into that more what like when do we think we need to have like a high confidence understanding of the data about this right so I don't mean to imply we have a low confidence of understanding the data um but we do have new data and we do yeah additional people that I want to sit on this right like um you know there are people that I think have high confidence but there's also a number of just the networking folks across teams that are thinking about it

um in terms of when you know if on not the consensus layer call this week but in plus two weeks from then like people if they have concerns voice them um that would be my preference because then we also get uh at least some amount of like devnet work as well right so like if Enrico is uh seeing lots of these what we think are exceptional co-pass exercised over on devnet6 you know that's also going to give us information so I really think that plus two weeks from this Thursday you know we should be able to Bubble up

most of the concerns from the data that we do have yeah I I think that's like a reasonable timeline anyone have lots of concerns about this okay yeah Perry says you know for a successful Denver six launch um agreed so hopefully I mean obviously if it takes longer it takes longer but if things go well then buy the CL call um on June I think it's 29th or 28th or something then we've had time to like have everyone review the data and hopefully run a couple stress tests on

them at six yeah and we can take it from there anything else uh in General on 444 before we wrap up so there was an issue that and record brought up in the last ACD that when based on the spec today when you start a validator from checkpoint sinking you have to backtrack all the blocks before you started doing your duty and the U ads of I mean that's fair that's honest but the ux of that is just that okay now I have to request perhaps like 66

assuming four blocks one of my move to States like 66 GB of blast it's something that worst case before I can start doing anything and then you asked of that it's a little cumbersome and I wonder anyone has more thoughts on this particular issue yeah my thought was that yeah definitely from the ux perspective is is a step backward because now the user are used do the checkpoint sync and then in just a couple of minutes you can start doing stuff and we are going a little bit backward here to say um now you have to

do a similar of of a of a full thing that where where you have to really wait and download a lot of data and if we move to three six the number of the the number of gigabyte goes up even more than 33 gigabytes has been calculated for 24 now so sorry why why is there a worst case we know exactly how much data is going to be right yeah the the target over that time period will be essentially the amount of yeah so if anyone computed that using six blocks per block that's not that can't happen it's not enough ether to pay for that

I do think that the security argument of having all of that data and you know not being able to reorg to a branch that doesn't have that data is very important I do also think that turning the node online and having it be able to operate as it's doing its initial backfill is probably not like a crazy security concession um so I yeah I think that that's okay likely unless it leaks into other modes like reorgs it leaks into other things like like that so you know maybe maybe I think it's it's worth having the

conversation on if that ux is worth preserving um but I would not let that ux allowance like week Beyond that uh mode that said you know it is it is a something of a concession right it is when you get if you have large amounts of the network that are all coming online at once which you know maybe happens because of compounding of another attack uh then you you end up in kind of a security concession Zone um so it's worth thinking about I I don't have a terribly strong opinion I guess something worth thinking about is that okay you trust your RPC provider now to give you the checkpoint state so

you have that trusted assumption right could you it's time to trust assumption to trust the RPC provider to provide you the blobs where that you can also verify it along the way right that's yeah maybe yeah yeah so maybe it's if you you try you trust your checkpoint sync so start get the get the blobs from there and start a testing and then backfill if you have an issue in backfilling abort and then do not allow that assumption to leak beyond the weak subjectivity checkpoint that uh was provided I mean I hear you you're right like the Assumption of correctness is is strong

um I think as long as you do backfill and as long as you don't allow that assumption to leak into other places I think it's probably okay um just a clarification question does the CLS and the El the focus update before the blob data is done uh being fetched during checkpoint sync or um does it wait for having all the blob Data before it sends the focus update

because the El won't start syncing until it sees the focus update I would wait till it has all the blogs it it's a center Fortress or something yeah the block needs to be fully imported so you have to have validated all the blobs to present for choice okay but that's definitely gonna increase think Times by a decent bit because we're gonna have to advancing State then download 68 gigs of data and only then will the El start downloading its couple hundred people so the way checkpoint sync for example in lots of work is you download the state and then you sync the first blog after the state uh

after the checkpoint uh you have seeing the state form and when you get that first block and blobs along with it then El will receive the FCU so you will not download the entire past blocks okay and I'm I'm pretty I'm pretty confident that like the if you say had a week subity State checkpoint sync from two days ago sink forward to head and have the blobs from that point and send your Fortress updated that you're in a pretty good State and you're not really in a degraded security mode you should still backfill because that's the honest

behavior of a network node just as an FYI so the blobs will not be available before a window so you everyone will be forced to do a checkpoint saying once uh the data once the current slot goes beyond four zero nine thick nine six epochs I think from the internet I mean backfill to the uh the network turning point I don't mean anything else

oh yeah well thanks everyone yeah talk to you all on the CL call later this week and um yeah let's get the net six up soon thanks bye see ya thanks bye thank you thanks all right