All Core Devs - Execution #234

Transcript

Nixo: Morning, guys. Well, give people a few minutes to trickle in and start at 2 or 3.

Okay, David, are we ready to go?

David (dionysuz): Yes. So, we're live now?

Nixo: Right. Welcome to All Core Devs number 234. Today's April 9th. I will be filling in for Onskar today. We have a few things on the agenda, a lot of little things. We'll talk about Glamsterdam, DevNet updates, I mentioned API changes. Some housekeeping for Hegota, AA topics, and then some miscellaneous items, if… Those all get… talked about in time. Okay, for Glamsterdam, do we have any DevNet updates?

Stefan Starflinger: I can start. We launched yesterday, Glamsterdam DevNet 3. With pretty much all the clients, so, that was pretty nice. Most of them seemed pretty ready, until I started, fuzzing a little bit. And, there, are some issues with gas accounting that still came up. It is still under investigation. I shared some of the information with the clients that I've been able to obtain, but there are still some EIP clarifications for 837, that we have to make to ensure that these, inconsistencies between clients are covered in the spec, and then I think there are also some changes to the execution specs that we need to make to make sure that these things are caught earlier. I'll also create some issues on the EIP, once I have a better understanding.

So it seems that there is some issue with the spillover gas, where, depending on, if there is enough gas left, you can either take it from the state gas or the regular gas, and if there isn't anything in those Reservoirs, it spillovers to the gas left, the previous implementation, and then there's the question if that is either state or… regular, in case there's a refund. There's also some edge cases for special opcodes on reverts, where clients treat that differently. Maybe some clients, that have already looked into it could give some insight. It also seems that in one case where Geth has forked off, it might be that Geth is actually implementing it correctly, from what I can see so far, and other clients might not, but in general, I think it's something where the spec needs to be also clarified a little bit more.

Maybe someone from Geth, that can talk about, if they've done some investigation already, what their view is here.

Nixo: Anyone from Gap? Okay, well, if… Geth wants to follow up async, then. Are there any other, execution layer clients that have been looking into this? Okay, Stefan, where should, where should the, execution layer clients go async to follow up on this?

Stefan Starflinger: Yeah, in the, Steel Discord, we're, generally sharing all the information. And, yeah, like, it's something that, It's still kind of pretty fresh since we launched yesterday evening. And, I think we'll figure it out, and, then, I hope the clients are gonna, sink again. I hope we don't need another definite. We'll see. Also, it would be good, to see if we can get the spec clarified as much as possible.

Nixo: Nope. Great. Anything else? On dead nuts?

Barnabas Busa: I can give a few comments about EPDS.NET1. We have launched a few days ago, and it's been, I'm not That's great. R. We are still trying to figure out what is actually going on. We have clients that are disconnecting from each other, we have clients that are banning their own clients, there's peering bugs, there's, There seems to be some consensus bugs. There are, which create, multiple forks of each other. So, at this point, we are still, working hard on I'm trying to get, .NET1 either up and running, or just restart it, maybe sometime next week.

Nixo: Okay, great. Thanks. Tony, do you want to say anything more about, missing… Test for those edge cases?

Toni Wahrstätter: Not really, I think, This is just… yeah, it just seems obvious that If we have, if we're struggling so much, I'm definitely free to… They should have been caught with test cases, I guess.

Nixo: Okay. Great. And… Okay, so moving on from DevNets, I made a PR, to… adjust the definition of, SFI, I will ask people to take a look at that. We won't make any decisions today, but it would be a topic We would talk about an interop. Basically just making SFI, more descriptive and, and… have a better definition so we know when to move things to SFI. And that will apply to Spencer's ask for, moving things to SFI, because right now, in 773, the Glamstagram Meadow, we have no, SFIs except for the headliners, and so this would better inform foremost on when to move things to SFI. And the definition that I proposed is based on an ACDT call from a couple weeks ago.

So just take a look at that, maybe think about it before folks go to interrupt. So, moving on to engine API changes, Mikhail, do you want to, talk about… I have put these all together, one of them is related to Glamsterdam, but you can… Take the mic for all of them.

Mikhail Kalinin: Yeah, thanks a lot, Nick. So I'll be… I'll be brief. I'll try to. So, alright, so the first change, that we have, in the list is allow zero safe and finalize block hash. To be passed to the EL. So the context for this change is that, CL clients wants to start from a checkpoint. to do a checkpoint sync from a non-finalized checkpoint. In this case, the CL client will basically know the finalized block route. But it will not have the finalized payload hash. In its database. So, and the same for the safe block hash. So what's proposed here? Is actually, To pass a zero… a zero hash. As a kind of a default, or, like, unknown value.

For the finalized and for the saved block hash. And, the EL should actually, if it receives this unknown value, if it receives all zero hash. Basically, should stick with the finalized block hash it knows, because it might already be synced in the past, and it has some finalized block hash in the database. The nuance here is that, Eventually, the finalized block cache will be resolved somehow, and the saved block cache will be, found by the CL by running the pass confirmation rule, for instance. So these two are… these two hashes are kind of, like, separate in that regard. So the finalized block hash could be all zeros, for instance, the safe block hash at the same time could be some, existing,

