All Core Devs - Execution #236

Transcript

Lightclient (Matt Garnett): Hello.

Nixo: Hello, hello?

GM, guys, we'll get started in just a few minutes.

Okay, Josh, are we ready to start streaming?

Josh Davis: You are alive!

Nixo: Great. Good morning or afternoon. This is All Core Devs, number 236. It's May 7th. Today we're going to talk about the… a little bit about the progress that came out of the Svalbard interop. There is a blog.ethereum.org blog post on that if you want to catch up. We'll go over some… other changes that, came out of the progress, or that are being proposed that came out of the progress, that happened in Svalbard, and then we'll go over some proposals for I go to non-headliner proposals, AA update, and, an engine API schema fix. Do we want to start with, Barnabas? You want to give an update on the Svalbard progress and some devnet updates?

Barnabas Busa: Sure. Can you guys hear me well?

Nixo: Yep.

Barnabas Busa: Yeah, so we started out, with answering devnet 0, on the second day of in the interop. We basically included, all the, bal-devnet-5 changes and, ePBS. And then we basically, went onwards, from there. We quickly had some issues, and then we launched, Glamsterdam didn't won, just a day or two later, and In devnet 2, that was two days after that, we also added a new EIP on the CL side, I'm just gonna put all the links here. With the notes, So the new EIP was the, EIP 8061, which is increasing the exit and consolidation churn limits. We also discussed to, possibly DFI 8080, on the sales side, so…

we haven't made an explicit decision during the interrupt, but maybe this is something we can discuss next week on the ACDC. Regarding any other CR changes, we decided not to push forward during the interop week on the forward-compatible, consensus data structures on the, 7688, and we decided not to move forward with 8045 during the interopweek, Which is the slash valid, exclude slash validators from proposing. Regarding the ER side, there has been a bunch of progress, especially, 8037. There has been lots of back and forth, and hopefully we can now, have a finalized pack, with finalized numbers, but I will, probably pass the mic to someone that is more familiar with, the 8037 changes.

We have, currently, Docker Access, Ball.net 6 up and running, with the old, Lighthouse and Lodestar images. That has been quite stable, and we have glamsterdam-devnet-3, which is basically the same spec as glamsterdam-devnet-2. But we can actually keep an eye on it now. This morning, I have started the P2P bids, using Builder, and it seems like, Lighthouse was unable to stay at the head, and They seem to have some issues thinking, At this point. That's the latest on Glamsterdam demonstrate.

Nixo: Great, thanks. Stefan, do you want to, talk about ball dubnets? Prior restoring, small person.

Stefan Starflinger: Yeah, sure. So, just a quick recap, we, did some accounting change for 8037 that we went back on during Svalbard, and so we moved quickly from Baldefinite 4, up to Baldefinite 6. And Baldefinite 6 is going pretty well at the moment, but there are still some issues that were found. And I linked most of them in the agenda, so I will share a link here. If someone wants to look in more detail. And then, the idea is now to move to BioDefNet 7, with a new testing release, and that addresses most of the fixes. That were found, and, to also include the, optimizations for the benchmarks, so that we have one stable, performant, execution side branch. It's still called ball definite, but it includes all the EL changes, which is a little bit confusing. But then, this should be the final, ball definite, so EL side only.

a branch, before we only continue with Gamstrom devnets, branches, And there is one ask that, Ben made, and I just summarized it here a little bit, is maybe we should have a debug get block receipts, because the gas accounting is becoming more complicated with different variables, especially the split between regular and state gas. It would be very good for debugging to understand how much state and how much regular gas was used. This doesn't necessarily need to surface to the user, but it would be good to have something like this as a debug endpoint, and I just kind of, created a recommendation of how it could look like. Maybe later, if clients want to speak on it or have some more specific suggestions, that would be great.

Felix Lange: Sorry, could it also just be added to the receipt? Sorry, sorry, sorry. Nick, can we somehow surface it? We could also just surface it in the block, no.

Ben Adams: I mean, we could… we could do, but then, It's a… it's a lot more field. But I think it might be helpful for users to work out where they spend all that.

Stefan Starflinger: I don't know, I think we should take this async somewhere to discuss it. I'm not sure where exactly the best place for it is yet, but I think it's something that we do need.

Nixo: Okay, great. Stefan, can I just assume that you'll put that in the, EL? EL channel and, R&D, where people can go to discuss it.

Stefan Starflinger: Yes.

Nixo: Any other updates on devnets, Salbard, or, like, 8037? Maria.

Maria Silva: Yeah, so I just wanted to clarify something quickly. So, we are… working on Vol devnet 7 for next week, but at this point, we still have some clients working on some optimizations, and those should still be merged to Vol devnet 3. So, we are working on bal-devnet-7, with the fixes from 8037, and that should then, at some point next week, become our EL stable branch, but until then, for the clients that are working on the optimization still from last week, please merge them to bal-devnet-3 so we can see the results on Benchmarker. Sorry, I think I'm… I may have missed some of the numbers there, but essentially, it's, like, merge optimizations to bal-devnet-3 until we have

all devnet 7 stable.

Nixo: Great. Thanks. Alright, any devnets Svalbard 8037? Otherwise, we'll move on. Okay, so in that vein, just, like, some, process. We had talked about, an SFI definition change, at… Svalbard, at one of the sessions, I had brought this up on a call, about a month ago to look through this SFI definition. I have made the final changes, reflected… that reflected that discussion. If there are no, Objections, I'll move to get that, merged in the next… day or two. And then, based on that definition, I think that, DancerAtops had a list of EIPs, that could be, moved from CFI to SFI, that would

help both ecosystem participants know that these are the EIPs that are most likely to go in, they're being worked on, they're quite stable, there's, like, a set of four criteria in that SFI definition. And he did a draft proposal, or a draft PR to, move those to SFI in 773, so if there are any… Objections to that, please comment on that, PR. Otherwise we'll get that, we'll get that merged by the end of this week. Tony?

Toni Wahrstätter: Yeah, regarding… regarding the process, I mean, I brought it up in the… swipeout session, the only thing we should, think about is, how do we then decide what to put on devnets and whatnot. Because this is one of the criterias in that, in those four points, and we don't really have a process for that right now.

Nixo: Yes, I actually, I think that, you may have missed earlier this year, we did actually make a prioritization list for, for the CFIs that are in Glamsterdam. We didn't, like, put it anywhere, we just discussed it on a call once, and I think 8037 was number one on that list.

