All Core Devs - Consensus #150

Transcript

[Music]

Alex Stokes: Great. Thanks. Okay, everyone. Today we have consensus layer call 150. Let me grab the agenda here. I'll put it into the chat. So, it's issue 1265 on the PM repo. And yeah, let's go ahead and get in to it. There's a number of things today around Pectra and some other fun stuff.

So to start with Pectra, uh we have DevNet 6 that has launched and yeah, the DevNet looks like it's gone much much better than DevNet 5, which is good to see. Uh would anyone here like to say any more about the status of the DevNet or any updates? Are there any issues we should discuss now? put a link here in the chat uh to Dora. Yeah, DevNet looks good.

Parithosh Jayanthi: Yeah, maybe just um note on one thing that's still uh partially missing on the DevNet. So, we do have some map blocks being produced by the blocks root relay. Uh we're still in the process of setting up the flashbots relay ourselves. Um there were a couple of changes in there that took a bit longer to integrate into our anible stack. Uh but we should have some information probably after the call or early tomorrow. Um and that should close up the me testing issue cycle as well.

Alex Stokes: Okay, great. And we did exercise at least the client pathways with the mock builder. I think I saw a message to that effect. Yeah, exactly.

Parithosh Jayanthi: So, we've already tested with the mock builder and it was fine and we also tested it locally on gotosis and we didn't notice any bugs in itself. Uh, but there was a request to make sure that there's execution requests in the me produced uh blocks as well and that's one thing we should definitely check and we haven't yet.

Alex Stokes: Okay, cool.

Then other than that uh any client issues that we should be aware of or do we want to call DNET 6 uh generally a success says nothing worth discussing which is good to hear. Um I think there are like a few small things just to flag it. Uh on the Discord, I saw that Lighthouse didn't conform to an API, I think. Um which I think is a pretty easy fix, but just something to be aware of.

And what else? So, there was also a question here about the beacon APIs. And let's see, I think this is from Paul. Can we get a more final spec so that we can update the beginning API references? Is Paul on the call here?

Yeah. So just in terms of that um just need to have the effectively the release version so that all the references can be um to the actual electro release rather than alphas or betas at some point. If we're getting close to releasing it'll be good to actually have a release of the spec.

Yeah. Was it a spock or anything?

We just can't cut the release until we have that ideally for the connect. Yeah.

Alex Stokes: Right. Okay. Um Yeah. Well, I mean, generally, I think how we do it is once we feel like the beta series is good to go, then we would cut uh the actual spec for Spectra, which it sounds like we're very close to. Um I don't know if we're quite ready, but we will be soon. Um, so yeah, I can reach out and or follow up on the beacon APIs uh once we're closer to that.

So cool. Um, anything else on the CL side there? I did want to flag uh the 772 m pool on the EL side because it came up other places this week. Um, but yeah, I need to see all things before we move to that.

Mario Vega: I've been working on some tests on the east side. It's um a little bit hard to pin down exactly what we behavior we want to see, but I'm going to try to keep uh the um the expected behavior to like some logical stuff that that is not including um uh transaction that would make the

block invalid and such stuff. But um but yeah, we're working on it. I'm going to be running some tests uh on Hive this this week. If I find anything, I will uh try to ping the the clients with information.

Yep. Okay. Uh these tests are for 7702 or another EIP.

Mario Vega: Yeah, exactly for 772. Uh yeah and as I say the the issues that um I mean this these tests are it's it's tricky to pin down exactly the behavior that we expect from the clients because there's nowhere in the in the specification that says okay you have to reject this this this type for transactions once they they you have another transaction that is not type four or whatever that that kind of

logic is never is not specified anywhere and I think that's fine um but I think uh we can try to still make some tests uh uh even even with the without this this specification. Um if it's not possible, I'm going to I'm going to see if I can find issues anyway. Uh it just means that we might not be able to merge uh tests to to east for example. But yeah, I'm going to try it out to see see what the what what the outcome is. Yep.

Alex Stokes: Okay. Thanks. And yeah, from my understanding, uh, it sounds like EL clients will want some special rules for 7702,