block hash… a block hash of an existing block. So basically, here is the proposal. It requires the, the implementation changes on the EL side, and yeah, that's basically to announce it here, and to invite EL developers and also CL developers to look at this proposal. And to further discuss. So, I know, if there are any questions, please just stop me. I'll do… otherwise, I'll just move to the next one. So the next one is, EPBS-related, and Yeah, to give you some context behind this change. I should, yeah, so there is, like, an optimization in the Foctrus updated. It's done for the case when, for instance, CL has… AL has been synced already, and the CL is restarted from scratch, and its database is, like, basically wiped out.

And it starts syncing, while EL already knows a big chunk of canonical chain, and it might be even close to the head of canonical chain, and then CL will, Depending on implementation, we'll be sending the new payload, and Fctor is updated. to the EL with the blocks that are already known as canonical, that are valid. So, in this case, we have a shortcut path for the folk choice updated handling. It basically says that In the case where the, the structure is updated to head. In this update points out to the already validated and valid block, which is ancestor of the head in observation to the execution layer. The execution layer may basically skip. the FogChoice updated call, like, basically just skip the update, and in this case, it also, in the case of the skip, EL must not build a payload, like, on top of that block. For EPBS, it's not gonna work, because

In EPBS, and a valid, payload should be… could be reawed out, because it was not timely. And, this proposal kind of… Like, handling this in a way that… The reorg… To the ancestor of the head, even if it's valid, becomes possible. And, also EL should start building a payload if there are payload attributes in the FogChoice updated call. But, to… to find a middle ground between that optimization that I have mentioned and the EPBS cases. It's suggested to have, like, only 32 blocks. reorg in this case. Like, not… the depths of reorg should not be more than 32 blocks. But, the nuance here is that All other reorgs, where the, actually have, is from the conflicting, block tree branch, the reorg should happen regardless of, you know.

Of, of that 32 block, limit. So that's kind of it. I think it's important for EPBS, so please take a look. comments out, and let's continue, on GitHub. Or ask questions here, if you have.

Nixo: Great. Any comments on that one? Otherwise, we will move to Hagoda.

Mikhail Kalinin: I actually have a very small, temperature check on the engine API. If we may.

Nixo: Go for it.

Mikhail Kalinin: Alright, so, this, this is related to the save block tag. We want to, to reuse it for the fast confirmations, for a fast confirm block. But the, problem is that the save block, currently points out to the justified block, and the alternative of not just reusing it, repurposing it for the first confirmed block. is to be, like, introducing the justified and confirmed block tags, and justified block hash and confirmed block hash to the engine API. I was just going to ask, If we take this road of introducing justified and confirmed, will it be possible to do it without re-law, or will we have to push this change to, say, to Glamsterdam or some other hard work?

For coordination purposes. Dustin, I hear from you, but there are some concerns about, like, that somebody might use save block, so, as justified.

Barnabas Busa: To merging the two branches together.

Parithosh Jayanthi: Yeah, the main reason is also that with the Merge DevNet, we can be extra productive on it at Interop.

Toni Wahrstätter: Yeah, I think those are very good points, so maybe we can just take the two, data repricing APs and then just put them on Glamsterdam Definite Zero. Both of them are very contained, talking about the two data repricing EAPs. I think Felix has done a great job on working on the tests. So, yeah, I think the risk is very low that we break. that dev flat with those.

Barnabas Busa: Is there a benefit in including them? I would actually rather not include anything new, but rather keep the scope as contain as possible, not including any new ELPs, and just focusing on merging the Merging the features set from both of them.

Toni Wahrstätter: Yeah, maybe we can follow along async. I think most clients have implementations for those already. It's… it's both of those are very minimal, so it might just be worth it. It's the two that Marius presented, ACTE two weeks ago, where he recommended that we should add them to the next definet. But, yeah. I don't have a strong opinion on it, but it could make sense.

Maria Silva: So, I think my understanding was one of the benefits was it would allow us to also test larger block limits, right, Tony?

Toni Wahrstätter: Yeah, exactly.

Maria Silva: data.

Toni Wahrstätter: So, I think right now.

Maria Silva: was… Yeah, it was one of…

Toni Wahrstätter: Go ahead.

Maria Silva: of the blockers. Yeah, I would say that the cost of data was one of the blockers for testing higher block limits in a DevNet. And initially, we were discussing it, including it. even in DevNet 3, because of that, the… of that issue, but then we ended up not including it. So that would be one… one benefit.

Toni Wahrstätter: Yeah, thanks a lot. This is a very good point, actually, yeah.

Maria Silva: I also have a question regarding having joined Amsterdam. DevNet, so we do have a couple of… questions around 8037 that were, delayed for DevNet 4, so one of them was, because of the testing infrastructure, we are not using the dynamic cost, we are just assuming a fixed cost, and then we said that we would do the dynamic cost in the next DevNet. Would it be the goal to do… the current version of the specs for 8037, the… that we have now and merge it with ePBS, or would we try to also tackle those, in the merged DevNet?

Stefan Starflinger: That's a great question. Maybe could clients maybe, say something about how much work it is to make it variable?

