All Core Devs - Testing #82 (CL Breakout)

Transcript

I think we have a good group of people here now. The next agenda item discussion for the CL would have been thoughts on how range sync should be used in Geth. Nico, would you like to talk some about this? >> So, what I wrote in the on Discord was if we even want to completely get rid of by range. I guess it's more of an implementation detail how you want to implement range sync. So, my idea at least in load side discussed this with Cayman during in the row as well is that we basically only sync blocks by range and then data columns and payloads we only sync them once we know the canonical state of

the blocks we synced. So, you would just always look one epoch back and then sync the payloads and columns that are canonical based on the view. This way it's also easier to fetch data from multiple peers. Cuz they like you only care about getting the data for the root, right? You don't really care whether that was canonical in the view of the peer or not. And there's like you prevent this off-by-one issue that you currently have where to determine the last payload in one epoch range whether it's canonical or not you need to look at the next epoch range and see if the block built on top

of empty or full. So, that's a lot of the source of the bugs, I think. >> I don't understand Nico, you're syncing blocks then finding them finding whether or not they should have included a payload or not and then after that requesting the payload and then only then you realize that your block was valid? >> So, for example, let's assume like a drastic scenario where you have let's say slot zero being being there and then it's a full and then the last block of the epoch builds on empty, right?

Then technically, you don't for that whole 31 blocks, you only if they all build on empty, you only need to sync one payload. Cuz they all build on empty, right? As an example. And on mainnet, if you don't have this chaotic and missed orphan payloads, then it's probably not that big of a deal. But especially if you have empty epochs in between, where like a whole range of blocks is missed as well, it's getting pretty hard to line up all the range requests, I think.

But yeah, um maybe others have thoughts. >> Well, you haven't replied my question. I don't understand how you're doing this. >> So, the idea >> blocks and then finding out after the you've seen the blocks that you needed to sync some payloads and then you request those payloads and only then you find out that the blocks that you synced were valid? >> Uh yes. >> Then how do you prevent from poisoning your fork choice view?

>> Well, you're not importing them. Like how does Prism do it right now? I'm guessing you get one range of blocks and then you get the same range of payloads and then you try to match them up. >> after we get all of the information that we have available so that we can sync. >> Yeah, but I don't see the difference. Like why do you need to get the payloads by range if you can get them by root? >> Well, it's just faster to get just one call instead of like sending a tons of calls to peers.

Just the same You could You could say the same thing about blocks. Why Why we have blocks by range instead of just requesting all by roots? Which is a proposal that is a good one the from Yasec and and Dab Lion of sinking backwards. But yeah. >> Sinking backwards by root. >> No, so the idea is to request pinpoint a branch that you want to sync and you request give me this many blocks from this root >> Yep.

>> So then you can sync them forward. Uh how do the other clients feel about this? I think Ethan expressed sorry Aton expressed some support for it. >> Uh I mean Lion's been working on this thing that we're calling tree sync, but it's really far out. But it leverages by root requests in the non-final finalized portion of the chain. Um yeah, I don't I don't remember exact details, but it does make things a little more deterministic in bad network conditions. So I think maybe some of the issues we have with range sync right now.

>> Yeah, but it wasn't by roots. So it is literally what I described. If you're trying to sync of a tree you say I want this leaf, I have this root give me all the payloads or all the blocks for like the last 64 blocks corresponding to this leaf. And then you gather the root of that chain that you got that gives you a root. And then you repeat that request. So this way you can sync on a tree a particular branch.

Which is a good one, but it still leverages called by range. It does not request each one root by >> Okay, I must have misunderstood something. >> I think I would be against completely removing the by range. And instead just option for clients to not use it if they don't want to. Is that appropriate Nico or Alan? >> I I think you want >> We also had like a separate by root request earlier like in Hulu we experimented with this where basically

we request all the blocks for a epoch by range and then once we know the specific roots that we need for that epoch we basically request all those all the data columns for uh specific roots from that epoch by root instead of by range. That wasn't much slower I think like we did experiment with it we ended up not merging it. That the reason we did that was because it was a little more deterministic in terms of we basically get the exact columns that we