uh, around handling these transactions in the mool. Right now, it sounds like there's partial support. Um, it would be good to hear from different E clients that are on the call uh, how much they're ready for this, but as far as I know, that was kind of the last, uh, big open question for Pectra. Like client says here in the chat, G pending PR.

So like client uh would would this PR basically block a actual release say like a test net release for G?

Lightclient: I think we're a little split on whether it would. Personally, I would really prefer to have this on our test net release. I think it's not great to make the release and then continue iterating on some pretty core pieces of pectra and then make a mainet release that really hasn't had time to sit on the test nets log. Like we're we're closing in on merging this PR.

Uh so should be around next week. I think that the times that were proposed kind of makes sense to us, but yeah, my preference is definitely to have this in before we release.

Alex Stokes: Yeah, that makes sense.

Mario Vega: I would I would encourage other ELS to go into this PR because it has some test cases in it. And I don't I don't I'm not saying that these test cases should apply to the rest of the clients, but it's important to at least think about it. And it's fine if you don't end up with the same logic, but just to think about it, it will be nice uh to have some feedback. Also, please go into the R&D R&D discord into the E testing and just chime in with your testing scenarios that you would like to see

test tested in your in your clients. Yep.

Alex Stokes: Cool. And that does tee us up for the next agenda item here, which is test net fork timing. So there are at least two comments here to address. Uh Tim has some candidates here. Let me just grab the link to this comment so everyone can look at it. And essentially, they're kind of all downstream of when we can get client test net releases out.

So there's a a suggestion if we can do this by February 10th, which I believe is next Monday. Uh then slots for Hleski and Sapoleia and then a plus 30-day mainet slot. Uh and then suggestions for February 13th releases, February 17th releases. The plus 30-day mainet slot here came from another comment uh by Lee Derek, and I guess I'll grab a link as well just so people have it handy. that's here. So yeah, the request was essentially saying like hey you know L2s even applications uh there's been some comments around this as well from say

lido and different staking pools uh essentially people using the L1 want some time similarly time between when we have uh you know our test net progression and mainet and the request was to basically say okay 30 days from the last test net fork uh is when we would set the mainet fork at the earliest. So that's the context for Tim suggestions here. And there's I guess two questions here. First is like do we feel like this 30 30-day buffer is good? Like maybe you know we could pipeline things a bit to have like a shorter amount of time in between test and mainet. Um if not then we have the 30 days here. And then otherwise the big question I think for people today is when they feel comfortable getting client releases out.

And there are a number of comments on the issue. Um, yeah, it might be hard to summarize them all, but it looks like generally either option one or option two in this comment that Tim has. So that would be releases by the 10th or February 13th. It does sound like many people feel February 10th would be a bit aggressive. Uh, does anyone want to chime in for their client?

Sean Anderson: Um, so for Lighthouse, um, I think it would be tough for us to get a release out by the 10th. So we were suggesting the 13th.

Um, we have like that one API fix and we have another performance fix that we want to get in on the test nets.

Alex Stokes: Okay. Then if we go for the 13th. Yeah, there's some other comments in the chat here around the 13th. So yeah, is anyone not okay with the 13th to have test releases. And so to be clear, February 13th, let me just double check my calendar.

I believe that's next ACE. So yeah, one week from now. And yeah, that would mean having uh Hleski and Sapoleia forks for

Peterra by

Tim Beiko: the 13th. Yeah. And just to be clear, the the mainet slots I put there as like a placeholder, but I wouldn't expect us to put this in the release. It was just to show if we wait 30 days, you know, what's the earliest decent mainet slot. Um but so then on next awkward devs we would announce all the client releases and then hopefully by the end of that day if not uh early on the Friday we'll have the blog post out with uh

everyone's releases.

Alex Stokes: Great. Yeah, sounds good to me. And generally people are okay with 13th. So let's do that. So, one week uh be ready by next ACDE. Then Derek here u is touching on the other comments here with the 30-day buffer. How do people feel about this? Um there was another comment by Frederick that from a security perspective, this is uh pretty good.

