Ansgar Dietrichs:Perfect. Hello, Juan, welcome to… All Core Devs, 233. We're really getting quite high into these numbers.
Transcript
Ansgar Dietrichs:We have a couple of things today on the agenda, first about Glamsterdam, and then, about our… hopefully… well, not hopefully, about wrapping up the Hego to Headliner discussion. So, starting with Glamsterdam first,
Ansgar Dietrichs:first general call for DevNet updates? Do we have… Any updates about the… Current ongoing debit efforts?
Stefan Starflinger:Yeah, sure, I can give a quick update.
Stefan Starflinger:Just a quick update on DevNet 2, it's going pretty well. We had one issue with Erigon, where they were creating too many transactions, too many peer-to-peer connections.
Stefan Starflinger:But otherwise, it's been going pretty well. And definite 3 efforts right now. I'm still doing a lot of testing. Most clients are very far along with the implementation, but there are still some rough edges that I'm ironing out and doing a lot of kurtosis testing at the moment.
Stefan Starflinger:And it would be good if clients could also help with that effort. I'm still finding a lot of issues just with,
Stefan Starflinger:same clients in the network, for PolyDevNet 3.
Stefan Starflinger:And then I'll do, mixed networks, and once that runs decently stable, I will launch, DevNet 3, I hope.
Stefan Starflinger:Beginning next week.
Barnabas:Can I also give an update on ePBS.net?
Barnabas:it's not looking good, so withdrawals have, broken the DevNet, and, we have decided to basically, give it a few days and launch with DevNet 1, with the new PTSC changes that, we have agreed on on ACDE.
Barnabas:Initially, I think Prysm will be the first one that will be ready, and then I'm planning to launch a network with only Prysm, and as the clients are, finishing their implementation, then I can start onboarding them.
Ansgar Dietrichs:Sounds good, and is there anything from the EL side that, people should pay attention to, specifically?
Barnabas:For ePBS, no. Optionally, if you are bored, you can create an ePBS, the Net Zero branch for us, and we could onboard your EL client.
Barnabas:And if you need some, explanation what you need to do to be onboarded, just reach out.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Any other DevNet-related updates?
Ansgar Dietrichs:Chris, looks like you're unmuted, I'm not sure if that's on purpose or just accidental.
Ansgar Dietrichs:Okay, then we can move on to the, next agenda item, which is, I think Maurice and Bhuta wanted to give an update on the…
Ansgar Dietrichs:benchmarking progress so far. Are you two on the call? And…
Ansgar Dietrichs:You wanna go out with that?
Marius van der Wijden:I'm here. Let me share my screen.
Marius van der Wijden:I hope you guys can see my screen now.
Marius van der Wijden:We can… Oh, yes.
Marius van der Wijden:I want to talk to you about, Some repricing updates,
Marius van der Wijden:we have this new tool called Benchmark Core, which is really, really cool. We have created a lot of benchmarks in the past.
Marius van der Wijden:And, we have this tool to run them.
Marius van der Wijden:On different client configurations, on, on different things. And, we can see…
Marius van der Wijden:We can put in a threshold that we want to be able to run, and we can see which tests are run… are running below this threshold, and which tests are running above this threshold.
Marius van der Wijden:If you remember from my last presentation on, I think 2 or 3 SEDs.
Marius van der Wijden:Our goal… the plan, or our plan right now is to
Marius van der Wijden:Make sure that everything runs at…
Marius van der Wijden:60 megabits per second, which would be really, really cool. So by default, this tool is, is, put into, or, yeah, it, it, it, puts the threshold at 60 megabits per second.
Marius van der Wijden:As you can see on this run, there are only 4 tests that would be less than 60 megabits per second. Most of them are
Marius van der Wijden:Oh, hi.
Marius van der Wijden:The benchmark core is available to…
Marius van der Wijden:To people who ask, so if you want to get access to it.
Marius van der Wijden:You can, if you are on an EL client team and want to get access to it, want to see your numbers, you can either ask me or…
Marius van der Wijden:Rafael, to add you to the… to it.
Marius van der Wijden:We have, several, benchmarking suites. We have the compute tests, 47904.
Marius van der Wijden:Those are around 5,000 tests.
Marius van der Wijden:And we have the stateful tests,
Marius van der Wijden:There are around 3,000 tests, and they,
Marius van der Wijden:Yeah, cover all of the opcodes that interact with
Marius van der Wijden:tests. Right now, we are reworking these tests on top of block access lists. We have some runs with block access lists already, and we have also… there's a mode in Benchmarkall where you can do the diff between two runs to see if they improved or…
Marius van der Wijden:Yep, or not improved. And, what we can see is…
Marius van der Wijden:Roughly 3X improvement, through, through DALS, on most compute tests.
Marius van der Wijden:On the floor…
Marius van der Wijden:core CPU, so this is, yeah, roughly in line with what we've expected the gains from Balls to be.
Marius van der Wijden:Now to the EIPs, EIP 8037, the state creation.
Marius van der Wijden:Change is included in the Definite 3 spec. Our clients have implemented it, and we have a pretty comprehensive test suit, from execution spec tests. One problem that, that is… that came up is that the legacy tests
Marius van der Wijden:Still need to be updated, they are being updated right now, but that's a bigger refactor, because…
Marius van der Wijden:Some of them are in a format where it's not easy to update them, so they need to be ported into the Python format or something similar, and they need to be updated so that we can
Marius van der Wijden:Programmatically change, change them depending on The, the block gas limit.
Marius van der Wijden:We have, EIP7976, the coal data flow increase, which increases the coal data gas flow to 6464.
Marius van der Wijden:This allows us to raise the max gas per block from roughly 105 million gas to around 670 million gas, which would be really, really nice.
Marius van der Wijden:We made some analysis, and roughly only 1.5% of transactions will be affected by this repricing, and there are no backward compatibility issues, because this is simply a transaction gas limit increase.
Marius van der Wijden:They are already included in the execution spec tests.
Marius van der Wijden:So, they can be very safely scheduled for the next definite.
Marius van der Wijden:Eap7981 increased the access, list gas cost, yeah.
Marius van der Wijden:We use the access list size in the 7976 calculation, so what I just talked…
Marius van der Wijden:bought previously, otherwise, these access lists could circumvent the floor pricing, and this would reduce the worst-case block size by 21%, with no impact on users. And we also feel that this can be safely scheduled for the next DevNet.
Marius van der Wijden:Change is very, very small,
Marius van der Wijden:But yeah, it will, it will get rid of the… this edge case where people just put a lot of call data or a lot of access lists.
Marius van der Wijden:And… and bloat the block that way, which, yeah, helps us to scale.
Marius van der Wijden:Then we have the 7904 compute repricings.
Marius van der Wijden:These are very preliminary numbers, but as I said in the beginning, our goal is still to, to, arrive at, 60 megas,
Marius van der Wijden:baseline for all of the compute opcodes, and hopefully all of the state opcodes as well. And these are roughly the opcodes that we are looking at, regarding the repricings.
Marius van der Wijden:Some of them…
Marius van der Wijden:can be, might be… might be able… like, we might be able to just optimize it in certain implementations, like, for example, the catch-up,
Marius van der Wijden:opcode is… in the second worst implementation, it's at 70 MHz, so it would pass, but in the BSU implementation, it's at 40. But there are certain things that are…
Marius van der Wijden:Yeah, as you can see here, the point evaluation precompiled is basically at the same level in all clients, so there's not much we can…
Marius van der Wijden:We can do to, Other than repricing.
Marius van der Wijden:So, yeah, we are in contact with, with clients in order to see if they can improve
Marius van der Wijden:these up codes.
Marius van der Wijden:Yes, EIP8038,
Marius van der Wijden:The state access repricing. Unfortunately, we have, less data on state access than we have on, on compute repricings, because compute repricings are very easy to.
Marius van der Wijden:easy to do. State accessory pricings are a bit harder, but those are roughly the operations that we would
Marius van der Wijden:Reprise, and, yeah.
Marius van der Wijden:So, the call, balance, self-destruct X opcodes. And why we want to reprice them? Basically, right now, you can…
Marius van der Wijden:I think it's… at 100 million guess, you can load something like 8GB of data from disk or something with, with, some of these opcodes, and that's a big problem for
Marius van der Wijden:for us, for increasing the gas limit, but it's also a big problem for CKEVMs. So, yeah, we would like to reprice them.
Marius van der Wijden:Yes, and then the gas repricing outreach, Bhutta has been working on that, so I would like to invite him to
Marius van der Wijden:To give his slides.
Butta:Yes, can you hear me?
Marius van der Wijden:Yes.
Butta:Alright, so over the last two months, I've been reaching out to various stakeholders. I will post some links in the chat.
Butta:So the first… the second one is the gas repricing.com website, where you can find various information. This is also the website that was sent to our stakeholders.
Butta:And if you're curious what the questions were during the survey, you can also go through the survey, which is linked at the top on the website.
Butta:But as of now, 21 people have been surveyed, out of which were 16 different teams, DeFi teams, wallets, Layer 2s, and so on.
Butta:Yeah, if you go to the next slide, some others…
Butta:I will keep it short, what the outcome was. We have posted a summary, an anonymized summary on Twitter of the outcome, if you're curious about the details, but…
Butta:Yeah, quick summary is that most of the entities were concerned about the complexity, not about the increase itself.
Butta:And a few entities asked for, toolings to be ready so they can test it out. Something also may be relevant for the DevOps team, the tool where
Butta:people are able to simulate transactions was quite helpful to see whether that destroys something.
Butta:Besides that, so 21 people… 21 entities were served, but we also reached out to, tool links and other entities that were not directly, impacted, so they can prepare accordingly.
Butta:And so far, no major red flags. So, yeah, that's a quick summary from my side.
Marius van der Wijden:Thank you, Bhuta. And, yeah, I didn't really finish the slide, so there's a bullet point too much, but,
Marius van der Wijden:For security reviews, we have created a framework to trace all transactions, in order to understand how these repricings would impact the transactions that are currently on the network.
Marius van der Wijden:Around 6.8 million transactions will be affected by 7904.
Marius van der Wijden:We are still, working on the analysis on this. Most of them are very likely,
Marius van der Wijden:arbitrage boards, and, and, things like ephemeral contracts that can be changed very, very easily.
Marius van der Wijden:In order to, in order to, yeah, to, to, to use the new pricing. There were very few contracts,
Marius van der Wijden:yeah, none that we have seen where we saw, like, an immutable contract that breaks because of the repricings that cannot be updated, yet. So, yeah, we are still working on that.
Marius van der Wijden:Once the numbers are final, we will rerun this tracing analysis.
Marius van der Wijden:And we will, invite external security reviews, from, from, from, companies, in order to get a, a better overview.
Marius van der Wijden:Of the impact of these changes, and we will also provide some grants for that.
Marius van der Wijden:Yes, and I want to quickly show you guys Benchmark Core.
Marius van der Wijden:Because it's a very… it's just a very cool tool.
Marius van der Wijden:you have to sign in with your GitHub, so if you're a core dev, you want to have access to it, again, you can either ask me or Raphael, and, you can, like, we have, we have different suits, and you can see some of them are on top of Mainnet, some of them are on top of BloatNet.
Marius van der Wijden:And you can see, how many tests are in each suit, and these are the compute suits, these are the stateful suits.
Marius van der Wijden:And if you look here, and you can look into one of the test suits.
Marius van der Wijden:You can see there are some, tests that are…
Marius van der Wijden:Red, some tests that are yellow, and you can see, these tests
Marius van der Wijden:for opcodes that should be… for the Geth implementation should be reprised.
Marius van der Wijden:And you can see which of those, this is, for example, the point evaluation precompile, so KCG.
Marius van der Wijden:And, what you can also do is if you…
Marius van der Wijden:click on one of the tests, you can see, okay, this test ran at 40MP per second, all of the time was spent in execution.
Marius van der Wijden:You can see the cache performance.
Marius van der Wijden:We only had, like.
Marius van der Wijden:Very few, storage reads, like 8 storage reads, or 10 storage reads in total, but all of them were misses.
Marius van der Wijden:And you can see the breakdown of the storage operations.
Marius van der Wijden:And you can also see which requests were sent, and what the responses were.
Marius van der Wijden:And
Marius van der Wijden:What's also interesting is, up here you have, a log of the client where you can see the whole, the whole version, the whole, the whole run, and you can see the configuration of the, of, of,
Marius van der Wijden:of, of this run, so we, used 8 cores, at 3.6GHz.
Marius van der Wijden:60gb of memory, and… but we limited the resources to 4 CPUs and 32GB of memory, so this is,
Marius van der Wijden:in line with, with this EIP we have about the…
Marius van der Wijden:Node configuration, and yeah, all of the stuff that you… that you want to…
Marius van der Wijden:to modify, maybe, for, for UCommerce. Yes, all of this has been built by, by Raphael and the PandaOps, so shout out to them.
Marius van der Wijden:Yep, I think that's it.
Ansgar Dietrichs:Nice, thank you very much. Do we have questions, comments?
Ansgar Dietrichs:Discussion about any of the content here presented?
Ansgar Dietrichs:Otherwise, yeah, you know, you can also take to the chat. Thank you very much.
Ansgar Dietrichs:And then we can move on to the next, agenda item.
Ansgar Dietrichs:Which is, an update on EIP 8070 progress by BOSUL.
Ansgar Dietrichs:If you're on the call.
Bosul Mun:Bye.
Bosul Mun:I'm Basel from CAP.
Bosul Mun:I'd… I'd like to quickly talk about EIP8070, Sparse Poppool.
Bosul Mun:So, I posted a related link
Bosul Mun:to the issue, I will stop.
Bosul Mun:So, in summary, we, got suffered this…
Bosul Mun:EIP's possible pool, and we would like to see this EIP get
Bosul Mun:gets SFI'd in the future, and by that, we mean that,
Bosul Mun:we'd like this to go through the similar process as other EIPs. Like, it's 70, like, getting into the DevNet.
Bosul Mun:So, we could also discuss this when we scope the next DevNet, but…
Bosul Mun:from our perspective, this is a relatively huge change, especially if you're working on SNAP2, so we first wanted to raise this early and get feedback from other colleagues.
Bosul Mun:So… We implemented a nature prototype, and also documented the complexity we've seen from
Bosul Mun:From guest side, on some security considerations we've identified while prototyping this.
Bosul Mun:So we'd be interested to hear from other client teams, how… what other client teams think about this, and also would like to answer, some questions and help others to understand this AIP better.
Bosul Mun:So, feel free to share thoughts or questions here, or on the document, or we can also set up a call to discuss each other's implementations and shape how to implement this.
Ansgar Dietrichs:Thank you. Yeah, and just to remind people, right, so basically, EIP8070, we… it's one of those,
Ansgar Dietrichs:non-protocol change EIPs, but we did decide to CFI it, so it's on the meta EIP for Glamstadam.
Ansgar Dietrichs:And so, indeed, it's a really good prompt to ask, basically, how do we tie this into the general fork rollout? So the proposal here is basically to say that we should
Ansgar Dietrichs:basically treat it in a similar way to the normal earpiece, and also start introducing it to DevNets, and, basically have it on a track towards SFI.
Ansgar Dietrichs:I'm not sure if this is something that people want to discuss now, if there's comments on this. Otherwise, yes, as Brussel was saying, this question can also
Ansgar Dietrichs:be tackled once it's relevant on the DevNet planning side.
Ansgar Dietrichs:Maybe just as a quick question, do we have, other clients, clients other than Geth, that already looked into this, have been… have been…
Ansgar Dietrichs:Kind of.
Ansgar Dietrichs:internally, Boom.
Ansgar Dietrichs:Working on this?
Ansgar Dietrichs:Yeah, if that's not the case, then I do think this is probably a good prompt for you all to maybe,
Ansgar Dietrichs:at next convenience, have a look, and so, so that, yeah, at the next DevNet scoping opportunity.
Ansgar Dietrichs:we can discuss this, I think.
Ansgar Dietrichs:Perfect. Then thank you very much, Postal.
Ansgar Dietrichs:And then, I think that concludes the Glam Slam topics. Is there anything else, any other Glam Slam-related topic that people want to discuss before we move on to each the headliner?
Ansgar Dietrichs:Okay, then let's go. Hey, go to headliner selection. So, just as a reminder, basically, we wanted to make that decision last week, but ended up, because it was very close to…
Ansgar Dietrichs:the edge of this decision, that we decided to have one more two-week cycle for people to form a final opinion. Basically, the remaining decision to be made here is, on the EL side, do we want to have a separate headliner? We already have
Ansgar Dietrichs:fossil selected as a cross-layer, but mostly CL-heavy headliner, so the question is, on the EL, will we have, frame transactions, which is the last remaining, headliner candidate?
Ansgar Dietrichs:Or will we go into the fog without a headliner? Before we go into this specific discussion, we have a few
Ansgar Dietrichs:bullet points to start there, but I just want to remind us that, in principle, if we choose to,
Ansgar Dietrichs:not, accept frame transactions as headliner. There is then still also the question of whether we would want to reject
Ansgar Dietrichs:it outright, or we could still decide to say we will consider in the future whether to potentially still include this ERP as a non-headliner, and or any other kind of restriction ERPs. So just keep that
Ansgar Dietrichs:in the back of your head for this discussion. To start, we had another breakout about frame transactions,
Ansgar Dietrichs:And the headliner process yesterday, do we have anyone on the call who was there yesterday and could give a summary?
lightclient:I don't know if I can give a full summary. There's a lot of, like, little topics that were discussed. I'm sure we can bring some of those up, whoever wants to…
lightclient:mention, but I can quickly kind of update what's happened in the past two weeks. I've sort of said this on all Cardo's testing earlier this week, so I'll be pretty short, but…
lightclient:We spent time and formalized our thinking around the frame transaction mempool. That seemed like a pretty contentious point in the last call, and we wrote a document, which I just pasted in chat, that outlined three different strategies for dealing with the…
lightclient:Frame transaction, then pull?
lightclient:And we also updated the EAP to support Strategy 2, which we felt was a good balance between being relatively straightforward and safe, but also giving a very wide range of capabilities, that we're trying to deliver with the frame transaction.
lightclient:So, we presented this also yesterday, and I think that there was still some… Questions and concerns about
lightclient:Some of the exact details and machinery.
lightclient:I know that Julio and Ben also have their own proposal now for something that's somewhat related to frame transaction.
lightclient:So if there's not any specific questions on this document, maybe they could talk a bit about what their idea is?
Felix (Geth):Maybe just as a quick update from my side, we have also, after a bunch of back and forth internally, added native batching into the proposal, so it, works very naturally with the frames, and basically, just to give a
Felix (Geth):comment on what this means. So, the proposal now includes a facility that allows users to, Mark?
Felix (Geth):adjacent frames as reverting together. And, using this facility, it is possible to, for example, send a transaction that first creates an ERC20,
Felix (Geth):approval, and then uses this approval in the next frame. But if, for some reason, the intended effect of the approval, like how the ERC20, if that fails, how the ERC20 is spent, if that fails, then the approval will also be reverted alongside this action.
Felix (Geth):And we believe this is a huge step up in the usability. People have been asking a lot about these, batching…
Felix (Geth):Facilities, and there were also other proposals in the past to introduce this, and we are happy that it composes very naturally with the frame transaction, with just a single bet, which can optionally be set on the frame to enable this.
Felix (Geth):So, I think this… for me personally, I'm very excited that we finally found an elegant solution for this problem, and just wanted to give a shout-out to this. Derek was very instrumental in
Felix (Geth):Figuring out the detail for this.
Derek Chiang:Oh, thanks, you know, I think maybe another update I want to give…
Derek Chiang:About the breakout from my perspective was that, I think we are also now working towards addressing another…
Derek Chiang:primary concern that has been expressed by, the high-performance L2s, such as space, as well as, like, some other high-performance EVM chains, which is that,
Derek Chiang:the cost of validating transactions, with firms is now obviously going from constant, right? You know, going from just a signature… going from just a signature check
Derek Chiang:to running EVM code, right? So we are actually, trying to,
Derek Chiang:Essentially have, like, first-class support for pre-compiliers.
Derek Chiang:in the firm's spec, so that, essentially a account will be able to, delegate its validation to pre-compiliers, you know, which have bonded validation cost. The exact mechanism is still to be worked out, and we are, in fact, working closely with
Derek Chiang:you know, the people who have expressed their concerns, such as, you know, Chris from BASE, as well as, like, Daniel from Monas, to, figure out the mechanism. But I actually, like,
Derek Chiang:actually, like, you know, if you look at, like, the, support for EOH in France, right, like, through the default codes.
Derek Chiang:the pre-compires has already been supported in the default code, you know, so at least for EOS, we already have this, great support for using pre-compires directly for validation, you know, which gives it, both guaranteed security as well as, bonded validation cost, right? You know, so, but…
Derek Chiang:As far as, you know, using pre-compires for valid… as far as using pre-compires for validation for smart contract accounts, that specific mechanism still being worked out, you know, but it is the direction that we are heading towards, you know, because we want to make sure that firms
Derek Chiang:will work well not just for L1s, but also for other high-performance EVM chains.
Chris - Base:I can just add, like, a small bit of input, on that, and…
Chris - Base:for whatever it's worth, like, what… how Bass is thinking right now, like.
Chris - Base:give… where 8141 is right now, like, I would say, you know, we're not supportive, we are working
Chris - Base:It seems like it's progressing in the direction… a good direction that we
Chris - Base:Would be more supportive of, but in its current form, there's… we still have issues with it.
Chris - Base:And yeah, just for, like, you know, more transparency, given, you know, our performance goals, like, competition, timelines, etc.
Chris - Base:As it is right now, we do plan on shipping an alternative earlier.
Chris - Base:This doesn't, like, exclude us from, you know, supporting 8141 in the future, but I just wanted to kind of
Chris - Base:Put this out there for, you know, transparency in how we're thinking right now.
Ansgar Dietrichs:Sounds good, that's helpful context.
Ansgar Dietrichs:Yeah, then let's… before we go to the open discussion part, about the headliner, two more short agenda points were about friend transactions. One was…
Ansgar Dietrichs:from Holger, from the Ethereum.js side about a frame transaction implementation. I'm not sure if, Holger, if you're on the call and wanted to briefly give an update here on the call, or if it was just
Ansgar Dietrichs:For people to check out async.
Ansgar Dietrichs:Otherwise, I'll just put the… Link in chat.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:And people can check that out. And then, as Matt already mentioned, Julio wanted to briefly talk about
Ansgar Dietrichs:alternatives to frame transaction, Julio?
Giulio:Okay, so… right, so,
Giulio:So, right, so I… I made this…
Giulio:other proposal, which is not really a… I don't think it should be seen as a compatible for any transactions, by the way, but…
Giulio:I think it's kind of complementary to some things that people are happy with frame transactions, which is mostly the current state of, from what I understand, are verified frames. So, I… I think I want to clear up some things first. Before I get into the AP, I did some stuff on post-quantum. I'd like to keep them off the conversation for now, because there is a bit of contentions there, so I just like to keep them off, but basically.
Giulio:But, this new proposal that me and Ben did, the scheme transaction is, is that… is basically, a more minimal version of what, REF
Giulio:suggested, last… in, two weeks ago. So, it basically have, have a concept of extensions, which is similar to frames, which, which, you know, it's kept… it's kept for now just abstract, so you can extend, like, the normal, you know, the normal transaction with the more stuff, more fields.
Giulio:In the future, and… and yeah, so basically… and… and the difference is that, instead of having very 5 frames, you have,
Giulio:enshrined signature scheme, essentially, right? So, you essentially remove the bad part… I mean, the bad part from a mempool perspective, and you replace it with something enshrined, which is probably safer to implement.
Giulio:Another thing that actually it allows is that, since it seems, at least to me, that, for example, as Bayes already said, that,
Giulio:in the current state, frame transactions are not finished. You can probably build frame… verify frames on top of scheme transactions as an extension. Like, you can basically do it async. You don't need to, like, speedrun it for an outliner.
Giulio:So…
Giulio:So yeah, basically, that's the whole reason why I proposed this. Like, it's mostly because, it's mostly because it sounds to me like a safer path
Giulio:towards what… towards frame transactions, if anything, and it's not really a replacement. And you can anyways, async, just do frame transactions as,
Giulio:As they intended, just maybe… just with more calm and less stress on the deadline, and without dealing with the details immediately.
Giulio:Basically. Right. And also, yeah, there is also a note on post-quantum, too, that is super easy to do post-quantum with frame transactions. There is, in the EIP, an example of a post-quantum signature scheme. It's not post-quantum, but basically, it's ephemera ACDSA, just read it, it's like…
Giulio:Unless… it basically makes it so, in order to
Giulio:to crack your public key, you would need to basically crack it in 12 seconds instead of just having it exposed forever, because it rotates the public keys all the time. It's basically what it does from Miracle Tree. I don't want to go into details, because it would take too much time, but just go read the AP if you're interested. And yeah, so this just… it also makes it super easy. I mean, we could probably ship something post-quantum, too, in
Giulio:Into this pretty easily, in my opinion.
Giulio:That's basically also the reason. I also think, personally, that, and this is just my personal opinion, is that… I guess my main problem with 5 frames is that
Giulio:I don't really… I think at the end of the day, you will still need to have pre-compass for new authentication methods, so to me, it just sounds like kind of fake abstraction, basically, but that's pretty much only my opinion on that. So yeah, this is basically the proposal. It's just a frame… if anything, it should be seen as a framework
Giulio:For account abstraction, you can build on top of it.
Giulio:basically frame transactions, except verify frames, and then you can do verify frames async in a more targeted and controlled way, basically.
Ansgar Dietrichs:N?
Ben Adams:Yeah, I'd sort of summarize it differently. Friend transactions is very…
Ben Adams:does have a strong AA focus, and I'd say this is more…
Ben Adams:changing the four EOAs, so it's changing the transaction
Ben Adams:So that the… the signature is independent from the transaction blob.
Ben Adams:And you can change the scheme used to sign the transaction, so you could put a
Ben Adams:you could use the, R1 curve.
Ben Adams:Or the pay curve that… We already have us precompiles, or you could bring in, post quantum.
Ben Adams:And that would… that would just work with the transaction, and then the transac… and it makes the transaction blob itself
Ben Adams:composable, rather than always adding new fields to it. So you… you say, and…
Ben Adams:I have blobs in this transaction, so these are the extensions. So you'd say, oh, I have blobs in this transaction, I have 7702,
Ben Adams:And it would upgrade 7702 to use Also, the, multiple schemes.
Ben Adams:And then, so from that, you could add frames as an extension. You could say, I have frames in this transaction.
Ansgar Dietrichs:Julian?
Giulio:I also wanted to say that, if… with this, another good side effect is that you will never probably need a new transaction type, and all you need to find is just, basically.
Giulio:an extension for new… for new use cases in the future. So it's also… going forward, it's also probably less protocol complexity as a whole.
Ansgar Dietrichs:And dental?
Danno Ferrin:So if the goal is to, separate the signature body from the transaction, there's two other EIPs with lower numbers that were submitted first.
Danno Ferrin:One of them, CADX separates it in RLP, and then there's another one that Search Budgensen has been working on longer with the PRF team that moves it, over to SSZ encoding. And if we're going to be moving the transaction out, we need to do it in a way
Danno Ferrin:Such that stripping out the signature and replacing it with a ZK format, or a reference, is going to be incredibly easy regardless of the content of the body. SSD does this with partial proofs very elegantly, and keeps all the hashes.
Danno Ferrin:And the CADX proposal that I have, separates it out into separate RLP forks, and the signature form of the transactions are literally in the transactions, so there's no transaction rewriting.
Danno Ferrin:So, if the goal is just to separate it, there's, I think, more durable and forward-looking solutions, but I don't think we're going to decide on scheme today. Really, we should be talking about frame transaction, and whether it should be the headliner or not.
Ansgar Dietrichs:Yeah, so maybe let me briefly jump in there, because yeah, I agree with what you said there about the decision for today, and just to clarify, so…
Ansgar Dietrichs:M… the way I see the decision tree here is that there's no real,
Ansgar Dietrichs:option here to even talk about nominating any other variant of a transaction generalization or account abstraction scheme as a headliner. That is just process-wise.
Ansgar Dietrichs:Not just process-wise, but also just maturity of these proposals-wise, just not the stage that they're in, and that's not an option.
Ansgar Dietrichs:So, I think, basically, the options that we have today are either we are selecting frame transactions as the headline, and of course, that could still mean, I think usually headline champions have quite a bit of leeway to change the nature of the proposal, especially early on into the process. So, for example, there could still be.
Ansgar Dietrichs:significant modifications as part of external feedback into this proposal, but either way, it would still be, in principle, frame transactions selected as the headliner. If we go down and choose no headliner, which would be the only other option available for today.
Ansgar Dietrichs:Then in that scenario, we could then later on, as part of the normal EIP process,
Ansgar Dietrichs:Or in the next coming weeks and months, basically figure out, are we going to select any
Ansgar Dietrichs:The such proposal to be a non-headliner for,
Ansgar Dietrichs:H star, that could be frame transactions, that could be any other variant or option, but then that discussion would not be for a decision today. That would… the decision today is exclusively about the headliner status. I hope that
Ansgar Dietrichs:clarifies that, and Tony, you had your hand up for a while?
Toni Wahrstätter:Yeah, thank you. Maybe just to add one more data point to the discussion, because we are very much focused on the different… enabling new types of signatures, but one very interesting data point is
Toni Wahrstätter:That frame transactions is very much generalizable, so you can run arbitrary code in the verify frame, and this also allows
Toni Wahrstätter:a quite cool use case for privacy tools. So, for example, for me as a user of privacy tools, it's always a headache to use relayers that eventually submit your transactions, because otherwise you would lose your privacy.
Toni Wahrstätter:And for the… with using the verify frame, you can basically have the smart verification done within the verify frame.
Toni Wahrstätter:without exposing the sponsor of the transaction to being drained, or anything. And this allows you to then submit withdrawals from a privacy pool without requiring a relayer.
Toni Wahrstätter:And for users of privacy protocols, this is… this is a great feature, because, as said, this is a… this has been a headache for a while.
Toni Wahrstätter:So, I think people should also consider that. While Julio's proposal is very nice in adding new signature types, the frame transaction proposal might be more generalizable.
Ansgar Dietrichs:Helix?
Felix (Geth):Yeah, I wanna also say that
Felix (Geth):I have a couple points. One point is that he…
Felix (Geth):Consider the frame transaction proposal to not be final, and we did not go into this process with the expectation of delivering a final proposal on this day of the decision of the headliner.
Felix (Geth):Rather, we just want to propose this as a direction of work, and we feel like, on the execution layer side.
Felix (Geth):There is capacity to work on account abstraction, and the frame transaction proposal as it is now, is kind of our best shot at account abstraction that enables many different things that we've gone over previously.
Felix (Geth):But, we are also still open to changing it, or…
Felix (Geth):Simplifying the proposal, if clients find it too risky, basically.
Felix (Geth):Tying it down a bit more in terms of the freedom.
Felix (Geth):So… To that regard, I would just say that
Felix (Geth):This becoming the headliner doesn't mean we have to ship exactly what is proposed, but it's just the start of the
Felix (Geth):Working on it for the next 12 to 14 months to really figure out the shape of it.
Felix (Geth):Yeah.
Felix (Geth):more to what the point of what Tony was saying, also just, these kinds of… this is… and also maybe as a response to the Julia's proposal,
Felix (Geth):The, frame transactions.
Felix (Geth):are not only concerned with enabling signature schemes, but they are more generally concerned with enabling things such as key rotation and post-quantum signatures and all kinds of other things for the accounts themselves.
Felix (Geth):So, it's, like, in some ways, a more general proposal that goes beyond just abstracting over the transaction signature. Like, there are many other ways to, like, for example, Tony said, Tony now presented an example where if you want to withdraw from a privacy pool, you're not really going to submit a transaction that has this, like.
Felix (Geth):in this, like, classic way, but it works a bit differently. The frames can capture this interaction while a…
Felix (Geth):Regular transaction cannot.
Felix (Geth):And then finally, more toward the point of Or should I say,
Felix (Geth):Julio's proposal. The other thing that we always have to do is that when it comes to enabling the flexibility of signatures, and especially post-quantum signatures, it is not just about enabling
Felix (Geth):the transaction origin signature, but also more generally, the frame transactions allow the user to break their on-chain computation into what we would call verifications and
Felix (Geth):state-modifying operations. And by enabling this decomposition of the EVM computation, the verification parts
Felix (Geth):when they are broken out of the regular EVM flow, can then be aggregated using CK proofs on-chain.
Felix (Geth):And we feel like this gives us a very comprehensive framework for introducing post-quantum signatures, not just for the transaction origin signature, but also, for example, for signatures which are to be verified by a contract. And, we feel that
Felix (Geth):it's just a bit narrow-minded to only look at the transaction, say, yeah, we have to convert the transaction signature to PQ, and then we're done, because the road to PQ is much longer than that.
Felix (Geth):And we have to consider all the use cases of elliptic curve cryptography and how they can be migrated on-chain, and that includes things such as use of EasyRecover and contracts, having alternatives to that that are actually workable, even though the signatures are large, and so on. And we feel like with the frame transaction, we actually do have a framework for doing that.
Felix (Geth):So, it's… it's… Just something to consider as well.
Felix (Geth):Anyways, I hope we can come to a good decision today, and, you know, that's it for me.
Ansgar Dietrichs:Thank you.
Ansgar Dietrichs:Patasarati?
Parthasarathy Ramanujam:Yeah, hi. Thanks for letting me speak. I mean, I'm, as a team who's been building wallets on Ethereum for 7 years, I just wanted to
Parthasarathy Ramanujam:highlight that, account abstraction or native account abstraction on Ethereum is long overdue. And, we've, the community has debated and deliberated on several options, and we think
Parthasarathy Ramanujam:at least, I can speak as a community member that, Flint's transaction happens to be the most popular, at least among the AA mafia group, when a poll was run. I would like to highlight a concern that if,
Parthasarathy Ramanujam:frame transaction isn't chosen as a headliner. There may be, I mean, the worry is that we may never implement native account abstraction in the near future. So, it is necessary, at least, I mean, as a team.
Parthasarathy Ramanujam:building on Ethereum that we would, like the core developers to choose this as a headliner core headquarter.
Parthasarathy Ramanujam:Thank you.
Ansgar Dietrichs:Thank you. Vitalik?
Vitalik:Yes, thank you. So, I, wanted to, just, kind of give, again, a, kind of high-level philosophical perspective on the, the thinking behind, frame transactions, right? Basically, you know, there's,
Vitalik:There's a doc that I published on the AA Mafia months ago, and I, you know, would definitely appreciate if someone digs it up that kind of goes step-by-step and shows how it's the most natural thing that,
Vitalik:satisfies, my…
Vitalik:Basically, yeah, all of the use cases that we've, figured out in, essentially, the last 12 years of accounting.
Vitalik:abstraction research, but in general, right, the, yeah, idea, the… The problem is that any… substantially released.
Vitalik:Simpler proposal is…
Vitalik:inevitably going to leave a lot of things out, right? So, like, for example, any proposal that depends on a, will inevitably leave out multisig, it will inevitably, by default, leave out key changes. It will leave out multisig that mix and matches, different signature schemes. It will, by default, leave out, like, post assertions, like,
Vitalik:what Frederick mentioned in the chat, will leave out sponsored transactions, and,
Vitalik:it will, leave out private account abstraction. And so, basically, yeah, inevitably, any proposal that is sort of much simpler than, what FrameTransactions already is, is, so…
Vitalik:one that is not going to be able to cover those use cases, right? And so, essentially, yeah.
Vitalik:like, this, this is the, yeah, the reason why frames is…
Vitalik:what it is, right? And so, the… if you make an incompatible proposal that, does not,
Vitalik:that I, doesn't sort of very naturally extend into
Vitalik:into frames, which would probably basically just look like frames on what the frames are, then essentially three years from now, it polluting the protocol that we need, right? And, also.
Vitalik:The other important point here is, that, all of the… from what I can tell, all of these simpler proposals can be implemented, like, can be expressed as a subset of, 8141, and in a couple of cases, 8141 plus a couple of, of other small, very small EIPs.
Vitalik:Right?
Vitalik:And so, the, like, the core philosophy here is basically that, like, actually, yes, you know, we can make the mempool very restrictive. We, I, like, I personally think it's totally okay to have the mempool be something that, like, if desired, for example.
Vitalik:only, like, even goes even more restrictive than, the, yeah, than the current proposal, and even says, like, okay, like, we do just, K1, R1, and a post-quantum scheme, and, support sponsored transactions, for example. And then…
Vitalik:But then, the key thing that we get is basically that other people that all core devs never has to care about or hear from ever again have their own corner to, work on an alternative mempool, and, like, basically, yeah, start with 7562, or potentially start with, even, like.
Vitalik:even newer ideas that come, and, work on being able to support all of these more complex use cases. And the,
Vitalik:mempool, and then the pri… the prime…
Vitalik:always has an optionality to add in
Vitalik:Some, support for more things, or even just…
Vitalik:At the end of the… yeah, in June.
Vitalik:the universal mount ball in its entirety at any point in the future without a hard fork, right? And so, like, the core idea, basically, is that the,
Vitalik:in protocol,
Vitalik:aspect of this, or the in-protocol part of this, is a part that's quite small in terms of spec lines of code, right? The bulk of the… the great bulk of the complexity is in… So, what we can do is we can say, well, we have a much more restrictive forward.
Vitalik:The… basically, there is a free market, and all of this continued development of
Vitalik:better rule sets can happen on the outside. Things like working on, supporting privacy protocols and enabling privacy protocols to be intermediary-free, which is, like, a personal passion for mine, because, like, the intermediaries
Vitalik:of actual…
Vitalik:existing privacy protocols are just a thing that always breaks for me. So, basically, you support both, right? And, you can support all of these, use… simpler use cases in a way that, is, very simple, very low on gas, and where there's, a way to do frames that even makes it easy
Vitalik:EM Freedom, and that's all part of the proposal, and then at the same time.
Vitalik:all of these other things happen. So, that's kind of the high-level view for, like, why, yeah, this design has been…
Vitalik:builds the way it is, and why I think it can, satisfy both, kind of, very conservative near-term use cases at a high level of.
Vitalik:Efficiency, and at the same time, immediately, yeah, open up space for adding…
Ansgar Dietrichs:So, just Vitalik, just to double-check that I understand, basically, would it be fair to summarize your point as saying that, basically, you would argue we should still do frame transactions, but you'd be very open to being very, very pragmatic about the short-term mempool site implementation, so that the actual
Ansgar Dietrichs:Limitation complexity is low, and people can still get what they basically would want with all these other paths out of it in the short term.
Vitalik:Yes.
Ansgar Dietrichs:Sounds good. Yeah, I think that's, in general a reasonable argument. Julio?
Giulio:Yeah, I just wanted to say that you can extend scheme to be, like, frames with an extension, but especially with verify frames in the future, it's just that
Giulio:it just allows you not to, maybe you cannot do everything in one go, basically, but yeah, that's pretty much it. I mean, it's not really only the signature scheme, you can abstract that as well with just simply an extension.
Giulio:So…
Giulio:You can get there, still with schemed. It's not like it locks you away from frame transactions. Actually, you can basically implement it on top of it, just in a more controlled way, at least regarding verification frames.
Ansgar Dietrichs:Right.
Vitalik:I guess I would just say, like, I just don't really just see in what sense, you know, like, frames are kind of uncontrolled, right? Because, like, you can have transactions that just are one verify frame followed by an execute frame, and it's equivalent. Basically.
Vitalik:clear.
Vitalik:Equivalent to a scheme that is…
Vitalik:verification-specific, right? And so, you know, the argument I would make is based only, allowing transaction, transactions of that type. And, like, functionality-wise, it's, kind of equivalent, like, you can,
Vitalik:you can see the one-to-one correspondence from one thing to another thing, and, like, effectively your GET schemes.
Ansgar Dietrichs:Yeah, so maybe one way of presenting this question, or, like, the decision we have to make today, is that you can… you can think of, like, we want to make transactions more general, and you can basically think of it as the element of it that's the…
Ansgar Dietrichs:generalizing the execution flow and execution logic, and then it's about generalizing the verification flow. And so we could do something that's inspired by, you know, some of what Julius is saying, by just basically trying to make the execution flow more general now.
Ansgar Dietrichs:But keeping the verification flow as is, but the point is that with native con abstraction and with post-quantum, we will eventually have to tackle the verification flow anyway, so the question is basically, the decision for Prime Transaction as headliner today would mean that we will tackle
Ansgar Dietrichs:also generalizing the verification flow, at least from the in-protocol side, already in HSTAR.
Ansgar Dietrichs:And then we can restrict it down from the mempool, keeping it simple there. The alternative would be to basically say, no, we don't do this hard fork, we wait for another hard fork.
Ansgar Dietrichs:I do think people have brought up in the past that, like, future hardcore folks might be more cramped on the EL side, so it might actually not be so easy to find another opportunity to then tackle this part, and we will have a somewhat of a time pressure because of post-quantum.
Ansgar Dietrichs:But yeah, so I think kind of like that is. So indeed, I don't think, Julie, I don't think, basically, like, saying… doing something that's more like your proposal, I don't think it would prevent us from, in the future, going into the direction of frames.
Ansgar Dietrichs:But I don't think it would yet give us the core that we will have to at some point do.
Ansgar Dietrichs:If that makes sense.
Ansgar Dietrichs:Derek, if you end up?
Derek Chiang:Oh, yeah, you know, I think I just wanted to, I guess, emphasize, like, a specific point. You know, I think…
Derek Chiang:I think, like, most of the debates that, I guess, between firms and, like, some alternative, you know, and most other alternative proposals, essentially just comes down to whether people believe that verification should be done through EVM code.
Derek Chiang:all should be essentially enshrined into the protocol, for example, through precompiles, right? You know, so for example, if you look at skin transactions, if you look at, like, the earlier EIPs, like the composable transactions, or the…
Derek Chiang:the, I think it's, like, 8164, like, the passkey, transactions. You know, they, they, you know, so, you know, they, they, they, they all believe that, it's, I guess, like, dangerous, or, like, you know, it would complicate the manpool to do the verification with, EVM code, right?
Derek Chiang:You know, so, you know, which is why they opt to do the validation through precompiliers. So, but I just want to point out that, like, actually, we don't have the troops, right? You know, so firm transactions.
Derek Chiang:as I mentioned in the beginning of the call, it's the only proposal that gives you the options, right? You know, so, you have the full option to fall back to EVM code validation if you choose to.
Derek Chiang:But it also has first-class supports for using pre-compires to handle the validation, if you prefer to have to let the protocol handle the security, right? So I just wanted to say that, like, just from the perspective of, like.
Derek Chiang:giving people more options, right? You know, you know, I sort of, you know, I sort of think of firms as superset of
Derek Chiang:the other proposals, you know, so, so, so to be… yeah, yeah, so, so, so I think, like, that's why I think firms aligns better with.
Derek Chiang:the broader Ethereum, philosophy of, like, just, you know, being, you know, allowing permissionless innovation, giving people their options, you know, and, you know, so, so I think my firm is, it's really, like, really the only proposal that satisfies the needs of.
Derek Chiang:Both camps, when it comes to how validation should be handled.
Ansgar Dietrichs:Sounds good. Before we, Amit, before we continue the discussion, I just wanted to briefly,
Ansgar Dietrichs:take a moment, like, we are now one hour already into the call, we need to make the decision today. Maybe now would be a good time to just briefly check in with clients to hear…
Ansgar Dietrichs:where the thinking is at? Are they still basically undecided? Are they decided? Is… is it even an option still that we might select frame transactions as the headliner today?
Ansgar Dietrichs:I'd briefly make… want to make the rounds with clients, and then we can come keep… we can go back to open discussion.
Ansgar Dietrichs:If that's okay with you, Ahmed.
Ansgar Dietrichs:So then I'd briefly, yeah, call on the clients, like, Geth, could you briefly give an update on your position?
Felix (Geth):Yeah, so we want the frame transaction.
Ansgar Dietrichs:Yeah, I guess this is not so surprising. Never mind.
Łukasz Rozmej:I think we… have…
Łukasz Rozmej:Bigger dubs that we wouldn't call… definitely don't want to call it a headliner at the moment.
Ansgar Dietrichs:Ben, I guess you wanted to add something from that other mindset?
Ansgar Dietrichs:He's still muted.
Ben Adams:Oh, sorry. I'd just like to add that we're, happy to work on it.
Ben Adams:Separately, do a kurtosis, and, you know, firm up.
Ben Adams:Permidopmo.
Ansgar Dietrichs:Sounds good, so you're open to it, but prefer to not have it be a headliner.
Ansgar Dietrichs:Aragon?
Giulio:We… I think we basically went from plant-sided, basically.
Giulio:Probably is like to know.
Ansgar Dietrichs:Okay. It's like, no, but open to it still?
Andrew Ashikhmin:Yeah, I guess we are divided, so some of us are actually in favor of framed transactions, but I think Julio's proposal is also a good stepping stone.
Ansgar Dietrichs:Sound good, peso?
Daniel Lehrner (Besu):Yeah, we, we still also figure, no headliner for Hagota.
Daniel Lehrner (Besu):And the team has concerns about,
Daniel Lehrner (Besu):complexity, basically, of a firm transaction. We think it's too complex.
Daniel Lehrner (Besu):For… for what it delivers in the end.
Ansgar Dietrichs:Okay, and, breath?
emma (reth):Hey, yeah, we are unknown.
Ansgar Dietrichs:Makes sense. And any of, the newer EL-side clients, so Nimbus, EL, or Erigon?
Iván | ethrex:On the Athrex side, we are in favor of the EAP.
Ansgar Dietrichs:Okay, yeah, so it does sound like…
Ansgar Dietrichs:they're still… we're still leaning towards NOA. I mean, we can go back into open discussion for a little bit.
Ansgar Dietrichs:I… my impression is that, actually, maybe a not-so-unlikely outcome would be to reject it today as headliner, but still work towards selection as non-headliner. Seems like a lot of clients are at the edge of being convinced they just need more time.
Ansgar Dietrichs:So it might actually be a not-so-unrealistic outcome to just ship it in the end as a non-headliner, but, yeah, for today's discussion, I think we should, yeah.
Ansgar Dietrichs:For now, just deal with the question of…
Ansgar Dietrichs:Do we want to select it as a headliner or no? Right now, we don't have enough client support to select it, so we can have another round of comments, and then see if we're ready to, like, make a decision.
Ansgar Dietrichs:Ahmed, you have your hand up?
Ahmed Al-Balaghi:Yeah, no, thanks for that. It's great to, to hear everyone's opinion on this. So, I think a lot of the arguments,
Ahmed Al-Balaghi:that was presented, sort of, full frame transactions, already been sort of discussed, and don't want to repeat those, but I just want to say generally, like, I think as an ecosystem, we kind of have to, you know, push hard and through, even though some things look a bit complex. I mean,
Ahmed Al-Balaghi:You know, the… like, we've been doing a counter strategy for a long time.
Ahmed Al-Balaghi:We've now been working a lot on orchestration, and we're kind of seeing…
Ahmed Al-Balaghi:first-hand from the ecosystem, like, what they want, you know, they want things, you know, from the EOAs, they want things, you know, directly where the users come from, and so I think if we…
Ahmed Al-Balaghi:were to delay this, it would set Ethereum back quite a lot, and I don't think all of us are in this,
Ahmed Al-Balaghi:Yeah, we're not… I don't think we're incentivized for this to sort of see this happen, so I think we're…
Ahmed Al-Balaghi:all wanting Ethereum to win, and for that to happen, we really need the UX to be way better. We need, native AA, because otherwise the current solutions that exist are just…
Ahmed Al-Balaghi:You know, I don't think they're… they're perfect, you know, not many projects want to use AA, you know, in the way they are right now.
Ahmed Al-Balaghi:Yeah, I just think, you know, as an ecosystem, we have to push hard and push through, to be honest.
Ahmed Al-Balaghi:Because there's so many, so many awesome things that we could do on the UX level from frame transactions. We already have a couple of ideas, we're already experimenting on them as well, and there's so many, like, use cases on the privacy side, and also, yeah, I think there's going to be a lot of innovation that will come from this. So, yeah, I think…
Ahmed Al-Balaghi:Just something for the, client teams to sort of reconsider, I think.
Ansgar Dietrichs:And Nico?
Nico Consigny:Yep, I think it would be also good to hear some opinions from other L2s. I see some people from OP Labs
Nico Consigny:From Arbitrum.
Nico Consigny:Mark from Optimism has been very supportive publicly of Primes. I would be interested to hear Arbitrum's opinion, too. Most of the, like, as Ahmed just said, most of the AA builders want to see things,
Nico Consigny:moving in the direction of native AA. We've been looking at it for a while, so yeah, it would be super interesting to take everyone's input in this process, and so, like, if I can give the mic to some of the L2s that didn't speak yet.
Nico Consigny:I think Lumi was here, and probably other people from Obi Labs.
Nico Consigny:Would be good to have your opinions, too.
Ansgar Dietrichs:Yeah, so if any of the L2s want to raise their hands, feel free to join the…
Ansgar Dietrichs:the queue, I won't fast-track you, I think it makes sense, though, just, just go one by one. So, next up is Julio.
Giulio:Yeah, I just… I just wanted… I just wanted to say that,
Giulio:But yeah, I mean, you can… you can probab… I mean, if you… and I don't want to… to say the same, but if you go for… but if you go for scheme, you can do probably very 5 frames as their own thing, as another liner in Nagota. Pretty… probably in a more controlled way, and you could still ship them.
Giulio:And, you know, if you ship many things at the same time, I think there are so many unknowns that people are not really that willing to implement them, that's all. Like, I think… I think it's just… yeah.
Giulio:That's what I wanted to say. You can still do it that way, probably.
Ansgar Dietrichs:Sinclot, Lumi?
Lumi | Offchain Labs:So, we have a little bit of mixed feelings,
Lumi | Offchain Labs:In a way, frame transactions seems like it's a really good solution for L1. One of the things that we're concerned about… we tried to form an official stance for this call, but we couldn't get to it.
Lumi | Offchain Labs:There are some concerns that we have, which is we're really targeting very, very low block times and very high throughput transactions, so…
Lumi | Offchain Labs:we could choose certain, you know, quote-unquote transaction types that would be allowed, but then the concern around there is if every L2 supports different transaction types, that creates fragmentation in the ecosystem.
Lumi | Offchain Labs:For wallets for… for applications, so…
Lumi | Offchain Labs:We don't have a official stance on this, we have a little bit of mixed feelings, but some of the directions that 8141 has been going in are definitely promising. And obviously, for off-chain labs, we have zero dev, and Derek is helping define the standard, so…
Lumi | Offchain Labs:That's what I can add from my side.
Ansgar Dietrichs:Thank you, and Josh?
Josh | OP Labs:Yeah, thanks. I think, just… I'll just echo something that, LightClain mentioned in the chat.
Josh | OP Labs:Which I think is a promising compromise here. I think we're in a similar position to many folks on this call, like.
Josh | OP Labs:native AA is, something that's definitely,
Josh | OP Labs:promising and something that we'd like to see, but obviously there are multiple proposals on the table, and at this time, it's difficult to definitively say which one would be best long-term. So I think White Client's proposal for maybe a compromise here of saying that account abstraction as a feature is the headliner, but the details are worked out over time.
Josh | OP Labs:To me, that sounds like a promising option. I'm curious to hear what client teams think about that.
Ansgar Dietrichs:So, just process, I mean, look, I'm just a coordinator, of course, ultimately, I'm willing to facilitate any decision whatsoever.
Ansgar Dietrichs:I… my understanding of the process would be that
Ansgar Dietrichs:basically, I think there might have been an option to select something that's more like a theme as headliner, not a specific proposal, but that would have still had to go through the flow, have been proposed in time, all these kind of things.
Ansgar Dietrichs:that did not happen. I think it would be reasonable to say, for example, select frame transactions with the specific
Ansgar Dietrichs:Expression of, from the, from the…
Ansgar Dietrichs:proposal champions from Matt and Felix to be flexible and possibly swap out the specifics of the proposal for a different version if the majority of people were to do that, so I think
Ansgar Dietrichs:That part, I think, would be fine, but I think completely switching over to a different headliner that has not been in the pipeline, I personally think is…
Ansgar Dietrichs:just too late into the process, given that it's literally the call now that we want to make that decision. Of course, if everyone wants… strongly wants to go with that direction, I'm happy to be overruled here.
Ansgar Dietrichs:But it doesn't feel like it's in the scope of what we should be able to do, process-wise.
Ansgar Dietrichs:Ben?
Ben Adams:I don't… I don't think a theme would help, because…
Ben Adams:We're… we're trying to put something firm into the…
Ben Adams:the plan, and we're saying, oh, we'll put something vague in. It's not… it's not really…
Ben Adams:Yeah, and one of the issues with, friend transaction is that
Ben Adams:isn't firm, so we've, like, rejected encrypted mempools for not… being fully designed.
Ben Adams:Equally. But… so I… what I would prefer is if we CFI'd it as a regular EIP,
Ben Adams:then explored it through implementation, firmed up the design that way, rather than as a headliner. Because the headliner is more, this is what we are shipping in the fork, we halt the fork until it ships, and I don't think
Ben Adams:Where I don't think it's… At the moment.
Ansgar Dietrichs:Yeah, I think something like this could be very reasonable. I'm not sure we would have to make that CFI decision today, but, yeah, I think, in general, that's a reasonable proposal.
lightclient:I just want to add something quickly, just to respond to that. Like, I think, yes, you know, frame transaction is continuing to evolve and change, but I do want to point out that AA is a little bit different than some of the other protocol-level EIPs that we might see, or we might say aren't firm.
lightclient:because there are so many different parties that are affected by AA, it's extremely difficult to ever reach a point where
lightclient:It is in a very firm state.
lightclient:Because there's always new people coming, new wallets, new chains, Coming with different needs.
lightclient:And there's not really, like, a perfect solution. We saw this with 3074 and 7702, you see this with 4337. Like, AA is a very hard problem to solve, and it's about finding the best compromise across, like, a bunch of different moving pieces.
lightclient:And I just want to, like, push back a little bit, like, I think the frame transaction standard is quite solid, and built on a lot of
lightclient:you know, in-production ideas with 4337.
lightclient:So, it's not like it's coming from nowhere. We're just trying to find the perfect
lightclient:solution to fit all of the different needs of the people and the protocols. And so, yes, like, these things will continue to change over time. I don't really expect that we'll ever reach a point where everyone is totally happy with how Framed is going to be.
Ansgar Dietrichs:Okay, and Andrew?
Andrew Ashikhmin:Yeah, I think, we should be…
Andrew Ashikhmin:more ambitious, and if you look at this draw map, if we, like, if we keep, postponing
Andrew Ashikhmin:doing hard things because they're hard, then we will never reach even a half of the straw map, so I think we should be more ambitious and do the hard things, not because they're easy, but because they're hard, but they are also
Andrew Ashikhmin:that they'll bring Ethereum forward. So, I personally am in favor of frame transactions, and I think if… I'm also happy to have account abstraction as a general theme for Higata. I also think, if you look at the straw map, there are
Andrew Ashikhmin:Actually, there is a stream of work related to mempools. There are encrypted mempools, and I think that encrypted mempools are crucial for Ethereum maturity if you want to, like, to prevent front running, and we need to prevent front running, like, for
Andrew Ashikhmin:Like, any serious corporate use.
Andrew Ashikhmin:then we need something like encrypted memposts. So, we just need to bite the bullet and accept that we do need to work on our mempulse.
Andrew Ashikhmin:And it will be, like, yeah, it's a big chunk of work.
Andrew Ashikhmin:But I think it has to be done.
Ansgar Dietrichs:And Nixon?
nixo:Just on process, I'm unopinionated whether this is going to be a headliner or a non-headliner,
nixo:But I just want to say that we shouldn't lose the forest for the trees here. We don't need to be a slave to process. The process that was proposed last year as the headliner process was more to be descriptive and helpful and clarify to outsiders what this process was. I think that if we have a quorum on ACD, which is the point of ACD,
nixo:We can decide to do something like put a general idea in place of a specific proposal, if that specific proposal is willing to cede to the general idea and make compromises with other proposals to get the best possible proposal.
Ansgar Dietrichs:Yeah, I don't think that's entirely unreasonable, although I do think with… if you want to basically make exceptional decisions like that, then I think at least it needs to be a unanimous decision amongst clients. I don't think we can make this, have the same threshold for decision as a normal process decision, so if all the clients indeed were to agree with that approach, I think that's a reasonable thing to do.
Pedro:I think sometimes we're trying to decide whether the AA is the headliner, or whether it's an 8141.
Pedro:I think the biggest challenge with all AA solutions in the past has been that
Pedro:We cannot find an ideal solution, therefore we never have one.
Pedro:And this kind of just puts more and more pressure into the AA teams to have to do everything themselves. Like, frame transactions is not perfect, but there will never be a perfect AA solution. The fact that there is even one AA solution as ambitious as this.
Pedro:included as a headliner was perhaps the most hopeful news I've ever had in the 8 years of history that I participated in Ethereum.
Pedro:And I would be very, disappointed to see this downgraded into something that is not a firm decision, because we can continue to improve
Pedro:you've seen the improvements that happened just the last two weeks for the EIP, with the EOA support, mempool policies, atomic batching.
Pedro:like, we're… we're really seeing a monumental change for AA, and we can challenge whether that is
Pedro:a good EIP, but not having this as a headliner, I think it's a problem.
Ansgar Dietrichs:And, Lumi, and then afterwards, I think, because we'll only have 10 minutes left, yeah, we'll bring it in and have a discussion about the concrete decision.
Ansgar Dietrichs:Salute me?
Lumi | Offchain Labs:I would just echo what you said in the comments of, what we can do is reject it as a headline or frame transactions, but we should commit to all core devs prioritizing AA work.
Lumi | Offchain Labs:Like, AA is probably, arguably, the single most important user-facing upgrade that we should do.
Lumi | Offchain Labs:we are gonna start seeing fragmentation between L2s, regardless of which native AA approach we go to, because every L2 team is prioritizing native AAA and user experience, so…
Lumi | Offchain Labs:we really should work on it now, and I'm personally worried that if we don't work on it now, it's gonna slip after ZKEVM and a bunch of really big projects. Like, this needs to be a priority.
Lumi | Offchain Labs:Like, we hear this every day from users, from enterprises, maybe more than all core devs, like, this is the single most important user experience choice.
Ansgar Dietrichs:Yeah, thank you. And just as a quick personal comment, I was part of the group that brought EIP 2938, which is actually relatively similar to frame transactions, to Occo Devs back in 2020, and back then it was the… the decision was, oh, sorry, London.
Ansgar Dietrichs:is already getting quite full, and we are too close to the merge, so there's just no time. And ever since, I think account obstruction has always been just barely beyond the horizon of important enough to prioritize it.
Ansgar Dietrichs:I personally would enjoy and appreciate seeing all code devs prioritizing this topic for HDAR in some form or another, either as a… with a specific headliner, or with a general headliner, or just without a headliner, but with a commitment that we will prioritize the topic in the general EAP section.
Ansgar Dietrichs:I feel like it's… the time has come, and we do see a lot of user interest and demand here.
Ansgar Dietrichs:Ben, if you want to have a quick comment, then otherwise, afterwards, I'll start talking about concrete decisions.
Ben Adams:I'm okay with prioritizing it, but I'm just saying, if… if we say AI is the headliner, the implication is that we do not ship HDAR until
Ben Adams:A solution is implemented.
Ben Adams:That's the… that would be the theme of what a headliner means.
Ansgar Dietrichs:Yes, I think that is a good…
Barnabas:window.
Ansgar Dietrichs:None of us?
Barnabas:We do need a user experience win, though.
Barnabas:I think we should be, holding off each store for this.
Ansgar Dietrichs:Right.
Ansgar Dietrichs:So yeah, I think… I mean, Ben, I think the comment is valid, so I don't think we should make this decision lightly, but I do think, you know, as Barnabas is saying, it might just be worth saying, yes, this is a commitment, we will take out… we will take the time that's necessary, and we will have this as a priority.
Ansgar Dietrichs:Knowing that this is a cost we're paying here, it's not free, but it's worth it, basically. So then…
Ansgar Dietrichs:I think the two decisions, basically, that I think then we make in sequence here is, one, we can still talk about do we want to just accept frame transactions as is, as a headline-up, with, of course, option to still adjust the proposal down the road. If we decide to reject it, then I think the follow-on question is, do we want to officially
Ansgar Dietrichs:prioritize just account abstraction as a general theme, as the EL headliner for the fork. Yeah, so let's start with the question of, do we want to
Ansgar Dietrichs:did clients… hearing all of this over the last few minutes, did clients change their minds? Is there enough of a momentum for frame transactions specifically?
Ansgar Dietrichs:I guess, question to, mostly to… Nethermind and, peso?
Ansgar Dietrichs:I would assume his clients may be closest to changing their minds?
Daniel Lehrner (Besu):No, from Besto, we still prefer no headliner. I mean, we can… Half-frame transaction maybe later, but…
Daniel Lehrner (Besu):I would not like to commit to, like, a blank check saying AA as a headliner.
Daniel Lehrner (Besu):Because I don't even know what this means, and how, when we would ship.
Daniel Lehrner (Besu):So, I mean, we can do this…
Daniel Lehrner (Besu):as EIPs, but I would not do it as a headline.
Ansgar Dietrichs:Okay, well, that already kind of answered the second question as well, but, like, let's first… yeah, let's first…
Ansgar Dietrichs:finish the discussion on… on frame transactions. Nethermite, I assume you… like, did you change your mind on… on frame transactions?
Łukasz Rozmej:So, I don't know what the rest of the team thinks, right? So, we haven't time any to discuss. My personal opinion has not changed. I would like to experiment with it and proceed with it, but I wouldn't put it as a headliner.
Ansgar Dietrichs:Okay. Then, I think, in terms of decision for today, it seems that
Ansgar Dietrichs:frame transactions specifically just does not have enough support among clients to be selected as a headliner, so then I propose it is…
Ansgar Dietrichs:rejected without changing the status of the ERP itself. I think the ERP should still be considered, PFI'd. Normally, we DFID headline ERPs if it's clear that they have no room outside of the headline status, but in this case, I think it makes no sense, so I think the decision would just be to
Ansgar Dietrichs:Declined the headline status for the specific ERP.
Ansgar Dietrichs:Is there any last?
Ansgar Dietrichs:Protest against that decision?
Ansgar Dietrichs:Okay, then I think that decision is made, and then the question is still, I… I'm open to saying we, last minute, select
Ansgar Dietrichs:account abstraction more generally as a headliner for the EL for H-star. It now already sounded like Besu was very skeptical about the idea. I do want to briefly open this up, maybe have a discussion just among client teams, because we only have a few minutes.
Ansgar Dietrichs:Do we have other client team opinions on this approach, selecting account abstraction as a headliner?
lightclient:I think death supports this.
Ansgar Dietrichs:Never mind, do we have an opinion?
Łukasz Rozmej:I don't have an opinion, like, without specifying the AP, it's pretty vague, so I don't know what it means.
FLCL:I think it's,
FLCL:Maybe choosing or not choosing headliner affects only one thing is, kind of motivation.
FLCL:To, commit and implement this, but if we find, that it is not a good approach, and other
FLCL:Strategies are better, like, let's keep… schema thing from Guido.
FLCL:We can switch and decline the…
FLCL:this approach of rent transactions. I mean…
FLCL:Maybe it's a good thing to…
FLCL:Confirm its, headliner just to, to make it, Like…
FLCL:To make people more motivated, to be more focused.
FLCL:Because… Like, reality, after all, will resolve whether we will use them or not.
FLCL:We need more testing, it's a very complicated thing, we need to play with it, and we will do it initially, but it will be headliner or not.
FLCL:So, not a big deal.
Ansgar Dietrichs:Right. But, so… I…
Ansgar Dietrichs:feel strongly that we could be so… in terms, we need to make a decision today. Like, I see a lot of support for the idea of 94A as a headliner in chat. However, so far, the process is that headliners and
Ansgar Dietrichs:these types of decisions are ultimately client decisions, and that community input, while I personally find it very valuable, I know that many quad apps do find it very valuable, but it is, has the role of informing client decisions, given that
Ansgar Dietrichs:we are considering just deviating from process here by selecting something that was not in discussion until today. I would really only do this if there was very strong client support. We have several clients
Ansgar Dietrichs:opposed to, or skeptical to NativeA as a headliner theme, so I just don't think, process-wise, we have a basis to select NativeA more generally as a headliner theme.
Ansgar Dietrichs:So I would…
Ansgar Dietrichs:I do think we should probably, as Orcher devs more generally say, that clearly we signal the intention to prioritize NativeA as a theme.
Ansgar Dietrichs:But that is separate from headliner status, so it's not a headliner commitment, but we just selected… we just… we just commit to prioritizing that exploration and trying to fast track any AP, but it does not come with the headliner.
Ansgar Dietrichs:commitment level. Does anyone want to…
Felix (Geth):So it's like this…
Ansgar Dietrichs:Jake?
Ansgar Dietrichs:Felix?
Ansgar Dietrichs:Did you want to say something, Felix?
Felix (Geth):Yeah, I was asking, so this is like a CFI+, or…
Ansgar Dietrichs:No, it's nothing, like, there's no… like, my point is that there's no decision today, no official… no official decision in any form. Like, the decisions are to reject the headliner, and so we will just not have an EL headliner. Again, I'm very sympathetic myself to the enthusiasm towards Native A, and I hope we can do something in the heartfork, I just don't see a basis for a decision here, other than what I just said.
Ansgar Dietrichs:Again, if people want to speak up, we have a Zoom user that wants to say something.
Zoom user:Sorry, I didn't share my name. Antonio here. Sorry, Antonio. Just about, like, a quick comment,
Zoom user:you know, since, like, I understood, like, that there is no strong support for a print transaction, this is okay, and it was, like, this alternate proposal today by Julio. I was wondering if there is still the chance to…
Zoom user:have two more weeks to, like, so making… having people chew over these two alternatives. I don't know how late we are in the process.
Zoom user:But given there is, like, this big uncertainty, and the topic is so important, I don't think that two more weeks will change too much. But the headliner, if we can have two more weeks to have more people, like, discuss.
Zoom user:Because I think, like, a kind of abstraction is… not the kind of abstraction is really an important topic for… for the future of the protocol, so it might justify, in my opinion, two more weeks to take a final decision about headline or not, and not closing the discussion today. Just my two sense.
Ansgar Dietrichs:So, given that we already made an exceptional decision to move the deadline by 2 weeks, and that enough was not enough to actually come to a different decision, I think at some point it is also not respectful towards the clients' teams that, do
Ansgar Dietrichs:Want to oppose this, to keep just not acknowledging their decision here.
Ansgar Dietrichs:So I… yeah, I don't think…
Ansgar Dietrichs:delaying, again, two weeks is a reasonable option, unfortunately. Banavas?
Barnabas:So, in previous workload devs, the Pandops team has never really spoken up, pro or con, a specific EIP, whether we want it in or not.
Barnabas:our voices usually try to be as neutral as possible, and I'm not really speaking on behalf of all the
Barnabas:Pandas, but, from my personal point of view, if we are also considered to be, part of the all core devs, and whether we have a decision or not, I would actually be for frame transactions as a headliner.
Barnabas:And, maybe my opinion, we'll actually balance it out and push it through to be an actual headliner.
Barnabas:I'm not sure how the other panelists feel, I can ask their opinion as well, and
Barnabas:Because I know that you're looking for a majority of clients. I know that we don't consider it to be a client, but
Barnabas:So I feel like we are, part of the Occord Devs process as a whole.
Ansgar Dietrichs:But…
Ansgar Dietrichs:Yeah, thank you for this. So, I mean, look, I do acknowledge that there clearly is a lot of,
Ansgar Dietrichs:disagreements around this topic, so I think the best path forward here, and we are also at time, so I think my proposal is as follows. We kind of already just now said we made the decision to reject frame transactions as a headline. And of course, all code apps can always, in exceptional circumstances, revisit prior decisions.
Ansgar Dietrichs:They're never final until they ship to chain, so if in two weeks, for some reason, we want to revisit the decision and undo it and change it, that is fine.
Ansgar Dietrichs:Same thing with selecting a more general theme. I think the decision today is to not select a more general theme either, and given that we decided today was the deadline day for this decision, that would normally mean
Ansgar Dietrichs:This is done, and two weeks from now, there's not going to be an opportunity anymore to select the headliner.
Ansgar Dietrichs:If, asynchronously, between now and two weeks from now, people come to a stronger shared understanding that this
Ansgar Dietrichs:situation is exceptional enough to require an amendment to normal processes, and we should go in a different direction, I'm totally fine with that, and I think we should listen to that.
Ansgar Dietrichs:M…
Ansgar Dietrichs:I… yes, but I don't think today, synchronously on this call, we have a basis for any other decision. Does that seem reasonable? Again, I think it's totally fine if we want to decide to make exceptional process amendments, but I don't think we can do this live on the call now.
Ansgar Dietrichs:so… Yeah, I don't… No… I mean, maybe, yes, I would now restrict…
Ansgar Dietrichs:contributions to only clients, just to… just for the formal decisions here. Ben?
Ben Adams:Are we okay to accept that, say, in 5 to…
Ben Adams:You know, 4 or 5 months after we've explored it a bit more.
Ben Adams:with an implementation, firmed up the specs, that we could revisit it as I had both.
Ansgar Dietrichs:That would be up for group decision. I…
Ansgar Dietrichs:that would require some more meaningful adjustment to a process, but I'm not sure why we could not do that, but we would then have to be intentional about it.
Ben Adams:Yeah, that's why I'm raising it.
Ansgar Dietrichs:Sure. I mean, I do think it does seem like, even though there's a lot of disagreement here on, like, the specific status and process and all these things, it seems like there's overall agreement that
Ansgar Dietrichs:Account obstruction is something that is important, that needs attention.
Ansgar Dietrichs:I do think it will receive that attention now. Everyone here wants to work on a resolution, so that's good. That, I think, is the kind of informal takeaway from today's call.
Ansgar Dietrichs:EL-wise, post-Glamsadam, the focus is, mindshare-wise, on a card abstraction, and then we will have to revisit at a later time what that specifically means, whether that just means selecting a non-headliner EIP, that would be the default path here.
Ansgar Dietrichs:Or do we want to exceptionally make a different decision down the road? We can do that, but we will consider this carefully, and not just make a snap decision now.
Ansgar Dietrichs:Is that… and that does… that also means we're not specifically assigning, like.
Ansgar Dietrichs:frame transactions will remain PFI'd for now, until we make a specific other decision.
Ansgar Dietrichs:Does that sound as a reason… is that a reasonable compromise to leave the call at for now, and end it? We're already 5 minutes over time.
lightclient:I feel like we should at least have it as CFI.
lightclient:I don't know if any clients would be against making that decision now.
Ansgar Dietrichs:You mean frame transactions specifically, CFI? I feel like we have clients that specifically even opposed it as, just in general, to do at all in Ethereum.
Barnabas:Too many clients, so…
lightclient:pose… Yeah, any clients oppose making it CFI? I thought I saw most people saying CFI is okay.
Ansgar Dietrichs:Can we just have that discussion in two weeks? I don't think.
Ansgar Dietrichs:Quite now.
Ansgar Dietrichs:We don't… I mean, you know, we're 5 minutes over, but we didn't have time to…
lightclient:I think.
Ansgar Dietrichs:If you get an act from every single… Look, okay, Matt, this is your section. If you get an act from every single client, it's CFI'd.
lightclient:Another mine?
Ben Adams:Yeah, we wouldn't object in a precedent kind of a setless fossil.
Ben Adams:They're, like, early CFI, so…
lightclient:Yep.
lightclient:Julio? Or Aragon?
Giulio:Fine. That's fine to cheer fight.
lightclient:Hey, Sue?
Daniel Lehrner (Besu):Yeah, I think they're fine with CFO.
lightclient:Russ?
emma (reth):Yeah, we won't block it. That's cool.
Ansgar Dietrichs:Okay?
lightclient:Ship it?
Ansgar Dietrichs:Then we… CFI frame transactions.
Ansgar Dietrichs:And by that, that's the last decision for today.
Ansgar Dietrichs:Thank you, everyone. This was a hard one, but I do think, again, overall, focus on account abstraction, I think it's… it's about time, so…
Ansgar Dietrichs:Yeah.
Ansgar Dietrichs:Thank you, everyone, and talk to you in two weeks. Oh, one last notice, just for my side, I will have Nixu fill in for me in two weeks, so Nixu will lead our good lives in two weeks, and I might still be able to be on the call for some portion of it, but, yeah.
Ansgar Dietrichs:Thank you, Nixa, for… for doing that.
Ansgar Dietrichs:Awesome. See y'all in two weeks.
Ansgar Dietrichs:Bye.
Marius Van Der Wijden (M):Confused.
stokes:Goodbye.
Chat Logs
00:03:55
parithosh:Did anyone check if we have an overflow bug at ACD #256?
00:04:07
Potuz:barnabas: post one of those flaming gifs
00:05:29
Fireflies.ai Notetaker B:B invited Fireflies.ai here to record & take notes. By continuing, you agree to https://fireflies.ai/privacy.
Type:
'/ff pause' - pause recording
'/ff leave' - to stop recording
View Realtime notes here: https://app.fireflies.ai/live/01KMJCZMBSR7PK4RH227RYAKHK?ref=live_chat
00:05:49
felix (eest):Replying to "B invited Fireflie..."
you would not believe your eyes
00:06:44
marek:@Barnabas Nethermind ePBS devnet changes: https://github.com/NethermindEth/nethermind/compare/epbs-devnet-0
00:07:44
Barnabas:Replying to "@Barnabas Nethermind..."
Thank you
00:08:33
Stefan Starflinger:shoutout to rafael for such a nice tool 🔥
00:09:02
parithosh:Its gated access since we only have a few runners, they all need to be a specific type of machine
00:09:21
Rafael Matias (skylenet):https://benchmarkoor.core.ethpandaops.io/
Most EL core devs should be able to login via github auth.
00:10:03
Giulio:“{"error":"user \"Giulio2002\" is not authorized: no matching role mapping found”}” :(
00:10:19
marek:Replying to "“{"error":"user \"Gi..."
same
00:12:06
Rafael Matias (skylenet):Replying to "“{"error":"user \..."
please retry. Added you and marek
00:13:03
marek:Replying to "“{"error":"user \"Gi..."
works, thank you!
00:13:51
Ben Adams:Replying to "“{"error":"user \"Gi..."
{"error":"user \"benaadams\" is not authorized: no matching role mapping found"}
00:14:04
Martin | ethrex:Replying to "“{"error":"user \"Gi..."
Add “mpaulucci” too plz
00:14:22
Luis Pinto | Besu:Results for Besu look outdated for main given our recent runs on MOD related ones
00:14:56
Rafael Matias (skylenet):Replying to "“{"error":"user \..."
added you both too 👍
00:15:19
Butta:https://x.com/EFprotocol/status/2031056150427242892?s=20
https://gasrepricing.com/
00:21:00
Rafael Matias (skylenet):I haven't tested this much in light mode btw :D I prefer dark mode xD
00:21:19
Giulio:This is amazing!
00:21:43
DanielVF - Monad:Very cool
00:21:58
Marius van der Wijden:Replying to "Results for Besu l..."
Yep sorry they might be old numbers
00:22:00
parithosh:This one’s got Rafael’s handiwork all over 😄 I think rest of us just reviewed if anything <3
00:22:13
Butta:amazing eips if you ask me 🤓
00:22:21
DanielVF - Monad:Am I misunderstanding, but is the new per storage slot access cost of more than the cold access read cost itself? So using access lists is defacto dead.
00:22:44
Bosul Mun:https://hackmd.io/@bosulmun/HyifHDRcZl
00:23:07
Rafael Matias (skylenet):Replying to "This one’s got Ra..."
It got a lot of help from Nethermind too that pionereed the benchmarking efforts with their gas-benchmarks repo. Also shoutout to them. Specially Kamil, which whom I spent a lot of chats with to get benchmarkoor to this point 🙏
00:23:46
parithosh:Replying to "This one’s got Rafae..."
100%, standing on the shoulder of giants 🙂
00:23:47
Marius van der Wijden:https://docs.google.com/presentation/d/1ui9lPlbyxVnA36vB0EGk577XZhTRgriMDeWO0DfiTdg/edit?usp=sharing
00:26:13
Fabio Di Fabio:not from Besu
00:26:30
Fabio Di Fabio:we will look at it
00:26:47
Ben Adams:Nethermind will look into it also
00:28:16
lightclient:https://hackmd.io/@matt/frame-mempool
00:28:18
lightclient:ICYMI
00:30:38
Potuz:Replying to "https://hackmd.io/@m..."
Strategy 3 can leverage ePBS builders as paymasters.
00:30:43
Giulio:Dont we have lodestars before schemed tx intro?
00:30:55
Giulio:Sorry etherm-js
00:31:20
Giulio:I can go first no issue, just out of order in the agenda
00:31:21
lightclient:possibly sry didnt check order on agenda
00:31:21
Ansgar Dietrichs:Replying to "Dont we have lodesta..."
yes, I’ll briefly ask for an ethereumjs update before handing to you if that’s okay
00:31:34
Giulio:Replying to "Dont we have lodesta..."
Ofc
00:31:44
Lumi | Offchain Labs:Lfg @Derek Chiang
00:31:58
Parthasarathy Ramanujam:Replying to "https://hackmd.io/@m..."
Naive question, How is reputation managed for ePBS builders?
00:32:25
Parthasarathy Ramanujam:Replying to "https://hackmd.io/@m..."
Paymasters will require stake/reputation management to avoid them DOSing the mempool.
00:32:27
Potuz:Replying to "https://hackmd.io/@m..."
nothing specified yet
00:34:52
Barnabas:@Chris - Base what alternative you plan on shipping?
00:35:04
Derek Chiang:Replying to "@Chris - Base what a..."
https://eips.ethereum.org/EIPS/eip-8130
00:35:33
Ansgar Dietrichs:EthereumJS: https://github.com/ethereum/pm/issues/1970#issuecomment-4116337595
00:37:42
Danno Ferrin:Wasn’t post-quantum the reason we are even discussing frames? It’s the first line in the motivation section. We’ve discussed basically everything but post-quantum cryptography in the pros and cons.
00:38:01
lightclient:I don’t really think you build VERIFY frames on top of schemed txs. VERIFY is the core of frame tx
00:38:19
jvn:Replying to "Wasn’t post-quant..."
There is also native AA
00:38:38
Parthasarathy Ramanujam:Replying to "Wasn’t post-quantum ..."
Native AA is needed irrespective of what PQ signature scheme is chosen for Ethereum EL clients.
00:39:14
DanielVF - Monad:I think PQ support is the easiest part of a frame.
Frames are essentially orthagonal to PQ.
00:39:49
Danno Ferrin:Replying to "Wasn’t post-quantum ..."
Right, my argment being we should update the motivation and be hones about why we are doing it.
00:40:35
Giulio:Replying to "I don’t really think..."
You can
00:40:47
Giulio:Replying to "I don’t really think..."
Just add a new scheme_type and add a verify extension
00:41:16
lightclient:Replying to "I don’t really think..."
but how do you have multiple verify frames for sender and payer?
00:41:40
lightclient:Replying to "I don’t really think..."
there are so many different ways to handle this that schemed tx is too rigid
00:41:49
Giulio:Replying to "I don’t really think..."
You still can
00:42:24
Parthasarathy Ramanujam:Is every scheme implemented as a new precompile? That is almost the same complexity as a new transaction type, no?
00:42:29
Giulio:Replying to "I don’t really think..."
What can verify frames do that an extension cannot do
00:42:45
Giulio:Replying to "Is every scheme impl..."
You already do that in frames
00:43:04
Giulio:Replying to "Is every scheme impl..."
Like - this is not getting solved in frames either
00:43:15
Parthasarathy Ramanujam:Replying to "Is every scheme impl..."
Not until you add support for PQ.
00:43:27
Giulio:Replying to "Is every scheme impl..."
Its the same
00:43:36
Parthasarathy Ramanujam:Replying to "Is every scheme impl..."
Precompiles for PQ is needed regardless of the decision on Frames
00:43:49
Giulio:Replying to "Is every scheme impl..."
Yeah exactly, it is the same
00:44:03
Łukasz Rozmej:Is the testing team fine with complications between FrameTransactions and Focil while delivering them in the same fork? Normally we avoided this kind of complexity creap in same fork.
00:44:08
FLCL:Is any pq signature prod ready?
00:44:24
Giulio:Replying to "Is any pq signature ..."
Dilithium or what I added into the EIP
00:44:34
Łukasz Rozmej:Replying to "Is the testing team ..."
@Mario Vega?
00:45:20
Danno Ferrin:the sponsor address is currently written into the frame
00:46:03
Chris - Base:All of these work in 8130 as well which is why we are pursuing it
00:46:13
Chris - Base:Given the state of 8141 + our timelines
00:46:17
lightclient:Replying to "I don’t really think..."
looking at it again, i guess you can do verify frames as an extension
00:46:20
CPerezz:Replying to "Is any pq signature ..."
Sphinx Dillithium and Falcon are all NIST approved and there’s a solidity coded by ZKNox. Antonio Sanso worked on it
00:46:32
Giulio:Replying to "I don’t really think..."
Yeah, just more targetted
00:46:45
Giulio:Replying to "I don’t really think..."
You don’t need to shove everything into a single proposal
00:46:58
Danno Ferrin:Replying to "the sponsor address ..."
To preserve privacy by removing the frame target we would need to do some signature changes to prevent signature substitution attacks. Dragan’s Composable Transaction (EIP-8175) has a very nice solution to this
00:47:24
lightclient:Replying to "I don’t really think..."
VERIFY is what we are aiming to deliver though. schemed tx doesnt provide anything over what we can do today
00:48:11
lightclient:Replying to "the sponsor address ..."
we have been discussing this a lot more and i think we are beginning to be open to moving signatures up to the root of the tx
00:48:28
lightclient:Replying to "the sponsor address ..."
we want aggregation to work both on protocol level signatures and in signatures used during evm execution
00:48:57
Filip - Biconomy:any contract that's managing funds / value can become a "paymaster"
say you start with usdc and want to swap via uniswap, pool contract could become a paymaster where output amount can be used to cover for gas as well.
Privacy pools is a cool use case, but in general any protocol could offer a gasless experience via verify/frame
00:49:37
Danno Ferrin:If each signature was given a unique hash (function of prior sigs or position for example) signautre substitution attacks are nerfed.
00:50:13
Fredrik:What about transaction assertions? It’s an important security feature for many users and it seems to be possible to do this quite elegantly in Frame Transactions. Can SchemedTransactions do this without adding more complexity to the protocol?
00:50:40
lightclient:Replying to "What about transacti..."
i assume it can it needs yet another exetension
00:52:00
frangio:https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8
00:52:01
Derek Chiang:Vitalik’s AA writeup: https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8
00:52:30
felix (eest):Replying to "Is the testing tea..."
frame tx will be a lot of work for us (but doable), and focil is not that difficult IMO
00:53:05
Łukasz Rozmej:Replying to "Is the testing team ..."
yeah but have you looked into their interaction?
00:53:25
Milos:Replying to "Is the testing team ..."
https://ethereum-magicians.org/t/focil-native-account-abstraction/27999
00:53:42
Jihoon:Replying to "Is the testing team …"
I am more than happy to help regarding the interaction. Please feel free to reach out, if needed!
00:53:47
Carson | STEEL:Replying to "Is the testing team ..."
I will bring it up at our meeting later today for discussion so that we can look over the particulars
00:54:22
CPerezz:Replying to "Is the testing team ..."
The worst part of Frame vs. Schemed is mempool validation and statelessness interaction.
ZKEVM stateless nodes will not be able to neither manage mempool nor help as includers in FOCIL.
00:55:07
CPerezz:Replying to "Is the testing team ..."
Arbitrary state validity rules are a mess for stateless clients. With 300GB state is fine. With 4TB we’ll see how many people holds state when they can not.
00:55:13
lightclient:yes the point of the mempool strategy doc is to convey that the public mempool can be quite restrictive in the beginning if this is the sticking point for accepting
00:55:28
Ansgar Dietrichs:As someone who has worked on native AA all the way back in 2020: I think it’s obvious we need to do (something like) frame txs eventually.
maybe it’s not urgent enough for H*, but it is the right principled approach
00:55:55
Filip - Biconomy:can someone clarify the "native batching" point for erc20 approvals and frames, mentioned earlier?
00:56:03
Cyrus:Replying to "As someone who has..."
If Frame solves AA fully and finally and the opportunity window is there, why wouldn't we go forward with it now? What's to be gained by waiting?
00:56:05
Alex Forshtat:Replying to "Is the testing team ..."
There has been a number of "partial statelessness" proposals that seemed to mitigate the "4TB" issue, I believe.
00:56:30
Barnabas:Replying to "As someone who has w..."
imo there is no reason to wait and have no headliner.
00:56:40
Jihoon:Replying to "Is the testing team …"
That's why FOCIL imposes further restrictions on Frame transactions to be included in ILs.
00:56:46
Mario Vega:Replying to "Is the testing team ..."
We’ll look at the interactions, we don’t have an answer at the moment, thanks for bringing this up
00:57:35
Nico Consigny:Replying to "As someone who has w..."
I do think it's quite urgent to be able to audit verifiers and have execution governance DeFi DAOs able to move their contracts to PQ. They are the main target that you would attack. So Frame has many many reasons to get in. And one somewhat time constrained reason to get in now
00:58:04
Jihoon:Replying to "Is the testing team …"
Frame transactions in ILs don't do arbitrary state validation; it will be a bit more restricted than the mempool rules for them.
00:58:33
CPerezz:Replying to "Is the testing team ..."
The problem is that if you have arbitrary state dependent validity conditions for txs. Then is impossible to not need the full state in order to validate txs and therefore maintain mempool or be an includer
00:59:10
DanielVF - Monad:Replying to "can someone clarif..."
Since a frame transaction can include multiple actions / contract calls, you can have two calls inside one transaction:
DIA, approve() to defi protocol
defi protocol deposit()
00:59:15
Danno Ferrin:Transaciton composability as seen in schemed transaction first appeard in Composable Transactions, EIP-8175
00:59:37
Łukasz Rozmej:Replying to "Is the testing team ..."
So FrameTransactions are not friendly to lightclients? You either have state or not able to verify transactions?
00:59:53
frangio:Replying to "Transaciton compos..."
schmidhubered
01:00:06
CPerezz:Replying to "Is the testing team ..."
Lightclients, stateless clients (ZKEVM), partial stateful clients, VOPS..
Anything that doesn’t have full state has severe issues.
01:00:10
Filip - Biconomy:Replying to "can someone clarif..."
yeah but why do we even call that out? isnt that the default property of frame txs in general? I thought that's some special case / work done on erc20 approvals more tightly coupled with frame txs on a low level
01:00:16
Parthasarathy Ramanujam:Hard disagree here. Why isn’t it necessary now? Why frames is the best we have, why not ship it as a headliner.?
01:00:28
Jihoon:Replying to "Is the testing team …"
It's not arbitrary state dependent validity conditions. See the runtime check in the article above.
01:01:07
lightclient:i know there is time pressure to choose headliner, but we do have >12 months before hegota to get this finished
01:01:08
Chris - Base:So no headliner just potentially delays it (but could still be included in h*) correct?
01:01:18
Csaba:Replying to "Is the testing team ..."
I don’t think we need to allow arbitrary combinations. It’s perfectly fine to say that if you want the IL mechanism to protect your transaction then you have to stay within limits on the verification.
01:01:30
Ladislaus:Hat auf "i know there is time..." mit 👍 reagiert
01:01:32
Jihoon:Replying to "Is the testing team …"
(FYI, I'm talking about those in ILs strictly.)
01:01:37
CPerezz:Replying to "Is the testing team ..."
That applies only to the txs you shove into ILs right? Not to overall validity conditions. These are imposed by frame txs EIP. Not by focil
01:02:06
Ansgar Dietrichs:if verification remains enshrined, we will never be able to natively support privacy pools
01:02:34
Pedro:Technically we can add precompiles in the future on top of VERIFY frames
01:02:50
Giulio:Replying to "Technically we can a..."
Thats schemed tho then
01:03:14
lightclient:Replying to "Technically we can a..."
it seems like we are debating the means more than we are debating the goals?
01:03:16
Orca 0x:on the breakout yesterday an additional EIP was mentioned which would allow delegation to precompiles which would then be called during verification. this felt like a good companion
01:03:32
Orca 0x:Replying to "on the breakout yest..."
(I don’t think this EIP has been written yet)
01:04:08
lightclient:frames gud
01:04:19
Nico Consigny:Replying to "frames gud"
Frames gud
01:04:23
Vitalik:Replying to "on the breakout ye..."
https://eips.ethereum.org/EIPS/eip-7819 is not exactly that, but a good companion
is
01:04:42
Cyrus:For those saying "no", please explain why.
01:04:54
lightclient:it seems like clients do want to do AA, we’re just debating what exactly it is. IMO that is the most clear sign for headliner?
01:05:27
Trent:Are we weighting non-client teams who would be largely impacted here? Eg. AA ecosystem
01:05:39
Barnabas:Sounds like lots of teams have people that are sold and people that are not yet sold.
01:06:06
Danno Ferrin:So no to headliner but frame is still eligible as a regular EIP for Hegota?
01:06:07
Ben Adams:Replying to "it seems like client..."
No, cos we wanted to do encrypted mempools but rejected due to what exactly not being firm
01:06:13
Dragan Rakita:Replying to "Sounds like lots of ..."
Contentious EIPs usually fail
01:06:55
Michael:2 in favour, 1 no, and the rest in the middle, no?
01:07:01
Parthasarathy Ramanujam:Why do we see such a large disconnect between client teams and the AA community. The community want this badly, but client teams are undecided. This is disappointing
01:07:14
Cyrus:What's the objection? Only Besu expressed a reason. What are the others saying?
01:07:16
lightclient:would clients be supportive of saying AA is the headliner and we figure out if schemetx or frame tx is the correct approach?
01:07:24
Danno Ferrin:Replying to "Why do we see such a..."
Welcome to ACD
01:07:31
Łukasz Rozmej:Replying to "it seems like client..."
I think it might tie our hands if we want to go with other directions. It has huge complex when it comes to interactions. My intuition is a lot of them are yet uncovered.
01:07:51
Ansgar Dietrichs:Replying to "would clients be sup..."
my understanding is schemetx is specifically not AA, no? because it doesn’t abstract the account / verification part
01:08:12
Derek Chiang:Replying to "it seems like client..."
But we can only discover them if we try implementing it, no?
01:08:28
lightclient:Replying to "would clients be sup..."
i think we can make VERIFY inside scheme tx if we need
01:08:34
Jvn:Replying to "Why do we see such..."
IMO I think AA ecosystem should be given some weight outside of the clients too !
01:08:40
Giulio:Replying to "would clients be sup..."
That would be more likely
01:08:41
DanielVF - Monad:Another thought is minimal frame transactions, with only EOA/key support. This would be radicly simpiler, give us payer seperation, batch transactions.
This would give us a lot of what we would gain in the short term with very restricted mempool rules.
This would then be forward compatible at the client side.
01:08:54
Łukasz Rozmej:Replying to "it seems like client..."
sure, but we don't have to make it headliner for that
01:08:56
Milos:Replying to "it seems like client..."
Yes, a lot are uncovered, but frames are the most flexible approach
01:08:58
Chris - Base:Base is planning on native AA via 8130 in the ~near term
01:09:03
Luis Pinto | Besu:Nothing stopping from prototyping and do devnets with geth
01:09:13
Pedro:I would like to second Ahmed’s thoughts
01:09:19
Ben Adams:Replying to "it seems like client..."
Yes, but that discovery and prototyping isn't headliner?
01:09:20
Cyrus:Replying to "Another thought is..."
Go big or go home. Half measures haven't worked in the past.
01:09:32
Ahmed Al-Balaghi:Replying to "Another thought is m..."
exactly
01:09:58
Vitalik:Replying to "Another thought is..."
The full EIP is not that many lines of spec code. So I don't see why nerf it in the EIP
Nerf it in the mempool, so that people who want more things can make their own mempool
01:10:21
Jihoon:Replying to "it seems like client…"
All opinions here are valid IMO. It would be quite different if this decision were to happen in 2 months later.
01:10:57
DanielVF - Monad:Replying to "Another thought is..."
I think the nerfed mempool approach is reasonable.
01:11:04
Danno Ferrin:Replying to "it seems like client..."
What Jhoon said, i think the big issue was the compressed time frame.
01:11:05
Ben Adams:Replying to "it seems like client..."
We are happy to prototype and help with this discovery
01:11:58
Giulio:Which clients would rather do schemed and then attempt adding verify frames as an extension?
01:12:01
Ansgar Dietrichs:Replying to "would clients be sup..."
I think process wise we can only select frame txs today - but you as champion can offer to be open to changing course once selected, based on feedback
01:12:48
nixo:Replying to "would clients be sup..."
actually, the process that Tim laid out last year allowed us to choose something generally
01:12:58
nixo:Replying to "would clients be sup..."
we haven’t used that yet, but it was explicitly in there
01:12:58
Ansgar Dietrichs:Replying to "would clients be sup..."
yes but there was no such proposal
01:12:59
lightclient:Replying to "would clients be sup..."
^^
01:13:04
Giulio:Which clients would rather do schemed and then attempt adding verify frames as an extension? bump
01:14:08
lightclient:I’m good to accept AA and not frames and contniue working on the details
01:14:12
Potuz:Replying to "would clients be sup..."
this does not make sense: there seems to be overwhelming support from the whole community (including core devs) on the urgency of AA and the fact that it *will* be ready for Hegota
01:14:50
Derek Chiang:Do we have enough conviction to say that client teams should start prototyping Frames to build more conviction?
01:15:08
Ansgar Dietrichs:what we CAN do is say we reject frame txs as headliner, not select a headliner, but commit as ACD to prioritize AA this fork
01:15:12
lightclient:IMO AA eips are never "firm"
01:15:23
lightclient:too many different parties and constraints we are juggling to make happy
01:15:50
Fabio Di Fabio:I like the idea of working on frame tx as normal EIP
01:16:40
Pedro:100%…. We don’t need a firm AA solution… but we need a singular AA solution!
01:16:47
Jihoon:Replying to "Do we have enough co…"
How is the bandwith of EL teams?
01:16:53
Ben Adams:We have to implement something exact not something vague though
01:16:54
FLCL:Is there a list of all those features requested to be implemented in some potential AA
01:17:08
Vitalik:Replying to "Is there a list of..."
I have my list in that doc that was linked here an hour ago
01:17:23
lightclient:we just need to be brave
01:17:31
Giulio:Replying to "we just need to be b..."
milady
01:17:51
lightclient:Replying to "we just need to be b..."
milady
01:17:58
accountless:Replying to "Is there a list of..."
https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8
01:18:23
Cyrus:There is a major disconnect here. I'm hearing massive support for AA (in some form), but then when you poll the client teams, there's all this non-specific skepticism. Why are they skeptical?
01:18:29
Ladislaus:Hat auf "we just need to be b..." mit ❤️ reagiert
01:18:43
Danno Ferrin:Replying to "There is a major dis..."
the cleint teams have to do the actual work
01:18:51
FLCL:Replying to "Is there a list of a..."
ty!
01:19:07
Cyrus:Replying to "There is a major d..."
"It's complicated" isn't a valid objection, though.
01:19:23
Potuz:100% that, the whole point of "headliners" was to choose a theme and not a particular implementation
01:20:14
lightclient:+1 pedro
01:20:19
Danno Ferrin:Replying to "There is a major dis..."
As two words no, but when you look into all the things it could break, work needs to be done to make sure it doesn’t leave the protocol in a worse place than it was before. “It’s complicated, let’s not YOLO it”
01:20:23
Chris - Base:So if thematic AA then even potentially 8130 if is demonstrated cleanly with good adoption on Base/L2s
01:20:34
Derek Chiang:I think it will be good for PR for Ethereum if we “break the process” by selecting native AA as a headliner, because that would show how much we as a community care about native AA, as we should
01:21:03
Carson | STEEL:Replying to "There is a major dis..."
"It's complicated enough that we're not confident we can deliver" seems a fair objection.
01:21:09
shazow:Is something becoming a headliner a one-way immutable decision? Can we like... try it out as a headliner and there's too much regret down the line, we can revise its status?
01:21:17
Milos:native AA as headliner
01:21:23
Ben Adams:So the implication is we don't ship H* until AA is in?
01:21:44
Michael:When would the cut off to decide a specific implementation be if Native AA was to be chosen as a headliner?
01:22:00
Derek Chiang:Replying to "So the implication i..."
IMO, yes
01:22:01
stokes:lets ship it
01:22:02
Łukasz Rozmej:Replying to "we just need to be b..."
"hurry up, before we all come to our senses"
01:22:04
Luis Pinto | Besu:Regardless of what that may be? This feels worse than shipping frame txs because there’s even more uncertainty
01:22:09
Ahmed Al-Balaghi:Ship it
01:22:15
Cyrus:Replying to "There is a major d..."
Yeah that's fair, but the client teams should say that explicitly. That's not what I'm hearing.
01:22:17
lightclient:Replying to "Ship it"
ship it
01:22:27
stokes:Replying to "Ship it"
ship it
01:22:28
Danno Ferrin:Replying to "There is a major dis..."
But they have
01:22:33
Barnabas:Replying to "Ship it"
ship it
01:22:41
Łukasz Rozmej:Replying to "we just need to be b..."
its a joke and a quote btw ;)
01:22:44
Lumi | Offchain Labs:Replying to "Ship it"
ship it
01:22:45
Rene:Replying to "Ship it"
ship it
01:22:56
Ladislaus:Hat auf "Ship it" mit 🚢 reagiert
01:23:19
Łukasz Rozmej:Replying to "Ship it"
"hurry up, before we all come to our senses"
01:23:31
Milos:Replying to "So the implication i..."
I would say. If we don't do it now, we don't do it in few years (because of zkEVM)
01:23:45
Rene:Replying to "So the implication i…"
Good
01:23:56
parithosh:Or we come to a quorum and decide to remove it if we cannot reasonably deliver frame txs for info we gain in the future
01:24:07
parithosh:We did this with multiple headliner style EIPs in the past
01:24:28
parithosh:e.g blobs + withdrawals, peerDAS/pectra as a whole and so on
01:25:01
Potuz:We can still do this even for Glamsterdam if ePBS is not fully ready on time, process is not immutable, it's fine to declare AA a headliner, there is overwhelming support. If it's not ready by the time FOCIL is fully tested, we can take it out
01:25:59
Derek Chiang:I’d say we select Native AA as the headliner, and we acknowledge that we will start with prototyping Frames, but could end up with a different EIP as the fork progresses
01:26:18
wolovim:FOCIL is the precedent for CFIing (rather than SFIing) a headliner
01:26:54
FLCL:Choosing headliner sounds like something symbolic, if you need it let's use it as headliner. If objective checks during implementation prove it is a failure we can decline it
01:26:54
Barnabas:We need to put AA as a headliner
01:27:14
Łukasz Rozmej:Replying to "We need to put AA as..."
"hurry up, before we all come to our senses"
01:27:51
Potuz:I think this also affects CL teams and I think we should support choosing themes for headliners without a specific implementation in mind
01:28:03
Ladislaus:Hat auf "We need to put AA as..." mit 👍 reagiert
01:28:38
marek:Replying to "We need to put AA as..."
I like the idea of putting AA as the headliner ;)
01:29:17
Nico Consigny:We can say Frame or Schemed transactions if "native AA" is too general ?
01:29:32
Dragan Rakita:Asking team opinion on new strategy decision at moment notice imo is not great
01:29:37
Jeevan (jvn):Replying to "We can say Frame o..."
scheme tx wont come under AA ig
01:29:47
Łukasz Rozmej:Replying to "We need to put AA as..."
I still have PTSD from 3074 & 7702
01:29:55
Chris - Base:Decision abstraction
01:29:59
Giulio:Replying to "We can say Frame or ..."
You can extend schemed to do same thing as schemed
01:30:03
Giulio:Replying to "We can say Frame or ..."
*frames
01:30:59
Ben Adams:CFI+ :)
01:30:59
felix (eest):there is no decision, i love you
01:31:25
fe:Let the filibuster continue
01:31:27
nixo:no CFI, just commitment to having an “AA” category as a priority for non-headliner CFIs and could also then e.g. prioritize it for devnets
01:33:13
shazow:For people who are opposed, it would be helpful to get some commentary about what would have to change in order to accept this as a headliner
01:33:28
parithosh:+1 from me as well
01:34:51
Łukasz Rozmej:IMO we can make it headliner in ~4-5 months when it is prototyped and a bit tested if that will be healthcheck then
01:36:02
Barnabas:Would it make more sense to schedule it now, aim high, then remove it later, if its really that bad?
01:36:08
accountless:these client teams haven’t given reasons to counter the arguments for native aa as a headliner aside from they udnerstand it is for motivation but dont' understand what it means. and so if they don't know what it means how do they know it shouldn't be a theme
01:36:10
lightclient:what if we make it headliner now and decide in 4-5 months if we want to keep it ;)
01:36:19
Ladislaus:Hat auf "Would it make more s..." mit 👍 reagiert
01:36:24
nixo:sounds like the best consensus is prioritize AA as a non-headliner, potentially “promote” it later on
01:36:32
Derek Chiang:@Ansgar Dietrichs are we going to express any public commitment for client teams to start prototyping work on native AA?
01:36:43
Jihoon:Replying to "IMO we can make it h…"
Can we derive enough and sustainable resources for that end?
01:36:48
lightclient:CFI+ ?
01:37:02
Lumi | Offchain Labs:Replying to "CFI+ ?"
CFI+
01:37:05
Pedro:Realistically if ACDE makes it a headliner it will motivate AA teams to spend resources to implement it
But if we don’t then many companies will not be able to allocate resources to a big MAYBE it will get included
01:37:27
nixo:i am against CFI - it didn’t go well for FOCIL
01:37:38
nixo:it was confusing
01:37:39
Barnabas:didn’t focil make it in as CFI?
01:37:46
Łukasz Rozmej:Replying to "Would it make more s..."
My philosophy is not to sign on something I forsee potential issues with. I prefer not to have a battle when we find something dealbreaking comes up.
01:38:01
Iván | ethrex:Replying to "CFI+ ?"
CFI+
01:38:46
FLCL::lfg:
01:38:57
Derek Chiang:@Ansgar Dietrichs can you clarify for everyone not familiar with the process what CFI actually means?
01:39:04
lightclient:we just have to be brave guys
01:39:13
lightclient:we can ship the strawmap
Summary
14 highlights
· 3 decisions · 2 action itemsExperimental
Summary
14 highlights · 3 decisions · 2 action itemsExperimentalfork status and schedule
repricing updates
testing progress
account abstraction
- Frame tx mempool doc published; 3 strategies outlined, Strategy 2 recommended00:28:16
- Frame tx adds native batching with atomic revert across frames00:30:38
- Scheme transactions (EIP-8XXX) proposed as simpler AA alternative00:37:37
- Strong community support for AA; clients divided on headliner timing01:03:12
eip 8070 sparse mempool
- EIP-8070 CFI'd; Geth prototype complete, feedback requested from other clients00:22:16