All Core Devs - Consensus #151

Transcript

[Music] Is the stream live or can we go live? Okay, thanks. So, hey everyone. Uh, this is consensus layer call 151. I'll drop the agenda here in the chat. It's issue 1280 on the Ethereum PM repo. And yeah, let's go ahead and get started. So, first up, Electra. Uh, let's start with Demnet 6. Um, if there are any open questions there. Let's see. Is Harry here or maybe PK? Yeah. Would you give an update on DevNet 6?

Yep. Um, can you have a quick update? Um, so actually there are no big updates this time which is good. Um, we have updated all the client images to their latest releases they made ready and uh the devnet looks totally stable. We have uh 97% participation. So um yeah, everything looking good. Um the only thing that's open right now is the uh math workflow um which Justin has been heavily working on. Um not sure if Justin is here. Maybe he can give a quick update on that.

Yeah, I'm here. Um, I'm current we've been currently testing the like SSSE workflow with the clients and builders and that boost and that's going really well. Most clients have that. Um, there still is an issue with the builder uh like flashbods are builder. Um, I don't know the status of that, but I know that they're working on it and I hope they get it fixing. Gotcha. Yeah. Just quick uh by the way if any breath people are listening I think they could use some help especially if you have some spare cycles. Uh we had a mapus community call yesterday and this came up and yeah it

sounds like I think it's mostly in the RB builder layer but maybe some interaction between RB builder on top of execution request and state calculation and something in here is a little off right now but otherwise yeah um that is ongoing. Okay, great. Roman says they're on it and otherwise yeah good to hear about the DevNet. Uh yeah, it looks super stable last time I looked at it. Um what else? There was a question about stationation aggregation. I saw some discord com. Oh Mario, just a very quick thing. Uh system contracts are up in Hleski uh Solia and mainet now. But yeah,

for 20 2935 7002 and 70 7251. Yep. Great. Yeah. And the contact addresses are in the EIPs as well if anyone is wondering. So thanks for doing that. Um I did want to touch on this question of attestation aggregation. I saw some messages in Discord that I think I think the algorithms need to be updated a bit given the new format. Is there anything there to discuss or do we feel good about that? Right.

Yeah. Hi. So um yeah, Prism had basically two issues with how we aggregated at the stations for Electra. One of them uh was easy to fix. Um but it was just about uh you know aggregates for one slot not being ordered by uh at the station bit count. So that I think was better than Rico and thank you for that and we we have fixed it already. But the second one is a bit more hardcore in uh and we are not exactly sure how other clients do that. So if someone would could share that would be great. So when we have the atestation pool and we have aggregated stations for one committee and then we see a block coming the block has onchain

attestations that are for multiple committees. And so the way we did that in phase 0 is what we did in phase 0 is we removed all aggregated attestations from our pool that matched atest stations in a block. But now because the block attestation is you know as a a supererset there's no like uh it's hard to match and so because of that we did not remove anything because there was no match between an unchestation and a aggregated station and that's why we have been leaving at the stations for previous slots in the pool and then packing them them again. So my question is how do other other teams decide I mean what is the algorithm for the other

teams to remove uh other stations from a pool when you see a block coming or do you not remove them and then and do something else because we're not sure the what to do exactly any option is kind of feels bad and out of computation etc. go. Yeah. So, how how works now is that we do a conversion of the attestation coming in and we put in the pool the in the in the new format with the committees index and all the attestation bits. So, we are actually able to to compare them um no matter what. So, yeah, it will be

add probably um additional complexity in the algorithm but is fully aware of comparing everything. So at the end we we will we will work as phase zero essentially in this uh regard. Do you have the code already in your uh client for that? Yes. Okay. Thank you. So I will take a look at at what TechU does and um yeah yeah hopefully hopefully something like that can work for us. So thank you.

You're welcome. So I can I can just add one thing. Uh we also add uh a change in our side which is the the easy part mentioned by by Radc which is the sorting capability. Before before Electra we were not all uh thinking about um sorting at the station because the block was uh able to handle 128 at the station. So it was not that relevant to to apply sorting but now is really a big thing and um we added this sorting as already

emerged in in master and deployed on the net 6 and it's looking good even if there there are still uh potential better um sorting of testation cross slots but at least uh within the same within the same slot we we we're doing definitely a better job and should be good enough for for devlets test nets. Sorry. Yeah. One more thing I would like to add which is u general thought is that I think all clients have different algorithms even for packing. So I mean for packing basically and there might be some other bugs. So I expect when we go