Dragan Rakita: This is one of the reasons why I would prefer Demet 4. This is just a preference, I wouldn't mind, like, doing much DevNet, but… There are a few, like, catch cases and AT3070s. Follow those, and we have, like, paintings that we moved for the next DevNet. And we simplified 837 for diametry, because it's, like, a big change that everybody needs to do.

Parithosh Jayanthi: How about in this case, we look at, EPBS DevNets until Monday, if it looks like they're going to be stable? Then we can, work on Glamsterdam DevNet 0, and, like, very rapidly iterate to Glamsterdam DevNet 1, where all of these changes are included. If it looks like EPBS is not going to be stable by Monday, then probably Battle DevNet 4 is the logical conclusion there. Does that sound like a reasonable path forward?

Maria Silva: just… just make sure I understand, though. So, in that case, if we have a stable, EPBS DevNet, then we would be doing the Glamsterdam DevNet with the current specs of all DevNet 3, and not.

Parithosh Jayanthi: exec.

Maria Silva: the…

Parithosh Jayanthi: Yes.

Maria Silva: Okay, got it.

Parithosh Jayanthi: Yeah, and the implicit understanding there is in the future, we're more tightly coupling everything, so we won't be able to move at the speed of the fastest moving change, but rather the slowest moving change.

Nixo: To summarize, so if the EPBS DevNet is stable by Monday, we'll move to a Glamsteram DevNet without the two, added gas repricings. That were just proposed, is that correct?

Toni Wahrstätter: I thought we would add them, but maybe I misunderstood.

Parithosh Jayanthi: To Glamstadam DevNet 0, we wouldn't add them. To Glamsterdam DevNet 1, we would add them, and the time delay between those two would be very short.

Toni Wahrstätter: Okay, gotcha. Thank you.

Nixo: Great. Anything else on that? There is, we will move on to Hakota. Okay, so just to, reiterate decisions from the previous call so that everybody is on the same page here, frame transactions were CFI'd not as a headliner, but as a non-headliner, and there was some disagreement about the specific implementation, and so we are broadly considering frame transactions CFI'd as a placeholder to decide on an AA direction, which means that, The people working on AA proposals need to work together to figure out, the best way to move forward. Does anybody have any contention with that, with that, view of the outcome. If not, I will point out that, that means that our headliner proposal process is complete, which means that we can now propose non-headliner, proposals.

So, if you have a non-headliner proposal, feel free to open a PR against the, Glamstream meta, or the Hagoda meta, which I think is, like, 80-81, if I'm… remembering correctly? And then, we have no end date right now. We're going to work through, Interop, and we will commit to at least giving, 2 weeks notice, maybe perhaps 4 weeks notice before closing that deadline. Any questions there? Great. Then we will move on to Antonio, who wants to give a 2-minute, pleon account function.

Antonio Sanso: Right. Can you actually hear me?

Nixo: Yes.

Antonio Sanso: Hello, hello, everyone. Thanks for summarizing the status quo, Nixo. I agree with what you said, I mean, this was actually what the decision was. Just, like, to see my point of view is, I mean, not knowing too much the process, and so on, but… from my perspective, like, the… there was, like, a generic not-agreement on… on the frame transaction proposal, but I think, like, all the core dev, I won't talk in the name of everyone, were kind of, agreed that native account abstraction is… this is, like. It's a good topic, too, for having a headliner in, In Agata. And of course, like, I come with my post-bantum transaction signature. had in mind, and from my perspective, this is really important as well to have it in Eagota, and I was just wondering if there's any chance

to reconsider or review or reframe the decision of not having it like a headliner, because, again, it was a long call, I understand that, but from my view, there was not a contention on not evacant abstraction, but a contention if framing transaction was the right proposal. And if we can see on the view of putting a generic NATIVAC and abstraction headliner, not a specific EIP, I think there is still time to find a proper EIP that… with the modification that we had in mind. On the non-perfect, Fremi transaction. And these are my two minutes, basically. Thanks a lot for giving me the chance.

Nixo: Antonia, do you have, do you see any reason that, like. Any goal of native account obstruction as a focus in the report can't be accomplished as Being CFI'd as a non-headliner.

Antonio Sanso: Sure, I mean, also, like, CFI is good, but, I mean, my understanding of Headliner is, like, to have a kind of North Star for a single release, so I think that deserves the case of being headliner, because it's a really important topic, people have been working for a long time on it, and now we really have The really important use case of the post-wantum is not the only one, but, I mean, again, I came with the post-antum use case in mind, and I think we're missing a chance, and we are missing an opportunity to do the right thing. And doing all because the process was not, like, designed for this specific nuance is a pity.

I mean, again, not a critic here to the process, just, like, what I read on… on the last conversations, like, that was really, like, a gap in the process that, yeah, we proposed the frame transactions deadline, or people didn't agree, but everyone actually agreed on the notifact and abstraction somehow. a more generic topic, so it would be a missed opportunity, in my opinion, but again, like, 92 cents.

Nixo: Okay, would anybody disagree with moving forward with, basically keeping it CFI'd as a non-headlinliner right now, and having the AA, folks move, work together, and if they can come up with something that, that garners a large amount of, support than talking about, switching it to a headliner, which… The implication of that, yes, Lumi, would be that we would delay Hagoda, If it's not done, we would make headcoda's, release dependent on that being done. Oh, gosh.

