AllCoreDevs - Execution #234

|2026-04-09| Agenda: #2004| canonical JSON

Transcript

nixo:Welcome to All Core Devs number 234. Today's April 9th. I will be filling in for Onskar today.

nixo:We have a few things on the agenda, a lot of little things. We'll talk about Glamsterdam, DevNet updates, I mentioned API changes.

nixo:Some housekeeping for Hegota, AA topics, and then some miscellaneous items, if… Those all get…

nixo:talked about in time. Okay, for Glamsterdam, do we have any DevNet updates?

Stefan Starflinger:I can start. We launched yesterday, Glamsterdam DevNet 3.

Stefan Starflinger:With pretty much all the clients, so, that was pretty nice. Most of them seemed pretty ready, until I started, fuzzing a little bit.

Stefan Starflinger:And, there, are some issues with gas accounting that still came up.

Stefan Starflinger: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

Stefan Starflinger:837, that we have to make to ensure that these, inconsistencies between clients are covered in the spec, and then

Stefan Starflinger: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.

Stefan Starflinger:I'll also create some issues on the EIP, once I have a better understanding.

Stefan Starflinger: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

Stefan Starflinger:Reservoirs, it spillovers to the gas left, the previous implementation, and then there's the question if that is either state or…

Stefan Starflinger:regular, in case there's a refund. There's also some edge cases for special opcodes on reverts, where clients treat that differently.

Stefan Starflinger:Maybe some clients, that have already looked into it could give some insight.

Stefan Starflinger: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.

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

nixo:Anyone from Gap?

nixo:Okay, well, if… Geth wants to follow up async, then.

nixo:Are there any other, execution layer clients that have been looking into this?

nixo: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.

Stefan Starflinger:And, yeah, like, it's something that,

Stefan Starflinger:It's still kind of pretty fresh since we launched yesterday evening.

Stefan Starflinger:And, I think we'll figure it out, and,

Stefan Starflinger:then, I hope the clients are gonna, sink again. I hope we don't need another definite. We'll see.

Stefan Starflinger:Also, it would be good, to see if we can get the spec clarified as much as possible.

nixo:Nope.

nixo:Great. Anything else?

nixo:On dead nuts?

Barnabas:I can give a few comments about EPDS.NET1.

Barnabas:We have launched a few days ago, and it's been, I'm not That's great.

Barnabas:R.

Barnabas: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,

Barnabas:There seems to be some consensus bugs. There are,

Barnabas:which create, multiple forks of each other. So, at this point, we are still, working hard on

Barnabas:I'm trying to get, .NET1 either up and running, or just restart it, maybe sometime next week.

nixo:Okay, great. Thanks.

nixo:Tony, do you want to say anything more about, missing… Test for those edge cases?

Toni Wahrstätter:Not really, I think,

Toni Wahrstätter:This is just… yeah, it just seems obvious that

Toni Wahrstätter:If we have, if we're struggling so much, I'm definitely free to…

Toni Wahrstätter:They should have been caught with test cases, I guess.

nixo:Okay.

nixo:Great. And… Okay, so moving on from DevNets,

nixo:I made a PR, to…

nixo:adjust the definition of, SFI,

nixo:I will ask people to take a look at that. We won't make any decisions today, but it would be a topic

nixo:We would talk about an interop.

nixo:Basically just making SFI, more descriptive and, and…

nixo:have a better definition so we know when to move things to SFI.

nixo:And that will apply to Spencer's ask for, moving things to SFI, because right now, in 773, the Glamstagram Meadow, we have no,

nixo:SFIs except for the headliners, and so this would better inform

nixo: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.

nixo:So just take a look at that, maybe think about it before folks go to interrupt.

nixo: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…

nixo: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.

Mikhail Kalinin:To be passed to the EL. So the context for this change is that, CL clients wants to start from a checkpoint.

Mikhail Kalinin:to do a checkpoint sync from a non-finalized checkpoint. In this case, the CL client will basically know the finalized block route.

Mikhail Kalinin:But it will not have the finalized payload hash.

Mikhail Kalinin:In its database.

Mikhail Kalinin:So, and the same for the safe block hash. So what's proposed here?

Mikhail Kalinin:Is actually, To pass a zero… a zero hash.

Mikhail Kalinin:As a kind of a default, or, like, unknown value.

Mikhail Kalinin:For the finalized and for the saved block hash.

Mikhail Kalinin:And, the EL should actually, if it receives this unknown value, if it receives all zero hash.

Mikhail Kalinin: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.

Mikhail Kalinin:The nuance here is that,

Mikhail Kalinin:Eventually, the finalized block cache will be resolved somehow, and the saved block cache will be,

Mikhail Kalinin: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,

Mikhail Kalinin:block hash… a block hash of an existing block. So basically, here is the proposal. It requires the,

Mikhail Kalinin: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.

Mikhail Kalinin:And to further discuss.

Mikhail Kalinin:So, I know, if there are any questions, please just stop me. I'll do… otherwise, I'll just move to the next one.

Mikhail Kalinin:So the next one is, EPBS-related, and

Mikhail Kalinin:Yeah, to give you some context behind this change.

Mikhail Kalinin:I should, yeah, so there is, like, an optimization in the Foctrus updated.

Mikhail Kalinin: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.

Mikhail Kalinin: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,

Mikhail Kalinin:Depending on implementation, we'll be sending the new payload, and Fctor is updated.

Mikhail Kalinin:to the EL with the blocks that are already known as canonical, that are valid.

Mikhail Kalinin:So, in this case, we have a shortcut path for the folk choice updated handling. It basically says that

Mikhail Kalinin:In the case where the, the structure is updated to head.

Mikhail Kalinin:In this update points out to the already validated and valid block, which is ancestor of the head in observation to the execution layer.

Mikhail Kalinin:The execution layer may basically skip.

Mikhail Kalinin: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

Mikhail Kalinin:In EPBS, and a valid, payload should be… could be reawed out, because it was not timely.

Mikhail Kalinin:And, this proposal kind of…

Mikhail Kalinin:Like, handling this in a way that… The reorg…

Mikhail Kalinin:To the ancestor of the head, even if it's valid, becomes possible.

Mikhail Kalinin:And, also EL should start building a payload if there are payload attributes in the FogChoice updated call.

Mikhail Kalinin:But, to… to find a middle ground between that optimization that I have mentioned and the EPBS cases.

Mikhail Kalinin:It's suggested to have, like, only 32 blocks.

Mikhail Kalinin:reorg in this case. Like, not… the depths of reorg should not be more than 32 blocks.