to Hollleski there might be a whole lot of difference with you know the participation uh depending on which client is packing. I think we might run into some hopefully not havoc but I think that there will be quite a you know um some unexpected uh blocks in terms of stationation inclusion I think so we should be ready for that in my opinion. Yeah, it's good that we have client diversity here and different algorithm. So at the station that has been left out by one client, maybe it will be included by others which is very very nice. And yeah, I want to echo what also Paul's is saying on on the ch on the chat because now the block print will be completely messed up

because not only because at the station changed the format but also because uh algorithm of me has been updated by by clients, right? But it doesn't it didn't sound like this was just like sort of you know natural variation client to client. It sounded like this was somewhat critical to like the actual efficiency of getting things on chain. Yeah. Yeah. Actually, it was in slightly inefficient on on on previous, but it is becoming can be considered critical now in in electric, right? So, yeah, just flagging this and I assume other clients feel okay about this.

So, yes. Yes. So I'm just thinking is there any way to uh to launch uh a very temporary network which would uh have like a million or or so of validators so we can test u uh this packing thing. So I I know that it's tricky with with large number of validators but maybe ops team could comment is there any way because it would really be great to do a very short uh lived uh network with a huge number of uh validators to test the packing uh thing.

All right, we might just do it live on Hleski. We'll see. Uh Enrique. Yeah. Uh this brings me thinking about uh so one one condition that makes everything a little bit worse is having lagging lagging uh lagging clients actually voting uh for for all the heads. So imagine that you have 50% of nodes correctly following the chain and then the other the other 50% are voting for and and n minus one n minus 2 n minus 3 and actually producing atestation for recently recent recent heads let's say and this could leave us

some atestation on the table still Um yeah so something like that oh just a question are you worried Rico that uh like the half the network is not updated and it's going to be voting for pre pre-fork uh blocks or you're worried that I I was worrying in a situation where the network is not really healthy and some some uh okay yeah so that that is more of an issue the the other one doesn't worry me that that much. But yeah, if we see it, yeah, that that's more of a an actual problem.

So PK says they're preparing a main set of work. Um I guess one question PK is, do you know if that will happen before Hasheski? Um we had some problems with our infrastructure there. Um I'm not fully sure what's the status but as far as I know the notes were sinking last time so should be happen before heski then okay if it does we can take a look there otherwise we'll look at heski and see what happens what is the client distribution on hleski like if this is just a prism issue then it might not be too impactful.

I guess let me ask this. Are we okay just to have Hleski proceed and see what happens here? Okay. Okay. But then yeah, we can definitely look at heski and take a look. Test nets are for testing. Great. And yeah, that was the next topic I wanted to bring up just test net readiness. So many clients had um test net release. Well, I guess all the clients had test net releases for the test nets. I feel like some of these changes that we've been discussing are maybe going to prompt another release

before Bayet. Um, anyone feel like they need to? Well, let me ask this. Do people feel okay with the test net releases they've had given maybe questions or anything that's evolved since? Okay. I'll assume that's be sure to look at this assetation thing on hash key. Okay. Anything else for Repra then next we will turn to Puros.

So perhaps to kick us off uh there's Puros 4. I heard there was an issue with Yeah, maybe someone can explain like is it that everyone is running GU as an EL on that Dubnet? I'm not sure if anyone here made it to the breakout this week. Um, I think the issue was that uh a change needed to be needed to be added to the E and uh Jimmy asked if they could like switch off EOF somehow so that they don't test eof plus uh

Press together. I guess anyone I guess no one here knows anymore. Fair enough. Uh so they haven't working on I I I I don't know anything but maybe I can try. Um, so one thing that we've we kind of discussed in the EUF call is that we would like to add or we would probably like to add another uh transaction type. And um also something that I think came up is whether

uh Pas is going to add another transaction type or reuse the existing transaction type. And um that will kind of inform uh or we kind of need to uh need to organize who's uh who's going to take which number for the transaction types. um that's something that we need to discuss as long as Pas is going to take another transaction type and uh otherwise yeah as as uh Kev already said we need a way of turning off um uh UF on the on the execution layer but

that is very easy so in GU guess it should be like a two line Uh, is this something how can we move forward on the UF thing? Like should we I can go to the next UF breakout and bring this up or perhaps we can discuss on ACT next week. Uh, I think we should discuss on ACD next week. Uh, so let's do that there. And yes, so then there were a few things but we'll go ahead and go to this one. So we had agreed to move the proof computation that was happening in the CL into the E.