Łukasz Rozmej: So, I'm jumping ahead here, and we'll leave Ben to show his proposal, but Ben yesterday published a very interesting ERC solution. Which doesn't need consensus changes, and does everything Account Obstructions tries to do, except Post-quantum signatures, which would have to be done in a separate transaction type. And, so, yeah, this is an alternative, to… to native account abstraction, and in my opinion, it's… potentially better and simpler, so I would really like everyone to… Read it, and give feedback.

Nixo: Okay, we'll give Ben some time, to… talk about that. But first, Pedro?

Pedro: Well, I would like to thank for the plea. I think we need more statements like that. There is… a lot of demand for this. We have navigated through account abstraction in multiple iterations, and as the chat is talking about, we do not need more health measures. I think that is the correct stance here. We need something that is truly native. I don't want to be coming into a core devs call and start comparing EVM to other machines, but Realistically, this is something that has been lagging behind quite dramatically with the whole blockchain ecosystem, and the only reason for that is because it has never taken priority, and when we saw it being deprioritized, because, in my opinion, removing it from the headliner, it seems like a deprioritization, it seems to be a risk that we're again

in a situation where we're gonna take another health measure. I really appreciate Ben for putting together an ERC. But the NRC defies the purpose of actually solving the problem natively, and this is something that should be done natively. I… I'm open to hearing for alternative proposals to 8141, but one thing that was very clear from the last call is that it was not actually discontent around 8141. There was only discontent around the maturity of our standard, because it was written first version in January. It was not the fact that client teams actually disliked H141, but they were skeptical about its maturity, given it was such a A short window of time.

Nixo: Antonio?

Antonio Sanso: Yeah, just quickly to, like, reply to Lucas, I mean, I didn't read the CRC yet, but, I mean, the fact that it doesn't cover the post-quant transaction at the moment is, like, again, I'm highly biased, but it's, like, really, like, the major use case at the moment, unless we are everyone in denial. I mean, it's already kind of… Minus, you know, like, really, like, the post-controlled intersection at the moment, if you read the news and the last development in the last days and weeks, I mean, it's kind of heavy at the moment, so… let's, let's…

Łukasz Rozmej: Oh…

Antonio Sanso: Quickly.

Łukasz Rozmej: Black… Let's give it maybe, Ben, room, but post-quantum are handled by different EIP, by Julio's scheme Transactions EIP, so those can work on combined, and we can have both, this is not a problem.

Nixo: We have some people with their hands raised. Do we mind if we skip to Ben real quick, just because we're already discussing it, and give him some, like, time to actually talk about it? Okay, Ben, you want to take the mic real quick?

Ben Adams: Yeah, sure. Sorry, I'm not very… prepared. As I say, it was just this morning, but… the topic was coming up today, so, my team said I should present. It's, as I said, it's an ERC. Can you hear me?

Nixo: Yep.

Ben Adams: It's an ERC, it's not an EIP, because it lives at the EVM level. So it's, wallet title deeds, so account abstractions through, NFTs. But the… the idea is to… Traditionally, you're… you have an EOA that is bonded to its custody, and the idea is to sever… separate that link, so… you instead bond a NFT, which is, the 7… 721. To an address, so they are… they become one thing, and your EOA is the sign-in key. And because of that, you separate the identity, the address that you're doing everything with, that is in the NFT, and you, like, invert, how things work. So you would, if you want to do address rotation.

you would… you would get a new EOA, and that could be a post-quantum, or, pass keys, or whatever, using Different transaction type. And then you would transfer the NFT to that account, and you've done key rotation, essentially. Because now all the assets have moved from one account to another, so you… Job transferable, Control there. And then you can do programmable smart, control through it. So you can… oh, sorry, you have a… so the… Title deed is bonded to an account. The NFT's token idea, as it were, is actually an account, and it controls that account, and because it is a… also a smart contract at the same time, you can batch through it, you can, with a signature, you can do guest sponsorship.

And so forth. So you can do… Key rotation without identity. So if you wanted to move your assets from your hot wallet. you would just move the NFT, and you could put it in your cold wallet, and it's taken everything inside that account, and transferred it over. Or multi-sig, or however you want to… or is quantum signature. And, you know, with that goes your Aave, ENS name, Uniswap LPT, your governance history, because it's attached to the transferable account. address. But because… it's an NFT, and the NFT is an account, and you can transfer it. You can also, therefore. put the NFTs inside each other, they can contain each other, and then you can create a EVM-enforced organizational hierarchy, either, you know, because you want to do some layout, or perhaps you're an organization, and you want to have your treasury separate from your engineering, your marketing, your operations.

And you want to, have secure trust boundaries. And that gives you, approval scope, risk isolation, so if you have… you might have, One that… one branch of your account that you're doing You have your solid assets in, and another one that you're… Using… I'm not in the app, so whatever. And you don't want any crossover of those assets, but you also don't want to manage multiple EOAs to do that. You can… you can do it through this structure. And then you can also do infrastructure-free gas sponsorship, so you can… you can do the signing. Which could be a batch sign, that goes through the smart account. And unlike, 4337, anybody can…