requested. We we will probably at some future point look into it again. But like the problem that Nico mentioned I think this is a problem also uh pre glorious because like we could also have a condition in which you downloaded you downloaded blocks for epoch one and then like the last uh like slot 31 or whatever was uh given as like an skip slot or something and then until you download epoch one you don't know if that was right or not. So, like Lighthouse

already handled that case before where we sort of validate the previous epoch that was processed and uh make sure that basically whatever the n + 1 epoch we get builds on top of epoch n that we downloaded and processed. So, it is something that we do uh handle even pre-gloat. Uh is that you're talking about, Nico? Because I'm not completely sure I understood.

>> Yeah, I think how you described it is what I had in mind. Like the first by root. >> Yeah, so we handled it uh like that is an issue pre-gloat as well, I think. Because like until you download the next epoch by range, you don't know that like the previous epoch was that was given to you was correct or not because it could be just completely full of skip slots as well. >> I think, yeah. I mean, that part is true, but we don't have this off-by-one issue, right? That we have with payloads

right now. >> I'll I'll need to check it out. I have I just woke up, so I might not I might not be speaking sense. >> Uh any final comments on this? I'm not sure if there's anything else to say. >> I really think this is can be done on the implementation side, like what strategy they prefer.

>> We also have on the spec side. >> Yeah, yeah. Also, we haven't implemented this in loads and not sure we even have consensus on what's the ideal approach. >> There's an obvious ideal approach not sync payloads. >> I mean do we have enough time to include that in glass? I mean Okay, I guess we can move on to a

different topic. Nico again, would you like to talk about EIP 8282? >> Oh yeah, I can quickly give an overview. So this was something mostly came and worked on. So essentially the ideas we want to have a separate deposit contract for builders and reuse the execution requests mechanism. So from the overall from the CL side wiring with the EL it should be rather straightforward cuz we can reuse that on the contract side it's essentially similar to the consolidation contract and the withdrawals contract

which has like this EIP 1559 fee increase which is there to prevent DOS. And um what are the things to point out? So exits, so basically you have deposit and top up mechanism there and a exit. Um for the CL side the nice things there is that you completely decouple builders from validators because right now we have this commingling in few places like in the voluntary exit for example. And also you have this requirement that pop keys don't overlap, which introduces a lot of complexities like the pending validator signature checks and so on.

Uh that would all go away, basically. >> I actually don't think that the non-overlapping pop key is a requirement. It's more of a nice to have If I recall. But yes. >> And that was Was it in the withdrawals or something? There was some place where I wasn't sure if we could even I get least if you do the deposit, right? That was what Lido brought up, the front running.

>> Yeah. >> Where you credited a deposit to the wrong um to the validator instead of Oh, no, it was the other way around. You could front run to credit a deposit to a builder instead of the validator. >> And >> [clears throat] >> that's right. >> It this cannot happen here because it's two different contracts, right? Uh I guess one nice thing would be you have a the execution address or EL side triggered exit and not like having the BLS keys able to do that.

I guess it's not really that important, but >> Could you describe how do you prevent this the front running issue by having these two contracts? >> I mean that the current deposit contract cannot credit to builders. It like all the code we have currently wired up to credit to builders would go away and you basically only have the builder contract deposit to builders. So if the Lido pool deposits to the >> do you deal but still how does it prevent the the burning? So So what happens if I deposit on the same key on both contracts?

>> You have two different entities. You have one builder entity which has like a different withdrawal credentials, right? So different if one address. >> Oh, so so we are now going to move into into allowing the same pub key for different for different builders and and validators. >> Yeah, that is possible, yeah. I'm not sure if people would do this, but there's no harm in having this. >> Uh I don't know if there's no harm, but I can't think of an exact situation which is harmful.