Uh with PROS there's like a slightly different set of proofs. Uh the computation is like somewhat heavy and so it helps many timings on the C side to just go ahead and push them to the E. And I think Tim already grabbed the PR here. Yeah, 9378 as a PR to the IPs repo. And this introduces the change. Uh I think let's see here. Yeah, Franchesco also grabbed this document here from Jimmy that explains it a bit more. So I think that was all pretty straightforward. And then the question came up of yeah so the first one is a question of transaction type. As far as I understand, we don't need a new

transaction type. Uh we will need to change the network level wrapper that we have. So the way the you know the pure transaction then would be gossiped would need to accommodate these new proofs. Uh they would be made in the E but we shouldn't need a new transaction type. So I think we're okay on that point that Mario's raised. There was then a question that came up around uh essentially migration and like how this would actually work if we do move the burden of this proof computation to the E.

And there was an idea basically to have the E try to do like a dynamic translation. Say if you get a 444 style transaction, you would then do the recomputation in this new way that we need for puros. And I know we wanted to touch on that today. Um there's hands already. So Terrence and then Daniel. Yeah, I think as far as this go, this also relates to the consumers of the blobs, right? So today they're mostly layer twos. So it may be good to also bring this up in the rob code to see what they think. As far as I know, as far as I read the run, I don't see any concern of like maintaining not having maintain two version meaning that layer

2's currently they do not future sign blobs. They basically will essentially sign that uh dynamically in a way that when the hard for triggers they will just sign a different transaction type. So it doesn't need to be like uh compatible in that sense. But yeah, I think Rob may also be a good revenue to ask like what they think about this issue. Yeah, we could. I mean, what would Okay, so there are at least some eel clients here. Like what would they prefer to do?

And maybe Daniel tease you up. Yeah. So I I I checked basis code and and in our case it would be much easier to add a new transaction type and to duplicate the the existing 48441. Um the reason for this is just that that we have already existing logic to to add and remove transaction types uh for a hard fork. Um but we don't have anything like that to change the definition of a transaction type at a hard fork. So I mean this this this would be more complicated.

Um and then the other thing with the dynamic conversion of the 4844 transaction to the to the new one with the with the cell proofs. I would rather avoid that because it's kind of a dos attack vector. Um because I I think the there were numbers floating around that one of this conversion takes like 150 milliseconds on a average hardware. So if you only send a few transaction to the EL you yeah it it's a lot of computation that needs to be done and we will need to take care of this by adapting the transaction pool which would be quite a lot of work I think

so this is strictly EL's thing speaking so I'm not sure if correct uh call to discuss but could we just do that new wrapper and bump ETH protocol version and then on that new protocol version we would use new rapper would it I not see a problems with that but I'm not sure can we like I think we can distinguish the the two rapper types uh based on the length of the proof anyway so it should be kind of easy to distinguish between them but why not protocol version well we can also do the protocol version. But we historically didn't change the protocol version if we bumped

something within the message. Only if like the over all format of the messages changed but we can do a new protocol version doesn't matter also. Yeah, we should probably discuss this on the on the call. Okay. Any questions then now about this topic? I mean one thing about figuring it out here at least if there's any progress we can make it just lets us move faster with pure Okay. Uh I'll be sure this is on the

agenda for next week and then otherwise uh there was a message here from PK uh devnet 5 of pure is up. Uh there's some links here. So let's see without UF support. Okay great. Um cool. So that's exciting to see. Let's see what else. So, we covered that and this. Okay, I did want to call this out. Jimmy made a pure readiness checklist. I'll grab the link.

Uh, this is super cool to see just to kind of track all the things we kind of need to do. Uh, we've had readiness checklists like this for previous forks. Uh, say like the merge, say like 444 and yeah, there's a list here. So, please take a look. um add a comment if there's something missing. And that being said, this should help us track what we need to do and keep moving forward on POST. Okay. Uh next up was a request to discuss the blob count in FU. Right now I believe the way Puros is written I think the

average ball count is 12 or something and this is quite far from the theoretical maximum that would be 8x on top of pectra. So say that's you know six and nine six would go to like you know 48 about 50 blobs. So then the question is do we want to go ahead and update the PU specs to reflect this now or how do we want to handle this? I believe it's 12 right now essentially just for like early R&D. there's a lot of new infrastructure to deploy and test and you know if we have that on top of say like a much larger blob count it's you know you can imagine complications that get in the way of sort of this primary testing simply