Mikhail Kalinin:But, the nuance here is that

Mikhail Kalinin:All other reorgs, where the, actually have, is from the conflicting, block tree branch, the reorg should happen regardless of, you know.

Mikhail Kalinin:Of, of that 32 block, limit.

Mikhail Kalinin:So that's kind of it. I think it's important for EPBS, so please take a look.

Mikhail Kalinin:comments out, and let's continue, on GitHub.

Mikhail Kalinin:Or ask questions here, if you have.

nixo:Great. Any comments on that one?

nixo:Otherwise, we will move to Hagoda.

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

Mikhail Kalinin: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.

Mikhail Kalinin: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.

Mikhail Kalinin: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,

Mikhail Kalinin: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?

Mikhail Kalinin:For coordination purposes.

Mikhail Kalinin:Dustin, I hear from you, but there are some concerns about, like, that somebody might use save block, so, as justified.

Barnabas: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.

Toni Wahrstätter: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.

Toni Wahrstätter:So, yeah, I think the risk is very low that we break.

Toni Wahrstätter:that dev flat with those.

Barnabas: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

Barnabas: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.

Toni Wahrstätter:But, yeah.

Toni Wahrstätter: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.

Maria Silva:And initially, we were discussing it, including it.

Maria Silva:even in DevNet 3, because of that, the…

Maria Silva: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.

Maria Silva:DevNet, so we do have a couple of…

Maria Silva: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

Maria Silva:do… the current version of the specs for 8037, the…

Maria Silva: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.

Dragan Rakita:This is just a preference, I wouldn't mind, like, doing much DevNet, but…

Dragan Rakita:There are a few, like, catch cases and AT3070s.

Dragan Rakita:Follow those, and we have, like, paintings that we moved for the next DevNet.

Dragan Rakita: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?

Parithosh Jayanthi: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.

Parithosh Jayanthi: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.

nixo: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.

nixo:Anything else on that?

nixo:There is, we will move on to Hakota.

nixo: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

nixo:frame transactions CFI'd as a placeholder to decide on an AA direction, which means that,

nixo:The people working on AA proposals need to work together to figure out, the best way to move forward.

nixo:Does anybody have any contention with that, with that, view of the outcome.

nixo: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.

nixo: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…

nixo:remembering correctly?

nixo: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.

nixo:Any questions there?

nixo:Great.

nixo:Then we will move on to Antonio, who wants to give a 2-minute, pleon account function.

asanso:Right. Can you actually hear me?

nixo:Yes.

asanso: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,

asanso:I mean, not knowing too much the process, and so on, but…

asanso: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.

asanso:It's a good topic, too, for having a headliner in,

asanso:In Agata. And of course, like, I come with my post-bantum transaction signature.

asanso: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

asanso: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.

asanso: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.

asanso:On the non-perfect, Fremi transaction.

asanso: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.

nixo:Any goal of native account obstruction as a focus in the report can't be accomplished as

nixo:Being CFI'd as a non-headliner.

asanso: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

asanso: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.

asanso:And doing all because the process was not, like, designed for this specific nuance is a pity.

asanso: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.

asanso: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

nixo:a large amount of, support than talking about, switching it to a headliner, which…

nixo:The implication of that, yes, Lumi, would be that we would delay Hagoda,

nixo:If it's not done, we would make headcoda's, release dependent on that being done.

nixo: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.

Łukasz Rozmej:Which doesn't need consensus changes, and does everything Account Obstructions tries to do, except

Łukasz Rozmej:Post-quantum signatures, which would have to be done in a separate transaction type.

Łukasz Rozmej:And, so, yeah, this is an alternative, to… to native account abstraction, and in my opinion, it's…

Łukasz Rozmej:potentially better and simpler, so I would really like everyone to…

Łukasz Rozmej:Read it, and give feedback.

nixo:Okay, we'll give Ben some time, to…

nixo: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…

Pedro: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.

Pedro:I don't want to be coming into a core devs call and start comparing EVM to other machines, but

Pedro: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

Pedro: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

Pedro:in a situation where we're gonna take another health measure. I really appreciate Ben for putting together an ERC.

Pedro:But the NRC defies the purpose of

Pedro: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

Pedro:it was not actually discontent around 8141. There was only discontent around the maturity of our standard, because it was written

Pedro: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

Pedro:A short window of time.

nixo:Antonio?

asanso: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…

asanso: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

asanso:days and weeks, I mean, it's kind of heavy at the moment, so… let's, let's…

Łukasz Rozmej:Oh…

asanso:Quickly.

Łukasz Rozmej:Black…

Łukasz Rozmej: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?

nixo:Okay, Ben, you want to take the mic real quick?

Ben Adams:Yeah, sure. Sorry, I'm not very…

Ben Adams:prepared. As I say, it was just this morning, but…

Ben Adams:the topic was coming up today, so, my team said I should present.

Ben Adams: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.

Ben Adams:So it's, wallet title deeds, so account abstractions through, NFTs.

Ben Adams:But the… the idea is to…

Ben Adams:Traditionally, you're… you have an EOA that is bonded to its custody, and the idea is to sever… separate that link, so…

Ben Adams:you instead bond a NFT, which is, the 7… 721.

Ben Adams:To an address, so they are… they become one thing, and your EOA is the sign-in key.

Ben Adams: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,

Ben Adams:how things work. So you would, if you want to do address rotation.

Ben Adams:you would… you would get a new EOA, and that could be a post-quantum, or, pass keys, or whatever, using

Ben Adams:Different transaction type.

Ben Adams:And then you would transfer the NFT to that account, and you've done key rotation, essentially.

Ben Adams:Because now all the assets have moved from one account to another, so you… Job transferable,

Ben Adams:Control there. And then you can do programmable smart, control through it.

Ben Adams:So you can… oh, sorry, you have a… so the… Title deed is bonded

Ben Adams: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.

Ben Adams:And so forth.

Ben Adams:So you can do…

Ben Adams:Key rotation without identity. So if you wanted to move your assets from your hot wallet.

Ben Adams: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.

Ben Adams:Or multi-sig, or however you want to… or is quantum signature.

Ben Adams:And, you know, with that goes your Aave, ENS name, Uniswap LPT, your governance history, because it's attached to the

Ben Adams:transferable account.

Ben Adams:address.

Ben Adams:But because…

Ben Adams:it's an NFT, and the NFT is an account, and you can transfer it. You can also, therefore.

Ben Adams: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.

Ben Adams:And you want to, have secure trust boundaries.

Ben Adams:And that gives you, approval scope, risk isolation, so if you have… you might have,