>> Uh relaying what Barnabas said, he said that this feels like a massive change so late. I tend to agree with that. Like uh I wish this I wish we had discussed this earlier, like a month or two ago. I'm personally hesitant to suggest or recommend this change or support it, whatever. How do other clients feel? How do you show support for

massive change really late. So. Is anyone in favor of this? Or maybe they continue exploring it. PK says if we open up the floor to a new operator deposit contract, we could check the BLS signatures in the EVM as well. But yeah, I agree it's too late. NC says next. >> just one comment on the signature. So you I think you don't want to add the signature verification on the EVM.

Cuz if we want to switch to post-quantum signatures, I think this is harder. And with the design that the current has that this builder deposit contract has, it doesn't really matter. You like it has a DOS protection built in with the fee increase. >> Barnabas? >> I mean, we could really just redeploy a post-quantum contract down the line because these are only builders. They're kind of disposable, I would say.

So I I wouldn't necessarily agree that we should not be adding the BLS signatures in the EVM. >> Uh you could do that, but I think I was thinking about this when we had it like this, but there's not that much of a benefit actually doing this. Cuz it would mostly be DOS protection, right? Or you basically outsource the cost to the submitter of the transaction. >> Yeah, it would just make it more expensive to basically do the gas calculation on the EVM. The Yeah.

Everything in the EVM. >> Curtis, you had your you had your hand raised for a second. Is there anything you wanted to >> I'm still thinking on the I'm still thinking on the the problems of synchronization and possible possible attacks by having the same key on both. >> It's a It's a hard problem to think about having the same public key on both different contracts. especially because keys are probably not owned by the same entity sometimes. So, uh yeah, I don't know. Uh I I don't have an attack. I thought I had for a moment, but I don't have one.

>> Uh so, regarding the BLS stuff, so the nice thing right now is you have only one function to do both deposit and top up. And if you add the BLS verification the contract, you need another one for top ups because I think top ups we want really cheap. Uh whereas like the initial setup where you need to uh verify the signature like the initial uh deposit would be more expensive then. >> I agree that is something that we should a property that we should try to have cheap top ups.

Is it okay if we spend a few minutes talking about the builder API that Terrence just brought up before ending the call? I don't know if you guys have We are at time, I know. Okay. All right. >> I I have not like I have like implemented the server side of it and build out like all the builder API. So, I have the server side ready. If any like client like wants to test, they can test. I like Also like over the last week like I spent like a few days like um like prototyping the builder API and prism like this is like my version, but

uh and like it the server side at least seems to work. So, I have like a branch. Terrence, I I'll I'll I'll put it in the EPBS channel like after this call. uh on the image and all those things and you can like test it if needed like >> All right. What's preventing us getting the builder's back today merged the PR 138? >> Mhm. Yeah, I mean I think it's more or less like it's like feedback. There's nothing like I mean there's nothing like stopping.

It's more like uh I I think this is a tricky part. It's like when do we stop in the builder's specs cuz like you have like builders and it's just not like client devs agreeing. It's also like you you want the builders to get more alignment, but Yeah, I mean I I think we like for example, there's one like open PR like for for example, like uh there's we have an API to submit the beacon block to the builder back. Uh and like and I and I think based on my implementation, I think like it makes sense. It might make sense to not even have that API for example, because uh you know, that's kind of it requires some water state cuz you can only submit the block back to the builder who has

the payload. so you kind of need some you need you and from the bid you can't derive okay like is the builder API block or not? So you kind of probably the engine API while while while in talking in the validator server while talking between the client validator client and the beacon uh API beacon block beacon chain you beacon node you you might need to maintain some state. So that's the thing. On that note like I also think like probably makes sense to merge it and we can raise like uh What is that? We can raise like PRs if we need to like update it in this in the future. So >> Yes. So can we just give builder like a deadline saying that hey, we're going to merge this by like the end of this week end of next week and this is the initial

