Justin Traglia:Alright, thank you. Hello everyone, welcome to EPBS Breakout Call 27.
Transcript
Justin Traglia:I guess we can… I can quickly mention that there are two new specification releases, so V1.6.0 Beta 2, and then the stable V.1.6.0 release.
Justin Traglia:Those primarily focus on GLOS, and include some new tests and spec changes. I suspect several of you have already
Justin Traglia:updated to… Track that. So, thank you.
Justin Traglia:There were a few merged PRs, I don't need to go over all of them, but I've checked them here, and there is one new open PR, which I have not
Justin Traglia:Reviewed yet.
Justin Traglia:But maybe… oh.
Justin Traglia:And then one other one that POTUS just shared in the chat.
Justin Traglia:I'll get added right now.
Justin Traglia:Oh, okay.
Justin Traglia:Thank you, POTUS we can talk more about that, and, Stefan's agenda item.
Justin Traglia:I'll add it to the agenda later, thank you.
Justin Traglia:I guess we should move on to client, implementation updates. Prism, could someone from Prism get us started? Terrence or Protus?
terence:Mmm… We'll be mostly focusing on Fusaka Mainnet, so not much progress in terms of just, like, merging,
terence:EPBS-related, implementation into the main developer branch, so we merged the, container branch, which contains all the container objects, so that was
terence:pretty much the baseline, and now we're focusing on merging the other things, but yeah, after, I think, this week, once we have the mainnet release for Fusatra, we'll see more progress. Other than that, we have a bunch of PRs that pass the spec test for the BK and spec.
terence:But not much after that. Yeah, so… but we'll see more progress soon.
Justin Traglia:Okay, thank you. And yeah, totally expected.
Justin Traglia:Is there anyone here from Lighthouse that could give an update?
Shane Moore:Okay.
Shane Moore:Yeah, a few of my PRs related to block processing are getting merged into Lighthouse, you know, like prosecution, bid, process withdrawals type of stuff.
Shane Moore:I know we have, Ethan who's joined as well, the effort. He's, working on Seek Manager-related changes for, like, execution payload by envelope type of stuff. And then, I think Mark's doing, some envelope processing, like, so payload processing splits.
Shane Moore:That's just an update of stuff.
Justin Traglia:Nice.
Justin Traglia:Thank you. Okay, someone from Taeku, please?
Stefan Bratanov:Yeah, not much update from our side,
Stefan Bratanov:Yeah, we've also been focusing on documentary release. Mary is working on some attestation, gossip changes.
Stefan Bratanov:And… yeah, apart from that, not that much of that.
Justin Traglia:Okay. Is there anyone here from NEMBUS?
Justin Traglia:I don't think so.
Justin Traglia:NC, from Lodestar, could you give an update?
NC:Yeah, so, so last week we have, we got everything in the beacon chain spec implemented and tested. We passed those associated spec tests.
NC:Nico is, looking at the blog production stuff, and I'm, working on the gossip change.
Justin Traglia:Okay. Thank you.
Justin Traglia:And, last but not least, is there anyone from Grantine?
Justin Traglia:They can give an update.
Subhasish:Yeah.
Subhasish:I can go ahead.
Subhasish:So, there are some open PRs around, Gossip Sub and RPC changes.
Subhasish:And, most of the, sync work is complete, except some of the storage and persistence, stuff. So, so we made some progress on, the networking side as well.
Subhasish:I think the… over the next 2-3 weeks, I think we'd have something.
Subhasish:I guess.
Subhasish:Yeah.
Justin Traglia:Okay, thank you.
Justin Traglia:And, do we have any…
Justin Traglia:estimates for, like, when we think DevNet Zero might be ready. I'm kind of personally thinking it'll probably be next year, like, mid-January.
Justin Traglia:At the earliest.
Justin Traglia:Does that sound right?
Justin Traglia:Okay.
Justin Traglia:Yeah, in my opinion, the rest of this year should probably be focused on Fusaka and making sure that goes smoothly, so…
Justin Traglia:Okay, otis, would you like to talk about off… adding an off-protocol value field to the…
potuz:Sure, it's a pity that, Francesca's not here, I think. Oh, no, Francesco is here. I'm here. Okay, good. So, yeah, so we… I reacted negatively because I didn't want to have this off-protocol value, being part of consensus.
potuz:But, I think I was wrong.
potuz:The… if we put this in the bed.
potuz:Then, we can actually have the clients check if this has been paid or not, or…
potuz:at least do some sort of check that the fee recipient actually increased the balance. And it could be tricked by the proposer itself, so this… but I don't see how this is an attack.
potuz:So there's something that can be done if we put this in the bid, instead of on the builder API, then the client can do some validation that the builder is actually paying
potuz:Which is something that we cannot do today with MapBoost, and we're just trusting the relay to do this check.
potuz:So I don't know, I'm…
potuz:Yeah, I'm just admitting that I was wrong, and that I want to take that back, I want to put it in the bid, but I don't know how people feel about it.
Justin Traglia:I haven't thought about it personally, but how do other client teams feel, if they have… if you have an opinion?
Justin Traglia:Okay.
Shane Moore:What are some of the cons of doing it? We had it.
potuz:I'm sorry, Shane, I didn't… I didn't get that.
Shane Moore:I was asking, if we add, the off-protocol value to the bid, what are some of the cons? You just mentioned some of the pros, so I was just curious, like, what are the.
potuz:Well…
Shane Moore:Yeah, oh, slightly larger size, I guess.
potuz:No, the…
Shane Moore:It's, like, one little value.
potuz:Yeah, that's not a problem. I mean, these things are not even going to propagate that much. The problem for me is sort of like a philosophical problem of enshrining this off-protocol thing
potuz:On the beacon state.
potuz:Which… which kind of sucks.
potuz:But this is going to happen anyways if we put it in the engine API, and it off… it actually helps the protocol having these payments,
potuz:outside of the churn of the withdrawal, so I'm not opposed to this kind of payments being even the default.
Shane Moore:Yeah, I mean, this is gonna be the most, like, used value.
Shane Moore:comparison to the normal in-protocol bid, then that's, I guess, a strong Point for it.
Justin Traglia:Parents?
terence:I'm not so sure how I… like, I guess, I mean, this is, like, an open question for me. It's like, do we… like, does it matter whether the EL client is, like, ready at day one? Because you can think of, like, EL client, like, this makes it more like an optional type of field, that EL client, for example, is not dependent, because, like, for example, the payload is not gonna be invalid if it doesn't pay this bid, right?
terence:I presume. So, basically, the EL client just kind of tells you, for example, that it's not, like, satisfied, and then you basically just log in on the CL client side, or you can also
terence:Blacklist the builder, for example, but, like, are you thinking to make this, like, a requirement such that if it doesn't satisfy the bid, you just return the invalid payload or something?
potuz:No, no, not at all. I mean, this is a trusted thing, so why… why would we, like, make it invalid? Also, because then it… the client… the proposer itself can try… can try to trick it.
potuz:And I don't think we want to even change the engine API for this, so to have a check that the fee recipient increased by something, you can just use the ETH API for this, like what we used to do for deposits.
potuz:I don't know, perhaps in the future, we can just ask on new payload.
potuz:if the… if it did satisfy… I mean, we kind of have that in the engine API as well, that when you send new payload, the engine replies with, what was the value for the field recipient? I mean, we can talk about that too.
potuz:And we can add this check to the engine API.
potuz:But in principle, it's not really necessary.
terence:Okay, yeah, because I thought you were going to do it at the NG API, but it doesn't have to be, yeah, because I thought because you want to do the, censorship on the NG API, you might as well do this one as well, but yeah, got it.
Justin Traglia:Is this something that needs to be brought up at ACDC, next, or next week?
potuz:I don't think so. This is, this is just a minor thing on… as of now, it's just a minor thing of moving something that is not yet in the beacon… in the builder API, adding it to the… to the bid.
potuz:If we do need to change the engine API, which I'm going to propose anyways, depending on what's going to happen with Fossil.
potuz:Then we can just bring this to the engine API.
potuz:And we can bring this to ACD, or ACDT, perhaps, to…
potuz:to discuss what change… I mean, if the changes to the engine API are bad.
Justin Traglia:Nope.
Justin Traglia:Maybe.
potuz:It's easy how it looks on the Engine API. So on the Engine API, when we send
potuz:And notifying new payload, Then, when we are sending this, we need to send the fee recipient
potuz:And when we receive a reply about if it's valid or syncing or whatever it is, the engine should reply of what was the increase in the value on that fee recipient.
potuz:What was the change of state from before the payload to after the payload on that fee recipient that we just sent?
Justin Traglia:Got it.
Justin Traglia:If you open up PR, we can discuss it there, like, and if it gets enough approvals, we might just be able to merge it before ACDC.
potuz:But the way, this can probably be done directly on the CL side, if we parse… I mean, I know everyone is going to be against it, and I'm going to be against it as well, but if we parse the block-level access list, we could just do this directly on the CL side.
Justin Traglia:parse the L and the CL.
potuz:Well, it's in the payload.
Justin Traglia:Yeah, I don't know. Personally not a fan of that.
potuz:Yeah, I definitely… yeah, I don't like it either.
Justin Traglia:And Francesco, brought up the idea of, like, maybe just having an enforced payment Boolean instead.
Justin Traglia:My opinion is that I'd rather just have value.
Justin Traglia:If we're gonna do this.
Shane Moore:Is there a benefit to enforced payment if you…
Shane Moore:Right now, we're looking at the bid, and you saw value and, like, the protocol value. You wouldn't really know which one was, like, selected in the end, but if you have the enforced payment Boolean, at least you could tell by looking at, say, like, the bid.
Shane Moore:Oh, okay, we're basically gonna ignore the protocol value here.
Justin Traglia:Otis, do you have an opinion on this?
potuz:I didn't understand what is this enforced payment boolean, so…
Francesco:I'm just saying, like, instead of having value and off-peracle value, just have value, and then a boolean that says if value is to be enforced or not, and if it's not to be enforced, then it's just an off-protocol value.
potuz:Oh… Okay, so this in the bid, you mean?
Francesco:Yeah, in the… in the bid.
potuz:Yeah, that's gonna be a larger change.
potuz:Both in the spec, and it's, like, kind of ugly to reason about. Currently, if we just added this off-protocol value.
potuz:We can just deal with it however we want.
potuz:But, so I can just ignore it as a client and not accept off-protocol values if I have this feature flag, or whatever it is.
potuz:Yeah, I don't know.
Justin Traglia:I also think I might have misunderstood. Would value be set to the off protocol value if enforced payment is false?
potuz:Yeah, but also, like, builders might want to actually have two different values, like, they might want to say, take this if you want to accept an in-protocol bid, and if you are willing to accept an off-protocol one, then I'm gonna pay you this other thing. And instead of sending two different bids on two different channels, or putting up two different endpoints.
potuz:This for off-protocol payments, and this for in-protocol payments. They can just send one bid with both values, and the proposer can choose.
Francesco:But, like, if you send one bid with both values, like, aren't they both gonna be… like, aren't you gonna make two payments at the end of the day? Like, how does…
Francesco:I mean, the protocol value is always enforced.
potuz:Yeah, yeah, that's true.
potuz:I don't know. Yeah, this is a problem of speaking up without thinking.
potuz:I don't know how we would enforce one or the other one, I don't know.
potuz:Yeah, I guess I'm gonna have to send two bids anyways.
Francesco:I mean, like, I don't really care too much about this, but just to say, like, I guess one slight benefit of this enforced payment thing is that if it's off, then you can just not run any of the logic that's related to the payment. But yeah, I don't know. Maybe it's even worse, because, like, now you have two, kind of, like, different paths in the.
potuz:Yeah, that's what… that's what I'm worried about, that you need to change the spec in, like, to dealing with this, and it's sort of like having a Boolean in the… I don't like this thing of having control booleans on helpers.
Justin Traglia:Alright, POTUS, could you open up PR for this, or is it too soon to do so?
potuz:I can. I was hoping to wait,
potuz:A week or two. I want to see what's going on with Fossil.
potuz:Because if we… if Fossil is accepted, then we already have this satisfaction of the inclusion list in the engine API. But if FoxSil is not accepted, then I want to have some sort of signal from the EL that there was censoring in the block, in the same, in the same call.
potuz:I can probably open the… just the spec for the… the value on the bid.
potuz:which is on the Beacon chain, on the consensus spec, and then the engine API… I tried to convince Shane of doing it.
Justin Traglia:Okay. It's okay. It's alright if you want to wait a week or two as well. I get that.
Justin Traglia:And this is a pretty good transition into your next topic about adding a censoring flag to the engine API.
Justin Traglia:Do you want to talk some about that? What are the benefits of this?
potuz:Oh, that's… that's a very simple thing. The, the…
potuz:EL clients, most of them, I think, have already implemented this logic already in the… for… for inclusion list. They… they have a way of, picking, what transactions they want to include in the inclusion list, so they have… they are tracking some transactions. And Nevermind even already has this Boolean to say that there has been
potuz:Some censoring going on, because they see some transactions that have stayed in the pool.
potuz:So, what I was hoping is that the EL will have some notion of some transactions that they locally see that they should have been included.
potuz:and they weren't included, for example, transactions that have been sitting in the pool paying, and they could have been included before, and they weren't, or transactions that,
potuz:That were reorged, and, for example, they appeared on a blog, then the reorgan blog didn't include them.
potuz:Those are the most dangerous ones.
potuz:And then if the EL has this notion, and then they see a blog on Notify New Payload, they see that some transactions that they were tracking for a while were censored, and they didn't get included, and they could have been included.
potuz:then, the Yel would just notify this on a Boolean, accept the payload as valid, but then come back with this Boolean saying, this payload was censoring.
potuz:And the consensus client can use this information to blacklist that that builder.
Justin Traglia:Terrence.
terence:Couldn't you use this to grid the builder as well, meaning you send the transactions to everyone except for the builder? I assume builders probably have, like, good memo assets and stuff like that, and then… and then the heuristic is probably generous enough that you waited long enough such that… to ensure the builder
terence:can get the transactions, yeah, just thinking out loud.
potuz:Yeah, this is not something forced anyways, and yeah, so if the EL implements a really bad heuristic, and, like, taking something from your mempool that you just arrived, and it didn't get included in that particular block.
potuz:Then I would say that's an EL bug more than a spec bug.
Justin Traglia:At which point would a builder become unblacklisted?
Justin Traglia:If ever.
potuz:I guess this depends on the CL implementation. I'm not specifying anything. I'm just leaving it up both to the EL to decide what heuristics they want to
potuz:To set this flag as true.
potuz:And to the CR to decide if they even want to act on this or not.
Justin Traglia:Got it.
Justin Traglia:Maybe we can bring this up at ACDC, next week, when discussing fossil.
potuz:I would rather wait for a decision on Fossil.
Justin Traglia:Oh, okay.
potuz:I mean, Yeah, so…
Justin Traglia:Are you saying that we might want to do this if fossil is not included?
potuz:Yeah, this only makes sense if fossil is not included. If fossil is included, this already is included as part of fossil. I mean, there's something better than this included as part of fossil.
Justin Traglia:But you're not, proposing this as an alternative to fossil, correct?
potuz:And yeah, I'm not… I'm definitely not proposing this as an alternative to fossil. That's why I don't want to undermine Fossil by proposing this on ICDC at the same time that Fossil is being discussed.
Justin Traglia:I support that. Yeah, let's talk about this two weeks from today.
Justin Traglia:Or whenever the next, EP glass breakout call is.
Justin Traglia:Okay, moving on to the next agenda item. Shane, would you like to talk about your comment?
Shane Moore:Yeah, it's kind of long, but essentially, in Process Epoch, we're doing…
Shane Moore:Process Builder Pending Payments, right? And that is going to be trying to get a quorum threshold, and let me see if I can even read it, it's kind of small on my screen. And process builder pending payments from the previous epoch… I'm sure it's making a function call to… yeah, if you can make it a little bit bigger, that would kind of help.
Shane Moore:process effective balance of it. Yeah, okay, so we're actually updating the balances on the state, before we're calling this Process Builder Pending Payments, and
Shane Moore:Yeah, I'm just curious if we should be using, like, the previous epochs balances to calculate this quorum threshold within, process builder cutting payments, or if we want, like, the new updated state's effective balance for this
Shane Moore:yeah, basically, do we just want to, like, replace where Process Builder Pending Payments is during process epoch to be before this, like, effective balance updates,
Shane Moore:Or not? And, like, what is the reasoning, one way or another? Because I wasn't sure.
Shane Moore:Because you're, like, essentially processing the builder penny payments from the previous epoch, so I kind of felt like the effective balances from the previous EPOC state should potentially apply for the quorum calculation. And, may help to, like, pull up the spec and look at it, not sure, but yeah.
Shane Moore:the end of Process Epoch, and then you can see in Process Builder, Paying payments.
Justin Traglia:Let me go to this function. Oh, actually, we're already there.
Shane Moore:Yeah.
Shane Moore:And then, like, the first thing, quorum, and you can see, like, there's a line at the top, right? Like, process the builder penny payments from the previous epoch. So I was like, okay, well, if we're processing stuff from previous epoch, maybe use effective balances from previous epoch, but that's not how, processed epoch is currently going, because we have it at the end, and it's after
Shane Moore:The effective balance updates have already been done.
Justin Traglia:I see.
Justin Traglia:I will have to think about this, son.
Justin Traglia:But, do other client teams have opinions?
Justin Traglia:Technically, I think the comment is misleading for process builder payment.
potuz:Which comment is misleading?
Justin Traglia:The… the doc string for, process Builder Pending Payments.
Justin Traglia:It says process, pending payments from the previous EPOC.
Justin Traglia:Or wait, no it's not.
Justin Traglia:I'm confusing myself, I'm sorry.
Justin Traglia:But it is using, effective balances from the…
potuz:Absolutely.
Justin Traglia:Fuck.
potuz:I think what Shane is raising is the fact that we're calling this…
potuz:we're calling this with the… with the balances. Does this come after or before processing the effective balance?
Justin Traglia:After.
Shane Moore:Yes, at the end.
potuz:processes.
Shane Moore:dog.
potuz:So… so, in principle, we might use a threshold, yeah, so…
potuz:I don't know. I don't think it matters much, but I guess semantically, it should be better if we do this before.
potuz:Yeah, I don't know. I need to think about this.
potuz:I'll…
Justin Traglia:with the… Would the fix be simply just moving it before, process effective balance update?
Shane Moore:Yeah, that's actually what I was thinking as well.
potuz:But doing it before… yeah, so changing the order of these kind of things typically, like, affects other things, so that's why I would be worried
potuz:I can't see off the top of my head if there's any danger of moving this function before process effective balances.
Shane Moore:Yeah, I mean, there's a little bit of nested stuff, so, like, within Process Builder, pending payments, the, I think, get…
Shane Moore:it has, like, compute exit epoch, and update churn as well, and compute exit epoch and update churn also will call, like, getEffective Balances as, as well, to calculate exit epoch churn, which is interesting, because, if you were to look at something like, I think.
Shane Moore:process wars and penalties, or, process register updates, like, you won't find it, like, in this,
Shane Moore:like, version of the spec. Those were, like, created in, like, I don't know, Lecture or something. But,
Shane Moore:Yeah, those guys also are gonna try to get effective balances, to be able to, like.
Shane Moore:use, the compute exit, epoch, and update.
potuz:insurance.
Shane Moore:as well, but those are, like, free, state updates. So I'm like, oh, okay, they're both trying to do compute exit epoch and update churn, but, like.
Shane Moore:those rewards ones are before the effective balance updates, but now we're having, process builder penny payments, use the same function, computex epoch and update churn, but with, like, a new state, effective balance. And that was, like, another long consistency that I noticed, and I don't know if it matters or not.
potuz:I'm not sure if it… if it actually matters at the level that… for the values that we have, but one of my biggest grudge
potuz:on the spec today, besides withdrawals, is that little helper, Computexit, epoch, and update churn. It made… since Electra, it made every reason and about any function much more complicated than anything else.
potuz:Because it computes something and it changes the state at the same time.
potuz:I really wish we just didn't have that helper, or we just split it into two different things.
Shane Moore:Yeah, and that was kind of, like, where part of my, like, dislike came from. I was like, okay, like, this is updating state using old, effective balances, for, again, like, process slashings, but now we're gonna be calling compute as epoch, update churn, updating state with.
Shane Moore:process builder penny payments after effective balances have been updated. It just seems, yeah, kind of… yeah, that was the inconsistency. So I was like, okay, if we just move it up, then at least we're gonna be using, like, the same effective balances for, compute exit epoch and update churn, state updates.
potuz:Yeah, my first reaction to this would be not to change anything.
potuz:there's two reasons. One is that we don't really change effective balances that much. And second is the fact that there's a huge difference between the threshold and, I mean, we have, like, a 20% resistance
potuz:To paying, and then, and then the reorg. So, I mean, there's a difference between the proposer boost and the quorum.
potuz:So I think, which is about 20%, and I think that can never be reached, not even close.
potuz:By effective balance changes, so I think it should be perfectly fine just to keep it as is, but I would just defer to French… oh, Francisco's already saying something in the chat.
Francesco:Yeah, I mean, I was just saying exactly this, that I… so, I mean, I think probably the right things to do is to put it before, but…
Francesco:it's almost… like, I don't think the effect is even, like… it's, like, barely measurable. Its effect, it should just be that the security margin just becomes slightly smaller, but it's, like…
Francesco:It's probably, like, a fraction of a percent.
Francesco:So I… I don't know. I think it probably doesn't really matter. One thing maybe I would…
Francesco:want to look a bit more into, unrelated to… I mean, related to this function, but, like, unrelated to the… to the security thing, is actually, yeah, the… what's happening with the exit epochs, just because I know that they're actually where things
Francesco:related to, I think, consolidations, and, like, withdrawal epochs that… where it matters the order in which things were happening in the epoch transition. So, like, if… yeah, if we're adding other things that touch the same kind of exits and withdrawal epoch stuff, maybe it's worth just checking that it's not, like.
Francesco:Kind of breaking any, any existing logic that, depending on,
Francesco:you know, certain things being, like, the only, the only ways in which, like, like, the execute or something was being touched during the epoch transition, but right now I can't, like, say that there's anything wrong, just, yeah, just something to double-check.
Justin Traglia:Is there a reason why we wouldn't want to move, process builder pending payments up?
Justin Traglia:Or is it just, no reason.
potuz:But moving… moving these things…
potuz:It's dangerous. It's hard to reason about. That's… my only fear is that, is that moving would trigger an actual bug.
potuz:It doesn't seem to, but… I don't know.
Justin Traglia:Yeah.
Justin Traglia:I mean, if we're gonna make the change, like, sooner the better, I guess.
Justin Traglia:Shane, could you make a thread on Discord, in the ePBS, channel?
Justin Traglia:And maybe we can continue discussing this there.
Shane Moore:Yeah, for sure.
Justin Traglia:Okay, thank you.
Justin Traglia:Any… does anyone… does anyone else want to say anything about this before we move?
Justin Traglia:Onto the next topic.
potuz:Yeah, just replying to Francesco in this thing. So the reason why I put everything on the end, I think it's just, historical, nothing else. We're just, like…
potuz:Any changes that comes,
potuz:It's easier to reason about changes that come to the state after we've done everything that we did before, and that's it.
Justin Traglia:Yeah.
Justin Traglia:Okay, stefan, would you like to talk about the… the thing you found?
Stefan Bratanov:Yeah, so it's something I spotted during testing.
Stefan Bratanov:Which, basically, we have a function
Stefan Bratanov:when… during the execution processing, which is verifying the prev run DAO, and that's basically using the…
Stefan Bratanov:Post, state when we have already processed the block, so the rundown changes.
Stefan Bratanov:Yeah, so I saw that Pod has already raised the PR.
Stefan Bratanov:For that, which looks good, using the bit.
Stefan Bratanov:So I guess for DevNet, we should probably… put this, and… Yeah, I mean…
Stefan Bratanov:base the DevNet on the next release, which includes this, I guess.
Justin Traglia:Yeah, we can make a new release pretty soon. I was thinking about doing a 1.6.1 release whenever there's, like.
Justin Traglia:A need for one.
Stefan Bratanov:Yeah.
Stefan Bratanov:Yeah, but yeah, putting the program down the beat looks good to me. That's what I had in mind as well.
potuz:It could be… it could be cashed in the state as well, I don't know. Putting it in the bid.
potuz:Makes it, it doesn't, yeah, makes it so that we don't need to be looking in the state.
Stefan Bratanov:Yeah, I think it's better in the bit.
Justin Traglia:And POTUS, why did you put Pref Randall where it is? Just curious. Any logic behind that?
potuz:In the… you mean the position in the… in the container?
potuz:I don't know, there were a bunch of hashes before, so…
potuz:Put all the hashes about in the same place, that usually alignment is good there.
Justin Traglia:Okay.
Justin Traglia:I was just curious, because of our previous discussion, on just adding things to the end.
potuz:Yeah, but this… this thing doesn't exist, right?
Justin Traglia:No, it doesn't. Yeah.
Justin Traglia:Okay, thank you. If clients can approve this PR, I will try to merge it as soon as I can, or as after I review it, and everyone else has.
potuz:Actually, what worries me the most is what Terrence is doing, and I'm definitely not going to do. Why in the hell test would pass? I mean, how can test be checking, be passing at all?
potuz:My guess is that the tests are constructing the payload after
potuz:the block has been constructed. And this is just a logical error.
potuz:Like, no test could ever pass on Gloas.
Stefan Bratanov:Is it not, like, separate processing? I mean…
potuz:Well, but you cannot construct a payload, so today, we cannot construct a payload that actually passes until you have seen the block.
potuz:Right?
Justin Traglia:Terrence?
terence:So the only test we really, really add in and spend time on are the SSD static, and then the block operation and process EPOD test. I think every other test, we just assume it works, hopefully it works.
terence:But we never really look into why, how, and what those tests are. So, yeah, we definitely need to spend more efforts on just, like, the sanity test, like, the block, and just the test that tests the whole stage transition function across multiple slots, or blocks.
potuz:But don't we have tests, like, for process, oh, I see, so probably the tests that check for process execution, payload?
potuz:they… They only focus on that particular function.
terence:What?
potuz:Already have the… yeah, okay, so this…
potuz:Yeah, this can only be caught if we test both at the same time, the block and the payload.
potuz:Okay, I can add a regression test in that PR for this particular issue.
potuz:But definitely not…
potuz:I'm not willing to write a test that, that does both things, the block and the payload. That seems complicated.
terence:Yeah, yeah, I say just add the test for the assert, the deadline.
Justin Traglia:Yeah.
Justin Traglia:Agreed, and then I can talk with Leo about adding More extensive testing.
Justin Traglia:Leo's kind of in charge of the consensus spec tests.
Justin Traglia:So…
Justin Traglia:Okay, is there anything else people want to talk about?
Justin Traglia:I think that was the last agenda item.
potuz:Can we go back to the bid thing? Because this can be probably added to this.
potuz:So…
potuz:Is there a… is there a preference for the… I don't… it wasn't clear to me if Shane and Francesco both preferred the bullion or the value on the bid?
potuz:If it wasn't a strong preference, then I would prefer to add the value directly. To me, it's easier to think about implementation that way.
potuz:I can just ignore it.
Shane Moore:I don't have a strong opinion.
Francesco:Yeah, I mean, me neither.
potuz:Okay, then… then I'll open the PR for the… for the… do you want me… do you guys want me to add the value and the same thing for the random mix?
potuz:And then we just fixed both at the same time?
Justin Traglia:I would prefer separate PR.
potuz:Okay, I'll open, I'll open too.
Justin Traglia:Are you just gonna name the field off protocol value?
potuz:God damn it, I'm horrible with names. I'll take it, whatever you give me.
Justin Traglia:I… I don't know.
Justin Traglia:I mean, that sounds fine to me.
potuz:Trusted value?
Justin Traglia:No, I don't want to use trusted and trusted.
Justin Traglia:I think that confuses people.
potuz:Off protocol volume.
potuz:Or EM, execution layer value, or something like that?
Shane Moore:Yeah, protocol value sounds so odd to put in protocol. It's the most logical thing, too, at the same time.
Justin Traglia:Yeah, I really don't know.
Justin Traglia:I can spend a little bit of time thinking about it, but currently, all protocol value is the most clear thing to me.
Shane Moore:I think it's best. It's weird, funny, you know?
Justin Traglia:Trust me, bro, value. Yeah.
Justin Traglia:Don't know.
Justin Traglia:Yep, I'll think about it.
Justin Traglia:Okay, anything else from anyone?
Justin Traglia:Okay.
Justin Traglia:Thank you, everyone, for attending. Talk to you in two weeks, or whenever the next breakout call is.
potuz:Thank you, guys.
Shane Moore:babe? Bye.
Justin Traglia:Bye, everyone.
Pooja Ranjan:Thank you.
Chat Logs
00:05:21
potuz:https://github.com/ethereum/consensus-specs/pull/4728
00:05:24
potuz:last minute one
00:08:03
terence:i think we want to update the test to assert the line committeed randao vs payload randao
00:08:07
potuz:caleb?
00:08:15
potuz:ah Caleb logged in and left
00:11:44
Francesco:Also might just be nice for ex-post transparency of the auction
00:12:15
Justin Traglia:Yeah that’s my issue with it too
00:13:01
Francesco:Other option could also be to just add a single bit, that says whether or not the value should be protocol enforced or not
00:13:22
Francesco:value (same as now)
enforce_payment: bool
00:14:27
Francesco:Replying to " value (same as now..."
(And of course if enforce_payment is not set the state transition just ignores the value)
00:16:41
terence:i wonder if execution api (not engine api)already support this today, for example if you know the index of tx? or check the balance of an account pre or post block.. minus if you have withdrawal amount
00:26:50
Francesco:Personally I wouldn’t care too much one way or another because anyway the balance changes between epochs are bounded and quite small
00:27:19
Francesco:Using new balances could be thought of as a very slight security reduction
00:34:38
Francesco:Assuming someone has deeply thought about it being where it is now in the first place 😆
00:36:53
terence:+1 in the bid
00:37:36
terence:can we add a test to this plz
00:40:44
terence:no preference for me
00:41:51
Francesco:el_payment
00:41:54
potuz:bid.trustme_bro_value
00:42:07
potuz:el_payment is good