Sponsor that, so that could be a friend. That could… you don't need, all the paymasters, the bundlers, anything like that? It could be, your company might give you Account, delegate you to it. And then you can… and they… they sponsor all your transactions, for instance. Or you're using a DEX, And, you know, CalSwap, for instance. You sign a transaction, you don't pay any gas, and they take it out the other end. So, yeah, so the required infrastructure is… is… none for the sponsorship path, because any EOA can relay. it's the standard EVM protocol transaction. Versus… Off-chain when it's trapped, so you got the… So it works with, fossil, And,

VOSP, which is the reduced state for validators, where you only keep the account try, rather than necessarily all the state. this will run through… As I said, it, it… Works through, both this, fossil censorship resistance, these transactions, NZSOP… Sorry, I'm just gonna… Go through… Victory. So essentially, you're turning your wallet… it's no longer… Sort of an isolated island. They become, transferable financial primitives. You can create a hierarchy of them. You can do gas sponsorship, key rotation, it works with fossil, it works with, PRP, you can do privacy withdrawal support, yeah. There's a… there's a huge amount more to it, like digital inheritance, and…

AI accounts, and… All sorts of things, but, yeah, so… I'll just… I'd present. Thank you for listening. Please check out the… ERC.

Nixo: Thank you. Tomah and… Do you have, You have had your hand raised, do you want to, take the mic.

Tomás Arjovsky: Yeah, sure. So I was wondering which was the process through which, the frame transactions idea was moved from Headliner down into a regular one. I was mostly wondering, because usually we get all of the clients saying this, and the idea that I'm getting is that now we are trying to say. if anyone is against this, but the decision is already taken, so I was wondering about that. And in contrast, I'm wondering why… We are seeing an ERC that was published 14 hours ago as a potential contender against this, which was a headliner yesterday.

Nixo: Okay, so the… to sort of clarify, the… Frame transactions was CFI'd, as a non-headliner. non-headliners are open for proposals starting today. The reason that it wasn't CFI'd as a headliner was because there was too much, disagreement among clients about the best path forward, and so I think the idea is going to be… That, we get… the AA folks to sort of agree on a best path forward. We would like them to work together, and if we can get strong consensus from a majority of clients. On, some proposal, then we can consider moving it up to a headliner again, in that vein, I think it would be good for… the AA folks to have an AA breakout, would anybody be willing to…

To sort of champion a breakout, to host a breakout.

Pedro: I would like to champion the breakout.

Nixo: Okay, great. Can you get in… well, protocol support will, get in touch with you if you leave in the chat a way the best way to get in touch with you. Great. Parthas Arathi?

Parthasarathy Ramanujam: Yeah, so, yeah, I… Just wanted to reiterate that it's high time, as Pedro said, that we have native account abstraction in Ethereum. We've had several ERC measures since 2018-2019. As a part of a team that runs wallet and has been running smart account wallets since 2018, I should say the fragmentation in this space is Already a lot. And if we are introducing another ERC and not native account extraction, I'm not really sure if that would serve the purpose that Ethereum wishes. So, I'm for… I agree with Pedro where we should probably be considering a proper native account abstraction as an EIP and not looking at ERCs anymore. That, is my opinion. Thanks.

Nixo: Great, thanks, Julio. Okay.

Giulio Rebuffo: Yeah, can you hear me?

Nixo: Yep.

Giulio Rebuffo: Okay, so, it just… I don't know, I just wanted to say that it's… it seems that, And so, yes, okay, with CFI frames, but… I mean, it's… I don't know how to put this, but I think it's a bit, I, I think… I think… I just wanted to ask… okay, whatever, I'm just gonna ask it, I'm gonna just bring it up again. Who here would actually prefer doing scheme transactions instead of frame transactions out of the client bits Because it seems to me like there is only one client that really wants to do frames, and I don't think that it realistically will get into the hard fork at this rate, to be honest.

Nixo: Antonio.

Antonio Sanso: Right, again, I'm not a developer here, you guys probably know me. I already expressed this to Julie in private. the thing is, like, I will… it doesn't matter if it's gonna be Frame or your solution, Julio, it's like, let's figure this out offline and in a kind of abstraction breakout room. The things, like, I want to point out is your solution probably was… I didn't look into the details yet, but it's probably okay, it's good, but, I mean, you're comparing your solution that you thought for a couple of weeks, compared to, like, 5 years, maturing EIP that took in consideration all the corner cases. I will frame it not like competitors, I will frame it like something to add on the current frame transaction, or, like, merging it.

I will not frame it like a competitor's.

Giulio Rebuffo: It's my position.

Antonio Sanso: Look, here, but, yeah.

Giulio Rebuffo: No, I, I agree, actually, I, I agree, I, I, I, sorry, yeah, so maybe this… sorry if I, if I passed around like that. What I meant is that the… the problems with frames, and I already said it again, is… has all to do with the verify frames part of the proposal. you can figure it out later, and you can decouple it from post-quantum as well at the same time, right? You can have something with which you can do post-quantum that's not contentious, and you can do it relatively much more easily later anyways. That's it. But yes, I agree, it should be… they should be complementary. Like, I don't want… this is not like a competition, of course.

