Parithosh Jayanthi:Yeah, so let's get started. First thing on the agenda today is, existing DevNet updates. Could we start with maybe Barnabas and then Stefan?
AllCoreDevs - Testing #077 — BAL Breakout
AllCoreDevs - Testing #077 — ePBS Breakout
Transcript
Barnabas:Sure. So, EPV as an has been broken, basically, from the get-go. They've been trying to recover it, without much success.
Barnabas:Since then, there has been some progress on, ePBS development, and we're gonna have a breakout where we're gonna be deciding, whether we're gonna be changing the beacon state to make it a bit more simpler, and then with that change, we would be just relaunching DevNet, 2.
Parithosh Jayanthi:Okay, I guess there'll be more on that topic in the breakout room, but in the meantime, Stefan, do you want to give an update on block-level access lists?
Stefan Starflinger:Yeah, sure. So we launched BalDevNet 3 on Wednesday.
Stefan Starflinger:And it went decently well, and then once I turned on some transactions, we saw, first Nethermind, fork away, and then, it seemed that Geth, had a disagreement with a lot of, the clients.
Stefan Starflinger:And it might be related to, also.
Stefan Starflinger:this issue, that I, raised against the EIP.
Stefan Starflinger:So it seems that there… if there isn't enough, gas left, state gas left in the reservoir, it tries to use, take it from gas left.
Stefan Starflinger:And then there seems to be a discrepancy in how that is treated. Some are using the gas from gas left as regular gas, and some are using it as state gas. Geth, I think, used it as state gas, and all the other clients considered it as regular gas.
Stefan Starflinger:So, I think, it would be good to get an understanding here. Maybe this clarification to the EIP is enough, and we should figure out in the breakout call what is the right behavior. I think also Marius found some other issues.
Stefan Starflinger:And, yeah, I think Spencer also mentioned something regarding how we best approach fixing some parts for BalDevNet 3, and then going on to Balddefinite 4.
Parithosh Jayanthi:For the 8037 topic, should we discuss it now already, or is it more appropriate in the breakout room section?
Stefan Starflinger:I think the breakouts would be good.
Stefan Starflinger:For it.
Parithosh Jayanthi:Oh, okay.
Parithosh Jayanthi:Oh, sorry.
Stefan Starflinger:And I also created a spec sheet for BalDevNet 4. I'm not too opinionated on how much we should still be putting work into BalDevNet 3, and when we should make the cut up for BalDevNet 4. I think that's something we can discuss also in the breakout room.
Parithosh Jayanthi:Like, what are the… What are the major changes between the two?
Stefan Starflinger:So there are, I think, 5 issues, and I think 2 or 3 of them
Stefan Starflinger:That are referenced, as the open spec decision.
Stefan Starflinger:kind of issues, in the BalDevNet spec. I think, two or three, what Spencer said, we can already include and iterate on in BalDevNet 3, and two of them, would require too much change, and they should land in BalDevNet 4.
Stefan Starflinger:Maybe, Spencer, if you would like to add something to that, your reasoning?
spencer:Yeah, hey guys, I think, I think it would be nice to…
spencer:Basically, a lot of what we have now for DevNet Free, there are open questions.
spencer:And I think, yeah, Maria posted, this open questions doc, I can… Maybe link it here…
spencer:And I think .3 to 6 right now, as far as I understand, and all of the clients are in consensus with eels.
spencer:And the spec for 3 to 6.
spencer:So my feeling is that 3 to 6, we just need to add the spec clarifications to the EIP text.
spencer:And then…
spencer:We'll add tests for that, and then it means that DevNet Free, the spec is the same?
spencer:The EIP text has just been updated, and we have tests for everything. And then for DevNet4, we actually focus on
spencer:Things that will actually modify the spec, and change the tests.
spencer:Including adding the dynamic, Cost per state bite for 837.
spencer:But we can, we can chat more about this in the breakout rooms.
Parithosh Jayanthi:Yeah, Maria?
Maria Silva:Yeah, I just wanted to… to add a point. So I do think we need to discuss also points 3 to 6 in my doc. So I think,
Maria Silva:Spencer said it's true, like, the current science and the spec are aligned, but I don't think I'm fully convinced that the current design is the right design, so I think definitely we'll need to have a discussion on this, and if we figure out that we should go with the design that is not currently implemented, then this would be a bigger change.
Maria Silva:and so we may need to include it in all DevNet 4.
Maria Silva:But yeah, I agree that, we should have a longer discussion on these, during the breakout.
Stefan Starflinger:Okay, that's fair.
Parithosh Jayanthi:Sorry, go ahead.
Stefan Starflinger:And apart from the discussions on AT37,
Stefan Starflinger:I would propose adding, 7976 and 7981, as something, that we can discuss, about adding to ValdevNet4.
Parithosh Jayanthi:Yep, Ben?
Ben Adams:I'd like to add, maybe 780 to that list, because since it affects every single transaction, it would be good to…
Ben Adams:Gets out of it early.
Parithosh Jayanthi:Oh, sorry, could you describe 2780 again?
Ben Adams:Dropping the transaction… base transaction, yes.
Parithosh Jayanthi:Got it. Maybe we can talk briefly about timelines for the two DevNets. So, when is PAL DevNet 4 meant to be launched, and would it be able to accommodate such change?
Stefan Starflinger:Regarding the timeline, it would be nice if we could launch it before interop, so,
Stefan Starflinger:regarding a date, I think the latest I'd want to launch it would be on the 29th, of April.
Stefan Starflinger:And I think, 27… What was it, 80? Would take, I think, considerably more time.
Stefan Starflinger:To add.
Parithosh Jayanthi:Yeah. Ben, what do you think? What's the implementation complexity like?
Ben Adams:I don't know if it's too hard, but I, I mean, it would have…
Ben Adams:Potentially a significant effect on the tests if they're assuming certain… Gas.
Parithosh Jayanthi:Yeah, Dan?
danceratopz:Hey everyone, yeah, Guru already put a PR for execution spec up for 2780,
danceratopz:And already added quite a lot of new tests for it.
danceratopz:And yeah, Ben's right, like, there are quite a few
danceratopz:Updates for the older tests as well, required?
danceratopz:I think most of it's in place, at least from the spec side.
danceratopz:It's pretty ready to go, barring edge cases, of course.
Parithosh Jayanthi:Okay, let's do Maria and then Tony.
Maria Silva:So maybe this is related to what Tony wants to say, but, he asked about the fact that 2780 is still waiting on benchmarks, so to give some context there.
Maria Silva:what this EIP is doing is it's breaking down the current intrinsic cost of a transaction into its various components.
Maria Silva:And some of those components are state access-related components. They are, like, read of an account.
Maria Silva:or read off an account with codes, these sort of things. And it's true that we still don't have final numbers on those, so those parameterizations will be updated once we have the final numbers for the state access EIP, which is the AT38.
Maria Silva:But this doesn't mean that we…
Maria Silva:We could potentially start working on the implementation
Maria Silva:Of the logic of breaking out these components.
Maria Silva:And then…
Maria Silva:essentially, we would be just changing the parameters' values once we have them. And so I think we could, in principle, start implementing 2780,
Maria Silva:Before having the final file and numbers, because the… most of the work will be in this logic of breaking out, like, the intrinsic cost into its various components.
Parithosh Jayanthi:Yeah, Tony and then Spencer?
Toni Wahrstätter:Yeah, I very much agree with what Maria just said, and basically wanted to bring up something very similarly. One thing we must also consider is that 2780
Toni Wahrstätter:Currently, for example, the cost to call an EOA, so an account with no code, is so cheap that it would introduce a new worst-case block size.
Toni Wahrstätter:Which is something we should also reconsider, like, there is no use case for calling, UAs so cheaply, and this is because, there are different costs for calling accounts with code versus without code.
Toni Wahrstätter:Yeah, I would just echo what, Stefan said, that data EAPs, are rather small and very much contained, so I think they can be added. I'm not sure if we can make it, until interop with 2780.
Toni Wahrstätter:Especially because there's still, some work to do with 8037.
Parithosh Jayanthi:Yeah, that's fair. Spencer, do you want to add to the same topic, or is it a different one?
spencer:Yeah, I just wanted to ask, like, maybe we could circle back to this question, next Monday? I think we could…
spencer:At least on the test side, see if there are any major conflicts with, AT37.
spencer:And then, if there are too many, then we can maybe push it to a later DevNet, but if it seems like it's feasible, then we could consider adding it.
Parithosh Jayanthi:Yeah, that sounds, reasonable to me. Ben, would you be able to work on the implementation side, so we can also get a grasp on how difficult it would be? So then we would have a better understanding of testing, we'd have a better understanding of implementation, and we can take a call next week. But currently, yeah, I think I'm leaning towards…
Parithosh Jayanthi:fewer EIPs and more stability, at least going into the interop event.
Ben Adams:Sure.
Parithosh Jayanthi:Awesome. Yeah, also just echoing Barnabas's comment, currently at least prefer
Parithosh Jayanthi:a stable base that we can discuss on at Interop. So, this can be an active discussion topic for, when we're in person, but we don't want to block other progress on it.
Parithosh Jayanthi:Great. So, we have a timeline for Battle DevNet 4, yeah, Tony?
Toni Wahrstätter:Can we quickly take a final decision on 7976 and 7981, the two data EOPs?
Parithosh Jayanthi:Sorry, I would assume that if they're small enough, and it is a non-controversial change, that we include them for BalDevNet 4. Is that…
Parithosh Jayanthi:A reasonable path forward.
Toni Wahrstätter:Yes, I would say so. So, just to summarize, there was, I think it was, they were very high ranked at the client priors originally. Then, the survey that Bhuta did also showed that the ecosystem has no concerns with them, or very minimal concerns.
Toni Wahrstätter:And it would be nice to just be able to test, what the maximum block size will be, especially now that we're adding block-level access lists, too.
Parithosh Jayanthi:That's fair. Yes, let's include the two in Bell DevNet 4, and as Stefan said, let's aim for before interop.
Parithosh Jayanthi:Assuming that we will have some delays, and we can at latest get it running during interim.
Parithosh Jayanthi:Yeah, any other comments for block-level accesses DevNet 4?
Parithosh Jayanthi:Cool. Do we want to discuss EPBS DevNet 2, or is that reliant on the breakout room decision?
Barnabas:Yeah, we need to go to the breakout for that.
Parithosh Jayanthi:Okay, cool. It feels like there's a lot to discuss today, and more, relevant breakout room-related stuff, so, if there's… I'm just gonna ask for, as a last call, for any shared room discussions. If not, we'd yield more time to the breakout today. Yaputos?
Potuz:I'm not sure if I am audible.
Potuz:Can you guys hear me?
Parithosh Jayanthi:Yes, we can hear ya.
Potuz:Good. Yeah, so there's something that is contentious to… to…
Potuz:contingent to the breakouts, but anyways, I'd like to ask here, because we'll need some ELDATs. There is a proposal to change something on EPBS that would allow us to actually sync, range sync.
Potuz:Without requesting payloads at all.
Potuz:And, yeah, so I'd like to have a discussion about that.
Parithosh Jayanthi:Okay, then I would propose that we do this right now, because at least on the order of things, I think figuring out this topic is higher than, AD37 changes. So, yeah, you have the floor, Potus. Do you want to give context, and then…
Potuz:Yeah, I can… quickly describe what the situation is. Today.
Potuz:When, when we do range sync, there are essentially two scenarios.
Potuz:Let's say that you want to… you'd spin up a node, and you want to sync over the last 5 days of blocks.
Potuz:And your finalized checkpoint happened just one day ago. So you have 4 days of
Potuz:Finalized, blocks that you're gonna sync over, and then one day of something that… where the chain hasn't finalized.
Potuz:We start from our previous head, or our previous finalized checkpoint, whatever it is, and we start requesting all blocks by range.
Potuz:We get both blocks and payloads because the payload is now included within the block.
Potuz:We do the state transition on the consensus layer.
Potuz:And, well, clients here differ in what they do.
Potuz:Some clients validate the block hash themselves.
Potuz:Other clients, like Prism would send the new payload to the EL, and the EL would validate the block hash.
Potuz:and return syncing, or if it actually manages to sync it, it will just return valid. And we advance this way.
Potuz:However, There is a proposed change on EPBS
Potuz:that, I mean, of course, now, with the current Hegota spec.
Potuz:We can do the same sort of syncing, it's just that now the payload comes in the envelope, so we request, by range, the blocks.
Potuz:and by arrange the payload, then the CL is in charge of interleaving them, finding out which payloads actually became canonical, and then you sync them one by one, you affect… you do the state transition for the consensus block.
Potuz:And then you do the state transition for the payload, and so forth. And then you do the new payload again.
Potuz:The proposal for changing the PBS will remove the state transition from the payload.
Potuz:That means that the CL can actually do all of the state transition without ever knowing
Potuz:That the payload… well, knowing that the payload was there, but without ever validating the payload, without ever validating the block hatch.
Potuz:And that's where my question lands.
Potuz:What happens if you range sync without requesting payloads for all the finalized sections?
Potuz:and we do all of the state transitions on the CL,
Potuz:We assumed that the block hash chain was fine on the EL,
Potuz:and then we just send an FCU, or a new payload, and start sending new payloads only on the unfinalized section. Will this make a client that just is starting out possibly sync through a finalized invalid block?
Potuz:I suspect yes.
Parithosh Jayanthi:Is there some EL dev who'd be willing to speak up for this?
Ben Adams:Do you mean, will we jump ahead to… Too far ahead.
Ben Adams:And not have anything behind two real people.
Potuz:I don't mean anything, because I don't know how you guys think. I suspect that you're going to start downloading a snapshot, and that snapshot could be based
Potuz:On an already finalized state that already includes an invalid block.
Parithosh Jayanthi:Yeah, Lukash?
Łukasz Rozmej:So, I remember having this discussion with Peter Shilagi at some point.
Łukasz Rozmej:that when we are doing snap sync, so when we are firstly getting… so, let me maybe describe… this is the scenario when you need to catch up to the chain, like, you have a stale node, and the strange sync is when you're catching up, right? It's not the first sync.
Potuz:Correct.
Łukasz Rozmej:So, currently, Nethermind, will replay all the blocks, so if we, in this, in this long chain, there will be an invalid block, we will catch that.
Potuz:But how do you get those blocks?
Łukasz Rozmej:We will get it from the network.
Łukasz Rozmej:So…
Potuz:Get them yourself.
Łukasz Rozmej:Yes. Yes, we will get them ourselves from the network. If you want, pass them to us, and you will go forward. We will request them from the network, and we will replay all of them. But potentially, clients…
Łukasz Rozmej:could redo the healing phase, for example, of SnapSync, and, or… or… okay, if we'll have balls, we will just do balls, so…
Łukasz Rozmej:That's also not a big deal. But balls will be only available for some time. We are discussing how long, so I think it will be at least few weeks, but, we'll see.
Łukasz Rozmej:So, yeah, there are, like, multiple ways of doing that, and some of them could potentially…
Łukasz Rozmej:not detect that the block was invalid, I think.
Łukasz Rozmej:We all trust, kind of, that it's… you say it's finalized, so we… We might not validate it.
Łukasz Rozmej:Currently we'll definitely… Nethermind will definitely validate it, and I think most of the clients will, if not all, but I'm not… I'm starting to think what will happen with balls, and I'm not sure.
Justin Florentine (Besu):Yeah, so I actually wanted to ask you, Lucas, are you guys checking a consensus state on the things that you are re-syncing? Because we do something similar, where we do a backwards sync, we follow the hashes all the way back, and then we replay them forward, but we don't check the CL in any way, so we have no notion of, like, whether things have been finalized or not.
Łukasz Rozmej:Well, we don't check CL, but we are replaying the block, so we… if the block will fail, we won't accept it, right?
Potuz:The CL should be fine here. We checked the consensus side on our own. The problem is, if you guys
Potuz:If… if we… the question is, should we actually force ourselves to check the block hash?
Potuz:To avoid sending you blocks, or can we even avoid that, even the check for the block hash itself?
Łukasz Rozmej:What do you mean, checking the block? I'm not gonna…
Potuz:Well, if we say that we have a chain of blocks.
Potuz:that we want to sync, we will perform this state transition on the consensus layer, and this state transition would include… the consensus block would say, my latest block hash was this, I am building on top of this execution payload.
Potuz:that has this particular block catch. We can check that the promise
Potuz:of those block hash chains is actually, well, we can check that this block hash is based on the parent block hash and so forth, but these are all promises. We… we are not actually doing the hash on the RRP of the payload, because we don't even have the payload. In principle, it could be
Potuz:That one of these payloads was invalid, that its block hash was not what it promised it to be, and we wouldn't even find out if we actually didn't request the payload to check that the block hash was what it promised to be.
Łukasz Rozmej:Okay, so you potentially will give us a block hash that… is invalid, so we might not be able to find it in the network in the first place.
Potuz:Correct.
Łukasz Rozmej:So, then we'll kind of be stuck by not finding it in the network, because we cannot validate something we cannot even obtain.
Potuz:That's fine, but then that means that you always will try to get all blocks and connect to a chain that you know, and all clients would do this, so there's no snap-syncing from a particular state, and taking that state as finalized and valid, and continue from there.
Łukasz Rozmej:generally, that was the consensus when we were doing the merge, that we… if we want SnapSync, we won't snap sync again, right? So we do that snap syncing at the initial sync, right, of the…
Łukasz Rozmej:Of the train, but that's what we have to do.
Parithosh Jayanthi:And he cooked.
Łukasz Rozmej:But again, I'm not sure how it's… I haven't really thought how it will, be working with balls, so I'm not entirely sure here.
Enrico Del Fante (tbenr):I was just to, add the question. Is this a situation that is definitely not new? Because you cannot assume that your EL down…
Enrico Del Fante (tbenr):you are using is in sync, you can somehow swap or wipe out the database with URL, and then anyway, URL needs to start syncing.
Enrico Del Fante (tbenr):while CL is still… still following the chain, and optimistically, so…
Enrico Del Fante (tbenr):the EL needs to, anyway, find out the blocks and replay everything.
Potuz:Yeah, but the thing is that when we sync optimistically, we actually have the payload, and we either
Potuz:Verify the block hash ourself, and then we avoid to send that payload.
Enrico Del Fante (tbenr):Yeah, I mean, are we doing?
Potuz:on the EL to sending us the syncing reply. My question is, can we do this without ever touching a payload?
Potuz:And then trusting that the EL is going to get those payloads on their own.
Łukasz Rozmej:I think so, I think yes, but again,
Łukasz Rozmej:we can get stuck if we won't be able to find those payloads in the network, for example, right? So there are situations where we could get stuck.
Potuz:That's… that's absolutely fine. I mean, getting stuck is not my problem. My problem is, if we… if I make prison never to request a payload.
Potuz:Am I risking someone that follows the chain to actually say that a block that is invalid being valid?
Potuz:So that's my only fear, and I really want… I want to use this feature because it's something completely new that we can actually range sync. It's very fast. It's going to be… it's… in my mind, this is a game changer, the fact that we can actually range sync without ever touching a payload. It's much faster to catch up.
Łukasz Rozmej:So, in my opinion, you should be fine, but,
Łukasz Rozmej:Yeah, I'm happy to hear Avar's opinions.
Parithosh Jayanthi:Enrico?
Enrico Del Fante (tbenr):Sorry, it was remaining up.
Enrico Del Fante (tbenr):But, yeah.
Parithosh Jayanthi:Okay.
Enrico Del Fante (tbenr):I think they.
Parithosh Jayanthi:do you feel like you got your answer, Potos?
Potuz:It seems that Nethermine says that it's fine. Thanks, Lucas, but I'd like to, like.
Potuz:have it here, it's on the record. I'd like to get an okay from other Yale devs, or at least have a validation of this.
Parithosh Jayanthi:Yeah, Tony.
Toni Wahrstätter:Yeah, it would be nice, Protos, if we could, document that somehow in written form. I would also like to look into it.
Parithosh Jayanthi:Yeah, yeah, I think we'll get it in writing, and then, have all the ELs act it.
Parithosh Jayanthi:Okay, cool. That being said, any other general topics we need to discuss with everyone, before breakout rooms?
Parithosh Jayanthi:Okay, then I will create them…
Barnabas:Harry, can you make, mark and David, co-host, so they can record these sessions.
Parithosh Jayanthi:Yeah, one second, sorry, give me a second.
Parithosh Jayanthi:Okay, David is co-host, anyone else?
Parithosh Jayanthi:Okay.
Parithosh Jayanthi:Mark, one second.
Barnabas:I don't.
Parithosh Jayanthi:Trying to find… yeah.
Parithosh Jayanthi:And,
Parithosh Jayanthi:Okay, perfect.
Parithosh Jayanthi:The rooms are being created now.
Parithosh Jayanthi:You should be able to… you should be prompted to, choose whichever breakout room you want.
Parithosh Jayanthi:If you're unable to, I can add you later.
Parithosh Jayanthi:I can add you to… oh.
Parithosh Jayanthi:Why can some people not see it?
Parithosh Jayanthi:Interesting.
Parithosh Jayanthi:I will add whoever can't see it.
Parithosh Jayanthi:Nixo, which one do you want to go to?
Parithosh Jayanthi:Interesting why it doesn't work for so many people today.
Parithosh Jayanthi:I'm so blessed to it.
Parithosh Jayanthi:Yeah, if you're not able to, please hit Menu Bar, More, and breakout rooms, and you should be able to choose.
Transcript
Transcript pending
Transcripts for breakouts are not yet processed
Transcript
Transcript pending
Transcripts for breakouts are not yet processed
Chat Logs
00:01:26
Enrico Del Fante (tbenr):Replying to "crap I can't hear an..."
Yes they are speaking
00:02:26
Stefan Starflinger:https://github.com/ethereum/EIPs/pull/11522
00:03:45
Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-devnet-4
00:05:07
spencer:https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8037/spec_review_state_gas_accounting.md#3-gas_create-state-gas-pre-outcome-charge-and-eip-text
00:07:01
Ben Adams:Replying to "https://notes.ethere..."
I'd like to add 2780 to devnet4 since it effects every tx would be good to get sight of it soon
00:07:30
FLCL:any takes on devnet-4 date?
00:08:39
Mario Vega:What’s the number of the EIP?
00:08:42
Toni Wahrstätter:2780 is still waiting for the benchmarks anyway?
00:08:43
Stefan Starflinger:2780
00:12:09
FLCL:https://notes.ethereum.org/@ethpandaops/bal-devnet-4 changed and mentions other two gas changes instead of 2780. Honestly solid and stable 8037 may be enough for 4. 3 repricing eips is too much on top of it. Or include 1 something simple
00:12:15
Stefan Starflinger:if we were done (end in sight) with 8037 i'd be behind adding 2780
00:12:34
Barnabas:Would prefer stability over adding another EIP. (for interop’s sake)
00:13:00
Stefan Starflinger:EIP-7976 and EIP-7981 are much simpler than 2780
00:14:15
Mario Vega:Replying to "EIP-7976 and EIP-798..."
The changes are simple in the tests too afaik
00:14:32
Toni Wahrstätter:EIP-7976 (specs and tests): https://github.com/ethereum/execution-specs/pull/2115
EIP-7981 (specs and tests): https://github.com/ethereum/execution-specs/pull/2144
00:15:15
Stefan Starflinger:How do I get into the breakout room again :D
00:15:57
Toni Wahrstätter:Replying to "How do I get into th..."
i think there'll be a popup
00:15:58
Łukasz Rozmej:what does that mean?
00:19:36
FLCL:at least one finalized block?
00:20:03
Parithosh Jayanthi:Wouldn’t this depend on snap vs full sync?
00:20:12
Justin Florentine (Besu):yes, i think we would backwards sync right over the unfinalized section.
00:21:26
Toni Wahrstätter:For at least the WSP yeah
00:24:13
Barnabas:who is responsible for reorging in case we have a massive parallel fork?
00:24:55
Toni Wahrstätter:There is a fallback to snap sync in case the state of the parent is missing though - not sure this can be triggered for the scenarion in discussion
00:26:35
FLCL:why is it significant?
00:28:00
Łukasz Rozmej:"I want to have that in writing" ;)
00:28:10
Potuz:I’ll have a quick writeup soon
00:28:27
Justin Florentine (Besu):i remain unsure but writeup can be consulted by rest of team, pretty quickly
00:28:50
Łukasz Rozmej:@Potuz how is it different from initial sync? In initial sync you also give us Payload/FCU and we get it from the network
00:28:52
Enrico Del Fante (tbenr):I get it now what the issue is 🙂
00:29:03
nixo:marc
00:29:07
Potuz:When we do init sync we do send you the payloads
00:29:13
Potuz:LH doesn't
00:29:17
Potuz:But they verify the hash
00:29:20
wolovim:Thanks 🙂
00:29:50
Potuz:Am I the only one that doesn’t see a breakout?
00:29:53
lightclient:I dont
00:29:54
nixo:i don’t either
00:29:55
Potuz:Can you add me Pari to the ePBS one?
00:30:02
Eitan Seri-Levi:I can’t see it
00:30:15
Eitan Seri-Levi:CL breakout pls
00:30:20
nixo:EL
00:30:24
lightclient:EL
00:30:26
wolovim:Menu bar: More > Breakout Rooms
BAL Chat
10:34:09
jochem-brouwer:https://github.com/ethereum/execution-specs/pull/2657
10:39:24
Louis:I could prioritize the benchmark review
10:39:30
Karim T. (matkt):It is the same as perf-devnet-3-24358000-amsterdam-stateful ?
10:41:21
Maria Silva:This one is for repricings
10:42:37
Mario Vega:https://github.com/ethereum/execution-specs/pull/2653
10:42:50
Karim T. (matkt):Replying to "It is the same as pe..."
@Rafael Matias (skylenet) I also sent you some messages on Steel when you will have time
10:47:39
Maria Silva:https://github.com/ethereum/EIPs/pull/11523
10:47:47
Maria Silva:https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8037/spec_review_state_gas_accounting.md#3-gas_create-state-gas-pre-outcome-charge-and-eip-text
10:52:06
Łukasz Rozmej:We should default to do simplest things, 8037 is already too complicated.
10:52:38
jochem-brouwer:The refund, it is given at the end of the transaction, or also "in" the transaction in case if a sub-call frame reverts?
10:53:21
FLCL:in tx so can be reused
10:55:11
jochem-brouwer:Antwoord verzenden naar "in tx so can be re..."
ok interesting, this needs analysis from security point also re: benchmarks. e.g. write to lots of storage slots which are already warm, then revert (ensure these storage writes only eat into the reservoir and not in regular gas) and then revert to get the state reservoir refund
10:55:29
jochem-brouwer:Antwoord verzenden naar "in tx so can be re..."
(and repeat)
10:55:59
FLCL:Replying to "in tx so can be reus..."
8037 reminds a bit of selfdestruct and number of issues it caused
10:56:38
Stefan Starflinger:lets really try to make decision on wednesday
10:57:13
spencer:should we open a thread for each point in the steel discord? or is that too much
10:58:01
Stefan Starflinger:https://github.com/ethereum/EIPs/pull/11522
10:58:44
spencer:Replying to "We should default ..."
I fully agree here!
10:59:31
Parithosh Jayanthi:Lets wrap up discussions please, we’re almost at time
11:01:14
Luis Pinto | Besu:Replying to "We should default to..."
So currently (pre-Glamsterdam) refunds are only given at the end of transaction.
In reverts all gas is gone even if the state was reverted. Couldn’t we go forward without having these complexities and just gobble up the state gas anyway. It doesn’t seem to be a change in behaviour from what we have now.
ePBS Chat
16:32:51
Potuz:One of them is particularly insidious because it uses the store when it should use unchain info
16:33:57
Barnabas:PR in discussion: https://github.com/ethereum/consensus-specs/pull/5094
16:34:54
Justin Traglia:Replying to "PR in discussion: ht..."
Thanks 🙂
16:35:37
Nico Flaig:yes saw them, we can figure out those details, not sure I agree with or understand what you mean about store.payloads but let's discuss that
16:37:27
Nico Flaig:that's right, let me check that
16:39:04
Nico Flaig:I have few more selling points if people need convincing :)
16:39:53
Barnabas:Replying to "I have few more sell..."
I think most people are sold.
16:40:05
Nico Flaig:also would like to mention trade-offs i have documented (just for the record)
16:40:14
Justin Traglia:@Eitan Seri-Levi will you be able to speak for Lighthouse?
16:40:45
Eitan Seri-Levi:yeah we really like this change
16:40:54
Nico Flaig:is the max size limit by gas limit, rather ssz size limit?
16:41:30
Raúl Kripalani:https://gloas.ethp2p.dev/
16:41:46
Potuz:Requests are not compressible much though, I wouldn’t worry much about compression
16:43:02
Parithosh Jayanthi:I think sam set that page up, can you text him raul?
16:43:06
Parithosh Jayanthi:He can get it updated for you
16:43:10
Raúl Kripalani:yep will do!
16:44:58
Potuz:Reverting for us will take a long time though
16:45:06
Potuz:We already have everything in develop
16:45:14
Barnabas:Replying to "Reverting for us wil..."
can you define long time?
16:45:20
Barnabas:Replying to "Reverting for us wil..."
can we make it before interop?
16:45:34
Eitan Seri-Levi:Replying to "Reverting for us will take a long time though"
yeah I think same for us. will take a bit to revert what we’ve done already
16:45:50
Potuz:Replying to "Reverting for us wil..."
I think we could try to target interop but I’m not certain
16:47:21
Enrico Del Fante (tbenr):Yeah state replay not requiring payload is another big win
16:55:06
Barnabas:5min left
16:56:11
Barnabas:we can relaunch devnet 1 with same spec, hopefully wont break fast, and do devnet 2 with the new spec
16:57:15
Eitan Seri-Levi:I don’t see the point of testing the current spec
16:59:44
NC:Lodestar is still working towards alpha.4
17:00:45
Barnabas:can we target genesis by 24th latest ?
Summary
11 highlights
· 3 decisions · 3 action itemsExperimental
Summary
11 highlights · 3 decisions · 3 action itemsExperimentaldevnet status
bal devnet planning
- bal-devnet-4 spec created; 2-3 issues for devnet 3, remainder require devnet 400:04:04
- Points 3-6 in design doc need discussion; current spec may not be final00:06:14
- EIP-7976 and EIP-7981 proposed for bal-devnet-400:07:11
- EIP-2780 (transaction base cost breakdown) proposed; affects every transaction00:07:37
epbs technical
- Proposed: ePBS range sync without requesting payloads for finalized sections00:15:41
- Removing payload state transition enables CL-only range sync; much faster catchup00:17:27
- Risk: could client sync through finalized invalid block without payload validation?00:18:59
- Nethermind validates by replaying all blocks from network during range sync00:22:19