ACDE: Yes. So we're live now. Welcome to All Core Devs number 234. Today's April 9. I will be filling in for Ansgar today. We have a few things on the agenda, a lot of little things. We'll talk about LAMSTAM DevNet updates, some engine API changes, some housekeeping for Hagoda. AA topics and then some miscellaneous items if those all get talked about in time. ⁓ Okay, for Glamster Dam, do we have any DevNet updates? ⁓ I can start. ⁓ We launched yesterday Baldefinite 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. ⁓ 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 of 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, 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. Anyone from Gath? Okay, well, if Geth wants to follow up async then. ⁓ Are there any other executioner clients that have been looking into this? OK, Stefan, where should the execution layer clients go async to follow up on this? In the ⁓ Steel Discord, we're generally sharing all the information. And yeah, it's something that is 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 going to I 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. Great, anything else on DEDETS? I can give a few comments about APPS.NET 1. have launched a few days ago and it's been not going as great. 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 seems to be some consensus bugs. and which create multiple forks of each other. at this point, we are still working hard on trying to get that one either up and running or just restart it. Maybe sometime next week. Okay, great. Thanks. Tony, do you want to say anything more about missing tests for those edge cases? ⁓ Not really, I think this is just seems obvious that if we're struggling so much on different freedom, they should have been caught with test cases, I guess. Great. ⁓ And OK, so moving on from Dev Nets, ⁓ 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. would talk about interop, basically just making SFI. more descriptive 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 Glamster-Gam Meadow we have no SFIs except for the headliners. So this would better inform Formos on when to move things to SFI. And the definition that I proposed is based on an ACDT call from a couple of weeks ago. So just take a look at that and maybe think about it before folks go to interrupt. So moving on to engine API changes. Mikhail, do you want to talk about, I put these all together. One of them is related to Glamster, but you can take the mic for all of them. ⁓ Yeah, thanks a lot, Nik. I'll be brief. I'll try to. So all right, so the first change that we have in the list is allow zero, save, 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 ⁓ hash as a kind of a default or like unknown value for the finalized and for the safe 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 been synced in the past and it has some finalized block hash in the database. The nuance here is that eventually the finalized block hash will be a result somehow and the safe block hash will be found by the CL by running the past 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 which requires ⁓ the implementation changes on the EL side and yeah. That's basically to announce it here and to invite the developers and also see our developers to look at this proposal and further discuss. So I don't know. ⁓ If there are any questions, please just stop me. ⁓ Otherwise, I'll just move to the next one. ⁓ so the next one is, ⁓ EPBS related and, ⁓ yeah, to, to, give you some context behind this, ⁓ I should, ⁓ yeah. So there is like an optimization in the fog choice updated. ⁓ it's done for the case when for instance, EL has, EL has been synced already and the CL, ⁓ is restarted from scratch and it's databases like basically wiped out. and it starts sinking 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, will be sending the new payload and forks updated to the EL with the blocks that are already known as canonical that are valid. So in this case, we have a shortcut pass for the forks updated handling. basically says that In the case where the the FulcTrue is updated, the 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 FulcTrue is updated call, like basically just skip the update. And in this case, 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 reorg 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 fog choice updated call. But to ⁓ define a middle ground between that optimization that I have mentioned and the EPBS cases, ⁓ it's suggested to have like only 32 blocks ⁓ reorganize in this case, the depth of reorg should not be more than 32 blocks. But ⁓ the nuance here is that all other reorgs where they actually had ⁓ is from the conflicting ⁓ block tree branch. The reorg should happen regardless of that 32 block ⁓ limit. So that's kind of it. ⁓ I think it's important for EPDS. So please take a look, comment out and let's continue. ⁓ on GitHub or ask questions here if you have. Great. Any comments on that one? Otherwise, we will move to Hagoda. I actually have a very small ⁓ temperature check on the engine API, if we may. right, so ⁓ this is related to the save block tag. ⁓ We want to reuse it for the fast confirmations ⁓ for a fast confirmed 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 conpass 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 real log or will have to push this change to say to Amsterdam or some other hard work or coordination purposes. Dustin, I hear from you, but there are some concerns about like that somebody might use a block. So as justified to merging the two branches together. Yeah. The main reason is also that with the merge dev net we can be extra productive on it at interrupt. Yeah, I think those are very good points. So maybe we can just take the two data repricing EAPs and then just put them on Clumset on DefNet 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 DefNet with those. Is there benefit in including them? I would actually rather not include anything new, but rather keep the scope as contained as possible, not including any new ELPs and just focusing on merging the ⁓ features set from both of them. Yeah, maybe we can follow along async. think most clients have implementations for those already. It's for it's both of those are very minimal. ⁓ So might just be worth it. It's the two that Marius presented a CTE two weeks ago, where he recommended that we should add them to the next effort. But yeah, I don't have a strong opinion on it, but it could make sense. So I think my understanding was one of the benefits was it would allow us to also test larger block limits, right, Tony? Yeah, exactly. So I think right now... Yeah, it was one of the blockers. Yeah, I 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. ⁓ ⁓ of that issue, but then we ended up not including it. So that would be one benefit. Yeah, thanks a lot. This is a very good point actually. I also have a question regarding having a joint 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 do the dynamic cost in the next DevNet. Would it be the goal to do the current version of the specs for 8037 that we have now and merge it with the PBS? Or would we try to also tackle those ⁓ in the merged DevNet? And that's a great question. Maybe to the clients, maybe ⁓ say something about how much work it is to make it variable. This is one of the reasons why I would prefer Daemonet 4. just the preference I put in my like doing much DevNet, but there are a few like cache cases in 8037 is full of those. And we have like paintings that we moved for the next DevNet and we simplified 8037 for DevNet 3 because it's like a big change that everybody needs to do. But in this case, we look at EPBS DevNet until Monday. If it looks like they're going to be stable. ⁓ Then we can ⁓ work on Glamsterdam DevNet 0 and very rapidly I trade 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 BAL DevNet 4 is the logical conclusion there. Does that sound like a reasonable path forward? 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 ball devnet tree and not the... Yes. Okay, got it. ⁓ And 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. ⁓ To summarize, so if the EPBS devnet is stable by Monday, we'll move to a Glamster and devnet without the two ⁓ added gas repricings that were just proposed. Is that correct? I thought we would add them, but maybe I misunderstood. ⁓ To Glamsterdam 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. Okay, gotcha. Thank you. Great. Anything else on that? All right, we will move on to Haggotha. OK, 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 ⁓ 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. If you have a non-headliner proposal, feel free to open a PR against the GlamStram Meta or the Hegoda 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 ⁓ two weeks notice, maybe perhaps four weeks notice before closing that deadline. ⁓ Any questions there? Great. ⁓ Then we will move on to Antonio who wants to a two minute ⁓ plea on account functions. Right. Can you actually hear me? Yes. Hello everyone. Thanks for summarizing the status quo, Nix. I agree with what you said. I 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. From my perspective, there was a generic not agreement on the frame transaction proposal. But I think all the core devs, I won't talk in the name of everyone, agreed that an Nadeva kind of abstraction is a good topic for having a said liner in the gota. And of course, I come with my post-bantum transaction signature hat in mind. And from my perspective, this is really important as well to have it in the gota 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 understand that but from my view there was not a contention on not if I can abstraction but a contention if frame transaction was the right proposal and if we can see on the view of ⁓ putting a generic NatiVac and abstraction headliner, not a specific EAP, I think there is still time to find a proper EAP that with the modification that we had in mind on the non-perfect ⁓ framing transaction. And these are my two minutes. Basically, thanks a lot for giving me the chance. Antonia, you see any reason that any goal of native account abstraction as a focus in the port can't be accomplished as ⁓ being CFI'd as a non-headliner? Sure. mean, also CFI is good, but my understanding of headliner is to have a kind of north star for a single ⁓ for a single release. So I think that deserves the case of being a 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-quantum is not the only one, I mean, again, I come with the post-quantum 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... design for this specific nuance is a pity. I mean, again, not the critic here, I don't know, to the process, just like what I read on the last conversations, like that was really like a gap in the process that, yeah, we proposed the friend transactions that people didn't agree, but everyone actually agree on the nativacan abstraction somehow, a more generic topic. So it would be a misopportunity, opinion, that, again, like, might make sense. Okay, would anybody disagree with moving forward with basically keeping it CFI as a non-headliner right now and having the AA folks work together and if they can come up with something 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 Hedgoda's release dependent on that being done. Lukasz? 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. ⁓ ⁓ This is an alternative ⁓ to native account abstraction. In my opinion it's potentially better and simpler. I would really like everyone to ⁓ read it and give feedback. Okay, we'll give Ben some time ⁓ to talk about that first. ⁓ Well, I would like to thank for the play. think we need more statements like that. There is a lot of demand for this. ⁓ 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 de-prioritized, because in my opinion, removing it from the headliner, seems like a de-prioritization. It seems to be a risk that we're again in a situation where we're going to take another health measure. I really appreciate Ben for putting together an ERC, but the ERC defies the purpose of actually solving the problem natively. And this is something that should be done natively. I am 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 8.141. 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 8.141, but they were skeptical about its maturity given it was such a short window of time. Antonio? 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-quantum 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-quantum transaction 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. let's give it maybe Ben room. post-quantum are handled by different EAP, by Julia's Scheme Transactions EAP. So those can work and combine, and we can have both. This is not a problem. 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 more time to actually talk about it? Okay, Ben, you want to take the mic real quick? Yeah, sure. So I'm not very prepared. As I said, it was just this morning, the topic is coming up today. So my team said I should present. As I said, it's an ERC. Can you hear me? Yeah. ⁓ it's an ERC. It's, it's not an EIP because it, lives at the EVM level. ⁓ so it's, ⁓ wallet title deeds. account obstructions through, ⁓ NFTs. But the, idea is to traditionally your, have an EOA that is bonded to its custody. And the idea is to separate that link. So you instead. bond a NFT, which is 721, to an address. So they become one thing, and your EOA is the signing key. And because of that, you separate the identity, the address that you're doing everything with, that is in the ⁓ NFT, and you invert ⁓ how things work. If you want to do address rotation, would get a new EOA, and that could be a post quantum or ⁓ pass keys or whatever using a different transaction type. And then you would transfer the NFT to that account, and you've done key rotation, because now all the assets have moved from one account to another. you've got transferable ⁓ control there. And then you can do programmable smart control through it. you can, ⁓ sorry. You have a, so the title deed is bonded to an account. The NFTs token ID 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, 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 remove the NFT and you can put it in your cold wallet and it's taken everything inside that account and transferred it over. Or multi-sig or how you want to, or post-quantum signature. And with that goes your Aave. ⁓ E and S name, swap L to 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, can also therefore put the NFTs inside each other. They can contain each other and then you can create an EVM and force organizational hierarchy either you know, because you want to do some, 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 branch of your account that you're doing. ⁓ You have your solid assets in and another one that you're ⁓ using unknown DApps or whatever. And you don't want any crossover of those assets, but you also don't want to manage multiple EOAs to do that. can do it through this structure. And then you can also do infrastructure-free gas sponsorship. So 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. You don't need all the paymasters, the bundlers, anything like that. It could be your company might give you an account, delegate you to it, ⁓ and then you can... And they sponsor all your transactions, for instance. Or you're using a DEX, you know, Cowswap, 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 none for the sponsorship path because any UI can relay. It's a standard EVM protocol transaction versus off-chain when it's trapped. you get the, so it works with ⁓ fossil and the SP, which is the reduced state for validators, where you only keep the account try rather than necessarily all the state. run through. As I said, it works through both ⁓ fossil censorship resistance, these transactions, ⁓ and VSOP. Sorry, I'm just going to go through. ⁓ So essentially, you're turning your wallet. It's no longer sort of an isolated island. become ⁓ transferable financial primitives. ⁓ You can create a hierarchy of them. You can do gas sponsorship, key rotation. It works with fossil. works with ⁓ PLP. You can do privacy withdrawal support. ⁓ Yeah, there's a huge amount more to it, like digital inheritance and AI accounts and all sorts of things. yeah, I'll just present. Thank you for listening. Please check out the ERC. Thank you. Toma, do you have your hand raised? Do you want to take the mic? 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 was a potential contester against this, which was a headliner yesterday. OK, so to sort of clarify, Stream 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 the 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 sort of a breakout, host a breakout? I would like to champion the breakout. Okay, great. Can you get in protocol support will get in touch with you if you leave in the chat away the best way to get in touch with you. Great. Parthar Sarathy. 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 a smart account Wallet 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 abstraction, I'm not really sure ⁓ if ⁓ that would serve the purpose that Ethereum wishes. ⁓ 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. Great, thanks, Julio. Okay. Yeah. Can you hear me? Yep. Okay. So, ⁓ it just, I just wanted to say that it's, it seems that, ⁓ so yes, okay. We see if I frames, but I mean, it's, I don't know how to put this, but I think it's a bit, ⁓ I think, I think I just wanted to ask, okay, whatever. I, I'm just going to ask it. Um, I'm going to just bring it up again. Who here would actually prefer doing scheme transactions that the frame transactions out of the client. Because it seems to me like there is only one client that really wants to do frames. And I don't think that it's realistically will get into the hard fork at this rate, to be honest. Antonio Right again, not the developer here. You guys probably know me I already expressed this to Julian private ⁓ The things like I will it doesn't matter if it's gonna be frame or your solution. Julio is like did let's figure this out offline and in the kind of extraction 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 five years ⁓ maturing the IP 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 like a competitors. This is not to say, not a developer here, but yeah. No, I agree. I agree. I'm sorry. I guess maybe this the... if I passed around like that. ⁓ What I meant is that the problems with frames, and I'll say it again, is as all to do with the very five frames part of the proposal. You can figure that 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 complimentary. Like I don't want, it's not like a competition, of course. Antonio. Oh, sorry, I need to lower my head. Sorry. Okay, Nico. Yep. Can you hear me? Yeah. 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-compiled 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 are 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. Yeah. I just wanted to say one quick thing. I added a PR that brings some of the ideas from the scheme 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 of 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 five years. And if we can't even, you know, solve this one, uh, like I worry about our ability to continue doing barred and complicated tasks on the execution layer. You're gone. I like to give small input on all of this. think design on AI 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 if you think about the minimal thing that we need. The 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 we're not really comparing apples to apples in most of these situations. Scheme transactions provide only a very small subset of functionality that the frame transaction provides. And if we're going to compare them, let's compare them and find a good solution. But let's compare two things that are achieving the same functionality. The thing that basically I want to iterate on is basically if we 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 and 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 heavy access to every intersection field is needed. We can like do something like simple with the hash. We can do simpler things, but the core ideas we need to clarify those. What are the... most basic mechanism that we need to explore these kind of things. That's why I'm urging everybody to think in that flow, in that direction. Well, it's the best way to think in that direction because on my side, I feel like we have described a lot of these and we've tried to 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, we haven't. We don'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? I don't know, it's not easy. Yeah, I mean, like we also have people from wallet teams here and the community here who are saying very explicitly that we need native account abstraction. And that's 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 five 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 in cumulative of all of these different things where gray values observed. Okay. ⁓ I think I would encourage people to ⁓ to to Dragan's point, decide what their minimum requirements for this thing are. And also, please look at the existing proposals and bring your qualms, your problems with the current ones so that those authors can be aware of what people's issues with them are to the AA breakout that gets scheduled. James. ⁓ 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. ⁓ should focus on what is important, the use cases like Matt was talking about, and what is important, the post-plantom migration, which we need to do for all users within the next three to five years. ⁓ I don't think that AA should be a blocker for PQ. ⁓ And coupling those in the design space seems irresponsible. HIDDLE Okay, Drew, can't hear you. ⁓ Julio? 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 live check. Like how many client teams would rather maybe do frames through schemes, through schemes instead of going directly for frame for the gota. It's just kind of a temperature check. I don't want to make like a dissuade or anything. that people aren't familiar enough or don't want to speak for their team through whole teams. Do we have any more? a 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 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? 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 R1 and ability to import it, export it. 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 Discord on the History Expired channel that there seems to be different ideas about it. ⁓ Two options specifically came up. ⁓ One is basically setting the next target ⁓ to be until Pectra. So clients should be fine with having pre-Pectra 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 bring up this question that... ⁓ 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 create. It's not a default. So default is to keep all of history. And we recently also added a way to prune until Pectra. I want to know basically, in the most aggressive version, how far can users prune their clients? So if you guys can just chime in here. Yeah, to Barnabas. I would argue that Finalized is... Right, okay. So, Eragon, you can be as aggressive as you want. Barnabas suggesting Finalized Epoch. I can tell you that one of the requirements that we have in Geth is that we need at least the last 90,000 blogs to be present. This is for social recovery, 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. Yeah, so I think this pruning target is mostly just if I may have political problem, it's just something we agree on. So if you agree that, for example, we decided 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 F wants, I don't know, 9,000 blocks, they can keep on 9,000 blocks. You can keep more than what you're required. You just cannot keep less than what you're required. So all you need to define is a number that is small enough, essentially, 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 use that and then science can just figure it out by themselves. Yeah, agreed. Like nobody is required to prune until that point. It's just we want to make sure I think from my perspective, we got to 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. So if I recall, EAP444 was staying one year. which was kind of agreed upon. Yeah, it was one year. I think one year is a very generous amount. absolute minimum is the weak subjectivity checkpoint. Which I don't know what it is given our validator set size. 14 days. 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, we want to have some buffer on that or? It's 14, that's comfortable. think we should do at least the blob. The 18 day blob, which is 8,000 epochs, I think. So that was 18 days. Yeah, the blob expiry window is, I think, 8000 epochs, which is 18 or 19 days, something like that. Yeah, I also hear the fact that like one year might be too long. I can also provide some data on this. I can tell you that the difference from pruning... So Pecta was almost one year ago and... The minimum for me is 100k. And the difference between that is around 70 gigabytes of history. the gain are quite small, I would say, compared to once you prune everything before that. So this is the kind of area that we're talking about. Just to throw out a number like one month. I mean, don't know if we can make a decision here, but I do want to have some concrete ideas. Why don't we just suppose we just ask the consensus layer what the week subjectivity period is, what the 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 going Yeah, I think we need the fixed period of time plus any un-finalized 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. Yeah. That's why you, think you have to ask the CL, right? I think it doesn't update that frequently. For example, with Blocklym AccessList, we also needed it because you keep paths for that period and there it's 3,530, a little bit more epochs. That's think 18 days or 20 days, something like that. But is the number of validators in the set not a portion of that function? Like whether or not it may change a lot? I think it doesn't change a lot. It's definitely part of the function, but it's not like that it updates frequently. Gotcha. I think Matt raises a good point, like what if we stop financing for a week, two weeks? Yeah, I think any numbers that we're coming up with, 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 them, that we need to be keeping those, ⁓ on finalized blocks as well as the, ⁓ finite period that we agreed on. We send a lot against one month, of course, with the caveat of finalized blocks that we have to store them. ⁓ A small comment, we have 18 days for blobs because if we stop finalizing, then it will take 18 days for inactivity leak 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. OK, so that's different than the week subject to day period. It's not actually a big subjectivity period, it's something more. It just happens that they're both similar numbers. Yeah. Okay. I have a question. What's our goal here? Do we really want to get to the minimal gigabyte level on disk footprint or are we fine with a bit of overhead? again, we... I would vote for some kind of defaults, a standard that's being somewhat, at least a bit conservative, so that one year on 4.4, it's quite much conservative, but maybe, you know, ⁓ something like half a year or three or a quarter should be like the defaults, in my opinion. One possible value in this regard actually that's sort of in between is to match the CL's 32,000 epoch period, which is about five months. People want a little more conservative. The interesting thing there is if you do that, there's a lot of overlap between what the databases hold. So the CLs and ELs can request data from each other actually in both directions depending on what each holds. And I know some allied, some data, some CLs and ELs both. In any case, if those periods match exactly, that opens up lot of opportunities there. And just wanted to ⁓ make a quick note to what Lukas 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. even if the user specifies the window shorter than, let's say, five months that we are talking about now, then the client should reject it. Sina, is there anywhere that people can follow up on this offline or follow what number is being discussed? Yes, please. There's a history expiry channel on Discord. Anything more on that? Great. Chase, do you want to talk about ⁓ your request to have devs comment on the new RPC method? Let's chase here. 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 SSE into the Engine API. Yeah, this is a topic that has been brought up multiple times. ⁓ So the core change would be to optionally bring SSZ over REST and no longer just JSON. This would basically enable performance improvement between the ER and CL. It would allow us to further blob scaling. 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 SSZ one day at a time. And we could do something like capabilities exchange where the CL would basically be able to use the SSZ instead of the JSON. I can post the execution API. Yeah, here and I'm open for feedback. ⁓ Great. That was the last item on the agenda, so unless anybody has anything else, we can close up for today. Thank you, everyone.