ePBS Breakout #5

Transcript

All right. So, welcome to the fifth meeting. This is the fifth breakout session of the EIP7732. Uh, we have a very small agenda. Uh, and I'm very sick. So, apologies for my tone. Um the first point in the agenda is something that Quintis raised which is the fact that uh builders can gather the IP addresses of proposers that request bids from them and do we can we do something about this? Do we want to do something about this? Uh what's the situation? This is definitely something that a proposer

that uh connects to them would be trusting them uh with this information and this is a trust assumption that EPBS does not solve in the current format. Does anyone have any opinion on this topic? I'm not a networking expert, but how hard it is for the proposer to change his IP after he proposes a block because he doesn't propose a block very often, right? I don't know about the networking.

I've been told before uh that builders anyways can do this today and they they already have them mapped. Uh but I'm not sure if that information but that is relayer today. It's not builder, right? This is relay today. Well, yeah. So, I've been told that this was builders, but I presume that this is with the help of the relay or probably already integrated builders. I I I'm not sure if this information is even true. But I don't even have an idea on how to mitigate this. So it is a problem that is out there. I don't know how grave of

a problem is also. [Music] So it's it's a problem that is there and unless anyone has anything to say about this, we can move on. I'll contact Anton who's been studying this problem from uh for the beacon chain for a long time and uh I mean he's realized that you can find the IP addresses just without being a builder without being anything just connecting a node into the network and uh so this might be a problem today. I remember a study kind of proving that was very very very easy to grab high high chance of uh picking the right IP

address for a given validator was or or picker node I don't recall. Yeah and Tom was doing this by spamming the network quickly. uh and uh I mean if we haven't mitigated that then it's not that I want to minimize this problem but if anyone can do it anyways you don't need to be a builder to get this number then there's not much that we as a group can do but but this is a problem for core devs in general all right so let's move on and let's have a short meeting so I have only two issues to to mention u I already fixed them in the in the EIP if anyone is looking at the

consensus PR um the status of that PR is as follows the the consensus layer PR it's mergeable uh it might actually be merged as SIS uh because there's no commitment to implement it if we merge it uh it's just an extra fork just like u there are other PRs like the whisk is is an extra fork there in the in the consensus repo. Now, uh it had we caught two bad bugs out of like trying to make it executable.

I am passing all tests that are relevant except for choice tests now and that's going to be a separate PR to uh to make it executable at the current fork. Uh the for choice tests are very nasty because uh well the changes to for choice are very large. So it's not really clear to me which tests should pass and which test should fail. So that's taken me a long time. I still have 34 tests to pass start. I started with 70 700 something test failing and now I'm down to 34 test passing uh failing. I hope to have that PR open in about a week. Um but I said that two

weeks ago. Um the two bugs that we found out of like trying to make it executable is one was the issue of uh the state route in the block hash. So currently you find out what your parent block root should be by looking at the state and hashing the last block uh header that you have in the state. The problem is that the block header has the commitment to the state root and that state root for the previous state is not uh is not put there as part of state transition. It makes sense, right? Because you're making a state

transition and only after state transition you actually copy the hash. So the way we do this today is that when we process the slot at that moment you insert the right uh uh state state root the hash to root of the state in the block header but this breaks in EPBS because in EPBS uh there's another there's a second state transition that happens within the same slot. So when you import the payload uh the execution payload then you need to check whether or not that payload was referring to the right block and therefore you need already the black the the hash root of the current block which

is already committed in this state. You've already performed state transition but the hash root was not performed was not updated. So the only thing that I did is I added that check when you process the payload just check that if the root is empty on the block hash then you just update it. You compute the hash now for the state and you just update it and so far nothing has broken out of that change. I kept the change of course in process slots because you might need to process a slot when the payload hasn't been revealed.

So you you might need to uh update the hash tree root the for the state both either in the payload or when processing is locked when the payload was not revealed. Uh the other consensus bug the other bug that that I found was in for choice. That one I'll probably defer for you to look at the comment. U it was in the filtering the tree. It was just completely broken. It was bad Python. Uh I was um so the idea is that when you have a node what are the childrens of this node uh within four choice and the children are every block that was based up of off of this uh route but uh but you have to consider them with or

without a payload and and in this change uh I was considering as children um well essentially I was considering no children for for the justified checkpoint. So therefore all tests were failing and then I figured out that for choice was completely broken because I was having an empty tree just only the the justified checkpoint was the the one I think this is fixed but this is harder to check if it's fixed because since I don't have four choice tests uh most of the four choice tests uh are broken currently uh it's hard to know if this was fixed. It requires a review. It is a hard thing to review. So I'm hoping that some of you would actually read it.