because there's like too many blobs floating around the network on the other hand what could happen is we never change this number uh and just don't get the scale that we could otherwise um bear here you brought this up is there anything else you'd like to Um, no. I mean, I I'm unopinated about whether we should change it immediately or a little bit down the road. I think that just rely on client teams whether if if there's a strong desire to basically first get to stability with a like a low throughput and only then push it a bit more to the limits, then that that would be fine with me. I just think it's important that we figure out a way to pre-commit to that. That's basically the plan because I think in principle the devet should always push as like at least towards the mature side of dev

nets they should always push to as high as we can go and then we can always consider for mainet to roll it out a bit lower than that if we if we have worries about specific like stability things or something. Um so yeah I I I think basically ideally we at least have a plan of like when are we moving the devets over to 48 bobs target throughput. Um, yeah. And I think for context on where that 8X number came from, I don't know if Franchesco's probably also on the call if he'd want to repeat that briefly. Um, yeah, I mean, it's just very napkin math thing of um that if you're the kind of if you're just a full node or a

validator with uh up to eight uh or a node with up to eight validators, you're only downloading um 1/8 of the total data. So that that's basically what it is. So it's just multiplying the actual throughput for pro and yeah that that factor right so one way forward here would be to put up a PR that just has this diff toulu that's some kind of pre-commitment and you know we can navigate that as we go through R&D.

Uh Mark did want to make a comment on BO. And this would be one strategy is to start with say the 12 of Fulu right now and then maybe raise it some but not to this full AEX number that we should be able to get to and uh then have this notion of BPO forks that we've discussed a few times on the call now. Uh that would scale up to this maximum that we think we can support. Was there anything else you wanted to discuss uh with the BPO concept Mark? Yeah. Um I mean just to give a quick definition of BO forks if people have been following it's the idea is just that at a certain epoch and time stamp we do a kind of pseudo hard fork where we change the target blobs and the max blobs and optionally the base fee up update

fraction on the EL and if we could make these parameters much more flexible we can avoid all the boiler plate code that comes with doing a standard hard fork and there's a lot of advantages of this that you know we'll have like mainet data and um be able to optimize um bottlenecks in our implementation um as we kind of adjust the the number the blob count upwards. Um and as far as I can tell, there seems to be sort of two ways that we can do this that we're thinking of. Either um make it like a config change or do some kind of onchain voting mechanism similar to the gas limit. Um I tend to vote towards the config change for now just because

uh it's a lot more code to do like a onchain voting mechanism. Um and it might be a bit early to kind of outsource this you know before these things are stable. Um and it it's it's kind of trivial to rip out the config stuff and pass it over uh later. Um, but basically like I've prototyped this in Reth and um, Lighthouse and it was pretty trivial. Um, and I everyone I've talked to has been in favor of this. Um, I actually don't know of anyone that that doesn't like the idea of being of doing a BPO uh, fork change. Uh, blob parameter only is what BO stands for.

Um, and I just wanted to say that on the CL side, as long as your code has a function like similar to the one I just pasted in chat, um, it's it's a trivial change. Um on the E side, it's already easy because all the ELS's um have implemented EIP7840 and you can make a a quite easy change to that EIP to just basically like instead of having a fork just have a time stamp on which these um parameters are are changeable. So I I guess I would say that I would hope that sooner rather than later we can come to

some kind of consensus that we're going to do this. Um just because it makes the the the code easier. And even if we can't come to consensus on how on whether or not we're doing like an onchain voting mechanism or or we're doing a um just a config change to do this, I would just encourage the consensus clients to have a function in their code um similar to the one that I just pasted in the chat because it makes it easier to implement and most I'm guessing probably already do because it's already a useful function for just the transition from DAB to Electra and from Electra to Fulu. Um, but yeah, also

I wanted to ask like is there anyone that has any arguments as to why we should not do blob parameter only forks? Yeah, I mean one Yeah, Oscar is about to just read your messages. No. Yeah, I mean I would just say I think they're really elegant solution. Basically, if we are find ourselves in a situation where we know that basically with just some future client updates or stability improvements, we can eventually get to a higher throughput number, but like in the initial at the time of the fork, we just haven't been able to get there yet. Then it makes sense. We already know that we have the headroom. So basically that's a really elegant mechanism to to then later on make use of that headroom. But I I think