Um, yeah. Anyone want to try to shorten this or uh do we feel like that's a good amount of time? And maybe just to make this concrete going off the timelines here, releases next Thursday would mean uh mainet slot say on April 8th. So that'd be mainet. Do anyone want to try to be more aggressive with the timeline or do we feel good about that? So Paul has a comment here is depending

on the test net. So this is all assuming that the test nets go well and obviously if there's an issue we'll have to reorient but in the optimistic case we would do the test nets they work great and then we'd move on to mainet 30 days later Tim says on March 6 we pick the slot right

Tim Beiko: so assuming with the schedule like we fork seleia on March the 5th it goes well then all core devs is the next day on the 6th we can agree on the slot assuming everything goes well we can use what I have here already um and that would give people like 31 day or

whatever to um yeah to update

Alex Stokes: yeah that sounds good one question is if that's enough time to assess because it' only be like one Okay.

Tim Beiko: Is there something about this fork that will uniquely take time to find out on Sepia that we wouldn't have seen on Holki?

Alex Stokes: One thing we could imagine is just testing all of the different features and there's a number of them. Um but yeah, not sure how much we want to do like aggressive red teaming on Spolia right at the fork battery.

Tim Beiko: Yeah, I think we should probably test this on Holski in the week before, but like and yeah, 7702, but my sense is if we wait for everyone to be ready to support 7702, we're only going to fork next year. Um, and that's been effectively out. You know, we've had the DevNet since Devcon that people can use. So, I I suspect not everything will have 7702 support on the day of the fork, but it's still better to fork earlier rather than later.

Alex Stokes: Yeah, I agree. So, yeah, I mean, let's do that. Let's say uh what was that? The fifth. And then yeah, we have the call the next day and can make a call there. If we feel yeah, if Alleski is kind of weird or we feel something comes up in the meantime that would want us to wait a little bit to watch the we can do that. But sounds like we should tentatively plan for uh calling mainet then. And yeah, Frederick says, "Yeah, we could always adjust it if we need to." Cool.

Okay, we're so close to Petra. Very exciting. Great. Okay, so CL releases uh in a week and for test nets and yeah, then we'll keep moving along. Any other points on Peekro we should discuss right now? then we will move on. So the next set of items are around peeros scaling the blobs. I think there have been some pretty exciting developments with DevNets there. Uh would anyone be able

to give an update on DevNet 4? I think that's one that launched recently or did launch. I couldn't make the uh breakout this week.

Parithosh Jayanthi: Yeah, I can give an update on that. Um, so we've been doing uh Pas Devet for testing mostly locally and on Curtosis and we've had a few runs running over multiple days and it's been quite good um and stable and we decided uh yesterday to then launch the public DevNet so Pas Devet 4. Uh I've been trying to get that up and running today and I'm close but it might happen again a few hours after this call or so and

I'll post information on the Pass testing channel but essentially it's exactly what we have on gotosis so it should be fine. Great. Amazing.

Alex Stokes: And there were plans to then move to net 5 assuming 4 is good. Uh any blockers there that we should surface right now?

Parithosh Jayanthi: Uh I think the main change is validator custody and we're still figuring out what other changes we want to plan for in DevNet 5, but I think we're still discussing what uh changes would exist there.

Alex Stokes: Great. Well, I'm glad to see progress and yeah, we'll be waiting to see how DNA 4 goes. Okay. Anything else then on PROS for the moment?

Sean Anderson: Uh yeah, so Jimmy asked me to bring up a couple things. Um one was the idea of shifting proof building responsibilities to the transaction center.

Jimmy from Jimmy's point of view is uh important for this so that we could scale the number of blobs in pure past 16. the uh transaction sender would build KZG proofs. Um and cell proofs. Oh, right now I think KZG proofs are built by the transaction sender, but cell proofs are built by CL's. Um and there's a computation bottleneck here. Um and if the transaction sender is computing cell proofs, we can shave off the proof computation time during block proposal.

Um so yeah wanted to raise that and then also wanted to discuss the idea of blob parameter only forks because that's another thing that would allow us to I guess start with a lower blob count on pure and increase it without having to wait for the next hard fork. Right.