Ben Adams:One that… one branch of your account that you're doing

Ben Adams:You have your solid assets in, and another one that you're… Using…

Ben Adams:I'm not in the app, so whatever.

Ben Adams: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.

Ben Adams:And then you can also do infrastructure-free gas sponsorship, so you can… you can do the signing.

Ben Adams:Which could be a batch sign, that goes through the smart account.

Ben Adams:And unlike, 4337, anybody can…

Ben Adams:Sponsor that, so that could be a friend.

Ben Adams:That could… you don't need, all the paymasters, the bundlers, anything like that?

Ben Adams:It could be, your company might give you Account, delegate you to it.

Ben Adams:And then you can… and they… they sponsor all your transactions, for instance. Or you're using a DEX,

Ben Adams:And, you know, CalSwap, for instance.

Ben Adams:You sign a transaction, you don't pay any gas, and they take it out the other end.

Ben Adams:So, yeah, so the required infrastructure is… is…

Ben Adams:none for the sponsorship path, because any EOA can relay.

Ben Adams:it's the standard EVM protocol transaction.

Ben Adams:Versus… Off-chain when it's trapped, so you got the…

Ben Adams:So it works with, fossil, And,

Ben Adams:VOSP, which is the reduced state for validators, where you only keep the account try, rather than necessarily all the state.

Ben Adams:this will run through… As I said, it, it…

Ben Adams:Works through, both this, fossil censorship resistance, these transactions, NZSOP… Sorry, I'm just gonna…

Ben Adams:Go through… Victory.

Ben Adams:So essentially, you're turning your wallet… it's no longer…

Ben Adams:Sort of an isolated island. They become, transferable financial primitives.

Ben Adams:You can create a hierarchy of them.

Ben Adams:You can do gas sponsorship, key rotation, it works with fossil, it works with,

Ben Adams:PRP, you can do privacy withdrawal support, yeah. There's a… there's a huge amount more to it, like digital inheritance, and…

Ben Adams:AI accounts, and… All sorts of things, but, yeah, so… I'll just… I'd present.

Ben Adams:Thank you for listening.

Ben Adams:Please check out the… ERC.

nixo:Thank you. Tomah and… Do you have,

nixo:You have had your hand raised, do you want to, take the mic.

Tomás Arjovsky | Lambda | Ethrex:Yeah, sure. So I was wondering which was the process through which,

Tomás Arjovsky | Lambda | Ethrex: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.

Tomás Arjovsky | Lambda | Ethrex:if anyone is against this, but the decision is already taken, so I was wondering about that. And in contrast, I'm wondering why…

Tomás Arjovsky | Lambda | Ethrex: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…

nixo:Frame transactions was CFI'd, as a non-headliner.

nixo: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…

nixo:That, we get…

nixo: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.

nixo:On, some proposal, then we can consider moving it up to a headliner again,

nixo:in that vein, I think it would be good for…

nixo:the AA folks to have an AA breakout, would anybody be willing to…

nixo: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.

nixo:Great. Parthas Arathi?

Parthasarathy Ramanujam:Yeah, so, yeah, I…

Parthasarathy Ramanujam: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

Parthasarathy Ramanujam:Already a lot.

Parthasarathy Ramanujam: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.

Parthasarathy Ramanujam: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.

nixo:Okay.

Giulio:Yeah, can you hear me?

nixo:Yep.

Giulio:Okay, so, it just… I don't know, I just wanted to say that it's… it seems that,

Giulio:And so, yes, okay, with CFI frames, but… I mean, it's…

Giulio:I don't know how to put this, but I think it's a bit, I, I think…

Giulio:I think… I just wanted to ask… okay, whatever, I'm just gonna ask it,

Giulio:I'm gonna just bring it up again.

Giulio:Who here would actually prefer doing scheme transactions instead of frame transactions out of the client bits

Giulio: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.

asanso:Right, again, I'm not a developer here, you guys probably know me. I already expressed this to Julie in private.

asanso: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.

asanso: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

asanso: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.

asanso:I will not frame it like a competitor's.

Giulio:It's my position.

asanso:Look, here, but, yeah.

Giulio: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.

Giulio: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.

Giulio: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?

asanso:Oh, sorry, I need to lower my hand, sorry.

nixo:Okay, Nico?

Nico Consigny:Yep. Can you hear me?

nixo:Yep.

Nico Consigny:Yeah, I think one important point around the post-quantum stuff is that there are many, many easy ways to do it.

Nico Consigny:We can just add a pre-compile and say it's done.

Nico Consigny: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.

Nico Consigny:And this is, like…

Nico Consigny:The key requirements that we have if we want to survive in, like, a world where

Nico Consigny:Schemes are going to be broken fast.

Nico Consigny:And there is simply no other proposition that is trying to tackle that.

Nico Consigny:So I think if we want to compare, like, apples to apples, we want to have another solution that is also providing crypto agility.

Nico Consigny: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:I just wanted to say one quick thing. I added a PR that brings some of the ideas from the Steam transaction into frame.

lightclient:Obviously, scheme transactions are… Focusing on a slightly different problem.

lightclient: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.

lightclient:actually means.

lightclient: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.

lightclient:And if we can't even, you know, solve this one.

lightclient:Like, I worry about our ability to continue

lightclient: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…

Dragan Rakita:Aa is basically fluid.

Dragan Rakita:And we should iterate on it. I would urge people to think about the minimal mechanism they need

Dragan Rakita:For something to work for them.

Dragan Rakita:And I think design will clarify If we think about it.

Dragan Rakita:If you think about the minimal things that we need.

lightclient:I… frame transaction. Like, we have thought a lot about what is the minimal thing. That's why we…

lightclient:Took the ideas from 7701 and tried to, like, minify it as much as possible.

lightclient:It's just, like, fundamentally allowing some execution to happen before the transaction is accepted as a, like, valid paying transaction.

lightclient: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.

lightclient:But, like, we're not really comparing apples to apples in most of these situations. Like, scheme transactions provide only, like, a very small

lightclient: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

lightclient: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.

Dragan Rakita:It is use case that you want to fulfill, it is use case that you want to have everybody

Dragan Rakita:Move to that use case, to that mechanism that you want to implement.

Dragan Rakita: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.

Dragan Rakita: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?

Dragan Rakita:That's why I'm urging everybody to, like, think in that…

Dragan Rakita:In that flow, in that, like… in that direction.

lightclient:what's the best way to, like, think in that direction? Because on my side, I feel like we have…

lightclient: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.

lightclient: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: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.

lightclient:And…