in my mind it's basically then still a a fallback mechanism. So like ideally we try to like just get to whatever the theoretical maximum throughput we can get with with any new technology change at the time of the fork already. And so this should only be a mechanism we use if if for some reason we basically just don't quite get the end time, right? So you know it's a nice idea and if it's needed we can do it but we should try really hard to not need it in the first place. You also brought up the point of having the blob parameters be yeah say like some quote onchain vote like we do with the gas limit.

This is nice because you would imagine that a validator or yeah I guess a validator can set their own numbers based on their setup. My concern would be that essentially, you know, operators are apathetic or, you know, just not paying as close attention as they could otherwise and then we end up in a place where these numbers don't change when they should. Thank god. Yeah, I would suggest if we do something like that uh that we find, um a better way to set the defaults. Like for example, you could imagine that uh by default your client votes for a value that's actually determined by some smart

contract um where like some I don't know like core deaths vote or something um so that like the default is very easy to change and then people can override this manually if they want. Yeah, it's an interesting idea. Do you think it would be gated on like yeah is this essentially like a core dev multisig controlling the smart contract or something else? Yeah, I mean that would be like one easy way of doing this and I mean that's basically the same as core defs releasing a client but without having the cumbersome process of everyone

installing that new client. So I think it's it's quite elegant if you do something like that. Yeah, I mean that's all well and good. I feel like if it's the same process, it it might be just like less code if we just had a a release with a config change. Um um Tim just asked like why not put out a fork. Um, it's just that there's a lot of boilerplate code that goes with an entirely new fork to change just a couple of parameters and that, you know, it's it's uh not a lot of code to make this these specific parameters flexible with a small config change. Um,

yeah. Oh, so you don't need a fork ID. the the only thing I ran into on the lighthouse side was that um the block size limits um the RPC block size limits right now are a function only of fork ID and they would need to be made a function of not just fork ID but epoch but that's pretty trivial and I think it's worth avoiding all the boiler plate code of a of a whole of a like standard hard fork um to work around that um And the other sort of main reason I would think to do this was is just that we can have like full mainet data like

we could ship with a conservative target and then have full mainet data um as we decide to tune things. Um you know similar to kind of what we did in DAB. We didn't ship DAB with the full capacity because we're increasing it in Spectra. yeah, go go go ahead pus. I suspect that the I haven't looked into this at all, but I suspect that there's more than just the block count per epoch. I mean we presumably the the code that computes the KCG proofs would also change also I mean with all the PRS changes now that also might be changed but uh the current situation if we add

this uh this block parameter only forks I think we will need to like look into the the KCG proof generation code I I prototyped it in lighthouse and wrath and didn't run into anything other than Yeah. So don't depend on the number of plots. So yeah, so if we don't change the position of the first index, it doesn't. Uh I think for us, yeah, I need to I need to think about uh how is it that we do the Merkel proof. Uh it's it's not the KCG proof itself. It's the the proof of inclusion. The Merkel proof of inclusion in the block. What I'm referring to

Because right now that's set to the max possible, but then wouldn't you just pipe that in from say like a config? I do have another question though if we don't have this be like a formal hard fork. So imagine we just go this config route and you basically just downloaded a configuration from your client. Um what happens if only half the network updates or something like this? Like if we don't have a forcing function of consensus then you're going to segregate the network and things break.

I mean that that is what a hard fork does anyway. We have to tell people that they need to update their clients or they'll fork off. What if we're telling them that? Why not just make it a hard fork? Oh, I mean a hard fork is a lot of code. I agree with Mark. Yeah, it's a lot less development effort. So the hard fork would be say Fulu. It would have this infrastructure to support a configuration or some other mechanism and then yeah the idea would just be like a light fork. I don't know if we want a different name for it but

basically it would just be like we would treat it like a hard fork but it wouldn't have all the infrastructure and code that reflects a new hard fork. Interesting. Uh Paul, is the reason that we're focusing on this so much now because we're not confident that we're going to be able to deliver the number of blobs that we want to deliver or should we just be focusing on delivering that data. We won't have mainet data to tune how many blobs or like understand how many blobs we can deliver before we before we push it. I I mean I guess and there's some argument that we might be able to ship it a bit faster if we're more

conservative at first and then we get more data. We can identify bottlenecks in our implementations. We can like be more confident about ship about changing to a higher amount. I would hope that we could have a reasonable level of confidence of shipping at item 16. That's all. So, um, I would have thought something like 32 or 48 wouldn't be impossible. And you know, worst comes to worse, we could tweak things when it goes onto something like Holski, right? So I think the path forward is we