Toni Wahrstätter: I'm sure It's on forecast, right? I mean, I know that… I know the priorization… okay, but there was a priorization with the tiers on fork… on forecast. And… We didn't really, go… with the… with the order we had on forecast, we were randomly, like, chosen EIPs that we put on the devnet. For example, 8047 was, like, the second lowest prioritized, EIP by clients, but we still agreed it's, like, important. So I think we… we should either not overcomplicate things and just Keep the freedom there, and put things on a definite that we think, when we think it's the right time. Yeah. I don't think we should directly go by the prior list.

Nixo: So the, the prioritization list, it was, is not on forecast, I will link it somewhere, but we can… I think we're not gonna have to CFI or, like, prioritize a CFI list again until we get to the final, list for Hegota, so we can… discuss if this is still, like, a controversial, move, but I think it does help the testing teams decide what goes in, and I… the criteria listed there was that the… basically the facilitators work with the testing team, to create that prioritization list, propose it on oral core devs, make any changes the clients, think are more appropriate, and then that's quite a flexible list. So that's just reflecting what the clients think, the ordering should be what's,

Based on what can't… what can go in, what's, able to, be implemented, what's important to implement, not just what's easiest, not just what's more… most desired. And then, put that in the… in the meta. And I think the idea is that's flexible. That's not, like, a… a rule set if things change. later on, then we can move things up and down that prioritization list, but it just helps the testing teams figure out what should go in. And I think that we can bring that at ACD if anybody thinks that an EIP is misplaced on that list. Pooja?

Pooja Ranjan: While we are addressing the PR11475, which talks about the specific condition, I would like to request to kindly look into the PR11006, which actually talks about an important part of this Proposal 7723. So, basically, there is a difference between EIP stage… status and EIP stages, so I… I believe that it has not been correctly documented in the proposal, and the PR suggests that we should actually update statuses with stages wherever applicable, wherever it is related to network upgrade, not the EIP standardization process. So, just wanted to bring it to attention.

Nixo: Okay, great. That is in the chat, if you have any, preferences on that wording, please go comment on that, on that PR. If… no objections, then we'll move to, SFI those EIPs. most of those are in… I think all of them are in devnets. There was a comment that 8037 is not… But the argument for that was a… the amount of work that has been done during Glamsterdam, and the fact that it is.

Marius van der Wijden: Mmm.

Nixo: Excellent.

Marius van der Wijden: He meant 8038.

Nixo: Oh.

Marius van der Wijden: 88 is not under DEFNet, and it shouldn't be SFI at this point, but 8037 is.

Nixo: Okay, yeah, 8037, 8038 is not on that list.

Ben Adams: Yeah, I… off by 100.

Nixo: Okay. Okay, we'll move on, to 80-70 changes. Camille, are you here?

Kamil Salakhiev: Yep, I'm here. Yeah, just want to quickly highlight, yeah, changes to 8070. Yeah, we've had a good progress in Svalbard, discussing sparse blog posts. Yeah, so we merged already the changes required in Engine API, basically introducing Git blocks before, and some updates for Fortress Updated. calls, yeah, so the last piece remaining is, yeah, make some final changes to 8070 EIP to kind of narrow down, the… behavior for the builder, and, yeah, also just highlight these engine API changes. So please take a look, Yes, I believe Geth's team is actively working already, on the AIP, and, Nethermine and Besso, yeah, also. Kinda, either working or considering to start working on that soon, so… Yeah, as soon as it's implemented in more clients, yeah, we can schedule for the upcoming devnets.

Yeah, so please take a look. Thanks.

Nixo: Great, thanks. Tony, do you want to talk about clarifying the min-rec depth, without rethinking?

Toni Wahrstätter: Yeah, this was one of the points we discussed, at Interrupt 2. Basically, how far do we want EL clients to reorg back in case of a deep reorg without triggering resync? And I think some clients, like GEF, are prepared to re-og back quite, quite, quite many blocks. Whereas other clients can only react back, like, a few epochs. And it would be great if we can align on the number there. And there have been multiple numbers proposed, for example, the 128 blocks, which was the minimum there. Then there was the week subjectivity period, so about 15 to 16 days. I think Jasek also proposed To have it more like 38 days, which is… Which is, with the inactivity leak kicking in, the amount of time we need to restore finality when 70% of the network are offline.

So, we don't need to resolve that today in the call, but it would be great if people can look into this agenda item, and we can resolve This, and have yields align on that number.

Nixo: Is there a deadline by which, we sort of need to have that sorted?

Toni Wahrstätter: So, in theory, we should have sorted it today, I would say, because, Reox could have many times, and I think many clients would today just trigger, sync. I think GEF is basically ready, because Marius was at some point saying GEF can react back, like, 90K blocks or something. That would be roughly the week's objectivity period. I would just ask other clients to, look into this. And then figure out, like, what to best do in order to not fall back into SnapSync. I know that sometimes it might take a while to restore the old state by going through the state divs and apply them. But this might be better than just returning an error to the CO. So better we miss a few blocks than we fall back into SnapSync.

Nixo: Karim? Kareem, did you…

Karim Taam: Huh, yeah.

Nixo: Raise your hand. Yeah, okay.

Karim Taam: No, I said we have a pair in Bezo for that, but as I said, it would be nice to really have a… a test with a shadow fork, even if it's not something we will run a long time, just to see the behavior of the different clients in a real, real environment, with a good test close to the reality. Because, yeah, we have a PR today, but it's difficult. We can't do a big rollback, but we need also to check after the rollback, to roll forward with the new head and see how… Or the client will, work correctly with the CL, etc, so I think it would be nice to have a test. To verify that we are working correctly in this case.

And maybe it will help to define the right amount of block. Like that, if we have a test, we can try different, reorg size and decide what is the best.

Nixo: Potus… I'm gonna call him POTUS before Felix, because POTUS couldn't raise his hand before.

Potuz: Oh, yeah, I just want to make a quick comment on the issue of reorging back. I think… So this is a problem that happens on EPBS, that we might send an FCU to a previous chain on the EL side. But… I think you guys should read this post that I posted on the chat. I think we should avoid completely, and we should even probably forbid an FCU to, without payload attributes to roll back. That means these reorg's bags are only relevant to building the next block. they're not relevant for the user that is following the chain, and it's not really relevant for the CL client to send an FCU without payload attributes to go back in the chain. So I think this shouldn't really affect users. We should never try to roll back the chain, live.

on… yeah, so on regular sync. This should be only used by the proposer of the next block to trigger block production. So only builders and proposers should use this rollback, and not… no one else.