lightclient:Like, I just don't really know what other things that we need to be doing to make a compelling argument to people that

lightclient: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

lightclient:gray values.

lightclient:observed.

nixo:Okay, I think I would encourage people to, to Dragon's point,

nixo:Decide what their minimum requirements for this thing are.

nixo:And also, please look at the existing proposals, and bring your, your…

nixo: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.

nixo:To the AA breakouts that get scheduled.

nixo:James?

prestwich:I've been involved in every AA conversation from the beginning of Ethereum.

prestwich:We are not going to reach a design that everyone agrees with.

prestwich:It is not possible in this design space.

prestwich:If something like frames is included, it will be because it has political weight behind it, and that's okay.

prestwich:we can debate this indefinitely. We have debated it for 10 years.

prestwich:we should focus on what is important, the use cases, like Matt was talking about.

prestwich:And what is important, the post-plantum migration, which we need to do for all users within the next 3 to 5 years.

prestwich:I don't think that AA should be a blocker for PQ.

prestwich:And coupling those in the design space seems irresponsible.

nixo:Pedro?

nixo:Pedro, we can't hear you.

nixo:Okay.

nixo:Julio?

Giulio: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.

Giulio: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?

nixo:Do we have any more…

nixo:AA conversation that can't be moved to… A breakout call.

nixo:Yeah, agreed. I don't think that we'll be making any decisions today.

nixo:Minus just having this breakout call where we dive into, the specifics.

nixo:And…

nixo:I would urge people to actually prepare for that, and not just come to the call, because having these

nixo: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.

nixo:To be on the breakout call.

nixo:If… No more comments on AA, we can move to the miscellaneous, smaller items on the agenda.

nixo:Great.

nixo:Sina, you wanted to talk about history pruning targets?

Sina Mahmoodi:Yes, thank you.

Sina Mahmoodi:So, I wanted to bring up… History pruning targets, and… Specifically thinking about future targets.

Sina Mahmoodi:And to provide a bit of context.

Sina Mahmoodi:You'll remember that a year and a half ago, we…

Sina Mahmoodi:Sat down at the interop, and… Agreed that from… May last year.

Sina Mahmoodi:Clients must be able to handle the fact that some other clients on the network may not have.

Sina Mahmoodi:pre-emerge history.

Sina Mahmoodi:And, because of that, we implemented Air 1, and… Ability imported, exported.

Sina Mahmoodi:And that's kind of where we left things, so since then,

Sina Mahmoodi:Many of the clients have added some way to prune parts of the history, and…

Sina Mahmoodi:I think there is some divergence in…

Sina Mahmoodi:The exact pruning mechanisms that clients have right now.

Sina Mahmoodi:I think, so basically it came up, yesterday in…

Sina Mahmoodi:on Discord, on the History Expirator channel, that's… there seems to be different ideas about it.

Sina Mahmoodi:like, two options specifically came up. One is…

Sina Mahmoodi:basically setting the next target, to be until Pectra, so…

Sina Mahmoodi:Clients should be fine with having pre-pectoral history pruned.

Sina Mahmoodi:and… The other one being rolling expiry.

Sina Mahmoodi:Which is, like, basically, its client stores, a window, and it's a moving window.

Sina Mahmoodi:But I think I've been thinking about it since yesterday, and…

Sina Mahmoodi:I would like to suggest a different way of looking at it.

Sina Mahmoodi: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.

Sina Mahmoodi:And… I think as part of that, I also want to, like, bring up this question that…

Sina Mahmoodi:Like, what, I want to know, basically, what is the landscape right now?

Sina Mahmoodi:How aggressively, can users prune their history,

Sina Mahmoodi: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

Sina Mahmoodi:And we recently also added a way to prune onto Pectra. I want to know, basically, yeah,

Sina Mahmoodi:In the most aggressive version, how far can users prune their clients? So if you guys can just chime in here…

Sina Mahmoodi:Yeah, to… to Barnabas?

Sina Mahmoodi:I would argue that, finalized is…

Sina Mahmoodi:Right, okay. So, Aragon, you can be as aggressive as you want.

Sina Mahmoodi:One of us suggesting Finalist Epoch.

Sina Mahmoodi:I can tell you that one of the requirements that we have in GATH is that we need at least the ninth last

Sina Mahmoodi:90,000 blocks to be present. This is for social recovery. It's like this mechanism that we have.

Sina Mahmoodi:And I think it's kind of important to have at least that amount of history around.

Sina Mahmoodi:But I'm open to hearing other ideas.

nixo:Hello?

Giulio:Yeah, so, I think this… the pruning target is mostly just, if I may, a political problem. It's just something we agree on.

Giulio: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.

Giulio: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.

Giulio: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…

Giulio: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…

Sina Mahmoodi:From my perspective, we gotta say, like, everybody is required to store at least, let's say, a month of history.

Sina Mahmoodi:Just trying to figure out what is a good number.

Łukasz Rozmej:So, if I recall, EAP444, was saying one year.

Łukasz Rozmej:Which was kind of agreed upon.

Łukasz Rozmej:Let me look it up.

lightclient:Yeah, it was one year.

lightclient:I think one year is, very generous.

lightclient:Mountain.

marek:Exactly.

lightclient:But the absolute minimum is the… Weak subjectivity checkpoint.

lightclient:Which I don't know what it is, given our validator set size.

Barnabas:14 days.

lightclient:Okay.

lightclient:So we couldn't do less than 14 days, because you want to be able to fully validate from that point on.

lightclient:And so it's a matter of, do we want to have some buffer on that, or…

lightclient:Is 14 acceptable?

Barnabas:I think we should do at least the plot.

Barnabas:The 18-day blob, which is 8,000 epochs, I think.

Sina Mahmoodi:Barnabas, so that was 18 days?

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

Sina Mahmoodi:of…

Sina Mahmoodi: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,

Sina Mahmoodi:from pruning… so, Pactra was almost one year ago, and…

Sina Mahmoodi:The minimum for me is 100K, and the difference between that is around 70 gigabytes of history.

Sina Mahmoodi:So, like, we're… like, the gain are quite…

Sina Mahmoodi:small, I would say, compared to… like, once you prune everything before that,

Sina Mahmoodi:So this is, like, the kind of area that we're talking about.

Sina Mahmoodi:Just to throw out a number, like, one month?

Sina Mahmoodi:I mean, I don't know if we can make a decision here, but,

Sina Mahmoodi: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…

jonny:Week subjectivity period is, or point is.

jonny:Because if it stops finalizing, you know, or… I mean, that can change. Just picking one just seems kind of, arbitrary, right?