version. And then if there's feedback, we'll continually iterate on it. So, I think if we I think might be good to just merge this version first and just keep keep keep giving the deadline, and if they miss it, that's okay. They they can still provide feedback. >> Okay, that sounds good. I I'll do that. Like so, I'm going to like put that we have like a TD. I'm going to put it there. And yeah, I think that spec is pretty much good. I'll I'll see if there's anything to clean up, and I think I'll merge it. Someone else should do that. And yeah, as I mentioned, like we have it like implemented the server side and builder, like so when anybody of you implement it, I'm like more than happy to test it with you guys. So, >> Just want to state that I think that's

the right approach as well, to merge and iterate. I think deadline next week would be way too late. I would say sometime this week, latest end of the week, but like to me, I'd say like Wednesday. >> How many people here have read this? >> I have. >> Okay, there's one. There's two, Barrett that wrote it. How many more people have read this? What's the latest version of the signed bit? Is it signed by your URL, pub key, arbitrary data?

>> It's all that signed by URL, like if you put the URL on the slot. That's like what people want. >> How many people have read this and know the controversy about this? >> It's agnostic data though now, right, Brent? >> Yeah. So, then then probably Wednesday is just too close to it. I mean, if we here that are supposed to be implemented don't even know, I I would give more time. >> Okay. End of week. >> End of week should be fine, yeah. >> What is the controversy?

Exactly? >> Well, there's been weeks and weeks weeks of arguments as to whether or not this even should be included. >> Yeah, I mean Yeah, like I think there are builders who still like who DM me who's like, "Yeah, I don't know if we should do this." That that that aspect is there. Um the way at least I'm thinking about it is like we can merge it and again, if there's more like opposition that comes up I I do feel like it's an easy thing to remove in the worst case if we need to also.

Doesn't seem like something that's hard to like take on. So, yeah, that probably requires some plumbing for clients like to sign this. But uh yeah, I think clients can figure that out. >> What's the status of the of the trusted I'm I'm going to I want to know uh what's the status of the analog of the register validator? So, in the original builder API we had some headers that we could send just just in time for the auction that would be just enough and then we wouldn't need to register in advance.

The builders requested that we register in advance anyways and we send another message uh an epoch or two before, which kind of makes sense, but what happens if we don't do that? Uh are the headers removed from the just-in-time or are we forced to send those messages? >> So, the way I what makes sense to me, I think is we don't have that header because I think if you already have this API, what and let's say the builder doesn't have the latest like builder preference of the proposer like they just like default to like a trustless payment.

And I think it's pretty rare like for that to happen, but if that happens, like either the builder can just choose not to serve it or they make it like a trustless payment. Because for me, like having an endpoint to serve and then an optional header that creates all these situations where Okay, like let's say you receive a header and you have a builder preference. What do you prioritize? So that all that all of that like becomes like things to take care of. For me, the simplest way is okay, we have the endpoint to submit the builder preference, the max trusted bid, right? And then you want When you have that endpoint, let's say the builder like says Let's say the builder doesn't have it. You just like either don't serve the bid or you fall back to like a trustless payment.

So that just seems like simpler like a simpler alternative, like. And a default, you know, like a simple default. So I think like that makes sense to me. Rather than having an endpoint and a header, and like, you know, at that point you have to define, okay, how do you prioritize if you receive an endpoint when you also receive a header when you also you have the latest builder preference stored. Like just like seems like so simple to just let them like Okay, you don't serve the bid or just fall back to like a trustless payment. >> Jared, do you still have a question?

Your hand is raised. >> Oh, no, I don't. Sorry. Thanks, everyone. I feel like we should end the call. It's already 10 minutes past. >> Yeah, and about like I I think if clients take a look, like I think we can give builders a deadline. If they take clients a look, clients can take a look, like by the end of the week, like I can merge it in, implement it in like builder, and we can like start testing. >> Yep, sounds good to me.

Yep, clients, please review browser's PR. Please ask for a link if you need it, but it is in the chat here somewhere. Okay, talk to you guys at ACDC I guess and reminder that it's 3 hours earlier. Bye everyone. >> See you guys. >> Thank you.