Nixo: Antonio?

Antonio Sanso: Oh, sorry, I need to lower my hand, sorry.

Nixo: Okay, Nico?

Nicolas Consigny: Yep. Can you hear me?

Nixo: Yep.

Nicolas Consigny: Yeah, I think one important point around the post-quantum stuff is that there are many, many easy ways to do it. We can just add a pre-compile and say it's done. But the goal here with the frame transaction is not just to have one post-quantum solution, but to have agility to move from one to another. And this is, like… The key requirements that we have if we want to survive in, like, a world where Schemes are going to be broken fast. And there is simply no other proposition that is trying to tackle that. So I think if we want to compare, like, apples to apples, we want to have another solution that is also providing crypto agility.

Else, we're just comparing things that are not fitting the same requirements. So I just wanted to put that here. And we can discuss this in the next breakout.

Nixo: Yeah.

Lightclient (Matt Garnett): I just wanted to say one quick thing. I added a PR that brings some of the ideas from the Steam transaction into frame. Obviously, scheme transactions are… Focusing on a slightly different problem. You know, they're saying we can bolt on the verify, you know, type functionality later to the scheme transaction, which, like, may be true, but frame transactions are built from the ground up to allow that behavior, because that's what most people believe is, like, what true native account abstraction. actually means. And so, I think that we should strive to actually achieve this, and not take the easy shortcut. There are many, many very difficult problems that we still need to solve in Ethereum over the next 5 years.

And if we can't even, you know, solve this one. Like, I worry about our ability to continue Doing hard and complicated tasks on the execution layer.

Nixo: You're gone.

Dragan Rakita: I'd like to give small input on all of this. I think design on AI… Aa is basically fluid. And we should iterate on it. I would urge people to think about the minimal mechanism they need For something to work for them. And I think design will clarify If we think about it. If you think about the minimal things that we need.

Lightclient (Matt Garnett): I… frame transaction. Like, we have thought a lot about what is the minimal thing. That's why we… Took the ideas from 7701 and tried to, like, minify it as much as possible. It's just, like, fundamentally allowing some execution to happen before the transaction is accepted as a, like, valid paying transaction. is complex, and there will be some complexity there. I don't think it's as complex as most people make it out to be. But, like, we're not really comparing apples to apples in most of these situations. Like, scheme transactions provide only, like, a very small subset of functionality that the frame transaction provides. And, like, if we're gonna compare them, like, let's compare them and find a good solution, but, like, let's compare two things that are achieving the same

functionality.

Dragan Rakita: The thing that, basically, I want to iterate on is, basically, if you have some use case that you want to fulfill, not just making most generic platform ever. It is use case that you want to fulfill, it is use case that you want to have everybody Move to that use case, to that mechanism that you want to implement. So, for the frame intersection, I don't think the… having access to every transaction field is needed. We can, like, do something, like, simpler with the hash. We can do simpler things, but the core ideas we need to clarify those. What are the most basic mechanisms that we need to explore these kind of things? That's why I'm urging everybody to, like, think in that…

In that flow, in that, like… in that direction.

Lightclient (Matt Garnett): what's the best way to, like, think in that direction? Because on my side, I feel like we have… described a lot of these, and we've tried to, like, make arguments about many different types of use cases that we want people to achieve in the core protocol, but then people still come on all core devs and say, like, we haven't… we don't know what the use cases are, we don't, like, know why people want this stuff. And so, like, I don't really know how to communicate it in a better way. Like, is it just, like, more breakout rooms? Is it, like, we can talk in person? Do we need to write more articles?

Dragan Rakita: No, it's not easy.

Lightclient (Matt Garnett): Yeah, I mean, like, we also have people from wallet teams here in the community here who are saying very explicitly that we need native accounts abstraction, and that something, like, of the shape of frames is achieving the things that they believe. You know, people who are operating smart accounts for the last, like, 5 to 10 years. And… Like, I just don't really know what other things that we need to be doing to make a compelling argument to people that there are properties of native account abstraction that most of the other solutions aren't providing that people want. Like, it's a long list of things, and maybe not any individual piece of functionality is the pivotal piece that makes AA worth it all, but it's, like, incumulative of all these different things, where

gray values. observed.

Nixo: Okay, I think I would encourage people to, to Dragon's point, Decide what their minimum requirements for this thing are. And also, please look at the existing proposals, and bring your, your… Your qualms, your problems with the current ones, so that, those authors can be aware of, like, what… what people's issues with them are. To the AA breakouts that get scheduled. James?

James Prestwich: I've been involved in every AA conversation from the beginning of Ethereum. We are not going to reach a design that everyone agrees with. It is not possible in this design space. If something like frames is included, it will be because it has political weight behind it, and that's okay. we can debate this indefinitely. We have debated it for 10 years. we should focus on what is important, the use cases, like Matt was talking about. And what is important, the post-plantum migration, which we need to do for all users within the next 3 to 5 years. I don't think that AA should be a blocker for PQ. And coupling those in the design space seems irresponsible.