Marius van der Wijden: But… photos, that means we would need to have this reorg within the proposing window, within the 12 seconds, right? And this is not possible.

Potuz: Yes, so… so what will happen is that the proposer will find out at the, later in the slot that, his head has just rolled back. And it will only roll back by one block. Actually, it needs to… it can roll back, and in the event of an attack, of a majority attack, it can roll back up to the justified checkpoint, and not more than that. But if there's no one that has a majority of the stake that is malicious, we can only roll back one block. And it's only for the proposer to say, you need to build me a block reorgan the last payload.

Mikhail Kalinin: I have a question, Potos. You were saying a bit different stuff before, when we were discussing this change. So… What is the finish?

Potuz: that I said differently.

Mikhail Kalinin: Oh, I mean, like, that, now you're saying that, basically we don't need to do, to do, revert on the same, I mean, like, reorgan on the same chain, deeply back, even if we are syncing, right? Well…

Potuz: Duh.

Mikhail Kalinin: Yeah, but before… but before that, you were kind of, like, saying that, we have to… we need to… we need this revert, up to a finalized checkpoint. I'm just wondering if anything has changed in that time.

Potuz: Nothing. The spec is the spec. So, formally, we can have a reorg, nothing is finalized, no payload is finalized. until… It's actually finalized, so we can… in theory, you can always reorder back all payloads. In practice, the proposer is the only one that should trigger this, and the proposer In practice, and even in theory, for the proposer, can only reorg back up to justified, because no proposer would reorg its own justified checkpoint. So that's one thing. And the… the other thing is that it's… if you're not under… the only way of reorging more than one block is if there's a malicious majority.

Nixo: Felix?

Marius van der Wijden: Are you still… are you still talking about reorgs within the canonical chain, or are you talking.

Potuz: Yeah, yeah, it's only within the canonical chain, but the post that I want you guys to read is that the important thing about this is it's that the user should never see this. So, but a user that is following the chain? see a reor back on the EL. Only the proposer should see such a reor back.

Marius van der Wijden: Yes.

Felix Lange: Talking a little bit about something else, yeah.

Marius van der Wijden: Yeah, we're talking about, any reorg, not in the canonical chain.

Potuz: Yeah, that's a different story. That should be up to finalize, in theory.

Felix Lange: Yeah, so we are… what I wanted to just give a quick overview, maybe this topic can also be settled later. So there is an EIP proposed, I'm not sure, I think, Tony, you proposed it, that basically clarifies the expected reorg window. that clients have to support, and I think that is a good direction to go in, because in the past, we have just completely left it up to the client. And this has led to the situation where there are some clients that cannot reorg very far, and others that can reorg very far. So in Get, we always had this, opinion that we have to be able to support very long reorgs in case the chain will actually hit this. However, it is important to consider that a very long reorg in the chain would also have a significant user disruption.

Like, regardless, if this happens, the chain is gonna be under heavy attack. Still, it is good to clarify it, because in case of such an attack, we have to be able to recover quickly, and the only way to do that is if the clients don't fall into the snap sync. Because in the case of a sinking chain. over a chain being attacked, the snap sync efficiency will also degrade. So we have seen this in the past with testnet incidents, where even getting clients to sync is the main issue. So what we would ask is that clients extend their reorg window, and this EIP doesn't. However, just as a quick comment also about how GET handles this.

it's not actually required for clients to have the state, like, all the way back. That would make them an archive node, and that's not really the goal of requiring this. And it's also not said that reorging back the chain like many blocks has to be a particularly fast operation. We… it doesn't have to be instant. It's just… that it has to be supported at all. So I think one thing is we could… we should really start, to create some tests that exercises this. and also see how the clients behave, just so that they have this theoretical capability. And then we can just see where it goes from there, like, what we can all agree on. But this, like.

38 days period or something sounds pretty reasonable to me, because if there's a natural limit in the beacon chain for how far back it could theoretically reorg at all, we could just use that limit, and that should be fine.

Nixo: Marius, is your hand still up? Okay, POTUS.

Potuz: Just from the engineering perspective, I'm a little bit confused. Wouldn't… wouldn't this in the happy case be a no change? Like, you… if you're finalizing, then it should be fine, you should be able to reorg the last 64 blocks, or whatever. And if you're… if we are not finalizing only in that situation, you trigger being a… sort of like an archive node since that point.

Felix Lange: It's not about being archived node, this is just about the client being able to walk the chain back to an earlier state. In GET, this is achieved by storing reverse diffs of the state up to a certain depth, and we need those reverse diffs just to be able to walk the chain back in the theoretical case. It's not fast to do this.

Potuz: Yeah, no, I understand, but my point is that you don't even need to store anything if you're finalizing. You never need to reor back if you're finalizing.

Felix Lange: Yeah, this is kind of true. We could, in theory, truncate also these reverse tips to the finalization point. That's correct. So if we are certain that, like, there will never ever be a situation where we have to reset back to a point before finalized, then yes. In theory, you can delete everything before the finalized. But you have to be prepared in the client for a situation where finalization is not working.

Nixo: Great. Do we want to… take this off saying, er, offline and, discuss it maybe in that EIP PR?

Felix Lange: It would be good to get more statements from clients. I mean, the execution clients are all here, so… and you guys should all know, like, what are the limits of the org. So, just to hear it from people, what's the situation, what do you think about it? It's not a… not a slow… you can just have a quick run of thickness.

Łukasz Rozmej: So we are… we are working on supporting, reorg up to finalization barrier to make it dynamic, and that's our goal, and it will be then arbitrarily long, as… as… as… Where the finalization barrier is.

Karim Taam: In Bizzle, we have something similar to GET. We have the trilog with the prior version of each account and slot and the new value, so we just have to apply this trilog to rollback, and we already have a printing mechanism that is not removing trilog. Before finalization, so as soon as we have a finalization, we can start running the whole try log. But before that, we are keeping this dry log. We just have to… To modify the logic, to not have a… out of memory, if you have a deep preyorg, and we have a PR for that. But, thanks to that, we should not have any really limitation. Oh. can choose a big number, it will not be a problem, I think. But we need two tests, I think it just… if you have a test, we'll be… we'll be more confident.

Andrew Ashikhmin: In Erigon, the default is that we can only unwind to 512 blocks, so we probably need to make some changes to support extremely long reorgs.

Nixo: Do we have anyone from rest? Go ahead, Corinne.