move ahead with pure dust dev now stay with the numbers we have we yeah we just need more data if those look good and we build confidence then we can start pushing them and hopefully we can get confidence in higher numbers and yeah if we can go all the way to the highest we think we can get with pure as specified today then we do that and we're all good. If not, this would be one way to ship faster, ship a bit more blob throughput, and then still have the ability to scale up to this theoretical max down the line. So, this is kind of a fallback, but it might be a very important one. So, it's worth thinking a bit about now.

Any other comments or questions? I think that was all we had for PIDOS today. And maybe a quick PSA, we have been playing around with the timing of the PiOS breakouts. Uh there's one, let's see, I think this week they had one. And I think it's 10 a.m. UTC to accommodate uh Asia time zones. And the idea is to alternate them so that there's one at that time, the next week it's ET clock, so uh 2 p.m. ETC alternate to the other time and you know flipflop back and

forth like this. So just a heads up. Yeah. Potus, I think that was Dra. Did you have something to say or was the the hand from another comment? Oh, sorry. Oh, good. Cool. Okay. So, next up then, uh, Kev wanted to give an update on his work with hardware requirements and the max blobs flag that fell a lot of that.

Uh, yeah. Yeah. So, I spoke to Eric. I don't think Gio's on the call. Uh, and they said they're fine with it. Uh Jimmy also gave more uh some more comments on the Fred uh which to me makes it seem essentially get blobs there's sort of this uh reliance on the time in the mele as well. Um so you might be able you might be able to sort of not need to publish blobs if they've sort of been in the mele for so sort of quite a long time. Uh, I'm not

sure how we'd codify that and it's something we'd need sort of without the max blobs flag anyways. Um, I'm not sure if anyone else wants to comment on that. So like if you have like 64 or 100 blobs that have been in the mele for let's say uh like one day, you just don't need to publish those right when you're when you've created a block. Uh and I think we don't know what the perfect time is when we can say we don't need to publish it.

Um yeah, this is using the get blobs mechanism. And the question is when you make the call and when to publish the blobs along with it versus not, right? I think we just don't we don't know. Uh but this is sort of a bit orthogonal to the max blobs. Right. Um, I don't know if anyone has comments on that. I remember Terrence did some analysis here. I don't know what he ended up doing.

Okay, cool. Uh, I guess if uh there's nothing else then yeah, I'd like to call for a finalization on this. Were there any comments on the PRs? Uh, just the one that Jimmy that I mentioned about Jimmy for get blobs, but I can double check again. Andrea just just a question. Do you have any stats of today how many publishing we going to save uh giving a certain

threshold? Uh could you is your question like how many how much bandwidth you save if you just like don't do the max amount of blobs? Yeah, I mean ho how many of these blobs has been there in the pool for for that long. So we can actually not publishing it, right? Uh so that's related to Jimmy's comment. He did have numbers.

Uh he said the get blobs hit rate was pretty high. Uh miss blobs per minute range from 0 to eight blobs. So, it's like it varies quite a lot. Um, but he uh I don't see any numbers based like based on how long the blob has been in the mele. Does that Oh, does that answer your question?

Yeah. Yeah. Um, I guess we can ping Jimmy in the chat to ask for more details on that. Yeah, I guess I don't quite understand how does the get blobs mechanism relate to the max blobs flag. Uh, so one way, well, I guess if the get blobs me say like sort of a naive scenario where every time you call get blobs, it's like you never need to publish anything. Uh if we was if we was in that scenario then the max blobs flags would just be not needed cuz it wouldn't like it wouldn't matter right doesn't matter how many blobs you have you just sort of you just publish a block and you never

need to sort of publish any blobs at the time when you publish the block. Mhm. Um but yeah it's a bit more uh it depends on how long the blobs have been in the mele. So it's not as easy as as a right but there's still a case where it does matter like I mean like it it would matter like in in practice. Yeah it would matter like if you get the blob and then you immediately need to create a block for example.

All right, that's my point. Like imagine you were not using git blobs or you know a node has chosen not to use it for some reason. Then like you would still want this functionality, right? I didn't know that you could choose not to use it, but yeah, that that would be another scenario. Well, that's a good question for CL's here. Uh do we all mandate this behavior and are we confident in that? I remember there is a PR from Dustin I guess um suggesting removing the optionality of get blobs uh engine API.