Alex Stokes: Yeah. We had discussed uh this proof point at Devcon and I think yeah okay so there's some notes here from Franchesco and yeah I think there were a few options here the current situation is downstream of the fact that we didn't

want to move this computation into the E but especially if it is helpful uh given all the block timings then that's something we can explore for sure. okay. Yeah. And Francesca, when you say they agreed with it then, you mean moving the salt proofs basically into the EL?

Francesco D'Amato: Yeah. I mean, at least whoever was in the breakout room at DevCon, I did not no one raised any objection to that at the time. And then we also talked about it again in the distributed bug building call and same thing. No one had any objection to that.

Alex Stokes: Yeah. I mean, and again, I think the only real argument was just a separation of concerns between EL and CL because it brings a lot of cryptography into the EL that the CL kind of can handle on its own. Um, but yeah, as long as no one feels strongly about that point and this helps, especially scaling, I say we do it. Okay, nice. Thank you. And then the other point on BO forks. Yeah, I think where I am on this is just waiting to see how the dev nets go with pure DOS. And yeah, if we get to a place where we want to start with a lower count than what's theoretically

possible, then something like bo I think would make a lot of sense essent essentially should appear to us with like a smaller number and then just you know as case we do commit to say like you know every few months we bump up the ball count by this amount um and then yeah have the sort of like on rails upgrade pipeline up until whatever we're comfortable with for the pure max. We have had a little time since this BP idea was introduced. Anyone else have has anyone else had any more thoughts about this? Do we generally feel good with the idea?

I'll ask a question. Do we have a target at a time for blobs? Yeah, I think the specifics will kind of depend on how the dead go. So peros itself gives us a 8x sort of theoretical uh upper bound and what I would like is just to ship periods with that number. if for some reason we don't feel comfortable with that then yeah we'll need to find a different option and bo is like a good tool if we need to do something that scales. Uh Dustin, I don't really follow your comment here.

Maybe you're replying to Paul.

Dustin Brody: No. Uh no, sorry. Sorry. I'll clarify the the thing with the scaling is at least my understanding and this is one been one of the tensions for going back I guess a while with the with PTOs. The proposer still has to send enough out or or whoever sends the block out. Somebody has to send all of the I mean whether they be a sufficient number of columns or or or blobs it um that still has to happen and currently pure DOS is set at a factor of two. So you need half the columns um to reconstruct everything uh 64 of the 128 uh which means that this it's the factor of eight still doesn't really um that

can help in certain cases but it doesn't account for like somebody needs to have the bandwidth. Yeah.

Alex Stokes: Yeah. I guess that was another big vertical here was essentially the um yeah question of local block building and I think there's a number of solutions there around how we'd still be able to scale the blobs while preserving some amount of local building. there was this idea of like having some plug in the clients that as a local node you could set the maximum that you want in the event that you know pure in the protocol scales past what you have available for uh your local bandwidth.

So there were diverging opinions on that in the past, but something else to keep on our radar as we move into periods R&D. Anything else on pure? Otherwise, I think we keep training on the devets and hopefully that gives us more information to keep moving forward. Okay, then next on the agenda, so that was

PHOS and then yeah, we had a number of things uh around research spec different things to call out. The first one should be pretty brief, just an announcement around hardware and bandwidth requirements. Uh, so Kevin and others have been working on this EIP, which I would imagine is anformational EIP. I'll grab this link here, but essentially it just uh puts down in text recommendations for node requirements. And yeah, uh, Kev, was there anything to add here? I think mainly the call out was just to take another look at this, uh, PR.

Kev Wedderburn: Uh yeah, I wanted to uh see what people were saying about the max blobs flag that we had in the previous uh ACD uh in uh because uh yeah, once we have max blobs flagged, then we wouldn't need to sort of constrain the network to the bandwidth of local block builders uh who are homestaking.

Alex Stokes: So, does anyone here oppose this idea moving forward with the max wall slot?