jonny:It's not always good.

lightclient:I mean, I think we need the… we need the fixed period of time, plus any unfinaled blocks.

lightclient: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…

lightclient: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.

Toni Wahrstätter:Epochs.

Toni Wahrstätter:That's, I think, 18 days or 20 days, something like that.

lightclient:But is the number of validators in the set not a…

lightclient: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:Gotcha.

Sina Mahmoodi:I think Matt raises a good point, like, what if,

Sina Mahmoodi:We stopped financing for a week, two weeks.

lightclient: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.

lightclient:Any number that we come up with, if we're not finalizing, then that we need to…

lightclient:Be keeping those, unfinaled blocks, as well as the

lightclient: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…

Mikhail Kalinin:It will take 18 days for inactivity League to… Eject,

Mikhail Kalinin:to basically diminish the validator balances of inactive validators to start finalizing again. So these 18 days are taken from that.

Mikhail Kalinin:As far as I'm recalling.

lightclient: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:happens that…

Mikhail Kalinin:print.

lightclient:It just happens they're both similar numbers.

Mikhail Kalinin:Yeah.

lightclient: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…

Łukasz Rozmej:I would… I would vote for some kind of default standard as being

Łukasz Rozmej:Somewhat… at least a bit conservative, so that one year on four… it's quite much conservative, but…

Łukasz Rozmej:Maybe, you know, something like half a year, or three months, or a quarter should be, like, the default, in my opinion.

Dustin: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.

Dustin: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,

Dustin: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.

Dustin: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.

Sina Mahmoodi:I think it should be kind of up to the client what they define their client, their default.

Sina Mahmoodi: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.

Sina Mahmoodi: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.

nixo:Anything more on that?

nixo:Great.

nixo:Chase, do you want to talk about the, your request to have devs comment on the new RPC method?

nixo:Is Chase here?

nixo:Well, then I will just copy this link into the chat.

nixo:And if EL devs can comment on this, Chase is proposing adding a new RPC method, and would appreciate comments from execution layer devs.

nixo:And we will move on to Barnabas,

nixo:For bringing the SSZ… for bringing the SSZ into the engine API?

Barnabas: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.

Barnabas:This would basically enable,

Barnabas: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

Barnabas:specific EIP is required, clients could just implement, SSD one day of time, and,

Barnabas:we could do something like capabilities exchange, where the CL would basically be able to, use the SSD instead of JSON.

Barnabas:I can post… the execution API.

Barnabas: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.

nixo:Thank you, everyone.

stokes:Thank you, goodbye.

Barnabas:Nope.

Andrew Ashikhmin:Thank you, bye-bye.

Toni Wahrstätter:Bye bye!

Chat Logs

Barnabas:Good luck Nixo! ❤️

Guillaume:yay, nixo ftw

Dragan Rakita:A lot of those got addressed, would like to see them so we can discuss them

Łukasz Rozmej:@FLCL is looking at this from Nethermind

Toni Wahrstätter:This sounds like we're missing tests for those edge cases

Dustin:the CL/EL devnets should just merged

Stefan Starflinger:Replying to "the CL/EL devnets sh..." soon tbd

spencer:Replying to "This sounds like w..." Have a PR for the create geth split, but worth discussing whether the behaviour is correct/incorrect: https://github.com/ethereum/execution-specs/pull/2639

Toni Wahrstätter:Replying to "the CL/EL devnets sh..." While both are breaking? Makes not much sense right now

spencer:Replying to "From Marius earlie..." Also in this PR: https://github.com/ethereum/execution-specs/pull/2639 Also have access lists tests

nixo:https://github.com/ethereum/EIPs/pull/11475

spencer:Want to say yes they should have been caught by tests but finding every edge case is very hard based on the scope of 8037!

Stefan Starflinger:Replying to "Want to say yes they..." its a lot

Mikhail Kalinin:https://github.com/ethereum/execution-apis/pull/760

Mario Vega:Replying to "Want to say yes they..." 8037 has really put our testing framework through a stress test

Toni Wahrstätter:Replying to "Want to say yes they..." Yeah agree, super hard to figure out all potential cases

Toni Wahrstätter:Replying to "Want to say yes they..." I meant it more like, now that we know the issue, we can create a test for it such that it's easier for clients to fix and validate their fix

Mikhail Kalinin:https://github.com/ethereum/execution-apis/pull/770

Dragan Rakita:Replying to "This sounds like we'..." @spencer is this issue 3 from https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8037/spec_review_state_gas_accounting.md

Dragan Rakita:Replying to "From Marius earlier ..." @Maria Silva we should probably add access list issue to https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8037/spec_review_state_gas_accounting.md

Dustin:safe block is currently useless

Dustin:as justified

Toni Wahrstätter:@Stefan Starflinger should we discuss bal-devnet-4 vs gloas-devnet-0?

Dustin:justified is some random gasper thing which shouldn't be exposed anyway in this context

Barnabas:Replying to "@Stefan Starflinger ..." do you expect any changes in bals ?

Dragan Rakita:Replying to "@Stefan Starflinger ..." Those should be less concerning as it does not include additional mechanisms but are “just”constant change. I lean more on bal-devnet4 but don’t mind the merged devnet.

nixo:nope

nixo:resumed

felix (eest):tests are ready

Giulio:Isnt epbs-devnet dead as of now?

Barnabas:yeah but we are working on it

Giulio:Replying to "Isnt epbs-devnet dea..." How can you merge it by end of april?

Barnabas:Replying to "Isnt epbs-devnet dea..." fix it by end of this week 😄

spencer:Agree with dragan, re having a devnet-4 with dynamic cpsb for 8037

FLCL:devnet-4 = devnet-3 + dynamic 8037 spec fixes + stability

Stefan Starflinger:Replying to "devnet-4 = devnet-3 ..." yes

Stefan Starflinger:Replying to "devnet-4 = devnet-3 ..." next week wednesday?

Łukasz Rozmej:why not ERC, why not before Hegota: https://github.com/ethereum/ERCs/pull/1658 ?

Parthasarathy Ramanujam:We have had several AA ERCs. It is time for native AA.

Łukasz Rozmej:you didn't have one written by core dev

Lumi | Offchain Labs:Headliner = we would delay Hegota if its not done

Łukasz Rozmej:read before judgibng, please!

Parthasarathy Ramanujam:Sorry, I read NFT controlled smart account and didn’t read further. Are we seriously considering that? :-). I will read and comment there. But, I think its unfair to dismiss other ERC proposals just because they aren’t core developer

Cyrus:No more half measures

DanielVF:IS this title deeds?