Karim Taam: I just wanted to say something. In Bezoo, in order to manage the deep reorog, what we are doing is to do this rollback by batch, so we are applying an amount of shredog, we are persisting this state, and restart applying a batch of trial, etc. Like that, we can, remove the issue of out-of-memory if we have a really, big, big reorg.

emma (reth): From the Reth side, we couldn't handle the one month at the moment. We'd need to make some changes.

Nixo: Are those blocking changes?

emma (reth): Mmm… I think it would just be a bit of work for us. So, it depends. On, like, when you need it. But yeah, it would be super slow for us, like, Felix is saying from Gath.

Toni Wahrstätter: Yeah, so can we do, my feeling is that clients are all more or less, ready for that until Glamsterdam, so I think as of Glamsterdam, we can assume that EL clients will be able to react back the 38 days, which is the number that Yasek proposed, which is the inactivity leak, with 70% of the nodes being offline, and then restoring finality. Then I would update the EIP. Currently, it has the weak subjectivity period in it, and I would update it to the I think it was roughly 38 days, That we would then have to, react back at the maximum.

Nixo: Is there any other client besides Reth who doesn't feel like, this is… Currently doable?

Andrew Ashikhmin: Well, it's probably doable, but as I said, for Erigon, we have to make some changes and to do the testing, so right now, probably doesn't work out of the box. It's, everything is doable, but… we… it seems that we have a lot of things, required for Glamstaden. We try to do it, of course, but, you know. Like, let's not repeat our mistakes with Pectra when we had to split it into two works.

Toni Wahrstätter: Yeah, I agree, this doesn't even need a hard fork, in my opinion. Like, this is something we should just agree that we want to move towards to, but this is nothing that can break a consensus here, so we don't necessarily need to do it with Glamsterdam. But yeah, we can just say, okay, we agree that we want to get there as fast as possible, and if we have it at Glamstadom, great, and if we don't, then sometime after Glamstadum.

emma (reth): Yeah, I think that's reasonable. From roughside.

Nixo: You're welcome.

Jochem Brouwer: Yeah, I wanted to quickly ask, because I saw that in Hive, this is possible to test, but since this is, like, a very deep reorg, is this directly supported? Because I would like to… help testing this, and also, because this is mainly about the performance, but this is also part of, like, a benchmark or whatever, but I think this is, like, very handy to… to see what the impact is on these kind of attacks.

Nixo: Otis…

Potuz: Am I correct that the danger here is that if I receive such a block, and everyone that becomes, I send new payload, I get an accepted, because they verified the block hash. and then for some reason, it becomes my head, then every client that cannot actually execute that reorg becomes optimistic. So, in principle, we could just immediately stall the chain. If every CL says, this is the head, and we're all optimistic, is that the case?

Mikhail Kalinin: It depends on what status the EL will return in the response to that reorg.

Potuz: But I haven't triggered the reorg yet. I just sent new payload, and it's a… it's based on a very, very old guy. So I assume that the EL does not execute it, it just tells me syncing, or accepted whatever was the original one. And then I… then I can actually just send an FCU to it. If the Yale has not finished executing, it will tell me syncing, I will just change my head to that, and then suddenly we're all dead because we're optimistic, all of us. That's my reading of what you guys are telling me happens. I mean, in… I don't care that it's too slow. It could take, like, 6 hours, but as long as the block is actually executed, we can just… we don't lose slightness.

Marius van der Wijden: Yeah, like, for gas, it is being executed, it just takes a long time. And we can only do 90,000 blocks instead of 120,000 blocks. So, we… like, for us, it's just a parameter change, but other clients don't have that capability yet, at all.

Mikhail Kalinin: But if… so you have to execute a block, but before that, you have to… to obtain the state, right? Which is kind of, like, 100,000 blocks ago. I mean, like, it diverges from the state that you have 100,000 blocks ago, so you have to apply reverse diffs, and then execute a block. Is that correct?

Marius van der Wijden: Yes, exactly.

Mikhail Kalinin: So, and I saw in the chat that it will take about 6 hours, right?

Marius van der Wijden: I think… So, like, we have to also test that.

Mikhail Kalinin: All right, and yeah, see, so in which status will be responded in the engine API in this case? If it's gonna be, like, sinking, then… And then it becomes the head. What Podit is saying, then, all CL nodes that Got into this situation, we'll be optimistic.

Marius van der Wijden: If I understand Sino correctly, we don't return anything, we just… We just do the reorg. And then at some point, we return. Accept at all. Pilot.

Potuz: But I think on new payload, you should return immediately, without executing.

Marius van der Wijden: Yeah, yeah, on new… no, no, this is on blockch just updated. This is only if you really force us to do… to execute this block. A new payload, we just can just ignore it. This, this can only happen in the case Where the CL node says, this is our current block. And that can only happen if there's… Either non-finality going on. Or a majority is malicious.

Potuz: then can I suggest that we agree on, if we are in such a situation, we decide that all clients should either return syncing, or all clients should execute and not return anything, so not to have a split there? If everyone returns syncing, then we all become optimistic, and then we wait until someone can actually execute it. And if everyone doesn't return anything, then the reorg is not even performed. Because we can't… we do not, change head until the EL tells us. We actually time out, and we would consider that block as not imported.

Nixo: Okay. Do we have any other open questions around this? Because I feel like we maybe aren't going to get to the number. the option that we want to choose today, but we have agreed that testing is needed, and it sounds like Joachim and Mario can work on testing. Okay.

Toni Wahrstätter: Apart from that, it would be great if… I mean, Yasek already looked into that. I looked into the number today a bit too, but if we can… That might work async, if we get more confirmation that, those 38 days might actually be the right number there.

Nixo: Great.

Toni Wahrstätter: I will update the EIP, right after the call, and then I can drop it into the CL. Cheat.

Nixo: Perfect. Okay, we're gonna move on to 8254. This… I think was a Barnabas and Marius topic. Do you guys… or do either of you guys want to talk about it?

Barnabas Busa: Yeah, so the main concern, came from the initiative to raise the gas limit in Grand Sterdam to 200 million, gas. Which will basically allow us to exceed the 8,192, deposits in a single slot transaction, which will basically make all the CLs fail. there's a few ways to, get around this. One of them is, get rid of the limit. The other one is to, enforce the limit on the ES side, and, Yeah, we could just also increase the limit, or decrease the limit. This is basically what we should discuss.

Nixo: So, to be clear, this would be a new EIP in Glamsterdam, in order to… enable…

Barnabas Busa: Yeah.

Nixo: Okay.