Nixo: Pedro? Pedro, we can't hear you. Okay. Julio?

Giulio Rebuffo: Yeah, so I'm actually going to… before I ask a question that I don't think was answered, but I just want to get, like, a vibe check. like, how many client teams would rather maybe do, frames through schemes, through scheme, instead of going directly for frames for a gutter? Just, it's just kind of a temperature check, but I don't want to make, like, a decision or anything.

Nixo: Possible that people aren't familiar enough, or don't want to speak for their team… their whole teams? Do we have any more… AA conversation that can't be moved to… A breakout call. Yeah, agreed. I don't think that we'll be making any decisions today. Minus just having this breakout call where we dive into, the specifics. And… I would urge people to actually prepare for that, and not just come to the call, because having these basic requirements that they, that they want, and maybe proposals to decouple things like post-quantum transactions and AA, and their issues with specific proposals would be very helpful and productive.

To be on the breakout call. If… No more comments on AA, we can move to the miscellaneous, smaller items on the agenda. Great. Sina, you wanted to talk about history pruning targets?

Sina Mahmoodi: Yes, thank you. So, I wanted to bring up… History pruning targets, and… Specifically thinking about future targets. And to provide a bit of context. You'll remember that a year and a half ago, we… Sat down at the interop, and… Agreed that from… May last year. Clients must be able to handle the fact that some other clients on the network may not have. pre-emerge history. And, because of that, we implemented Air 1, and… Ability imported, exported. And that's kind of where we left things, so since then, Many of the clients have added some way to prune parts of the history, and…

I think there is some divergence in… The exact pruning mechanisms that clients have right now. I think, so basically it came up, yesterday in… on Discord, on the History Expirator channel, that's… there seems to be different ideas about it. like, two options specifically came up. One is… basically setting the next target, to be until Pectra, so… Clients should be fine with having pre-pectoral history pruned. and… The other one being rolling expiry. Which is, like, basically, its client stores, a window, and it's a moving window. But I think I've been thinking about it since yesterday, and… I would like to suggest a different way of looking at it.

And that is, basically trying to figure out what is the minimum amount of history that must be kept for the health of the network. And… I think as part of that, I also want to, like, bring up this question that… Like, what, I want to know, basically, what is the landscape right now? How aggressively, can users prune their history, with respect to different clients, now. So I can tell you, for example, that in Geth, it's possible to prune until merge, as we agreed. It's not the default, so default is to keep all of history, and And we recently also added a way to prune onto Pectra. I want to know, basically, yeah, In the most aggressive version, how far can users prune their clients? So if you guys can just chime in here…

Yeah, to… to Barnabas? I would argue that, finalized is… Right, okay. So, Aragon, you can be as aggressive as you want. One of us suggesting Finalist Epoch. I can tell you that one of the requirements that we have in GATH is that we need at least the ninth last 90,000 blocks to be present. This is for social recovery. It's like this mechanism that we have. And I think it's kind of important to have at least that amount of history around. But I'm open to hearing other ideas.

Nixo: Hello?

Giulio Rebuffo: Yeah, so, I think this… the pruning target is mostly just, if I may, a political problem. It's just something we agree on. So, if you agree that, for example, we decide to do 100,000 blocks rolling window, there can be some clients that decide to instead do 200,000. that shouldn't be a problem, right? Like, if you… I think you can just define a bound, and then every single client can figure it out. If we want to say finalized, and GAF wants, I don't know. 9,000 blocks, they can keep on 9,000 blocks. Just, you know, you can keep more than what you're required, you just cannot keep less than what you're required. So just… You know, so all you need to define is a number that is small enough, essentially, that… that can work under theoretical conditions, or under conditions we like, maybe it's 100,000, maybe it's not the finalized checkpoint, and just… and just use that, and then clients can just figure that out by themselves.

Sina Mahmoodi: Yeah, agreed. Like, nobody is required to prune until that point, it's just we wanna… make sure, I think… From my perspective, we gotta say, like, everybody is required to store at least, let's say, a month of history. Just trying to figure out what is a good number.

Łukasz Rozmej: So, if I recall, EAP444, was saying one year. Which was kind of agreed upon. Let me look it up.

Lightclient (Matt Garnett): Yeah, it was one year. I think one year is, very generous. Mountain.

marek: Exactly.

Lightclient (Matt Garnett): But the absolute minimum is the… Weak subjectivity checkpoint. Which I don't know what it is, given our validator set size.

Barnabas Busa: 14 days.

Lightclient (Matt Garnett): Okay. So we couldn't do less than 14 days, because you want to be able to fully validate from that point on. And so it's a matter of, do we want to have some buffer on that, or… Is 14 acceptable?

Barnabas Busa: I think we should do at least the plot. The 18-day blob, which is 8,000 epochs, I think.

Sina Mahmoodi: Barnabas, so that was 18 days?

Barnabas Busa: Yeah, the blob expiry window is, I think 8,000 epochs, which is 18 or 19 days, something like that.