Cyrus:Full AA or bust

Parthasarathy Ramanujam:Full AA. No more ERCs.

prestwich:all AA designs are half-measures. always have been

DanielVF:Wallet deeds seem very cool

Łukasz Rozmej:@Pedro have you read the proposal, or just jumping to conclusions?

Giulio:Work the usecase from the usecase, not from the tech

Cyrus:Replying to "@Pedro have you read..." Anything that can be done as an ERC only is not real AA

Giulio:Native is just an adjective. Pick the right tool

Alex Forshtat:If "Account Abstraction" as a headliner is still controversial, does Post Quantum Infrastructure make sense as a "topic headliner"? Especially given the recent news?

DanielVF:There is discontent around 8141 - it does make descisions that can't be backed out. Reth is opposed to it.

Ben Adams:Post Quatum doesn't need Frames

Orca 0x:Replying to "all AA designs are h..." when native key delegation

Pedro:Replying to "There is discontent ..." Of course there are decisions that cannot be backed out… because its an EIP that requires EL changes

Justin Florentine (Besu):Replying to "all AA designs are h..." right after address space expansion

Dragan Rakita:Awesome pictures

prestwich:Replying to "all AA designs are h..." don’t need address space expansion, you can do it like 7702

Giulio:Replying to "Awesome pictures" You are awesome

Lumi | Offchain Labs:Replying to "Awesome pictures" NotebookLM

DanielVF:Hella cool

Hadrien Croubois (OpenZeppelin):This has existed for a while, it’s nothing new, and it doesn’t solve anything about what we do we current EOA

Parthasarathy Ramanujam:Isn’t this similar to ERC6551?

Giulio:Maybe we should CFI something like frames too

lightclient:8221 requires centralized transaction relayers or users to have separate gas accounts to use public memoool and FOCIL. solving those are a non negotiable for AA in my opinion

Cyrus:Why are we talking about more ERCs? It's insane. An ERC cannot solve the EOA problem.

Hadrien Croubois (OpenZeppelin):I literally built this in 2019~2020

Pedro:Honestly there should be a rule that ERCs should not be discussed in ACDE

lightclient:Replying to "I literally built this in 2019~2020" very forward thinking 😉

Parthasarathy Ramanujam:The idea is not new. It has been built before (by non core developers)

Łukasz Rozmej:Replying to "Why are we talking a..." not to lose FOCIL/public mempool or statelessness

nixo:lol at ben saying “i’m not prepared” and having a beautiful 14 slide presentation queued up

Hadrien Croubois (OpenZeppelin):Replying to "I literally built this in 2019~2020" I was late to the party. Fabian did that with 725 before me

Łukasz Rozmej:Replying to "Why are we talking a..." you loose one of them with frames

Łukasz Rozmej:Replying to "Why are we talking a..." currently

Hadrien Croubois (OpenZeppelin):Replying to "I literally built this in 2019~2020" Just without the nft registry part

Parthasarathy Ramanujam:Replying to "Why are we talking a..." You lose them here, because you will be forced to use a centralised relayer.

lightclient:“a third party with eth” not decentralized

DanielVF:Replying to "“a third party wi..." Couldn't it be you with Eth?

Hadrien Croubois (OpenZeppelin):Replying to "“a third party with eth” not decentralized" Exactly. This is a very hard thing to decentralized. So far 4337 is the solution to decentralizing this

lightclient:Replying to "“a third party with eth” not decentralized" no because smart accounts can’t originate tx without native AA. 4337 works but you need a bundler. which means you need a middleman for FOCIL

Hadrien Croubois (OpenZeppelin):Replying to "“a third party with eth” not decentralized" Saying « you don’t need 4337 » just show you don’t understand what the problem is

CPerezz:Replying to "“a third party with ..." I believe this has in mind a lot more than just AA. It tries to reason further with other protocol-parts in mind. The goal isn’t to just do AA. But do it on a way compatible with the rest of features we plan to ship.

FLCL:q: will txpool contain signatures for gasless txs? (ig no)

DanielVF:Replying to "“a third party wi..." So the core of AA to you, @lightclientis that a contract can initiate a transaction?

FLCL:AA is the headliner

lightclient:Replying to "“a third party with eth” not decentralized" yes. we have good mechanisms for the execution abstraction portion of AA

Dragan Rakita:Replying to "lol at ben saying “i..." He has magic powers

DanielVF:We had multiple votes from the majority of client teams against frame transactions as a headliner

DanielVF:Replying to "“a third party wi..." Thanks.

Tomás Arjovsky | Lambda | Ethrex:Who are “the AA folks” who “will be taking this decision"? Is there a separate meeting where this decisions are taken?

Pedro:pedro@walletconnect.com

Orca 0x:this breakout will be tracked at https://github.com/ethereum/pm/issues ?

Orca 0x:I think “AA” was CFI’d

Parthasarathy Ramanujam:3 teams were in favour, no?

Guillaume:Replying to "3 teams were in favo..." yes

Parthasarathy Ramanujam:It is not 1 team.

Tomás Arjovsky | Lambda | Ethrex:Gotta count the numbers beforehand giulio

nixo:Replying to "Who are “the AA folk..." yes, having a public breakout call to resolve a “best path forward” for an AA proposal. if we can find consensus among a majority of clients, it makes sense to discuss making it a headliner. AA folks = authors

nixo:Replying to "this breakout will b..." yes

Pedro:Definitely more than 1 team was in favor of Frame Transactions and 2 transactions were neutral 00:53:46 Łukasz Rozmej: My problem with frames and all native AA proposal I read I can't combine: native AA statelessness/partial stateful FOCIL/public mempool My concerns arn't political, my concers are purely technical.

FLCL:5 years spent, so broader community need to spend how much time to agree on them? 1 month?

lightclient:btw i did open a PR to frames eip to bring some ideas from scheme tx into it: https://github.com/ethereum/EIPs/pull/11481

Giulio:Replying to "3 teams were in favo..." Who is the rhird? I forgto ethrex

prestwich:AA can’t be allowed to block PQ

Trent:Wonder if this discussion would be more useful in the breakout

Hadrien Croubois (OpenZeppelin):Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do

Parthasarathy Ramanujam:Replying to "3 teams were in favo..." AFAIK, Besu were ok with it. They just didnt want it to be a headliner.

Ben Adams:Replying to "Adding a precompile ..." Which is what the scheme txs did

CPerezz:Replying to "Adding a precompile ..." But AA != PQ. You can solve the second without the first

CPerezz:Replying to "Adding a precompile ..." And ofc the second with the first