Marius van der Wijden: Yeah, so, the A2 platform, the one that Barnabas is proposing, basically says that we have to count every, deposit, and if, above.

Felix Lange: In Liechtenberg.

Marius van der Wijden: Huh?

Nixo: Go ahead, Marius, I think that was an accident.

Marius van der Wijden: Oh, okay. We have to… we have to count every deposit, and, and then, at every… after every transaction, we have… we have to check whether… whether, Whether this transaction can still fit in, or if it can't, and then we have to move it out, and then… so yeah, it… Makes block building quite a bit harder. For block verification, we can choose to either… Verify the limit after every transaction, so we can verify the limit after the end of the block. Verifying it after every transaction has the advantage that we can arrow out earlier. Verifying it at the end of the block means we will, in the worst case, spend more time But it's much easier to implement. Yep.

I… I'm not a big fan. I had the idea of just… Just, deleting every deposit that goes over a certain number. And just, yeah. But that is, griefable. Another idea, and it has… gained some laughs in the chat, but it's actually a serious idea, would be to switch out the deposit contract With a different deposit contract that, that codes a limit per block. And, Then we would actually limit it Where it makes sense, because right now the idea is to limit it in that… in the single part that… where it doesn't make sense, and that is the EL, it would make sense to either limit it on the deposit contract, or to limit it in the CL. Yeah.

Barnabas Busa: How would you propose to limit it on this scale?

Felix Lange: I can give a comment, sorry, for earlier audio issue. So, for… we can either reject the block on the CL by just validating that there are not more than X. Number of requests? However, this is a bit awkward because it creates a new invalidity condition for the block on the CL side only, so it's kind of like, basically, we would have to modify the fork choice to say that this block will never be… You know, in the… in the active fork. So this is possible. Or, I was also wondering what it would take to raise the limit on CL site.

Ben Adams: We'd also need to change, not the validation rules, but the building rules, so that It doesn't… The CLs then reject the block, moves to another EL, which overstuffs the deposits, which then gets rejected, which moves to another EL, which then overstuffs the deposits. Otherwise, we'd halt by just doing the same thing again and again.

Nixo: Tony?

Toni Wahrstätter: Yeah, I agree that this makes block building a little bit more complicated, because you would basically introduce a new, cycle problem, where one transaction could basically consume, for example, all 512 deposits, and then you can't really append more transactions into the block. So we basically, in addition to the gas limit, we would have another, very arbitrary limit that you can't even statically see, like we do for block transactions, for example, that we have the same problem, but we can at least statically see it from looking at the transaction, which is not the case here. But yeah, it feels like Banabas EIP is the simplest thing to do by just, capping it, and… EL clients would just abort block building, or not append any more transactions if we hit it. Just for context, this almost never happened in the past, so I think we had two blocks

That actually went over the 512. So this is really an edge case we're talking about here. So I would prefer a very simple solution here.

Nixo: Mars?

Marius van der Wijden: Yeah, quick question. Pluto seems to be… worried about builder deposits. I have no idea how they work, and whether they will run into the same problem, so it would be… Are they also deposited via the deposit contract?

Barnabas Busa: Yes.

Marius van der Wijden: Included.

Potuz: So, from the perspective of DL, they're just the same, they're normal deposits, so for block building, I guess it's… you're not gonna recognize this. But the problem is that on the CL, we might actually need to do a signature verification immediately on the block as we are importing it, which is not something that we do for normal deposits, for validators. So this… in that sense, what, what Tony said, which is fright, we only had, like, one of few blocks with this many deposits, like, 512 would be more than fine. My fear is that, A, for builder deposits, we do not know if we can actually survive 512 deposits, as we did for validators. Because for those validators, we didn't need to immediately verify signatures. We put them in a queue, and then later on, we… on a churn, we verified those signatures. For builders, we would like to do this on demand immediately.

which I'm not sure we can handle. And second, we do expect, at the fork boundary to get a lot of deposits for builders. So, I would not discount this problem of builder deposits. So, if there is a word in which we can cap this, the building time on the EL, that would be great.

Nixo: Okay, great. Do we wanna do… is there any opposition to PFI-ing that to 7773? And then, it sounds like they're… Sorry?

Peter Miller: Yeah, can I just clarify? It would seem to me that if you do this, there's a denial-of-service attack, where people have… you send a transaction that spends loads of gas. And then, after spending that gas. Turns out to not be inclusible, because it makes a ridiculous number of deposits.

Toni Wahrstätter: So I'm like…

Peter Miller: I'm quite wary of doing this. I'm like, can we not, like, find a way… basically, I… Because currently, we have a rule that you can tell, cheaply and statically, whether a transaction is includeable. And once you pass that check, you can include the transaction in the block. I'm very skeptical that it would be a good idea to act… to add a condition for block validity that violates that principle. So we should… it… the transaction should fail in some way, and still be includeable, if it busts this cap. Just getting to the end of a transaction and go, oh, sorry, you couldn't include that. doesn't, like, align with the basic principles that the EL goes through.

Nixo: Tommy?

Toni Wahrstätter: Yeah, what Peter is saying is true. So basically, this is exactly the problem that… and what Marius was proposing would fix it, basically switch out the deposit contract, because then we would essentially have the transaction revert in case the maximum deposit number is reached. Otherwise, EL clients would have to find a way, for example, just abort block production at some point if they Keep trying to append transactions to the payload, and the block turns invalid because the maximum deposit is reached.

Nixo: Felix.

Felix Lange: I just want to give the quick note that, we already have such a condition in the form of the maximum block size. So even currently, the builder has to be aware of… No, actually, yeah, so the builder has to be aware of, like. How big is the block that it's currently building? But it's a bit… it's, like, kind of goes in this direction also, but it… so we do have to verify that condition while… while building.

Nixo: Okay, just to sort of time box this, do I understand that this is, like, the biggest blocker right now towards, 200 million gas? For Glamsterdam?

Barnabas Busa: Yeah, we could… we could safely do 190. But, as soon as we go over 193, we are gonna have issues.

Nixo: Marius, if, your, your alternative, direction, would that be a different EIP, or would that be 8254? Oh, boy. just to age by far.

Marius van der Wijden: So… the problem… well, it seems like even 190 is too much, because CLs cannot handle more than 512. -Oh. More than a couple of builder, builder, signatures. So, I don't know.

Nixo: Can we, propose 8294 to Glamsterdam and have this open as a… as a way to address this one last blocker, and have people… Discussed this async about how to fix this one last blocker to 200 million. Felix?