This is definitely a step in the direction. Uh yeah, I agree with PUS as well. I replied to Jimmy that I think uh if you just have a bunch of blobs coming into your mele, you need to sort of propagate those pretty quickly before it's your time to propose, for example. Um so it doesn't scale uh as well if there's just a bunch of blobs in the me pool. Oh, I was referring to something else. I was referring to like we want to have enough blobs that all blobs will not be in everyone's mouthful.

To have enough blobs so that all blobs will not be in everyone's I mean if we're relying on every client having every single blob at the time that we're proposing blobs then we're already relying on everyone downloading all blobs right and this is not what we want. want to be in a situation where the mele would be properly blocks, but for validators they still need to Okay, I see. No, no, sorry. I see. Beard death.

Or even beyond that, you know, like because Yeah. Like if if we do have if every node has all the blobs, then we don't need DAS. Yeah. So it's it's it's I think it's it's silly to like focus on these kind of mechanisms today if we want to get rid of them anyways. Um yeah, Jimmy's data was on uh I think you said mainet. So it was using 4844. yeah, there's also the point that we could end up in a place where more blobs are in private impulse versus public and then get blobs doesn't really help there either,

Yeah. But that's not a problem for local blob builders like they don't have access to private blobs anyway. And if if you are have access to private blobs, you're a builder. you you can just propagate the the block the blobs norm right y also just wanted to say about the pos's comment like I mean it's true that yes eventually the mele doesn't scale and we are doing all of the sharding thing on the se because we don't want everyone to download everything but there is I think like still quite a bit of leeway before then just because things in the mele are much more relaxed let's say than in the like they have 12 seconds to to propagate. Um and uh yeah, also like the

the mele is like works by announcing pool uh versus uh the like how the CL works. So I think there's still like quite a lot of room for uh things still working in the mele with all the blobs going through there um at throughput levels that would not work the CL. But yeah, I mean eventually we we that is something that we we need to address regardless. Uh any more comments?

No. Yeah. Um Okay, cool. Uh I guess eels can we can sort of ask the L when they plan to uh implement it um on the ACDE call. Uh the next thing was the hard drive requirements. Uh, did anyone have any comments on that?

Uh, was there a PR or something? I thought we had already merged one version of that. Uh, I don't think so. I think the EIP is still open. Uh the one part that I was just going to bring up is basically going with a Nixo suggestion for determining uh how much someone should spend on hardware. I don't know if Nixo wants to add more uh to that or if anyone had any strong opinions on it.

But we can probably just get market data from the numbers we have, right? Just find machines that match those numbers. Uh the the idea was that uh that we base hardware requirements on when a person uh to be profitable running a validator. So we keep those numbers. My suggestion was under six to 12 months, but I don't know what you landed on with that. So um based on what the current rewards are that we make sure that any validator who is buying recommended hardware can make up the costs of that hardware within 6 to 12 months.

And I mean that's that's really sustainable because if um if liquid staking massively drives down the validator rewards over time then we'll be ending up with lower and lower allowed cost for hardware. Uh, thank did you have did you have a suggestion for also or do you think we should just go with like uh a USD amount?

Yeah, I think we should go with the USD amount. I mean the thing the thing is we're at like four months right now with making up hard hardware costs and so like aiming for 12 months means that uh we have a 3x increase from from here which would not be a problem. Um and if we don't keep it under 12 months then it's never going to be sustainable to run a validator. I see. So the thing is I don't believe that running a validator is the right question for running full nodes like we want full nodes to be run like for other reasons as well. So I don't I don't think that like just a valid data

economics is the right angle and yes like I mean sure ideally we would like it this way but like there's a way like for example there's a high chance we want to do stake targeting at some point and that might well mean almost zero zero returns. Are we then going to say oh now you suddenly have to be able to buy your machine for $50? I don't think so. Um, I guess I don't get on comment caring more about full nodes about any

income. have well yeah of course but to some extent full nodes can have different requirements but I'm just saying like in a way there's always going to be this connection between full node hardware requirements and then staking hardware requirements and so I think the the the bigger bottleneck to me is always to make sure that actually people that want to run a full node but don't actually participate in staking can do so so comfortably and then I think everything every other kind of limit realistic limit on on the network will then come downstream from from that bottleneck.

yeah, I don't think I fully agree with that. I think the requirements between a full node and a validator at least for a CPU are like it's pretty significant, right? Just because a validator doesn't need to uh sorry a full node doesn't need to doesn't have some attestation deadline. So they have the whole slot instead of like just two seconds or something. Right. It's definitely a difference. I'm just saying they also have literally zero income from running a full physically. Um yeah, that's all I want to say.