Giulio:Replying to "3 teams were in favo..." No they were not

Giulio:Replying to "3 teams were in favo..." Its 2 then

Parthasarathy Ramanujam:Replying to "3 teams were in favo..." I asked this question to the Besu team explicitly in the last ACDE and they responded that they wont block if 8141.

Giulio:Replying to "3 teams were in favo..." Thats not support

Hadrien Croubois (OpenZeppelin):Replying to "Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do" AA is not « one thing », it’s many things!

Justin Florentine (Besu):you can't minimize and focus an intentionally abstract feature

Parthasarathy Ramanujam:Replying to "3 teams were in favo..." Neither is it against. We are getting into semantics.

Giulio:Replying to "3 teams were in favo..." I spoke to them too and they largely prefer schemed, both can be true

Hadrien Croubois (OpenZeppelin):Replying to "Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do" Gas payment by a third party for smart contracts: 4337

Justin Florentine (Besu):now, if you want to focus on PQ, that can be minimized and focused. AA cannot.

Luca Donno | L2BEAT:Replying to "My problem with fram..." is there any proposal on how to make frame txs compatible with statelessness?

Hadrien Croubois (OpenZeppelin):Replying to "Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do" Allowing EOA to behave like smart contracts (including 4337): 7702

Łukasz Rozmej:Replying to "My problem with fram..." I don't know of one

Łukasz Rozmej:Replying to "My problem with fram..." And it is inheritely impossible, you need state to validate transaction

DanielVF:I think the core of requiring execution and full state access before inclusion is the thing about frames that makes a lot of other (non-frame transaction) things difficult.

Hadrien Croubois (OpenZeppelin):Replying to "Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do" Saying « this solves AA » makes no sens. You have to say what problem about AA it solves

Łukasz Rozmej:Replying to "My problem with fram..." well potentially if you include witnesses/zk-proofs of their validity with them - maybe

Parthasarathy Ramanujam:And those who disagree with the proposal do not attend the breakout call as well

CPerezz:Replying to "My problem with fram..." Strategy 2 makes it compatible. BUT, if we at some point need more, the mempool participant number will def sense it

Derek Chiang | ZeroDev:Replying to "My problem with fram..." VOPS was designed with native AA in mind: https://ethresear.ch/t/a-pragmatic-path-towards-validity-only-partial-statelessness-vops/22236#p-54075-vops-and-native-account-abstraction-aavops-9 This was written before frames, but frames was designed with VOPS in mind

CPerezz:Replying to "My problem with fram..." THAT IS NOT TRUE

Hadrien Croubois (OpenZeppelin):Replying to "Adding a precompile don’t solve the fact that we need a tx.origin, and that tx.origin is an ECDSA. Without alternative to ECDSA for creating protocole transactions there is nothing ERC/precompile can do" IMO a problem worth solving is « how to permanently move EOA to smart accounts, getting rid of the ecdsa key ». « How do we make EOA that are not ECDSA » is also an interesting problem to solve (for all the devices that have P256 keys)

Derek Chiang | ZeroDev:Replying to "My problem with fram..." Wait sorry which part?

CPerezz:Replying to "My problem with fram..." I wrote this with some colleagues. We just mentioned that it could work. But was very hard and would be a very minimal AA. Otherwise, if we need arbitrary state, all crumbles

Dustin:Yeah, one theme of one of the ACDEs re 8141 was people looking for one bullet point or one tl;dr for why 8141 specifically was good, what was it "really" about. Seems to have been an allergy to its general-purpose abstraction angles

Dustin:specifically a couple of ELs disliked it exactly because it's a general solution

CPerezz:Replying to "My problem with fram..." AA-VOPS works only if we go for Frame with Strategy 2 or Schemed (or any ERC ofc)

lightclient:Replying to "My problem with frames and all native AA proposal I read I can't combine: native AA statelessness/partial stateful FOCIL/public mempool My concerns arn't political, my concers are purely technical." why is it so minimal?

Justin Florentine (Besu):this is the second call in a row where we've been holding ad-hoc "votes". not a thing we normally do.

CPerezz:Replying to "My problem with fram..." “Canonical Paymaster” should answer the question no? 🙂

FLCL:frames are cool. We need to start prototyping it asap and facing tx pool issues. If it will be very bad at it we may fork without it. that's why not headliner

CPerezz:Replying to "My problem with fram..." Let wallets adopt whatever they want as contract. And all the sudden, you’ll be in deep trouble tracking arbitrary state

lightclient:Replying to "My problem with frames and all native AA proposal I read I can't combine: native AA statelessness/partial stateful FOCIL/public mempool My concerns arn't political, my concers are purely technical." did you look into actual paymaster implementations?

lightclient:Replying to "My problem with frames and all native AA proposal I read I can't combine: native AA statelessness/partial stateful FOCIL/public mempool My concerns arn't political, my concers are purely technical." i have looked at them and they are very similar

CPerezz:Replying to "My problem with fram..." They are 3 fields. Yes. Sure. But that doesn’t mean this is what will end up being used in the long run

CPerezz:Replying to "My problem with fram..." So you promise compatibility “now”. I agree. But future? No guarantees IMO. And if we ship, we’re locked there. And the implications for statelessness and FOCIL will be high

Barnabas:most aggressive should be finalized epoch ?

Giulio:For erigon, be as aggrwssive as you want

Stefan Starflinger:Replying to "most aggressive shou..." weak subjectivity period?

Milos:I think most aggressive is weak subjectivity

Łukasz Rozmej:minimum 82125 epochs in Nethermind

Barnabas:Replying to "minimum 82125 epochs..." where is this num coming from?

Derek Chiang | ZeroDev:@Łukasz Rozmej if the Ethereum public pool does Strategy 2 (local state only + slot restrictions), doesn’t that give us native AA + statelessness + mempool safety?

Marc:Replying to "minimum 82125 epochs in Nethermind" as specified in eip-4444

Dustin:90k is arbitrary

Łukasz Rozmej:Replying to "minimum 82125 epochs..." so 1 year

Luca Donno | L2BEAT:Replying to "My problem with fram..." I don’t understand sorry, if strategy 2 is compatible with VOPS, what’s the problem? Accounts that need arbitrary state will not be able to use the mempool and we can specify it as a fundamental tradeoff, but still allow the option rather than removing the tradeoff point from the space

Marc:Replying to "minimum 82125 epochs in Nethermind" I believe we just drop pre-merge by default though

marek:Replying to "most aggressive shou..." If it is a finalized epoch, you won't be able to save the blocks as ERA files or in any other way.