I think I put something on the PR just because I'd previously suggested something similar. Um so basically for local block building and um it got met with a bit of resistance but I'm not against the idea generally.

Am I Yeah, I'm

Ahmad Bitar: I'm also not against the idea in general. Uh I'm just like against any trend that uh that has been surfacing a little bit lately about um disregarding uh solar stakers and doing local block building or um not priorizing local block building because it's dying out.

Anyways, I do believe that uh having a resilient network requires that local block building falling back to local block building is always available uh regardless of whatever mechanism And uh if we if if this is something that is planned for for for Perra then then uh then then that uh that maybe is fine. Um but if it is something that is planned for a more aggressive push on blobs uh uh for for Fusaka for example then I would say that we need a more permanent solution to this problem.

something that would still allow solo stakers and home stakers to um participate in in local block building if they had if they ever have to without compromising on their uh uh fees that that they receive from from from blob potential blobs that they can post on on on the on the on this. And uh this is uh yeah uh the that this is why one of the things that I have uh also done in this call I I think you were getting at it later on is I proposed DPS for uh Fusaka. I understand it's not a small uh thing to do or uh that it's an easy to

do uh uh u fork. It's very complex but it could uh be it is a solution to a lot of problems and it also have a lot of advantages u that other uh research and uh uh and incidents have shown us uh before I I wouldn't want to waste more time of everyone's time on this so I'll stop here.

Alex Stokes: Okay, thanks. Uh, Ansgar, you had your hand up, although it just went away.

Ansgar Dietrichs: Yeah, I just I mean I just want to say I I think there are more minimally invasive changes we could make to also retain local buck building capabilities. I put one a sketch of one idea in the chat. Um, I mean, I think EPBS in general seems great. I I'm not convinced we should have it considered even for Fuzaka necessarily just because it seems like too complex but um yeah I don't think that a good argument for it would would be specifically the local building because I think there are much lighter weight solutions for that.

Uh Terrence

Alex Stokes: had a question around the max blobs flag. Have we brought this up in a roll call? Uh it might affect L2s in some sort of way. Yeah. Has has this come up? Does anyone know in roll call? We have another roll call next week so we can bring it up there and then report back. Nice. Yeah, I think running it by L2 is there would be nice. Um Terrence, was there something specific you had in mind?

Terence Tsao: No, it's just today the block pricing is determinative, right? You know exactly what the tom max is. So as a layer two, I can look at the man pool. I can have some pretty uh algorithm. I I can predict the next few slots of the block

price then I can kind of uh batch post uh op optimally right but with this is like I probably do not know who are the validators that's constraining blobs that's proposing in the next epoch because of that the blob pricing may slightly vary in in in some way. I'm I'm not sure this is like a blocker blocker, but it will be nice to let the consumer of the blobs know that. And I think layer two are the biggest consumer so far.

Alex Stokes: Yeah, for sure.

I I guess this isn't like in the average case, it wouldn't really affect L uh L2s, right?

Kev Wedderburn: Because uh most of the uh blocks that are being built are not by local block builders.

Terence Tsao: Yeah, for sure. But you can imagine today we have a finality incident, right? And say today we're missing more than three slots per epoch, then things will change. And I'm I'm saying that the layer 2 should know this basically. Right.

Kev Wedderburn: Right. Okay. I see.

Ahmad Bitar: Hey, quick question you you guys. Um uh so I brought up before about uh like open references or guides um or really just like um data pools, statistic pools, whatever you want to call it in terms of people being able to um uh it's a reference of guidance for something like the uh the block flag I mean excuse me the blob flag that we're discussing. Is there something like that? Like for example, I know that my um bandwidth it only supports like 24 25 megabits per second down or so and whatever. Let's say maybe 25 up. Um this is what would make sense for me to um set my max blob size to be rather than it seems like right now we're like okay perhaps flag will be helpful and it's limiting but

then there's the question of how much knowledge and experience and um info do people have in terms of how to properly set that flag

Kev Wedderburn: right? Uh I agree with this. I think we need something like that in general. Uh essentially what is the maximum amount we can go to for the protocol based on these assumptions. Um so I think we'd need that uh sort of anyways,