Okay, I see. Dangra, your comment on liquid staking, do you know how much that drives it down? I don't have any numbers on that. I mean it is uh like essentially we don't know like the e the e economics basically depend on people's try and preference for money and everything but there's no fundamentally reason why we couldn't end up with 100% of each stake eventually and the corresponding um lower returns like the main the main problem is that

liquid staking basically removes almost all costs of staking um because you can keep your token liquid and so on. So if you have enough liquidity then at some point people might be happy to even do it for just 0.5% returns. It's not like something that will happen immediately but um in five to 10 years it's you can well imagine that that happens right and I mean of course this is the wrong forum for like economics like that maybe but like just to briefly mention right like the problem there is that in principle at that point you can't anchor to validator rewards because there is no like basically you could imagine the

scenario of just basically everyone who who holds ETH is basically participating in securing ing the network by delegating or running a node themselves. Um, and so you literally like intrinsically there is no way of making money with that. So you can't basically say the the full node requirement would have to be able to pay it out of the reward because the whole point is that instead you have to think about it as a tax for security. So the question is this is not how how much are the rewards and can they cover it but how much of a tax in this case in terms of like how much you have to pay for your hardware are we willing to place on ETH holders to help secure the network. So basically it's a spectrum. Right now we are still more on the you earn money side. And so

for now as still a reasonable mental model to think of it as like you have to pay out of for it out of your rewards but as we slide more and more towards higher percent of of people staking then it's more and more just a security tax. And so then it's not just not about being able to pay for it out of out of your income. It's about how high of a burden are we willing to place on people that want to participate in Ethereum by holding ETH. And what are the thoughts on using a percentage of how much ETH is staked? So like currently it's 32 percentage of what you mean just like

across the entire supply uh like how much E5 I've staked and then you say that uh other requirements is like let's say for example 10% of that is that a better measurement than using the uh returns well one thing is the ETH price is volatile style. So that might be kind of hairy to think about. And then you do get to issues like Jen Craz are bringing up where we could kind of paint ourselves into a corner where we get to a place where it's like, okay, now the quot hardware budget is much smaller than it should be.

Uh Dunkra, you unmuted as well. Yeah, I mean just the same thing. I think like it's just too volatile. I think like a dollar amount is the thing that's reliable and um just like makes sense. Okay. And if we go over dollar amount, how does that get uh updated if it gets updated? Uh because I think that's what the Nixo and Rasheen were the the motivation behind it. Are we comfortable with where we are right now? of what's in the PR.

Uh, it's currently 1K. Does anyone have issues with that 1K? Well, I I would probably start with the requirements themselves, right? So again, we don't want to get into a place where we're like saying, "Oh, we have to hit this certain dollar target because then we could end up in a place where there just isn't enough capacity to run the protocol." So instead, let's be happy with like ideally we can find hardware numbers we like uh to begin with and then hopefully that's like a reasonable dollar amount and then in terms of changing it, yeah,

I would imagine on some cadence we can go through a similar process like this and just revisit it later. That sounds fine to me. Does anyone have any comments? Uh okay. Uh any comments on the other sort of requirements? We sort of spent a

bunch of time on essentially the block building process and any comments on the full nodes or testers um where testers I will I will surface comment here in the chat that things are changing so rapidly like there's a lot of uncertainty so like the way we deal with that is we just try to do our best right now and just iterate as we go. So yeah, let's not spend too much time just going through every little last detail.

We should do, you know, a good enough job, but let's not get hung up on a lot of things we just simply won't know. Okay, cool. Uh, so yeah, I'd like to call for finalization on this as well. Would you like to merge a week from now?

Yeah, sure. And if you have any final comments, take them to the PR. Cool. I think that was it for today. Anything else anyone would like to bring up? We do have some time.

I think most people are busy with Peterra as I think they should be. Uh you know one obvious next big question is talking about Faka and its scope uh coming up. I was kind of thinking we go through the Petra the Petra retrospective process we had discussed and I think we had agreed we'd kind of try to get final comments in by next week. I'm not sure if there's anything people would like to service now. Otherwise, probably makes sense to focus on PCRA. We do have Pleski coming up on, let's see, it's Monday, whatever day that is, the 24th.

So, February 24th, uh, 9:55 p.m. UTC. So, if there are no other topics for today, let's focus on Petra and I'll see you next time. Byebye. Bye. Heat. Heat.