Felix Lange: The way I should have lowered my…

Nixo: Okay. Okay, I will, Barnabas, if you want to PFI 8254 to 7773, and we'll have it in the PFI, not CFI, just to indicate that there are open questions that need to be addressed. Because we would definitely like to get that floor of $200 million. If possible. Right. Let's move on to, pavel has two items, related to self-destruct, one Glamstream related, and I think one, general. Pavel, do you want to take the mic?

Paweł Bylica: Yes, hello? So I'll start with, EIP8246, which proposes to Remove the burn feature of self-destruct. So… not going into, like, very, very much into details, the service track has, like, multiple things it does at the end, but, It can also burn if, if… If you target, the EF transfer to yourself, and And the main motivation why we would like to remove that is the other AP, AP7708, which emits logs for transfers and also emits logs for burn events. So, kind of contrary to the CIP, I propose that instead of emitting logs for the burn events, we actually get rid of burn events from EVM.

And that's, like, the main motivation of this EIP. How this is done is basically we… We try to, persist the balance of the account. So, distraction might not be, like, complete in the end. We can… we might be left with the, With the accounts that… Will be empty, but will have, some balance left. So yeah, so that's basically, like, rough overview. of the CAP, and… Proposing this, rightfully triggered the question if we can completely remove, self-destruct. And I think… Should be clarified what the complete removal means. It's not like the service tracking structure will stop working, it will… Still do some stuff, but in the limited factor.

So, I think the agreement is that, it will behave as, sometimes called, send all instructions, so we'll still send EF to the targeted address. And will terminate the execution of a call at this point, as it does currently. And thus has been proposed previously, and we kind of… head to… Went back to some defensive positions, and we removed Self-destruct partly. But still, in the case, an account is created in the same transaction, ServeDestruct kind of behaves as historically it was designed. Okay, so, so yeah, that's basically… Like, intro to this part, and I collected some data about self-distract usage, in the current mainnet.

And I can give some details, but basically this is available already. So I can send the link to the AP, the first one mentioned, and the… And my, like, brief report about self-destruct usage. And if there are no questions so far, I can go over, like, basic, like, some overview of the data I collected. Okay, so there's no questions so far, so, So I… I collected all the self-destruct events since, for the last 5 million blocks. And, And the, this, like, yeah, the block 20 million happened right after Cancun, so this was the point where we modified some of these tracks already.

So we have the… all the events that happened in these 5 million blocks. And the usage of the… I mean, the usage of the service track actually, increases, although the… the deprecation notice that we… we kind of notified users of, previously. So absolute values go up, If we compare that with the gas limit, I can say, roughly, it stays on the same level, so we might want to attribute the increase of usage to the gas limit increase. Although we can also identify, like, more unique users, Coming for this pattern, so that's one thing. In general, there was, like, five, well, this was half a million events that happened, within these 5 million blocks. And if we consider, like,

the context where self-destruct is completely removed, That would, that would cause creation of additional foi… 400,000 accounts. Some of them would have… Would have some… code, and the code is actually very small. It's, our, combines into around 3 megabytes of additional code. So the number of accounts are quite big, I would say. The number of codes is, like, tiny. And why people use it, I'm not currently sure. I tried to classify this, I mean, categorize the usage, and I have some idea how to do it, but well, there's not so much time to do so, so far. And finally, So, so the, so the gas, gas schedule, so the users already pay for the creation of their account, and they don't get any refund, coming from the service track.

So, like, there's not… from our perspective, like, the kind of protocol devs is not really issue. So, even if the account will remain in the state, someone paid for them. And within this event of self-destruct, like, majority of this would work as it is right now. So basically, the only difference would be that there were some Duster counts remaining after transactions, but the workflow will not be broken. So only 12% of this, usage would be broken, and this only happens with… if any of these schemes reuse the same address, because the next time you want to create account on the address, and It wasn't, and if it's not properly self-destructed, it means the creation will fail.

this is 12% of all of these, events, but still, I think this is the part we'll need to, like, dig into. And, yeah, so basically, that's the overview. My personal comment is that from the usage patterns, I kind of find some, like, elegance into this that they actually clear after themselves. Because many of these… many of these, usage is basically, like. create… just create, like, a top-level account, do some scripting, and then serve this track. There are definitely other ways to do so, but yeah, this is kind of, like… At least, it doesn't cause unnecessary state decrease in this in this region, I mean… Yeah, so that's… that's it. And, I think that's… that's all for… from me for now.

Nixo: Peter?

Peter Miller: Yeah, firstly, Thank you, that's, incredibly helpful, and I really appreciate that you've gone to the effort of producing this data that we can look at. I basically agree with you about the whole wasted account. We currently… charge people for creating accounts that get self-destructed in the same transaction, and then we don't refund them that if the account gets self-destructed. We don't care if such accounts end up in the state because they've paid for them. I find the fact that you've located 60,000 transactions. In two years, that would fail. If we removed self-destruct. makes me skeptical that we'd be persuaded to do it. Like, I think I agree, everyone agrees that if we could just get rid of self-destruct, we would absolutely like to do this. But the only reason we kept self-destruct is because users told us that it would break stuff.

If we didn't… if we removed it entirely, and that this was basically the only use case. And we've historically observed a very extreme policy on changing things that might break current users. And there are a lot of candidates for things that we would remove. If we were happy to, like, break the occasional user. So, I just don't see how it's viable to remove same-transaction self-destruct, given that there are 30,000 cases a year Of people actively relying on it, as in their contracts and transactions would break if they didn't use it. Which is my understanding from your statistics.

Paweł Bylica: Yeah, I can… I can… I wanted to raise my hand, but I… I lost where the button is, but anyway, yeah. So, like, I have two comments. One, all of this data is available if someone wants to do, like, further analysis or anything like that. Secondly, I think this… this situation is not so dramatic as it sounds. Is that my observation, although I'm… I don't feel as an expert on, like, usage analysis of… of… of contracts. So many of these usage are still kind of scripts. So, you kind of make a decision to send it, and the moment you create a transaction. And the other part of the usage is some kind of, like, operation, like, operator doing some stuff with a factory, but the… this operator kind of can be identified as an EOA. So.

It's… it's actually also, like, kind of decides to use a contract that has this pattern in their, and the moment it sends a transaction, so I think there's a way to migrate that. It's not like a… Yeah, so… so I kind of find it this… this pattern… It's basically some, like, helper… scalper EVM bytecode, but I… I kind of feel there's a way to migrate existing users. how ex… how… yeah, how to notify them, how to identify them, it's kind of… yeah, I don't know, but yeah, if… if you dig… yeah, if you go deeper into data and, like, the usage patterns, I think we can identify some… some ways, but… Yeah, kind of agree also that, well, it would… we would need to at least