Alex Stokes: right? And I think he was asking like if we essentially how would I know as a say solo staker how to set this flag. So the thing is blobs are fixed size. So it should be a pretty straightforward calculation and you know clients can pay out guidance. Uh if you know how much

bandwidth you have locally dedicated to getting blobs out then it should map really directly into some concrete number that would be your max. Then the idea is just as you go to boot up your client you put in that number and then you should be good to go.

Cool. Cool. Um, I

Kev Wedderburn: I'm wondering if I haven't heard from Aragon on this. Uh, is there anyone from Aragon that can say something?

You're

Alex Stokes: just looking for their feedback on

this for the max blobs or for Okay. Is anyone from Caron on the call? I don't see anyone. Okay. Uh, we'll have to reach out some other way like C. Yeah, it would be good to get their input. And right like was referencing. So we did have a PR merge to set PFI for Faka for EIP7732

which is the IP for EBBS. Uh I'll just grab a link here in case anyone wants it. It's 9291 on the IPS repo. And yeah, I don't really want to get into like fusaka fork scorpion today. Uh we should focus on fact before we open that thread in earnest. Uh but yeah, so it is pfied and yeah um I guess just yeah that's a heads up and otherwise uh we do have some time.

So I did want to bring up at least the conversation of these petro retrospectives. Tim started a thread on Ethereum magicians and has been collecting input. There have been a number of really interesting responses. So I would encourage everyone to go read through this thread and there have been a number of client dev responses um at various points here. I don't think we have everyone, but since we do have some time today, if there's any sort of uh early takeaways or points around Pekra and how that might inform how we move forward uh with hard fork planning and implementation, R&D, all of the above.

Uh now would be a good time to get into that. I think a big takeaway that a number of people had was just in terms of scoping being more disciplined around how we actually do this. So, you know, one thing you could imagine is that we basically Oh, yeah. So, like one concrete idea that I kind of like would basically be saying by, you know, fork n uh the scope of n plus1's already set. And then what that means is we don't have to like mix in the concerns of determining a hard fork while we're also building the current hard fork which this is one thing we kind of did with Peterra and it uh seems to lead to distractions.

Uh so that's the feedback I've seen from many people actually and I think it's something we should really consider. Uh I will flag Tim's comment here. It would be nice if we could get all the retros by next week. So, if you're a client team and you're listening, if you could please add your thoughts, uh, and I'll again, I'll direct you to this theory magician's thread to get some more information there. But essentially, yeah, uh, once we have all these, it'd be nice to kind of like go through some summary. I would even suggest taking like one specific uh, ACD and dedicating it just to that. And yeah, then the idea would be to like pull out uh, concrete suggestions for how to improve ACD moving forward. so that we can yeah keep

things smooth and improve the protocol. Any other retrospective points that anyone would like to get into at the moment

Tim Beiko: maybe? Yeah. like uh one as people uh send their rituals. If if we are going to seriously consider like you know uh finalizing the scope of one fork as we start uh or as as we ship it and and as we ship the previous one, sorry, and

then open the door for um for uh the next fork. In practice, this means the scope for Fusaka would be like frozen. And so I think it would be good for client teams to start reflecting on what that implies. Um my sense when I talk with people about this is everyone agrees in the abstract that yes this would be great and then two minutes after they propose an EIP that they obviously want in the fork because it's important. Um and so this is kind of the issue we always run into where um it's yeah like if we want to make this commitment you know right now there's two things in Fusaka and um this means

everything else would go to the next fork and we should you know we're shipping uh Petra in the next uh basically month or two so we should um yeah finalize that

Alex Stokes: right so it you know yeah it played out it would be like essentially going with the CFI PER show we have right or sorry CFI Fusaka that we have right now. Then anything around other EAPs would go into Glsterdam and the idea would be like we can turn on Fusaka and then in parallel perhaps even in some like slightly different forum have the conversations around uh which actually IPs go into clamster.