Sina Mahmoodi: of… Yeah, I also hear the fact that, like, one year might be too long. I can also provide some data on this. Basically, I can tell you that the difference, from pruning… so, Pactra was almost one year ago, and… The minimum for me is 100K, and the difference between that is around 70 gigabytes of history. So, like, we're… like, the gain are quite… small, I would say, compared to… like, once you prune everything before that, So this is, like, the kind of area that we're talking about. Just to throw out a number, like, one month? I mean, I don't know if we can make a decision here, but, I do want to have some concrete ideas.

jonny: Why don't we just suppose… why don't we just ask the consensus layer what the… Week subjectivity period is, or point is. Because if it stops finalizing, you know, or… I mean, that can change. Just picking one just seems kind of, arbitrary, right? It's not always good.

Lightclient (Matt Garnett): I mean, I think we need the… we need the fixed period of time, plus any unfinaled blocks. But also, I thought the weak subjectivity was not a fixed period. I thought it was something that was a function of how many validators there were, and how long it would take for the validator set to… Fully rotate out and a new one in.

jonny: Yeah, that's why you… I think you have to ask the CL, right?

Toni Wahrstätter: I think it doesn't update that, frequently. For example, with block of access lists, we also needed it, because you keep files for that period, and there it's 3,530, a little bit more. Epochs. That's, I think, 18 days or 20 days, something like that.

Lightclient (Matt Garnett): But is the number of validators in the set not a… portion of that function, like, whether or not it may change a lot.

Toni Wahrstätter: I think it doesn't change a lot. It's definitely part of the function, but it's not like that it updates frequently.

Lightclient (Matt Garnett): Gotcha.

Sina Mahmoodi: I think Matt raises a good point, like, what if, We stopped financing for a week, two weeks.

Lightclient (Matt Garnett): Yeah, I think any numbers that we're coming up with, I mean, I think it needs to be the same on blobs, it needs to be the same on bowels. Any number that we come up with, if we're not finalizing, then that we need to… Be keeping those, unfinaled blocks, as well as the Finite period that we agreed on.

Nixo: You said…

marek: Against one month, of course, with the caveat of finalized blocks, that we have to store them.

Mikhail Kalinin: a small comment. We have 18 days for blobs, because if we stop finalizing, then… It will take 18 days for inactivity League to… Eject, to basically diminish the validator balances of inactive validators to start finalizing again. So these 18 days are taken from that. As far as I'm recalling.

Lightclient (Matt Garnett): Okay, so that's different than the week's subjectivity period.

Mikhail Kalinin: It's not actually a big subjectivity period, but it's something more…

Lightclient (Matt Garnett): happens that…

Mikhail Kalinin: print.

Lightclient (Matt Garnett): It just happens they're both similar numbers.

Mikhail Kalinin: Yeah.

Lightclient (Matt Garnett): Okay.

Łukasz Rozmej: We have a question. What's our goal here? Do we really want to, you know, get to the minimal, minimal gigabyte level on disk footprint, or are we fine with a bit of overhead? Because, again, we… I would… I would vote for some kind of default standard as being Somewhat… at least a bit conservative, so that one year on four… it's quite much conservative, but… Maybe, you know, something like half a year, or three months, or a quarter should be, like, the default, in my opinion.

Dustin Brody: One possible value in this regard, actually, that's sort of in between is to match the CL's 33,000 epochs period, which is about 5 months. if people want a little more conservative. The value… the interesting thing there is if you do that, then there's a lot of overlap, Between the… what the databases hold, so the CLs and ELs can request data from each other, actually in both directions, depending on… depending on what each holds, and I know some OI, some data, some CLs and ELs both. But in any case, if those periods match exactly, that opens up a lot of opportunities there.

Sina Mahmoodi: Yeah, just wanted to, make a quick note, to what Lukash said. I think it should be kind of up to the client what they define their client, their default. As long as we all agree that the minimum should be kept, so if… even if the user specifies a window shorter than, let's say. 5 months that we are talking about now, then the client should reject it.

Nixo: Sina, is there anywhere that people can, follow up on this offline, or follow what number is being discussed?

Sina Mahmoodi: Yes, please, there's a History Expiratory channel on Discord.

Nixo: Perfect. Anything more on that? Great. Chase, do you want to talk about the, your request to have devs comment on the new RPC method? Is Chase here? Well, then I will just copy this link into the chat. And if EL devs can comment on this, Chase is proposing adding a new RPC method, and would appreciate comments from execution layer devs. And we will move on to Barnabas, For bringing the SSZ… for bringing the SSZ into the engine API?

Barnabas Busa: Yeah, this is a topic that has been brought up, multiple times. So the core change would be to, optionally bring SSE over REST, and no longer just JSON. This would basically enable, performance improvement, between the EL and CL. It would allow us to further blobscaling, and hopefully we can do a zero breakage change, so all of this should be optional. No specific EIP is required, clients could just implement, SSD one day of time, and, we could do something like capabilities exchange, where the CL would basically be able to, use the SSD instead of JSON. I can post… the execution API. They are here, and I'm open for feedback.

Nixo: That was the last item on the agenda, so unless anybody has anything else, we can close up for today. Thank you, everyone.

Alex Stokes: Thank you, goodbye.

Barnabas Busa: Nope.

Andrew Ashikhmin: Thank you, bye-bye.

Toni Wahrstätter: Bye bye!

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