Barnabas:Replying to "most aggressive shou..." we don’t need all clients to be able to save era files. We are talking about most aggressive, not least aggressive

marek:Replying to "most aggressive shou..." yeah, I agree

jonny:wouldn't you have to ask the cl?

Dustin:Replying to "wouldn't you have ..." for CLs it's ~finality

Dustin:Replying to "wouldn't you have ..." reorgs don't go beyond that

jonny:Replying to "wouldn't you have to..." the cl knows the wsp

marek:One year is too long; a couple of months, let's say three months, is better

Derek Chiang | ZeroDev:Replying to "My problem with fram..." Yeah same question as Luca above. Would be helpful to know the pushbacks against adopting strategy 2 (or a variant of that) in the mempool while keeping the underlying AA protocol flexible

Dustin:Replying to "wouldn't you have ..." oh right, yeah, that's a CL calculation

Parithosh Jayanthi:Yeah ~18D

jonny:Replying to "wouldn't you have to..." seems like a good thing to expose so the EL can ask

Barnabas:sorry its 4096 epochs not 8k eitehr way its 18.2d for blob expiry

Łukasz Rozmej:keep in mind that when blocks grow post glamsterdam those numbers will also grow

Giulio:I think 2 weeks is fine

Milos:+1 for one month (or some round number of epochs around that time)

Giulio:Sure or +1 month

Barnabas:we have bigger issues if we stop finalizing for 2 weeks lol

prestwich:after MEB isn’t it more complicated than “validators in the set” ?

Parithosh Jayanthi:Yeah for adversarial scenarios we usually take 2 weeks of non finality as the number

Milos:this window should be counted from last finalzied, not from head

Justin Traglia:https://ethspec.tools/#specs/nightly/functions-compute_weak_subjectivity_period

Luca Donno | L2BEAT:Replying to "My problem with fram..." We already allow for this kind of tradeoffs e.g. with blob txs not being supported by FOCIL. Other more complicated accounts can send along the witness if they really want to use the mempool and maybe there is some design similar to blob tickets to allow for propagation of large witnesses

Barnabas:I’d be comfortable with 8192 epochs (~36d)

Milos:Replying to "I’d be comfortable w..." and let's say counting from finalized, not from head

Justin Traglia:Re the weak subjectivity period, we’re already at the “maximum value” and it’s very unlikely to be lowered by validator set changes anytime soon. See this: https://github.com/ethereum/consensus-specs/blob/825f555394b88987be201591cd47017b9c5b3b2b/specs/electra/weak-subjectivity.md?plain=1#L46-L56

CPerezz:Replying to "My problem with fram..." The answer is simple. It works now. AA-VOPS works with strategy 2 because we can track “ONLY THE FIRST 4 slots of every account’s storage tree”. If in the future, the enshrined Canonical Paymaster (https://github.com/lightclient/EIPs/blob/a5db43b500056d544cb0950b08a3bd488aca1eb5/assets/eip-8141/CanonicalPaymaster.sol ) is not enough because community wants more use cases, then, we have a problem. Because 4 slots is not enough anymore. And if you want to support the use cases you’re back at the start line.

Toni Wahrstätter:Replying to "Re the weak subjecti..." Yeah, the 3533 epochs number looks stable

FLCL:Shorter slot times may affect it or it's timestamp dependent?

nixo:https://github.com/ethereum/pm/issues/2004#issuecomment-4200750948

Mikhail Kalinin:Replying to "Re the weak subjecti..." this is because the churn is capped at the moment. if we remove the cap and moreover increase the churn, this value will be changed, although, the change towards reducing WS period

CPerezz:Replying to "My problem with fram..." It’s all about risk. If we’re fine with taking the risk of not getting the enshrined contract right, we can totally go Frame!!! I even mentioned this here: https://ethresear.ch/t/frame-transactions-through-a-statelessness-lens/24538

Barnabas:https://github.com/ethereum/execution-apis/pull/764

Dustin:exchangeCapabilities is still a giant TOCTOU

Dustin:from a CL perspective

Łukasz Rozmej:Replying to "https://github.com/e..." we might be able to start implementation soon

Derek Chiang | ZeroDev:Replying to "My problem with fram..." @CPerezz can u message me on TG? https://t.me/derek_chiang

Derek Chiang | ZeroDev:Replying to "My problem with fram..." Let’s jam more async

Summary

17 highlights · 3 decisions · 3 action itemsExperimental

fork status and schedule

Frame transactions CFI'd as non-headliner; AA proposals now open00:44:07
Glamsterdam DevNet decision: Merge with ePBS if stable by Monday00:26:38
Gas repricing EIPs proposed for DevNet 0; final in DevNet 100:27:07

testing progress

Glamsterdam DevNet 3 launched; gas accounting edge cases discovered00:04:54
EIP-8037 clarifications needed for spillover gas and state refunds00:06:13
ePBS DevNet 1: multiple consensus bugs, peering issues, client disconnections00:08:27
bal-devnet-4 planned for next Wednesday with dynamic cost spec00:34:07

engine api changes

Allow zero safe/finalized block hash for checkpoint sync00:11:20
ePBS: Remove FCU shortcut to enable payload reorgs within 32 blocks00:14:10
SSZ over REST proposed for engine API performance improvements01:17:07

account abstraction

Ben Adams presents Wallet Title Deeds ERC (NFT-based AA)00:35:30
Frame transactions require centralized relayers or gas accounts for mempool00:48:37
Native AA incompatible with statelessness/FOCIL without Strategy 2 constraints00:54:58

history pruning

Consensus emerging: 1 month minimum history (plus unfinalized blocks)01:01:47
EIP-4444: one year; weak subjectivity: 18 days; blob expiry: 18 days01:08:07

organizational

SFI definition PR to clarify when EIPs move to Scheduled for Inclusion00:10:08
AA breakout call to be scheduled; Pedro to champion00:58:07

Decisions

Frame transactions CFI'd as non-headliner; AA proposals now open for Hegota00:39:56
If ePBS stable Monday: Glamsterdam DevNet 0, then rapid DevNet 1 with gas repricing00:22:56
If ePBS unstable: bal-devnet-4 with dynamic 8037 and stability fixes00:22:56

Action Items

All teams: Review SFI definition PR #11475 before Interop discussion00:10:08
Pedro (Protocol Support to coordinate): Schedule AA breakout to align on proposal path forward00:58:07
All teams: Discuss history pruning target in History Expirator Discord channel01:16:37

Targets

Monday - Decision point for ePBS DevNet stability00:26:38
Next Wednesday - bal-devnet-4 launch (if needed)00:34:07