Łukasz Rozmej: Lash uh one comment from me as a cordv is that it's sometimes hard to judge those EIPs especially on their maturity of a specs etc because sometimes we uh include something or consider something but then it's then changes few times more later and uh that's something good to try to having to come up with some assessment of of specs finality of EIPs and I know you always have last minute changes sometimes But it might be helpful to like to to have this longer uh plan forward. So that's something to consider,

Alex Stokes: right? Yeah, I mean it does seem to be a pretty strict improvement. And yeah, the idea would be to like have fork scooping discussions for the next fork after the current fork. Um obviously as we like get into the R&D process things change but the idea would be to limit the scope of what we're talking about with respect to like these sorts of changes to just a small set and then not also have to bring in a conversation. Oh, what if we did, you know, this new EIP that we have devots for on the side, should that come into this fork? And yeah, the the whole point is just to be more focused. And I have high conviction that more focus will make us move faster.

Yeah, Trent has another comment. Enforcing basically ELS or CL specitions. Yeah, that would definitely help. A big one is testing. So we should be very strict about no EIP possibly or even PFI without test but definitely CFI. Any other preliminary thoughts?

If not, then right uh any client teams who haven't put together a PET retrospective, please try to do so by next week. We'll keep moving there. And otherwise, in the meantime, if you have a few moments, uh take a look at the ETH magicians thread. There's a lot of good content there. Let me grab the agenda over here. What else do we have? Okay. Yeah, Frederick wanted to announce Pekra bug bounty attack. Uh Frederick, would you like to say some words about that?

Yeah. So, usually for the hard works, we add a 2x multiplier to the bug bounty program in order to get more people to basically review the uh the code specific to the uh the hard

fork

um in hopes that we will find issues before they they go live. This time we're doing a bug bounty competition instead with a $2 million with a pool of up to $2 million depending on the findings. And uh we will be launching this after the uh client releases are ready. So I guess sometime after the 13th most likely. Basically what we would like

like our ask is that client teams create this type of one pager type of document which is describing where the various security researchers should look for changes specific to Pectra in their client. Um, this is basically just to make things a bit faster for the security researchers so they can quickly drill down on the code that's in scope of the competition because uh nonpectras code will be out of scope. So please try to find some time to do that.

Um because it will uh mean that security researcher will have a easier time potentially finding issues uh with your client. And on top of that, it would also be good if the if any dependencies that are being used by clients or the protocol uh could do the same. So uh if any dependencies being used have implemented changes specific to PCRA then uh please do the same and uh I think the easiest way to distribute this is probably through the uh R&D discord and you can

send me a private message if you want. I'm uh Frederick on there and then I'll make sure that this is all compiled for the uh for the competition itself. Thanks.

Yeah,

Alex Stokes: great. Uh and when you say I guess yeah, one question would be like where could I go to follow the developments here and just get more information? Uh would there be like a Ethereum.org blog post announcing this after client releases?

Yeah. Yeah, exactly. Yeah, we'll do that on the blog. uh we'll update the bounty.org uh website to point to this competition as well and we'll make some some tweets as well. So we'll try to get

uh get the word out as much as possible. And of course that's also something worth mentioning now that we say it um when we do run the competition obviously if the uh the clients were able to help push the word out. that would also be appreciated because we want as many people as possible to to see that the competition is ongoing and partake in the in the competition to find flaws before hits mainland.

Alex Stokes: Yeah, makes sense. Thank you.

Cool. So, I think that was all we had on the agenda for the day and let me just see if there are any more comments, but I think that's about it otherwise. Yeah. Okay. Anything else Ann would like to bring up? Yeah. Ke you have a get b get blobs question.

Kev Wedderburn: Um, yeah. So, we've added get blobs and I've been getting mixed uh answers about sort of how effective it is. Does anyone sort of have any ideas? Uh cuz it ranges from the proposer or local block builder no longer needs to send out the blobs to

maybe they need to send out half. Um so yeah, I wanted to get some thoughts on get blobs. Oh, pus. Yeah,