All right. So, that's all my update and there's nothing else in the agenda. So, if anyone wants to say something, it's now Hello. I I'm on my mobile. I'm sorry my reception also bad. Uh, if possible, could we could we uh talk shortly about the IP thing? I I wrote you in the meantime, but uh you didn't you probably didn't see it. Uh you know, we're trying to spin the EPF project with a builder rating. Is this IP thing going to affect it? I'm trying to comprehend this.

Uh I don't see how I don't see how you can uh I don't see how you can detect in your node that the builder is collecting your IP information. Uh the the current uh rating uh system is about uh uh bad uh responses, right? Uh bad uh so there currently right but the proposal for for the proposal for rating it's mostly focused about censorship.

Like if you see that the builder is consistently putting out blocks that uh that don't include transactions that you see on your mele then you might want to downscore that uh that builder. Um if you see late then you might want to downscore those those the builder. So, so you can you can check for conditions that you check locally and you you have like different different weights and allow your user your operator to down score for whatever reasons you you believe it they're valid. But I don't see how this IP issue would would play a role there because you cannot see from your node that the builder is actually collecting IP addresses and you don't actually need to share

that information with the builder in order to get your information about the builder as a node. That's correct. That's correct. The nodes will only downgrade or upgrade a builder based on their their own view of the chain. Uh you don't need closer. It's local and you don't even need to be a validator to do this. You don't even need to be a propos a proposer. You just run a node and you have information of your local node. Okay, you can have a scoring system that is separate from your actual validated Okay, that's uh thank you very much for the for the clarification.

Right, there any more comments? Uh this looks like this time is going to be an actually short uh short note. I guess we can get like implementation update right. So from my end that like I'm working with EPFS fellas on like implementing the actual spec itself which is the PR that pers on the consensus back. So I think besides like while he's fixing all the tests definitely welcome reviews on the Python code but meanwhile we're also looking into adding the Python code into the prison client. So that's where we are at today. I I believe Enrio and maybe Genda

were looking at the same thing as well from their perspective. So yeah definitely welcome feedback. You you're right. Uh I know there are I have fellows that uh have this in their project. This was of a different uh approach something that pot proposed on a on a different discussion but yeah I I think there are fellows doing exactly what uh what you're saying and that's the implementation in the actual uh client that's I thought they should be here but they're not on this meeting I mean in the chat you said that they're doing this in Nimbus that's great too Right.

Nice place from Techo. Yeah, we spoke the last breakout that I was planning to start working. The bad news is that I haven't started. The good news is that I I completed finally what I was doing before which is the SSD stable container finally implemented. So I next week I plan to switch and switch contexts again finally and start putting my other on it. The other real bad news is that I'm going to go in on vacation for for for for three weeks after after the next week which will will add a little bit of posing on the work but I will start

let's say that's that's already good news. Um all right. So what I was thinking if if you guys are starting just a little piece of advice would be to implement just the minimum which is not even deal with the auction itself. Uh if we can prove for me the a proof of concept that would be good enough is if we can prove that we can handle the 12 seconds block the 12 seconds slots. So that means you get your local block from your local EL but you break it into a bid and a payload and a consensus block and you just locally produce blogs as if they were from EPBS. I think this is the really minimal viable proof of concept that

doesn't even implement the auction because the auction part is easy to do than later without the P2P part but the actual just requesting alame boost that's also easy to add but for that we need to agree on what the the the builder API would be and that's surely it's going to be a nightmare so I think the easiest thing to do is just to focus on locally produced blogs but uh broken into different pieces uh which already would guarantee that we can actually handle 12 seconds. I think the second easy thing to do this is the second easy thing to do is just um you can essentially you can build like a kind of like a local builder or or or like a or or or like altruistic

builder. You basically just kind of like request the payload from GU or your EL client every slot and submit a bid and and you but then you also have to be a validator as well. You have to stake and then you basically try to win every slot to set the base baseline and then if you see the block is included then you just review the payload at the second half. I don't think that's that hard to do either and I think that may be a fun project for the EPF or I I could take on that as well.

Yeah, that's that's that's definitely but yeah, it should be a flag also on validators. Uh just submit a bit every every block, which yeah, we'll have to deal with the with the spamming events. Right. Right. And that's good for testing the PTP path. Yeah. Go ahead. No, no. I'm I I was just going to close the meeting if there's no comments. All right, let's go work. See you guys and thank you very much.

Bye. Bye. Bye. Bye. Take care. Bye. Bye.