Make sure we actually find all of the cases that we need to, handle.

Nixo: Okay. Paul, can I… is it accurate to say that, 8246 is being proposed for Glamstrom to enable 7708, and then… Removing self-destruct is a… is a longer-term, goal that might be for Hegota, and maybe needs a little bit more analysis into other, He's…

Paweł Bylica: Yeah, I think that's not accurate, because we also had discussion with the testing team, and I think if you want to completely remove self-destruct, and we… I think the moment of Glamsterdam is also a good one, because it simplifies other AIPs, to my understanding, but Maybe some… someone from the testing can comment on this.

Peter Miller: I think that the, evidence, having looked at the data for these two AIPs that you've produced, is that removing the self-destruct, burn is at the level where it's unlikely to create any real breakage, and it is somewhat annoying, so I would be quite supportive of that. like, removing self-destruct entirely, given that it has actual users who will experience at least some breakage, is going to require, like, long-term research, and definitely can't make it into Glamstam.

Nixo: Mario?

Mario Vega: Yeah, I could comment quickly on the testing. Yeah, it definitely will be nice, but I feel like if UX is gonna break in some… at some, to some degree with this change. It's… it's… I mean, the nice part would be that, local access list and 837 would never have to interact with self-destruct. That's very nice, because we will remove a lot of cases where this is like a… a problem to testing, but we have already, like, test cases for that, so we're not really removing work from us. It's like, basically, we're just simplifying the change, which is good. But I feel like, I mean, yeah, I do agree with the point that it's maybe too short notice. So, for us, I feel I'm leaning towards the

the burn… the burn removal. I think, I think it's a nice middle point.

Nixo: it seems like there's con… there's, some support for that, based on the emoji reacts in the chat. Powell, does that sound good? And if yes, do you want to, do a PR to… CFI that in 82…

Paweł Bylica: Yeah, yeah.

Nixo: Yes.

Paweł Bylica: Sure, you can do that.

Nixo: Are… is there any, opposition to… to going straight to CFI for that, EIP, given that it, It seems to have broad support. Great. If not, we'll move on to Hegota. Okay, we have a couple proposals for Hegota and an AA update from my client. Do we want to start off… With 7709. From Ignacio.

Ignacio Hagiopan: Yeah, sure, I have 3 slides, to present this, so it should be pretty quick. Give me a second… Can you see my… Screen.

Nixo: Yep.

Ignacio Hagiopan: Cool. Yeah, so I wanted to, propose 7709 for Hegota. And I said. TLDR of what this EIP is proposing today, and he'll know when… whenever he has to execute a block hash up call. It, resolves the result, by using, any memory cache of the last 256 block hashes. And that's, justified by the current price of BlockHash, which is 20 gas. And what the EIP is, proposing is that, at the protocol level, we decide to resolve, block hash values, via an S load. Against the system contract of EIP2935 that was activated in Prague. Because the system contract is storing the history of the more than 8,000, block hashes,

So, since block hash in-window size is the last 256 values, this can be a result from the… The storage try of the system contract. So the reason why, I'm proposing this is that block hash not being resolved from this system contracts. Create some complications for creating the execution witness for stateless environments. So if you're trying to execute a block statelessly, and this block contains a block hash execution of code at any point in the transaction list, the stateless client should receive This value, and approve that this value is correct. So, since block hash is, a kind of stateful opcode that is not really being resolved from the tries. This creates some complications whenever this execution width is constructed in a stateful EL, because

For other state-to-log opcodes, like slowed or balanced, the Yale State Tracker usually will be aware of this axis happening, so… Creating an MPT proof for that stateful access is pretty natural, but for plug hash, it's not really the case. And the execution witness construction needs, like, an exceptional path to really resolve this. Because it's not, like, formally estate access. So, that's basically the gist of the motivation for this. So it's basically making block hash not be, like, an exception compared to other opcodes that are stateful. the, kind of, main concern that this EIP can have is what is the UX impact, because making block hash be resolved via an S-load to a system contract basically means that we have to reprice it to… to…

To be aligned with what is happening. So that means that, we will be moving to the current 20 gas, price to an S-load cost, so it might be cold or warm, Depending if the… if the block hash is, repeated or not. So that's a decent amount of price change. Like, in the worst case, it would be around, like a… A lot of… a lot of change for users. And actually, if EIP8038, happens, this will be even more than today. The final numbers of DCIPs are not really yet decided, but probably we will expect a big change, so… Yeah, this might… might make things worse. So, I'm planning to run a replay analysis of historic blocks to really understand which is the UX impact.

Probably I will try to wait until 8038. has some final-ish numbers, and we can try to understand which is the UX impact. I wrote some, deeper… analysis around DCIP, some implications. So here's the link if anyone is, interested, I also write the specs and tests in the execution specs repo. So yeah, I will share the slides, the link to the slides in the chat, so anyone can look at them. And, yep, that's mainly it.

Nixo: Felix?

Felix Lange: Yeah, sorry, I just have a quick question. So, is it… you are giving the main motivation for this change that, the stateless client would have to be aware of the hash, but is it not reasonable to expect that the stateless client should be aware of the last 256 block hashes in the history? I feel like this is a very obvious I mean, most status clients will be aware of it. You would really, really, really have to have a client that is, like, completely unaware of the chain in order to not have this.

Ignacio Hagiopan: Right, so the idea here is that the stateless client doesn't really have to… doesn't really need, like, memory about the previous blocks that were executed, so I want, like, the execution witness to be self-contained. Regarding… What is needed to execute the block? Because if not, you need an execution witness plus some kind of memory of the last Blogs that happen.

Felix Lange: Yes, I understand this. I was just wondering, like, what kind of client would that be? Because most, like I said, most clients that are participating in the chain at all, even very, very lightweight ones, would have knowledge of the chain. I'm just, like, really wondering, like, it's… I feel like a very narrow case for a client. I mean, there's more like a… philosophical change, I guess, that you're trying to…

Ignacio Hagiopan: Yeah, I think this is mainly about just making the execution witness just have all the information that is needed for executing the block statelessly. It's just basically that, and not having assumptions about, These stateless clients having knowledge about what happened. Like, previously. So it's like a pure function, circus client.

Nixo: Oh.

