Justin Traglia:So hi everyone. Welcome to EPBS Breakout Call 23. I'll be subbing in for Will this week, who is busy participating in the
Transcript
Justin Traglia:ZKEVM AMA?
Justin Traglia:I'll share the agenda right now.
Justin Traglia:Here's a link.
Justin Traglia:I think I'd like to start by discussing some of the open specification PRs for EPBS.
Justin Traglia:All of which are actually from Terrence, by the way.
Justin Traglia:Most of these are tests, but there is one, which is maybe… we need to chat about some.
Justin Traglia:Let me share a link to it real quick.
Justin Traglia:So this PR, is titled, Rename Execution Payload Header to Execution Payload Bid.
Justin Traglia:Potus, you had some comments about it?
terence:I can give a brief update. So, I believe Porter's has reviewed it, and, like, Poters is good with it, and, so there's a follow-up PR on top of that, meaning, I guess, like, more of a general discussion is just that
terence:Like, previously, we basically replaced the, header with this notion of beep, but we still named it header, but that was in the same position in the state, and people generally didn't like the naming at all, right?
terence:And therefore, so what I did was that in this PR, I essentially, replaced the name, but since the name is replaced, I'm changing it to a different field location.
terence:But then the previous header is still there, it just essentially disturbed zero. But then, like, Francesco and Potus both have, like, good feedback on, like, okay, well, could we just essentially update the header during process payload, its execution payload, such that it's still same as today?
terence:And also, because of that, we can also remove latest block hash, basically.
terence:And such… so, but my PR only does the first part. My PR just essentially does the renaming, changing to a different field location, but it still starts to zero, so we basically want to merge this as it is, and Portos will open a subsequent PR that essentially updated
terence:update the, header, send us to date during process payload, and remove the block hash. Supporters will do the second part, so… but then, I do… I… sorry, I was under the impression yesterday, I was in the wrong PR, that this has been merged, but it doesn't look at this has been merged.
terence:And there's a bunch of conflict, so I will… yeah, this is my priority today, so I apologize for the confusion to POTUS. And, yeah, so my priority is to merge this today.
terence:But I believe Portis was good with it a couple, a couple days ago already, but now it just has conflict, so…
terence:Yeah.
Justin Traglia:Yep. Yeah, we can fix those conflicts and merge this today. I don't see any issues with that.
terence:Thank you.
Justin Traglia:There were some more testing PRs. Is there any value in going over.
terence:I can click over this. So, yes, withdraw, we can do. I just haven't had the time and the energy to do it. I think process withdraw is just really hard. And then, a couple days ago, or weeks ago, I was seeing Discord message that, like, French check still has some feedback, so I was one… so I had a question on whether, like.
terence:yet the expected withdrawal will be refactored or something, such that it's easy to test, but doesn't look like it. So I'll… so… yeah, so… so I think I will pick this up.
terence:again, it just, yeah, it's just really hard to test, because GET, because right now, GET Expatic withdraw has 3 different sweeps, and we put builders first, but after builder, there's, there's the pending one, and there's a full one.
terence:Yeah, I just haven't had the time, but we should definitely add a test for that. And also, if anyone has time and energy, feel free to take over on that, but if not, I will pick it up. It just… it's… it's just a little bit of low priority right now, because I'd rather handle the… because I'd rather handle, the other PR first.
Justin Traglia:Okay.
Justin Traglia:And for the other testing PRs, I think…
terence:test, yeah, I just want to open… so the first test is more like a, proof of concept.
terence:I wanted… I wanted to… instead of writing tests for 4Choice specifically, I want to write down all the test cases first.
terence:And then… and then have some sort of agreement on what the test scenarios are, because in EPBS, there is this notion of empty, so it kind of makes it slightly more tricky to cover all the test cases.
terence:And, yeah, so I wanted to write down the test cases first, before I even write the SPAC code for that, before I can write a spec test. So I believe I shared the test cases on HackMD a couple weeks ago. I haven't gotten any feedback. I also want to look in McKay Hall on this as well, because I know he has been thinking about this along the line.
terence:But I think it's slightly low priority. I think, like, this is not, like, a blocker for definite zero for Fortress tests, but yeah.
Justin Traglia:Okay.
terence:No, can you share that? No, I see.
Justin Traglia:Could you share a link to that? Yeah, yeah.
terence:I will share that, in a few minutes. Let's see, attestation processing test, so that one is important to review, supporters will review that hopefully soon. And then attestation pill or ability to reset test, yeah, that one is also important. So the… so the last two items on… are on both displayed.
Justin Traglia:Okay, I agree. I guess the task items, we can probably merge the bottom three open PRs. Yeah.
terence:Yeah, yeah, I just want to support this review, the last two.
Justin Traglia:Okay. Is there any value in going over the merged PRs since the last breakout call? Or just, maybe this is, like, a good brief overview, just looking at them?
terence:I don't think so. I think, like, the important things, like, some of those are actually structure changes, so it's, so, so, yeah, so those are important for Definite Zero. So, I think for Definite Zero.
terence:I think it's more important to come into consensus on what is the structure, and what is the state transition function, so I wouldn't pay so much attention on, like, the forchery stuff, and then the… and then the timing, the preset, but yeah, but I think the merge PR are important for Definitely.
Justin Traglia:Okay, cool.
Justin Traglia:I guess this is a good opportunity to talk about DevNet Zero Sum. Potus, do you know, or what are your plans for DevNet Zero? Do you have any timelines?
potuz:Yeah, so, we sort of, like, agreed to try to target, end of October, even if it's a single, client. That's starting to look, very tight, but I think we still can make it.
potuz:Having said so, I mean, as we were talking before, the… this call started.
potuz:There are 3 things that I can see would, affect Definite Zero that aren't merged
potuz:on the spec yet. One is for choice, is this, get, proposer head. That's not so problematic, because that's not consensus breaking.
potuz:But the other two are these decisions that, that are PRs that aren't even open. They're very minor, but, we still need to make a decision. One is what Terrence was mentioning, the fact that once we renamed the header for the bid.
potuz:The question is where to put it.
potuz:My personal preference was to put it in the header's place, like, even if it's renamed, just keep it there, and remove the header that is completely useless in the Peacon state.
potuz:But I think Francesco did not like this, and I definitely know that the people from Lodestar did not like this, because they prefer to never remove things from structures.
potuz:Since it's just a header, then it's… okay, so it's not so bad to keep it.
potuz:But then if we keep it, it doesn't make any sense to have it as it is now, or as it will be when we merge Terrence SPR, that it would just keep it as a completely useless structure, we just empty it out.
potuz:So I think we should agree on merging this thing, which would be to keep the header with the same functionality as today, remove the latest block hash, because it's going to be included in that header.
potuz:And then add a new field, which is the bid.
potuz:that's already added in Taren says PR. So I think I'll open a PR, to just keep the header. That should be very simple. It just keeps the header, it updates the header whenever we process a payload.
potuz:And, so that's… Yeah, so that's another transition.
potuz:And what else? That's it.
Justin Traglia:How do, other client teams feel about this?
ethDreamer (Mark):Lighthouse can do either pretty easily.
Justin Traglia:Okay. And I see from Stefan at Techu. This sounds good to him, too.
Justin Traglia:Okay, cool, yeah, please open the PR.
potuz:There was another one that is escaping my mind now, and Terrence just mentioned it, and I'm blanking out.
potuz:But there's… yeah, there's another issue, I'll just recall it in a second. But once we have those, I think we just freeze… oh, yeah, so this… there's… there's this issue.
potuz:well, there's this issue of with, expected withdrawals that Terrence mentioned that, that it might be changed
potuz:Francesco, and I think he was just, relaying a message from Barnabe, who was worried about the fact that you could just exploit… that you could exploit the fact that the builder's withdrawals are processed before the remaining ones.
potuz:In Get Expected Withdrawals.
potuz:It's sort of like a very weird attack to, like, try to cut the line to use those withdrawals, because those are, like, just one per block that you can just add.
potuz:But anyways, I don't know how to change that, or… I mean, in principle, you could just move it in the end, but then it becomes a problem, and then the builders themselves have, have some charm, so it's not really clear how that's going to change.
potuz:even if it's changed, I'm not against changing it, but the problem to me is that if we keep delaying
potuz:setting this… freezing the spec for DevNet Zero in those kind of changes, then we're never going to make it by the end of October. So my proposal would be to keep the withdrawal pass as they are now. Whenever that's researched, and even if we merge now, a fix, we still keep the spec frozen as it is now, plus this thing of, like, adding the header.
potuz:try to target them at zero, and then move on with the remaining items that are missing. One would be this
potuz:overhaul of withdrawals. I think Alex Stokes also wanted to look at this in general, like, the spec is really horrible for withdrawals now. And also the builder spec. We need to look at the Beacon API, as Sean opened up PR, there's some reviews, I think it's good.
potuz:So, the Beacon API, I don't think there's any contention, but the Builder API needs to be designed, but it's also outside of the spec for DevNet0. So my wish would be to set the scope for DevNet Zero now, as the spec is today, plus this issue of the header.
potuz:Leave the withdrawals as they are, and start to actually start coding on our main branches.
Justin Traglia:I agree with this.
Francesco:So…
Francesco:Question about withdrawals, they're not really skipping any line, right? Like, it's… there's… because it still uses Computexit, epoch and UpdateChurn for the…
Francesco:Even for the builder stuff, it's just that among things that have the same exit at POC there first, which doesn't really seem much of an issue to me. Like, I know that I brought this up, but yep, then at least I looked at it more, and it didn't seem like an issue to me, and I think…
Francesco:Barnabad looked at it, like, summarily, like, a while ago, so I don't know that…
Francesco:we also, like, had, you know, deeper thoughts about this than this, so if… if, you know, this understanding is correct, I think, yeah, we can leave it like this.
Justin Traglia:Okay. And how do other clients feel about the October .NET Zero timeline? Like.
Justin Traglia:I know you only need or want one client, but it'd be nice to have two.
Justin Traglia:I'm assuming the one client would be Prism, right, POTUS?
potuz:It's not clear. Taku was more advanced than we were.
Stefan Bratanov:Yeah, I'm not sure, we… I guess it depends. We've started doing some work with Lois, so it's possible October, but we haven't started on the more complicated part, so…
Stefan Bratanov:Yeah, I'm not pleased.
Stefan Bratanov:Not currently.
Justin Traglia:Okay.
Justin Traglia:Is there anything you need from, like, specs-wise? Like, a release with new tests and stuff?
Justin Traglia:I'm assuming we'll have probably multiple by then.
potuz:Yeah, they had…
terence:popping.
potuz:is going to change. So the Heather thing is going to change the state transition. So… so that's going to be my priority, even before reviewing Terrence's PR, is to have that PR with the Heather changed today.
Justin Traglia:Okay. And if we get that merged and included in the next release.
Justin Traglia:which I guess would be Beta Zero, then you could probably start working off of that soon, correct?
potuz:Correct.
Justin Traglia:Okay.
Justin Traglia:Anything else about DevNet Zero? Or, yeah, POTUS.
potuz:I'm nothing… Goodbye.
Justin Traglia:That's fine. Let's move on to the next agenda item, then. Shane, are you here? To talk about the EPS Beacon API standardization?
Shane Moore:Yeah, certainly, I'll drop, the PR in the chat.
Shane Moore:And, yeah, as you mentioned for .NET Zero, yeah, I know some client teams will have a single process where, you know, they don't really use the Beacon API between the auditor client to the Beacon node to, you know, propose box and whatnot, but, at least other clients do, so that'd be very, good to have this at least, like, in a pretty good spot.
Shane Moore:for, the DevNet Zero, and…
Shane Moore:I was thinking it would probably be, like, a pre-release. I at least saw on the Beacon API, like GitHub, that you can… that they do support, like, pre-release versions, which is nice.
Shane Moore:And I was… my first kind of question is, you know, how many people should we get… try to get reviews from? I just posted this already so far in the, like, ePBS channel, but maybe there's other forums where, you know, we could, move the needle as well.
Shane Moore:was the normal process, I guess, is my question.
Shane Moore:bug people. Witch people.
terence:We're giving, our team, James and Radick, to also look into this, just because they are more on the Beacon API side from the Prism side, yeah.
Shane Moore:B.
Shane Moore:Yeah, I saw Ratic, took a look last night, appreciated that.
Justin Traglia:If it were me, I'd probably just reach out to Nico, like, and just bother him about it.
Shane Moore:Okay, yeah, he, he also, I think, commented…
Shane Moore:on one thing as well. But yeah, I kind of thought, like, okay, maybe we need, like, Grandine and other folks as well, but if that's not the case, then… but sure.
Justin Traglia:Feedback from client teams would be good, too.
Shane Moore:Yeah.
Shane Moore:Okay, I guess we can move into other questions, that are probably interesting to talk about.
Shane Moore:So yeah, a lot of new APIs, as you can kind of tell. Like, we're gonna be able to get bids now, and also we're gonna be able to get envelopes, and sign, and then publish those guys to network, and payload attestations as well. We're gonna be able to get
Shane Moore:PTC, duties, so those are the new things, but more interestingly, I think, is, like, the modifications to existing APIs. So, you know, we currently have, like, a GET block, and that GET block is cognizant if it's receiving a
Shane Moore:blinded or unblinded, block, and the block comes back with blobs and, like, KZG commitments, and, now in Glowass world, it's simpler. We just get back, essentially, a beacon block, and it's never blinded or unblinded.
Shane Moore:the question became, like, oh, do we keep this V3 endpoint currently that has, and just update the response object to get rid of this concept of blinded, unblinded, get rid of the blobs, or do we make, like, a V4 endpoint that's,
Shane Moore:you know, obviously separate. So, you can see kind of pros and cons to both of these things. If you do the V4 endpoint, you can… I kind of think it's probably cleaner code,
Shane Moore:Because if you think about, you know, just modifying produce block VT response, you're gonna have more, kind of, like, messy conditional logic, potentially, to try to handle, like, oh, are we receiving this
Shane Moore:Like, unblinded, like, tag in the header, or not, and then have conditional logic based off of that, and it's supporting all the different previous, forks.
Shane Moore:Whereas, if we kind of go with, like, the proof spotv4 response, then, it's, you know, obviously cleaner. We just have to put at the fork transition in the validator client that once you hit, you know, global SEPOC, switch over to the new endpoint. And yeah, I've definitely seen all these comments with,
Shane Moore:like, it seems like preference so far is towards the produce block V4, and yeah, I'm totally cool either way. I spent a lot of time thinking about, like, A versus B, and couldn't decide in the end, so I figured I'd open up to everyone else, and yeah, figured I'd also ask on here if…
Shane Moore:Anyone else has an opinion on, yeah, Averse B. Produce block V4 response, or produce block V3. Keep that as modified.
Shane Moore:Pat says, Nico said before would be better, and yeah, I mean, we could totally roll with that if, if that's, like, kind of, like, consensus.
Justin Traglia:Does anyone else have an opinion?
Justin Traglia:Yep.
Justin Traglia:Stefan also says that he thinks V4 sounds better.
Shane Moore:Sweet.
Justin Traglia:Okay, let's just proceed with V4, then.
Shane Moore:Okay, cool, cool. And, I also noticed in the header that there's this incensus block value, field that goes back in the, like, produce block V3 response.
Shane Moore:At least in my house, they don't seem to be using it. I'm curious if any of the other clients know if they use this field for anything. It kind of just tells you, the rewards that you would get from proposing a beacon block.
Shane Moore:You know, transaction fees accumulated kind of thing.
Shane Moore:I'm just asking because I don't know if I need to support this field or not, going forward.
potuz:So I think… so there are two things about values. One is the value that you would get from a payload that we use to compare against the builder's, the builder's bid.
potuz:But then there's also this value that you get from consensus when proposing a blog, and I think this is a request from Vouch. So, I don't know if the people that typically deal with Jim are here, but otherwise, I would just reach out to Jim.
potuz:And ask him, because I assume that that's gonna be a hard request from Vouch.
Shane Moore:Yeah, that was the one. That's the one I was talking about.
potuz:Who's the best block from consensus side? And then he chooses this based on the value.
Justin Traglia:Yeah, I believe, Jim is retired now, by the way, so…
potuz:Wow.
Justin Traglia:Christmas? Maybe I did not know.
potuz:I think it's still in PG. Wow.
Justin Traglia:Yeah, I forget who mentioned that, but yeah, he left a while ago.
Shane Moore:Okay, Chris Barry, it seems.
Justin Traglia:Yep.
Shane Moore:Okay, yeah, it's good to know that there's probably some use case there.
Shane Moore:Anything else that's kind of useful?
Shane Moore:Anybody else in the comments part?
Shane Moore:of… this task?
Justin Traglia:Sorry, are you asking me to…
Shane Moore:Oh, yeah, yeah, sorry. Do we need a new endpoint that could be used to signal creation and gossiping of data column sidecars by whoever's bid is included in the consensus block? Or perhaps this can be triggered after the call to release a signed execution payload envelope?
Shane Moore:Yeah, I was curious, because, just didn't see anything, particularly in the spec that says, like, how we're gonna release blobs going forward. Maybe it's dealer's choice or whatnot, but, you know, it's typically, like, battery client-driven, or, like, well, builder… also be builder-driven as well, if, they win the bid. So…
Shane Moore:Yeah, just curious how we plan on signaling blob release going forward, and if we need a new API for that, or kind of trigger it as, you know, like, hook into the envelope release.
potuz:Can I ask, how is this, typically done by… I was surprised to see your comment in that, in that PR. How are clients that use the Beacon API doing this now?
potuz:Because we… we release the blobs when we release the blob.
potuz:So that, that, that triggers it.
potuz:And that's it.
potuz:I don't know how other clients do it.
Shane Moore:Yeah, I mean, at least from reading through Lighthouse, it seems that, whenever you get the block back from the beacon node, it'll come back with the blobs, and then when you go to, like, sign it, and then release the block.
Shane Moore:back to the beaconode, you also send the blobs back, and I'm pretty sure whenever you send it back, it triggers, creating these data column sidecars. I was thinking with Glow Ass, you know, we're not gonna…
Shane Moore:have the blobs, necessarily, whenever we, you know, get the consensus block back, and…
Shane Moore:get the successes block to the Valerie client, and then sign it and post it, so it's…
potuz:But I guess my question is, why would you need… why do you need to have the blobs
potuz:Anyway, even today, or even after gloss. So, after gloss, I would just request the payload envelope to sign.
potuz:Get the payload envelope to sign.
potuz:And then just post it, and never, never even ask for blobs at all.
potuz:And just have the beacon node, whenever it's posting the payload envelope.
potuz:also broadcast the blob sidecars. Build and broadcast the blob sidecars.
Shane Moore:So I don't understand why there should be even a…
potuz:A trading back and forth between the validator client and the beacon node for blocks.
Shane Moore:Yeah, so I think what you're saying is go with that second option of…
Shane Moore:Whenever you release the execution envelope, also trigger creating the column sidecars and gossiping those.
potuz:Correct.
Shane Moore:Yep. Okay, cool. That was, one of the ideas I was thinking.
Shane Moore:Cool.
potuz:I think, by the way.
Shane Moore:I mean, it's nice, you don't need a new endpoint.
Shane Moore:I think this is what we're doing now on Prism.
Shane Moore:B.
Shane Moore:Inc.
Justin Traglia:Beautiful.
Shane Moore:Anybody?
Justin Traglia:No, I was just gonna ask if there's anything else you'd like to talk about regarding, API? Beacon API?
Shane Moore:I think I'm good. Thank you, everyone.
Justin Traglia:Okay, let's move on to the next topic. One second.
Justin Traglia:I guess the next topic is Barath and his,
Justin Traglia:Well, I posted some questions, but he wants to talk about, like, the impact to relays and,
Justin Traglia:out-of-protocol software like MapBoost and CommitBoost. Marath, are you here?
Bharath:Yeah, yeah, I'm here, like, yeah, so I was, like, I spent some time thinking about, like, how the Builder API could look like.
Bharath:So, I mean, so, like, with EPBS, like…
Bharath:I think one of the things I was thinking about is, so let's say there's, like.
Bharath:We have, like, off-chain relays, which have not been, like, staked.
Bharath:with the protocol. The design kind of gets, like, a little, like.
Bharath:weird, right? Like, let's say you have an off-chain relay, who…
Bharath:who, like, they have an execution payload header. You need kind of, like, four, like, API calls, right? In the sense, like, the validator first queries the relay, gets the header, creates a beacon block, and then, again, since the validator has to sign the,
Bharath:execution payload envelope, which is created by, again, the off-chain relay. So, kind of, you have… I was thinking about, okay, there's gonna be a system with, like, 4 API calls. But, I think porters, like, you… in the chat and Discord, you mentioned one of the things that Prism is probably not gonna support, like, blind signing.
Bharath:Like, in the sense that…
Bharath:like, at least I… by my understanding, you wouldn't support, like, relays or builders which are not staked with the system. So I think one of the things, like, I wanna just, like, get some understanding is how are you people… how is the client team now thinking about,
Bharath:off-chain relays with EPBS, right? Like, are the client teams very particular that
Bharath:We only, like, have, like, a direct connection with builders who are staked.
Bharath:Or are they also open to having, like.
Bharath:supporting systems for off-chain relays, like, which are not staked in the system. Because, at least in my head, like, it kind of… for the off-chain relays, which are not staked, the design gets a little weird, like, the technical design gets weird, like, you know, you have a validator who poses, like, they're self-building, but…
Bharath:they are kind of querying an off-chain relay and stuff like that. Whereas, you know, if you have… if you're only, like, having direct TCP connections.
Bharath:with builders staked in the protocol, you know, like, it feels, like, kind of easier, you just get the execution payload header, and the builder is responsible for broadcasting the envelope to the PTC. So, I just wanted to get a sense of how the client teams are thinking about this. Do you want to support, like, off-chain relays, or are we specifically only want to support, like.
Bharath:builders who are staked, and if somebody wants to support, like, a relay which is not staked, you have to fork your own client and make the changes, like…
Justin Traglia:Maybe we can start with POTUS. POTUS, do you have any opinions on this?
potuz:Oh, I don't know, we haven't talked to Prism, but, as a team, but I am
potuz:Fairly certain that, we as a team would agree in not supporting this.
potuz:And I don't see why the spec should specify this, even if clients were to support such a thing, I don't see why it would be specified, as it is not today.
Justin Traglia:to be clear, this is, like, external third-party software, like MapBoost?
potuz:Yeah, so signing something that you haven't produced.
Bharath:And when you mean signing something you haven't produced, just, like, just for me to clear my head, like…
Bharath:You mean, like, signing something which doesn't come from the protocol, like, from a stake builder or something?
potuz:Signing, for example, an execution payload envelope that is blind, to which we only have a block hash, and we don't have the payload.
Bharath:Hmm…
Bharath:Got it. So, so you're generally saying, like, it's… you wouldn't want to, like, do that? Like, you would ideally wanna…
Bharath:Only, like, support, like, talking to stake builders, like…
potuz:Correct. I think that if… if the problem is, having to… to have some sort of off-protocol
potuz:mechanism that would be supported by clients, like, at least PRESM, I think builders should…
potuz:Try to pull together stake, get a relay that is staked, and provides this service for those builders that don't want to have staked themselves. And then you can even channel payments off protocol.
potuz:on the execution layer, just agree to have a bid for, say, one way, and channel the payment on the execution layer. There's many… there's a lot of design around this, and all of that design
potuz:I think it should be done… within the protocol.
potuz:what we see as a CL client should be within the protocol, and whatever happens off protocol, well, it should specify whatever it is off protocol. I don't see why consensus clients should be specifying a way of getting a way over protocol.
Bharath:Okay, okay.
Bharath:Got it.
Bharath:So you basically… Yeah, go for it, Justin, sir.
Justin Traglia:I was gonna say, personally, I agree with Protus's take.
Justin Traglia:It'd be really nice if everything was just in protocol, and
Justin Traglia:Like, the idea of builders pulling together and just,
Justin Traglia:Staking, like, a relay sounds ideal.
Bharath:Yeah, that makes sense. Like, like, I didn't… do you guys see a world where, like.
Bharath:Rather than just, like, a builder like Titan staking, it would mostly be, like, relay staking and…
Bharath:Builders, like, are these, like, non-stake entities who, like.
Bharath:who, you know, who go through these relays. I guess, you know, in today's world, you can also think of relays as builders. They're, like, we… they're kind of, like, interchangeable at a point, but I guess, like.
Bharath:maybe somebody, like, an ultrasound would probably, like, stake, and, you know, other builders, like, submit through them. Like, do you guys see, like, something like that, like…
Justin Traglia:Yeah, I mean, that's how I see it.
Justin Traglia:Lorenza?
Lorenzo:Hey, just want to add a comment from our perspective, well, I guess from Titan. I think someone was making a good point on the Discord that
Lorenzo:in a lot of cases is, I guess, is partly, let's say, the capital that is required to be staked, but also the expected value of producing a block.
Lorenzo:So, on a lot of blocks, the…
Lorenzo:Let's say the builder either makes no money, or…
Lorenzo:on average loses money, let's say, if he subsidizes, but let's say he makes no money, because even if there is, like.
Lorenzo:a top-line profit, let's say, a lot of the
Lorenzo:Of the profit actually is rebated to the apps, and the originator, so the builder itself, let's say, makes off and very little on the block.
Lorenzo:So bidding on-chain when there is a chance for the block to be, let's say, not to land is negative expected value, so…
Lorenzo:Yeah, I guess just… that's, I think, a good point from our perspective, whether clients are thinking about to support that or not, I guess, should be considered.
Lorenzo:That being said, I do agree that maybe this exact protocol should not be
Lorenzo:Let's say in the spec, if it's, cleaner.
Justin Traglia:Thanks. How do other client teams feel about this?
Justin Traglia:I don't want to call anyone out.
Stefan Bratanov:Yes, I'm thankful here, so…
Stefan Bratanov:How would then proposers connect to what builders? There would be a builder API change, I guess, to connect directly to Builder, or…
Stefan Bratanov:Yeah, I understand how the local flow will work, but I'm not sure what the other one. Or there is no floor, I'd say.
Stefan Bratanov:Design.
Justin Traglia:Yeah, POTUS?
potuz:I think… so, Stefan, we can… we can talk about this in a second. I think there's essentially no changes, but I think the question that,
potuz:that Justin is asking you is how you guys feel about supporting not only, like, connecting directly to builders, but connecting directly to relays that are not builders, that are not state.
Stefan Bratanov:Oh, so then we basically… we create a folder, create a bit of it?
Stefan Bratanov:I don't know how it will work if the…
Stefan Bratanov:I guess I'm just asking if, like…
potuz:Justin, can I describe what would be the flow of blind signing?
Justin Traglia:Sure, yeah, go for it.
potuz:Okay, so the flow for blind sign-in would be like this. You start the slot, you request bids from relates, as you do today with MapBoost.
potuz:The relay returns a bid, which is not signed, like the execution bid now, that would be signed by a builder. It would just come with a hash, everything but the signature.
potuz:So the signature would be the point at infinity.
potuz:So you choose the best bid.
potuz:For yourself, you put the value to be zero, because you're… you're gonna be self-building.
potuz:And you sign the block.
potuz:And you submit the block.
potuz:Okay? So at this point, the relay knows that their bid was chosen, and then you call them to request
potuz:their payload envelope. They send you a blind payload envelope.
potuz:So that means the payload envelope, but with the hash, not with the block itself.
potuz:You sign the payload envelope as if you actually built it.
potuz:Because you need to sign it because the bid did not include a signature, you submitted as if you were locally building. So you sign the payload envelope, and you send it back to the relay, as you do today when you send the block today.
potuz:The relay reassembles the full payload envelope with your signature, but with the builder's payload, and broadcasts it. So that would be the flow that it would be required from clients to support if you want to have
potuz:map boost, like, today.
potuz:And I… I… what I'm saying is that Prism will not support this.
Stefan Bratanov:Oh, yeah, yeah, this seems like a cut, just board. Yeah, yeah, it doesn't make sense. I think we also…
Stefan Bratanov:We'll be against that, and it'll just complicate the implementation.
Justin Traglia:I think I agree as well.
Justin Traglia:Francesca, you left a comment in the chat. Would you like to… Talk?
Francesco:Yeah, I mean, I… Don't understand why, if you wanted to support,
Francesco:bidding in some way that doesn't require putting all of you at risk, essentially. Like, which, for example, could be the case if you want to…
Francesco:I don't know, maybe make a bid that's much higher than the stake that you have, or just… I don't know, like, the… I guess if these issues that, the people from Titan were bringing up,
Francesco:Proved to be, like, meaningful.
Francesco:like, why would we do it in this complicated way that looks more like MethBoost today, versus just basically setting the bid value to zero, but still having the builder sign it already? Like, do the same exact flow as you would if you were…
Francesco:Doing everything in protocol, quote-unquote, but with just the value being zero, and then you only just basically additionally require the real value to be specified, like, somewhere outside of that.
Francesco:Of course, like, then, you know, it wouldn't… you wouldn't get the trustless payment thing and so on. But yeah, at least in my worldview, like, that's just really not a big deal, and really, trustless payments are mostly…
Francesco:useful as a fallback, so I don't really… I mean, I guess there's two questions to this. Like, one is, like, if we did want to support something like this, why wouldn't we do it this way, versus, like, this, you know, basically thing that looks more like MavBoost, where you are actually signing with your own key. And then the other question is, like.
Francesco:why wouldn't we support this? Like, to me, it seems like we actually should support this. But yeah.
Justin Traglia:Lorenzo has a question about how would the value be specified, like, in a header. It'd be at a protocol.
Francesco:Yeah, I mean, it could, I don't know, be that the API just has this… you get the bid, and next to the bid, you get some…
Francesco:other value, and if the bid value is zero, this other value has to be set to something else. And of course, I mean, you will only ex- you will only accept such, you will only accept zero-value bids from, you know, actors that you trust in some way, like, maybe you have a whitelist or something like that. Like, similar to MavBoost today, just with a different flow.
Justin Traglia:Got it.
Justin Traglia:Do any other, devs have opinions on this?
Justin Traglia:I mean, I would… I'm interested to hear what other people think.
Justin Traglia:Okay. I guess we can chat more about this, offline, probably on Discord.
Justin Traglia:Yeah.
Justin Traglia:I think that's the last agenda item, unless we want to keep talking about this.
Justin Traglia:A couple extraordin questions.
Shane Moore:about, this, like, builder API that could be fun.
Justin Traglia:So currently…
Shane Moore:we were thinking that we would have, the bids back through, like, a direct HTTP, like, connection to the builder from the beacon node. That's one flow, and of course, you can get bids back from the PTP as well.
Shane Moore:And I'm curious if we also want to support direct connection from Beacon Node to Builder through HTTPB.
Shane Moore:To get back envelopes, if there's any benefit to that, or if we just purely plan to get envelopes through, P2P.
potuz:You mean request an envelope from the builder?
Shane Moore:Yeah.
Shane Moore:Like, we're requesting bids from the builder, or would be.
potuz:Besides, besides doing this thing of, like, going off protocol a la MapBoost, what would be the use of that?
Shane Moore:I don't see one, that's why I was asking if we needed it at all. But, I don't know, just…
Shane Moore:I know the original question was, like, what kind of modifications do we need to build our API? This was just something I thought could be worth talking about.
Shane Moore:Maybe the answer is no use.
potuz:So, I think… so not for the current tip, but, but I think for previous payloads, Enrico was,
potuz:I don't know if he even opened it a while back, but I think there was, there were talks about having ways of requesting past blocks and past payloads, both by range and by hash.
potuz:And that would be a way of getting from the builder such a thing.
Shane Moore:And also, if we're gonna do, direct HTTP connections, to builders from the beacon node, would we support multiple, HTTP connections to multiple builders? Because I think right now most clients are just kind of hitting, like, one endpoint.
Shane Moore:to try to get back whatever the relays have decided is, like, the best bid, for example. And now we're saying, like, yes, we can get bids through PTP, but most of it's gonna come through direct HTTP connections, and, like, are you managing… how many connections are you, gonna try to manage, I guess, is the question.
potuz:Yeah, I think that… I think clients need to implement what MedBoost does today.
potuz:I think clients would have to be MedBoost.
potuz:You just put a list of builders that you're connecting to, you send the requests to those builders, the request looks like, it doesn't need… it does no longer need, builder registration.
potuz:You request on the spot, you send the fee recipient that you are… I mean, again, we haven't decided on any of this. This is how I view the Builder API. The… you just send several requests to a list of whitelisted addresses that you have, builders can advertise them anywhere, it doesn't matter, because since you trust them anyways.
potuz:because of trustless payment, you can just put the list however you want. You send in the request.
potuz:the usual data, I am proposing the next block, this is my parent block root, this is my parent block hash, this is my gas limit, and this is my fee recipient. Please send me bids for this.
potuz:And, well, that's it. You just have a timeout, and you choose whatever bid by whatever algorithm you want, which one is the best, but then you only take back bids that are already signed.
Justin Traglia:That,
potuz:There is a request from builders into having this request being signed.
potuz:I think we should probably defer this discussion for later.
Shane Moore:Yeah, I mean, DevNet Zero is supposed to be just for, like, self-building support, right? It's still the plan? So, yeah, this technically is kind of later scope.
potuz:Correct. I think it's fine to have the builder API being correctly scoped, and we can do this now, but yeah, for DevNet0, it's only local building.
Shane Moore:Boop.
Justin Traglia:Chris, I think you wanted to say something?
Chris Haug:Yeah. I'm curious with the two parts of the submitting, bids through the P2P, and then also the beacon, requesting direct bids, if we assume that mostly it will be the direct HTTP requests.
Chris Haug:getting the winning bids, like, why are both needed? Why is the P2P broadcasting still required as well?
Chris Haug:Or when do we expect that one to win, and not the HTTP request?
Chris Haug:Photos?
potuz:So there's many reasons to have this. The easiest one is because it's trivial, and it's not a GOS vector nor anything, but also, like, the thing is that this is actually decentralized.
potuz:You don't need to advertise anything, we are going to have, like, people setting the floor price for bids. Like, Prism itself will be a builder that will be submitting bids this way.
potuz:my home node would be doing this, and any home staker can do this. I mean, of course, we don't expect these, builders to win.
potuz:The one situation where a loan staker might win a bid is someone that doesn't… that doesn't build often, like, not Titan, but I have some private information that will happen next block, then presumably I can win over the P2P side, because I can make a bid
potuz:That, with information that no one else has.
potuz:I don't think this is so important, but it is important to have a decentralized way as a fallback, because if there are only 2 builders, or 3 builders, they might be offline.
potuz:We can always fall back to self-building, but eventually we were going to be in a place where self-building doesn't really work. We want to be in such a place, like, with just a blob count, for example.
potuz:So, this allows anyone with a good connection to be a builder, and it's a good fallback mechanism. Since it's very cheap and trivial to implement, it didn't make any sense not to have it.
Chris Haug:Yeah, I think it would be good to highlight in the spec, like, which parts bids are expected to come in, because currently the specs looks like… looks like most bids would come or win through the P2P, and to have both clearly specified, I think that would be helpful for us.
potuz:API is what is missing. So, we haven't really specified yet the builder API, which specifies how validators will request bids from builders, and we need to do that, indeed.
potuz:But just one extra point to your question on why the P2P side. If we have only 2 or 3 builders, then it's very easy to have a collusion and go off protocol.
potuz:I don't know if it's easy, but… but it is plausible to, in a market with only one or two winning builders, to have an off-protocol system. That's why I'm also against what Francesco suggested, of having the payments coming off-protocol in a stressless manner.
potuz:Because that sets itself for collusion. And then having a floor price at least sets a floor price.
Bharath:So, like, basically when… The slot starts.
Bharath:like, the client would query two bit pools, right? You have the one bit pool from the direct TCP connection, when you get bits from the direct… connecting directly to the builder, and you have bits from the P2P pool. So you'd assume, like, the design's gonna be, like.
Bharath:you start the slot, and, like, you probably have… and you try to compare, like, where you get the highest bid from. So I would assume you… you get… you have a cutoff, like, maybe after one second, I look at both, pools, and which pool ever… which pool gives me the highest bid, I… I… I just go with that.
Bharath:Like, is that, like, my understanding correct that? Like…
potuz:Yeah, the easiest way to implement is exactly as we do today, that you look at your local environment on how it is, and at the same time, you're sending on the background a request to MapBoost.
Bharath:So, your local view happened when you sent the request to local MedBoost. You could, in principle, do it the other order.
potuz:to give more time to P2P bids, but but the easiest way is just… you send your request with an actual timeout, it doesn't matter in that routine, and then that time… whenever that time's out, that's it. Or if you get a reply before your timeout, that's it, and you compare with your local view.
Bharath:Got it. Now, I guess, in this case, your local, we will have your, like, a block you built locally.
potuz:And are you including, like, the P2P… No, so your local view is the P2P stuff as well, as well.
Bharath:Oh, yeah, got it, got it, got it. Does that make sense, got it.
Chris Haug:So, in terms of the design of the Builder API, is that in process already right now, or who is in charge of that, and are, like, the relays involved? Is Ultrasound involved? Is BuilderNet involved? Like, Lorenzo's here, but it seems like it would be good if, like, relays and builders are involved in designing the Builder API.
potuz:Yeah, I think the only people that we talked about how it would be, that's why I know that there was a request of having them signed, are people from Titan.
potuz:The idea was to try to keep it just exactly as it is today.
Chris Haug:Okay.
potuz:So that… so that it's minimum change. And I don't see why we would… we would have to make it different.
potuz:The only difference that I see is that we no longer need registrations.
Chris Haug:And that the stake collateral is needed?
potuz:Yeah, that's part of the protocol, right?
Justin Traglia:Lorenzo?
Lorenzo:Yes, just a clarification, I think from our side, either sign or not sign is fine, so it's not, like, a hard request or a request at all. Just, we thought would be, like, a natural kind of evolution, but…
Lorenzo:Either is fine, yeah.
Justin Traglia:There's a question in the chat from Owen about,
Justin Traglia:about the first block following the fork, like, does it have to be a self-built block or not? Potus, correct me if I'm wrong, like, can you create a new validator with a 0x03, with… or…
Justin Traglia:Credential.
Justin Traglia:you can't… I don't think we'd be able to, convert it.
Justin Traglia:prior to glass, but I believe it's possible to create a new one. Is that right?
potuz:I think you could, deposit it now. I don't know who would do it, but…
potuz:Yeah. What… what we don't know how to do is to…
potuz:convert the homestakers into builders before… so, an existing validator into builder, before the fork.
Justin Traglia:Correct, that wouldn't be possible, but…
Justin Traglia:I really could create a brand new validator.
Justin Traglia:As a 0x03.
Justin Traglia:Credential.
potuz:Yeah, but there's this issue of… we need to understand how the sweep was going to work, because currently a 03 prefixed validator would not be a compounding validator?
Justin Traglia:Correct.
potuz:So that's the issue. So then probably you're gonna be swept.
potuz:But I think it's… I mean… Yeah, that's, that's just good.
Justin Traglia:Okay. Yeah, I need to look more into that as well.
Justin Traglia:But it's, yeah, good question, Owen.
Justin Traglia:Anything else from anyone?
Justin Traglia:Okay, I will return 6 minutes to everyone.
Justin Traglia:Thank you for attending.
potuz:Thanks so much, Justin.
terence:Thank you.
Justin Traglia:Yep. Bye, everyone.
Chris Haug:Thank you.
Stefan Bratanov:No one knows about you.
Chat Logs
00:01:10
Justin Traglia:https://github.com/ethereum/pm/issues/1714
00:01:36
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4525
00:06:55
potuz:can do those today in a bit
00:09:55
Francesco:I think that’d be my preferred option as well, even if we think that the header is not particularly useful
00:10:10
Stefan Bratanov:yeah sounds good
00:14:22
potuz:same for us
00:15:23
Shane Moore:https://github.com/ethereum/beacon-APIs/pull/552
00:15:52
terence:fork choice test cases: https://hackmd.io/@tchain/BkhU9DM_gx
feedback welcome
00:16:40
potuz:The people that are typically picky about APIs:
- Jacek
- Etan
- Dustin
- Paul Harris
00:16:50
potuz:not a coincidence it's mostly Nimbus :)
00:17:25
potuz:FWIW that beacon API looks good to me.
00:18:40
potuz:Nico also says v4 would be better
00:19:47
Stefan Bratanov:yeah I mentioned it before I think in our chat v4 sounds better
00:21:06
Chris Haug:Jim is retired now
00:21:12
terence:yeah lol
00:21:12
Chris Haug:mainly Chris Berry on vouch side now
00:21:27
terence:naa he left a while ago
00:21:35
potuz:wow
00:21:38
potuz:did not know this
00:21:43
Luca | Serenita:Vero uses the block value too 🙂
00:21:48
potuz:I'm feeling like a dinosaur
00:25:50
Justin Traglia:https://hackmd.io/XUQhAwAKRhi3vo4yFq13EQ
00:26:30
potuz:why would we need to specify this?
00:31:04
potuz:Buildernet would be very viable for this
00:31:17
potuz:I do not know what are the regulatory conditions and the such
00:31:24
potuz:but something like Buildernet is very feasible
00:35:43
Francesco:I don’t understand what’s the point of this versus just accepting signed 0-value bids, with real bid value specified outside of the protocol bid. It requires the builder/relay to be staked, but that doesn’t seem like a big deal, it can just be 32 ETH
00:36:17
potuz:yeah that would be the simplest way
00:36:24
potuz:but people argue that they don't want to be staked
00:37:31
Lorenzo:How would the value be specified? like in a header?
00:37:58
potuz:could be a sidecar, and I definitely disagree with Francesco on this :)
00:38:24
Bharath:Probably would be an off chain agreement ?
00:38:54
Francesco:Replying to "but people argue tha..."
I doubt that people have a problem with staking 32 ETH?
00:38:58
potuz:yes, it needs to be a trusted builder
00:39:09
Francesco:Replying to "but people argue tha..."
(Especially if the bid does not put that stake at risk at all)
00:39:22
Lorenzo:Replying to "but people argue t..."
yep agreed
00:39:42
Lorenzo:Replying to "but people argue t..."
my point was mainly about client support
00:40:57
terence:the only reason is to something like: https://ethresear.ch/t/payload-chunking/23008/2
but it's pretty side tracked
00:43:16
owen:For a validator to become a builder I assume they upgrade withdrawal creds. Does this happen in the first block following the fork? If so can that block be built by a builder or would that block need to be a self build?
00:44:28
Justin Traglia:Replying to "For a validator to b..."
Good question. I believe the first block would need to be a self built block. Cred changes could go into the first block at the fork, but it wouldn’t really take effect until the next slot. Right?
00:44:44
Justin Traglia:Replying to "For a validator to b..."
Maybe next epoch.
00:45:15
Justin Traglia:Replying to "For a validator to b..."
Can bring this up after the current discussion.
00:46:31
Justin Traglia:Replying to "For a validator to b..."
Maybe it’s possible to have a 0x03 validator prior to gloss.
00:46:37
Justin Traglia:Replying to "For a validator to b..."
*gloas
00:47:38
owen:Replying to "For a validator to..."
that would be ideal
00:49:08
Bharath:No registrations is very nice haha
00:49:26
potuz:that's nice to know
00:51:10
potuz:@Lorenzo you're not worried about other builders hitting your endpoint requesting bids?
00:51:16
owen:Would be good if titan relay or builder was ready to go from the fork