Potuz: it's currently very effective. Uh the time that you need to wait for DA availability well for DA now on on blobs is almost zero. Uh it would be much better though if the blocks would be sent earlier than the blobs so that we avoid uh bandwidth waste. But as of now that feature has been reducing the amount of time that you need to wait for for proving uh that the data was available uh to essentially zero on my local node

here.

Kev Wedderburn: Oh, so that means that the yeah so the only bandwidth needed is from the block itself and uh is it worst case now it's like 1 megabyte.

Potuz: The worst case for the block. So blocks are in average now 115k byes. Uh I I do not know what the the worst case is though.

Kev Wedderburn: Okay, I see. Okay. Yeah, that's super helpful. Um I guess then what is the what is the limit on because obviously

we can't just scale to like a million blobs like what is the now bounding the limit on the number of blobs then if it's not the block if it's not the blob it's a

mele it's a mele

Potuz: and this is dependent on how they implement it. So currently it seems that all blobs fit in all memples and Mhm. and your local node will have all of the blobs uh because they are being publish published publicly. Uh but definitely this doesn't scale. So right.

Okay. I see. Yes, but we don't have to like I mean why like it's very clearly easily possible for rollups to just like send their blobs directly to block builders or something like we can still keep the me pool for censorship resistance but does it does every blob transaction have to go through the me pool? No, that's fine. But then the thing is that then the get blob feature that Kev is asking about will not be helpful for anyone, right?

Kev Wedderburn: Oh, I see. Well, I guess if they send it to block builders, are we talking about via some MEB boost based strategy? Um, because bandwidth, I guess, is no longer an issue in that case either.

Alex Stokes: Well, it could still be on download, right? So, imagine we have like a thousand blobs and maybe you're constrained on download, right?

Kev Wedderburn: Yeah, I think I computed the download. Uh I don't have the numbers up, but yeah. Yeah,

Alex Stokes: I do have something to say. Okay.

Uh I did want to service Onscar's comment here at least the question around yeah having clients send out the block before the blobs. Um cuz yeah like we're saying this get blobs thing doesn't actually really help without this. Um and I think different clients either do blobs before block or maybe some do block before blobs but it would be nice to standardize this. Do clients have a sense of how much of a lift it would be to switch to block before blobs?

I think the builder and the relay sort of like dominate here. So I I don't think it's an issue for clients. Uh I mean we can but I think whatever we do is going to be mostly irrelevant for the network just because most blocks go through relays. Yeah.

Kev Wedderburn: Uh but I think for the average case uh average case size of a block it's okay. like the upload speed uh needed is like 3.2. It's just the worst case is uh not great from what I computed.

Assuming you need to get the block out in, you need to send the block out to eight pairs in two seconds. Go.

Enrico Del Fante: Uh I just want to say that yeah tech is already sending uh blocks before blobs when it's time to publish and essentially we are doing like so we send a block and uh we start blobs sending uh out uh as soon as we get the confirmation that we have successfully sent the block over at least one pier.

This is the current default behavior. Great.

Alex Stokes: Uh there's a comment loadar publishes the blobs before the block. Was there a reason for doing it this way or would be load be interested in doing it the other way?

Enrico Del Fante: I I guess the the block before block is more on the relay side um behavior. Well, this is more on the um solo sticker local building behavior side of the things,

Alex Stokes: right? Which kind of suggests you might

want some way to have the relay customize versus local builder.

Enrico Del Fante: Yeah, maybe makes sense to have maybe options that say depends on who who are you and which part of the network you're playing with. Having one strategy and and the or the other one could be um a good option to have on all clients.

Alex Stokes: Any

other comments or questions? If not, we can go ahead and wrap the call. And everyone is very busy with Peterra. And yeah, if there's nothing else, then client releases, please have those ready by a week from now. So, next ACDE. And yeah, we will get Petra to mainet. I think Tim, you might have had a PSA here. Please move all your picture to us call.

Tim Beiko: Yes. Um, so this way we can finalize the specs.

So yeah,

Alex Stokes: any petra IP authors, uh, please go do that as part of the IP process. to move the status to last And yeah, otherwise I think that's it for the day.

Thanks everyone. Byebye. What's up?

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