Paweł Bylica: Yeah, so I think this is not, like, super fancy change, but it makes the witness very much consistent and self-contained. Like, for example, you can pin this… this element in the storage to the block hash root, block state hash root, right? Otherwise, you would need to have, like, the hash chain of blocks to prove that the values are correct. And for that, you would need to block headers to actually hash them, and so on. So… Yeah, there's nothing we cannot do right now, but it just makes it nicer. And then, like, the witness is only about status, nothing like external elements there.

Nixo: Peter, and then I'm gonna time Alex this so we have enough time for the last 3 items on the agenda.

Peter Miller: Yeah, that makes sense. I was just quickly going to say this is a very small change, but the benefits really are quite substantial. If we get rid of this, we're pretty much going to be in a position where you can validate a block with only the current block and its body, the parent header, and the state. And currently, you require the last 512 headers, and there's no good reason for this. Now we have this contract, so this is a very sensible change.

Nixo: Great. Let's move on to, EIP8253. Jokam, do you wanna… Take the mic.

Jochem Brouwer: Yes, yes, yes, let me also share my screen. Okay, I also have some slides. Can you see my screen?

Nixo: Yep.

Jochem Brouwer: Okay, cool. So this is about… I was beaten this one, so let's… let's go. This is about ERP 8253, remove EIP used back in accounts, and the context of this is also about ERP7610 on ERP by Gary and Martin. which is… which I've PFI'd for a glance at them. It is still in PFI, because this is somewhat, I would not say controversial, but okay, let's get… let's get into those points in a later slide. So, if we go back in time, at, well, nine and a half years ago. at change start, we could create contracts which did not start with non-0, but that was actually… sorry, that did not start with nonce 1, but the contract creation was then always 0. And, this leads to a specific kind of account, which was only possible to create before Spurious Dragon.

This is an account where the code is empty, you have zero nons, but the storage is non-empty, and this leads to problems when you check for contact collisions. Because EIP684, which defines how you check for contact collisions, that says, okay, you should check the months and the code, and that should be zero, and it should be empty, so it does not check for the empty storage. And this is what was introduced by 7610, because this is not specified in the protocol yet. But this condition is theoretically possible. As previous vegan, we introduced EIP161, this is the state clearing EIP, and this bumps the standard conflict norms to 1 to mark these accounts. 224 of these accounts existed at Spurious Dragon, and 28 accounts of them exist today, which I will call the fossil accounts.

The ones which were removed, so the difference of these 2 on the 24 and the 28, these, it's actually no balance, and these are then empty by the definition of EIP161, and these were then deleted from the state already. So, about ERP67610, the argument against is that the address collision cannot happen in practice, because this would… well, you need to do some… well, it's a theoretical attack. And there's also, like, this extra runtime code, because you have an empty storage foot check on creation, which might need an extra disk lookup. regarding on the database layout, or you can check against a hard-coded list of existing accounts, which GEF has currently moved to. It's this, VR.

to Gav, which is already merged, so there's now not the storage with Jack anymore, but the list check. And this list, I've checked it, I've also checked this against the list which I got at this ERP, and it's the same list, so that's good. Okay, so about this ERP… It's this pull request, which I will share here in the chat. Because it's this one… okay, yes. It's this… VR, which I don't seen the chat. Okay, so at the fork block, what we do is we bump the launch of all the accounts which have zero launch, no code. And non-empty storage, so there is at least one key with a non-zero value which exists in the storage fee of this account. And the balance is non-zero because of this argument which I just made, because all the empty accounts have been cleared by this ERP7523.

The nonce is bumped before running the system contracts, so, yeah, also before any transactions. The non-spump is reflected in the book access list. There are the 28 non-perms, and this converts the previous dragon accounts, the fossil accounts, to accounts which can also be created now, because this is… has no code. But they write the stories in the init code, and per ERP161, the non-stage created account is at least 1. So why should we do this? This makes ERP7610 obsolete, because the ERP7684 collision check is not sufficient, because it is not possible to pay these accounts anymore, where we have, like, this weird situation where we have storage, but we also have zero nodes. Which was his point.

It removes the pre-spirious dragon type of accounts from state, which is not possible to create anymore. It removes specific code at clients to handle these accounts. It removes also this type of accounts from state, so you can maybe do some kind of nice database layout optimizations. And it removes this, well, this special handling of these accounts, also in the testing suite, and the best point I want to raise is this simplifies the protocol, and it makes us all happy. Okay, that's lost my… points.

Nixo: Great, thank you very much. Peter, I know you have a comment to make, but, we have two more things to get through. Light client, just real quick, do you feel like 5 minutes is enough to… or 4 minutes is enough to give an AA update, or do you want to kick it to the next one? Because if you want to kick it to the next one, we can… do some questions on Yochum's presentation.

Lightclient (Matt Garnett): I can go very quickly.

Nixo: Okay. Real quick, though, Joachim, if anybody wants to discuss this, where's the right place to go?

Jochem Brouwer: That's to execution depth at R&D. Okay. Yep.

Nixo: Thank you. Matt, the mic is yours.

Lightclient (Matt Garnett): Thanks. Yeah, so I got a chance to talk to a lot of you guys in Small Bar last week. We had one major session where we discussed some high-level AA goals and constraints. This was kind of separate of How do we achieve these things? And I was more focused on, like, what exactly are we trying to achieve? posted the HackMD with the result of that session in the chat. And from there, had a lot of other conversations with people. More focused on the frame transaction proposal. And we are still working on figuring out what the right spec is that can make everybody happy. One specific spec item we spent a lot of time talking about was the 2D nonces, and we ended up deciding that we would just

Proposed the 2D nonce. mechanism for frame transactions, this separate EIP. For now, and see… if, you know, what the feasibility of actually including this together with the frame transaction, in a GoTo would be. But yeah, I'm happy to answer any questions here offline. But otherwise, we'll just keep working on the spec for the next week or so, and then hopefully get to implementing some prototypes.

Nixo: Thanks for the update. Mercy, do you… you wanted to go over your engine API V2 scheme effects? Mercy here.

Mercy Boma Naps-Nkari: No, I just wanted to bring it up so that, Codex can make a decision on it and also approve the PR. And also on this one, We'll be removing this so that people are aware of this. This plan for PR788. Thank you.

Nixo: Thank you. That is all of the items on the agenda. Thank you guys for coming. See you in two weeks.

Lightclient (Matt Garnett): Thanks.

Jochem Brouwer: Bye-bye. Thank you.

Mikhail Kalinin: Bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.