lightclient:Okay, I think it's probably good to go ahead and get started.
Transcript
lightclient:Just posting the agenda… Here in the chat.
lightclient:I added a couple items, I think a few people added, some things to discuss on… the…
lightclient:on the issue, but also just trying to make a lot of space for people to ask questions and, you know, further discuss the proposal. Hopefully we can
lightclient:try and move forward past some people's, like, concerns about the EIP.
lightclient:But with that said, I think a good place to start here is to talk a bit about this proposal that Derek from
lightclient:from Zero Dev, came up with pretty recently.
lightclient:When we were talking last week on All Core Devs, there were…
lightclient:you know, I think two main complaints about…
lightclient:8141, the first one was…
lightclient:People being concerned about whether or not 8141 is going to get adopted, at what pace is it going to get adopted?
lightclient:etc. And so…
lightclient:Derek had a nice idea, which to me feels like it would resolve some of these concerns.
lightclient:Which is that… we add support for EOAs natively in the frame transaction.
lightclient:And when we originally wrote the frame transaction.
lightclient:Our expectation was that it was, like, this in-game transaction type. It was focused only on accounts abstraction. You needed to have code deployed into your account to utilize it.
lightclient:And we've… we didn't really see a clear path to also supporting ULAs at the time.
lightclient:I think Derek has put together a nice EIP around how this can be supported, and, like, the simple idea is that if there is not code deployed to the account which the frame transaction is trying to verify.
lightclient:then we can put in place some default account. And, like, the shape of this default account is, you know, definitely up for question. You know, it could be EVM code, it could be a pre-compile, it could be extremely minimal, it could have some bells and whistles.
lightclient:That's, like, definitely a question.
lightclient:But I'm… Curious if people have had a chance to think about
lightclient:think about this PR, think about adding EOAs to the frame transaction, and if that would
lightclient:Alleviate some of people's concerns about
lightclient:the adoption story for frame transactions.
lightclient:Also, I see Derek's here, I don't know if you have other things you wanted to say on…
lightclient:on the PR.
Derek Chiang | ZeroDev:You know, I think, I think I'll just wait for some questions first,
Derek Chiang | ZeroDev:I think you said most of it, but the biggest motivation, like you said, is basically that in our, commercial.
Derek Chiang | ZeroDev:endeavors, you know, as a company to push for the adoption of AA. The single biggest
Derek Chiang | ZeroDev:blocker is really just the fact that, with, for example, ERC437, right, you know, like, you really have to be using a new account.
Derek Chiang | ZeroDev:to take advantage of that, right? You know, so 99% of existing EOA users
Derek Chiang | ZeroDev:or, you know, rather, 99% of existing Ethereum users, well, OUA users, cannot reap the benefits of that. So that's why there has been a strong inertia to, not adopt AA.
Derek Chiang | ZeroDev:So I think our firm transactions happen to be designed in a way that, actually, if you look at the proposal, even if you look at the PR, actually, it doesn't take much change to the spec to support UA. You know, I think that's the thing we realized
Derek Chiang | ZeroDev:So I think, like, by supporting your aides.
Derek Chiang | ZeroDev:which essentially just means that with firm transactions, with these updates, EOAs can now send sponsored transactions, right? You know, whether that means being sponsored by the dev.
Derek Chiang | ZeroDev:Or meaning the US can pay gas in ERC20 tokens, like USDC and USDT, I think that's gonna be, you know, just make firm transactions so much more impactful than if it did not support US.
Derek Chiang | ZeroDev:And they will also get the community so much more excited, because now, like, all users, right, like, across all wallets can,
Derek Chiang | ZeroDev:can… can support that. You know, can, you know, can bring the benefits of AI to their users.
ivo Georgiev @ ambire:I have a few questions about that. So, first of all.
ivo Georgiev @ ambire:Isn't it possible to use frame transactions with 7702?
lightclient:Absolutely.
ivo Georgiev @ ambire:Yeah, so that makes sense, but you still require… but you still want to…
ivo Georgiev @ ambire:add another ERC where there's some default code, for your ways, in a frame transaction. Would this default code
ivo Georgiev @ ambire:also be, observable outside of the frame transaction? Like, if I do a regular EOA transaction, and someone reads the code for this EOA, would it return, this default code? Because that implies, like, this implies a pretty big change to the network. Like, every address is a contract now.
Felix (Geth):We don't… we don't… I don't think this is what we…
Felix (Geth):what we're going for. I think it's more about introducing the notion that
Felix (Geth):like, first of all, I'm not super in favor of adding this functionality to the transaction, but I think even if it was added, the only sensible way would be to just make it so that there are specific semantics that activate when the account has no code. But we're not just gonna give every account code.
ivo Georgiev @ ambire:Okay, so, if I understand correctly, Derek, correct me if I'm wrong, the account will have called
ivo Georgiev @ ambire:if it's a new way without code, or without a delegation, and you are running in a frame transaction, and maybe some other condition, or just those conditions, because I think, honestly, I think it would be…
ivo Georgiev @ ambire:Yeah, Nethermind. Yeah.
ivo Georgiev @ ambire:Only those two conditions, right? Frame transaction and a new way.
Derek Chiang | ZeroDev:That's right, yeah, you know, so, like…
Derek Chiang | ZeroDev:Felix said, oh, we're not actually defining code in the EVM assembly code sense, you know, like, like, it's more so that, like, if you really read the PR, it's actually very simple, you know, it's literally just saying that, like, oh, if the target of a frame is, has no code.
Derek Chiang | ZeroDev:then the client should do the following, you know, so it's more like client behavior rather than inserting code into the EOA. And by the way, just to be clear, this is not like a separate EIP or ERC, it's just updating the spec to say that 8141 supports EOAs.
Parthasarathy Ramanujam:So it's just for that particular transaction, or the code that gets used is persistent across future transactions as well.
Derek Chiang | ZeroDev:So again, you know, we are not actually inserting code into the account. So it's literally just saying that if…
Derek Chiang | ZeroDev:the target of frame has no codes, then we… we… the client assumes that the UA behaves in a certain way, you know, so… so yeah, so the answer, it doesn't carry over to the future transactions.
ivo Georgiev @ ambire:Check light client's comment. She thinks of it more as, temporary set code for AOA, just for the context of the transaction.
ivo Georgiev @ ambire:Got it. Not outside this transaction, so I think, yeah, I think that makes sense. I do like this idea, but I think, in practice, it has a lot of overlap with the possibility of the account simply having code thanks to 7702.
ivo Georgiev @ ambire:I mean, to put it in other words, maybe a bit too… a bit too brutal, but to put it in other words, if 7702 adoption, was going the right way, this EIP wouldn't be needed.
lightclient:You mean this PR wouldn't be needed?
Felix (Geth):the PR for temporary code, in case of a frame transaction.
lightclient:Yeah, I mean, I
lightclient:feel like 7702 provides the function, you know, majority of this functionality with 8141 that we were looking for. This is why originally we weren't
lightclient:Posing to add?
lightclient:EOA support in 8141, because we kind of just imagined that people would use 7702.
lightclient:I think a lot of wallets are, but for whatever reason.
lightclient:Some wallets choose not to. Like, Ravi chooses not to use 7702 at all, even in, like, a simplified manner. And a lot of users don't upgrade their wallets, even if the wallet supports 7702.
lightclient:I think there's a lot of factors at play here.
lightclient:But if it's… if it's pretty minimal to add a default account in 8141,
lightclient:And it gives us an ability to kind of, like, improve the EOA
lightclient:experience with frame transactions over time, then, to me, this is good, and it solves a lot of the complaints that people are having, and I think that it matches
lightclient:a lot of the other proposals that have been coming around, things that are, you know, of the format of the Tempo-style transaction.
Felix (Geth):Sorry, maybe one quick comment about this, so… the… the… mmm…
Felix (Geth):I think the only reason… the only reason why we should consider adding support for EOAs is just to make it possible for people to use frame transactions with all accounts, without having to do another special operation to upgrade their account into a smart account. And so this…
Felix (Geth):Like, for me, this would be coming more from the angle that it should just work, like, the frame transaction should be possible to target, like, any account.
Felix (Geth):Because otherwise, it's a bit weird. It's like a niche thing where you need to have a smart account. I mean, smart accounts are pretty common, but it's still, like, if this transaction type can only be used with specific accounts.
Felix (Geth):makes it less useful, so that's why… I think that's where this whole debate is coming from. Should we add some kind of default path for the current accounts?
Derek Chiang | ZeroDev:Yeah, I think… I think, I think, I also think we should not underestimate the… the friction of…
Derek Chiang | ZeroDev:like, because with 7712, it's not just that you have to create a delegation, but also that you have to pick a account implementation, right? I think that's actually a big reason, you know, from my conversation with someone, is why they have not adopted 7712, because, you know, like, you know, MetaMask, for example, they have the…
Derek Chiang | ZeroDev:the resources to build your own, you know, audited account implementation, right? But not all wallets do. And by the way, like, wallets today are not just
Derek Chiang | ZeroDev:big wallets like MetaMask, right? Like, like, like, if you are kind of, like, in the wallet space, you, you, you, you know that there are, like, a lot of, like.
Derek Chiang | ZeroDev:applications today that are actually, basically, like, wallet, right? You know, like, they don't call themselves, like, wallets, but they actually embed a wallet into their application so that, like, the users, they store funds on the application, right? So for those, like, really long-tail
Derek Chiang | ZeroDev:or just, like, mid-tail players, kind of, like, auditing their own accounts, you know, and, like, picking, like, an account implementation can feel pretty scary. So I think, like, you know, I want to echo the comments in the thread, which is basically saying that, like.
Derek Chiang | ZeroDev:like, good defaults are really important, right? You know, like, so if, like, just by default, all accounts just have a guaranteed bug-free way to do gas abstraction, to pay gas in ERC20 tokens, to be sponsored gas, I think that's actually super impactful, you know, and it's guaranteed to be bug-free, because it's guaranteed by the protocol.
lightclient:Evo.
ivo Georgiev @ ambire:So, I would say that in practice, one of the… one of the big drawbacks, one of the big reasons why 7702 isn't getting that adopted.
ivo Georgiev @ ambire:is, yeah, of course, what you said, picking default implementation, etc, just lack of understanding, but also the lack of support from hardware wallets. This is changing, but…
ivo Georgiev @ ambire:What this EIP will introduce is, first of all, an escape hatch from this. So, when hardware wallets implement frame transactions, which they definitely will.
ivo Georgiev @ ambire:This problem gets solved automatically, so we no longer need them to convince… to whitelist specific implementations and etc, which has been quite a pain.
ivo Georgiev @ ambire:But then, on the flip side, this might completely kill their incentive to fix this problem, which, honestly, I don't think…
ivo Georgiev @ ambire:is… I think it's a good trade-off.
ivo Georgiev @ ambire:Because all users get batching and paymaster capability by default, but then again, implementation… there is no incentive for hardware wallets to whitelist new 7702 implementations anymore. But I think it's a good trade-off.
lightclient:No, that's a good point.
lightclient:Any further comments or questions on this?
lightclient:I feel like it seems there's a lot of support in general to add the default account.
lightclient:I guess there's two points saying that 8141 basically makes 7702 obsolete.
lightclient:I don't know if I would say that. Like, to me, 7702 is still a part of the smart account migration, like… like Derek says. And I think I would have felt more uncomfortable with a default Ethereum
lightclient:smart account, if users also didn't have the choice via 7702 to delegate to any type of smart account they wanted.
lightclient:So I kind of think that they work nicely, together.
lightclient:Felix.
Felix (Geth):Yeah, I just wanted to quickly mention that for us, we see it as the long-term strategy that, for now, 7702 remains supported, but in the long run, because 7702 is not
Felix (Geth):Post-quantum secure, it will have to be turned off.
Felix (Geth):And so… or we need to find an alternative to it.
Felix (Geth):And this is something that has not really happened. At the moment, we are… in our thinking, we have this… this notion that
Felix (Geth):with the frame transaction, you can always deploy a new account, which doesn't have any ECDSA key attached to it.
Felix (Geth):or you can take your existing account and you can turn it into a smart account by creating a delegation using 7702. And then at some point, we want to introduce a mechanism that
Felix (Geth):Allows you to make this delegation permanent and unchangeable.
Felix (Geth):So, basically, you can…
Felix (Geth):you… at that point, you would have your account delegated, and then you would just either mark it, like, not delegatable any further, or something like that, and it would be fully upgraded, and there would be no more link to the existing ECDSA key.
Felix (Geth):Or, alternatively, we can just…
Felix (Geth):I mean, I think delegations are just gonna stay in the protocol forever, because people have created delegations now, and they need to keep working, but the mechanism for introducing new delegations is something that we still control. I do think that in a world where
Felix (Geth):Friend transactions exist, and…
Felix (Geth):you don't really… for new accounts, you don't really need 770.2. You can just create your smart account, and…
Felix (Geth):Never worry about this whole delegation thing.
lightclient:Yep, agreed.
lightclient:I guess before we move to more topics, I'm curious if…
lightclient:the addition of this EOA default account.
lightclient:sways any people's opinions around their feelings on how 8141 will get adopted.
lightclient:Do people feel kind of the same still, or is this something that you think is going to improve adoption of 8141? Increases, like, your opinion on this as a headliner?
Chris - Base:Yeah, I think a big boost.
Chris - Base:EOA support, I think, yeah, get everyone
Chris - Base:You know, using these standards, and then…
Chris - Base:We can worry about actually, you know, turning off all of the quantum risked.
Chris - Base:teachers.
Chris - Base:Like, 7702, etc.
lightclient:No.
lightclient:Cool.
lightclient:Anyone else?
lightclient:Okay. I think we still need to…
lightclient:decide the exact format that the default ELA interaction's gonna look like.
lightclient:And that's going to be some ongoing work over the next few weeks.
lightclient:Happy to have as many people weigh in and contribute to that. We'll do it in the open on GitHub and AA Mafia and the Aether9D Discord.
lightclient:But I think that I'm pretty convinced that we need to do something here, and it's just a matter of, like, finding the right solution that everybody feels good about.
Chris - Base:I think, just to add on this, I was playing around with,
Chris - Base:kind of this… a similar idea, but not just for EOA, and I think this comes back to,
Chris - Base:some of the design work I did on another different transaction type, but… And also kind of a topic I want to discuss later on. But,
Chris - Base:Obviously, when using EOA, we have, like, the native, code to verify that
Chris - Base:Transaction signature, like, instantly, versus running,
Chris - Base:arbitrary code execution for wallets at random addresses. So I think there's, like, potential to…
Chris - Base:Almost add a, like.
Chris - Base:maybe it's a new mode, I'm not sure, we need to kind of, like, think about that, but yeah, a verify frame that…
Chris - Base:enables some… you know, Look up into some canonical…
Chris - Base:key store or something for the account, and that can use native implementations. This is, you know, coming from…
Chris - Base:Us wanting to be able to instantly verify transactions, kind of in the early days, rather than having to run arbitrary code, trace it, and then make a decision on if
Chris - Base:You know, it conforms to our rules.
Chris - Base:So this is kind of like, yeah, native, and then it would basically look up at some
Chris - Base:yeah, canonical key store for the account. I don't know if that's, like, a… we want… we, like, prefer that in a contract. I think a contract does make sense, because then…
Chris - Base:Nodes can optimize, you know, just keeping that… that state as the instant validation
Chris - Base:state. It's a much smaller set than, like, you know, having to store every contract.
Chris - Base:across…
Chris - Base:the entire, kind of, space. So, really, you just store that canonical contract, which would have the key, information for accounts, and then basically that native verify step is just, like, instant. It would be, kind of, the main path for,
Chris - Base:the majority of accounts, as long, you know, and we can kind of… they can use, you know, the precompiles that already exist. We don't have to, like, go crazy with key types or anything, but that would give us kind of,
Chris - Base:you know, P256 from 7212.
Chris - Base:Etc. But yeah, that's kind of the thinking there for native that I think could be powerful. And also, like, maybe that, canonical key store is, like… I know that's also kind of a proposed solution to eventually marking an EOA as disabled.
Chris - Base:So, yeah, I think that's, like, an area that, we should explore.
lightclient:Are you saying that you think this is an area to explore for the default DOA account?
Chris - Base:So…
lightclient:I think that…
Chris - Base:Yeah, I think it's more of a, like.
Chris - Base:technically, I think the, like, default account in this is more like, well, if there's no code, we will…
Chris - Base:you know.
Chris - Base:it's not necessarily a default code, it's just if there's no code, we will do an EC recover, for an EOA.
Chris - Base:and similar… I don't think there needs to be no code, but there can be, like, an indication of, like, maybe it's a new frame type, like, native verify, or a mode, and this is where I'm not, quite sure on the best approach, but basically, like, you can imagine a new frame type, which is, like, native verify.
Chris - Base:And then in that, Frame, it just specifies, like, if the…
Chris - Base:account has a configuration at this location for this type of key, then we can do a native verify, and that, like…
Chris - Base:Just enables the kind of node performance and transaction validation.
Chris - Base:that, I think, Early on would be great to have.
lightclient:Felix?
Felix (Geth):Just, I want to give a quick, comment here, because I was also concerned with this while,
Felix (Geth):working on the EIP. And so, the way the EIP is structured now, this can be accomplished by directly targeting the verification frame to a pre-compile. And I think this is an underexplored area, kind of, but I think it would be something that
Felix (Geth):we can…
Felix (Geth):we can also use. So instead of having, like, a special frame type, it's just more that, like, the,
Felix (Geth):what you, so one thing to understand about the EIP is that, when the approval of the sender happens in the EVM,
Felix (Geth):It happens through the approve opcode, and the approve opcode has a definition that says this opcode can only be used if this is running in the context of the
Felix (Geth):F…
Felix (Geth):transaction sender account. But if a pre-compile were to be used, it doesn't have to adhere to this…
Felix (Geth):same semantics.
Felix (Geth):So it's kind of equivalent. And I kind of left that in because I felt that it would just…
Felix (Geth):Also, allow us to reuse the existing extensibility mechanism that we have.
Felix (Geth):Which is the precompiles to enable new key types to be deployed.
Felix (Geth):And then, basically, we just give a…
Felix (Geth):It's like a fast path for the authorization.
Chris - Base:Yeah, I think that's exactly what I'm thinking. I think the only, like, last piece of that puzzle is, like, you know.
Chris - Base:are all these key types going to be, EC recover… like, sorry, recoverable? And I'm not sure… it seems like we need some sort of…
Chris - Base:Location for, kind of… I don't know…
Chris - Base:If it's a public key, or it's probably, like, some sort of hash on, like.
Chris - Base:You know, to actually fully verify, especially with PQ being the goal, like, yeah.
vitalik:Yeah, I think, I mean, most forms of cryptography are not recoverable, and, I think one other nuance there that kind of makes the whole recovery concept, in my opinion, even more long-term dead is that, we want to,
vitalik:batch, like, signatures off-chain using Starks, right? Like, and, like, this is the whole thing that, the, like, verify frames are… this… are designed for, and, like, you just have to do it if you want to avoid, like, 3 kilobytes of, call data overhead per transaction. And once you do that, then, on, like, there literally isn't enough entropy on-chain
vitalik:to do any recovering, and, and so we pretty, like, I think we pretty much have to switch over to this, kind of, like, address has to be explicitly specified frame.
vitalik:Yeah, I mean, so, sorry, I feel like my internet was, wonky, and I came in halfway through your suggestion. Like, your suggestion was basically to try to find ways for accounts to basically, like, directly make precompiles their validation code, right?
Felix (Geth):To be fair, this was my response to an earlier…
vitalik:Okay.
Felix (Geth):Proposal that was given by… Who was it again?
Chris - Base:That was me, Chris.
vitalik:Yes, exactly.
Felix (Geth):I didn't see your name on the screen anymore. So yeah, Chris gave this, gave this suggestion that maybe we could add a frame type that would give this native validation.
Felix (Geth):Because we were talking for the start of the call a lot about this, possibility to add support for EOAs, which would be…
Felix (Geth):Yeah, like, basically accounts which do not have any code, and making it possible, for them
Felix (Geth):To participate in this whole… frame transaction.
Felix (Geth):floor.
Felix (Geth):So, various things, but I think Chris's suggestion also came from the perspective of just having the increased performance. I mean, people do really worry a lot about the performance of this.
vitalik:Right.
vitalik:Yeah, so, yeah, so I guess, yeah, thinking about, like, the delta between, like, the status quo approach, right, where essentially, yeah, a, like, a minimal account, something like, like, if you want to make a SecB R1 account, then,
vitalik:it would basically have to, like, load storage, or load the public key from local storage, right? Then it would call into the R1 precompile, and then, it would basically return accept. I guess,
vitalik:like, that feels like a very small amount of EVM execution, right? Like, I would guess that's probably, like, literally less than 100 instructions, and so…
vitalik:like, I'm curious, yeah, like, how much that problem is, right? Because, I mean, obviously, yeah, if it's… if it's a huge problem, then there's a, yeah, kind of natural,
vitalik:solution, which is basically that you take one of the other EIPs that I think… I think, like, I proposed this a couple months ago, where basically it's like native delegation, right? And, like, accounts can basically use an EOF type to just specify another account as,
vitalik:As their contract code. And, if you, like, add one bit to that, then you can, like, basically, yeah, say, like, your account is, a,
vitalik:in…
vitalik:account, like, a standardized accounts wrapper around, stuff… around some other thing, so it's, like, doable, but yeah, I'm curious, like… because, like, I feel like if we…
vitalik:if we're seeing, like, 100 steps of EVM code execution as a large problem, then, like, that feels like something that has to be addressed more broadly, and, like,
vitalik:Yeah, I'd be curious about that.
Chris - Base:I think just coming from, like,
Chris - Base:performance perspective, like, with transactions coming in, we're kind of in this… in the EIP in its current form, it's like, we're in this situation where we need to simulate
Chris - Base:In order to know if we…
Chris - Base:you know, should store it in the mempool if it validates any kind of 7… ERC7562 related rules or anything.
Chris - Base:Whereas, like, ideally, in, you know, in the current state, we can kind of, like, quickly make a decision, and…
Chris - Base:I think that even with, like, you know, factory deployments, etc, like.
Chris - Base:There's a lot of service area for, like, basically, yeah, just, you know, wasted compute that,
Chris - Base:It is hard to, manage, like, effectively, I guess.
vitalik:Right, but, like, the wasted… Yeah, like, the wasted compute here is, like, literally 100 EVM, steps, potentially, right? Because it's basically wrapping up recompile. So, like, this is what I'm curious about, like, is, like, is it high overhead for you despite that?
Chris - Base:Well, I mean, without using, like, you know, precompiles or anything, like, I know we could set gas limits, etc. on transactions coming in, but, like.
Chris - Base:You know, it could be transactions that call into a factory, like, transactions kind of do need high gas in order to…
Chris - Base:do things.
Chris - Base:And that's kind of it. Yeah, we're in this state where we need to run… we actually need to simulate the transaction. It can, you know, up until it's paid for and approved. So it's actually… it can be quite a bit of gas.
Chris - Base:And that's on every transaction incoming.
vitalik:So we wanted to… Right.
Felix (Geth):So this is now going into this general direction, which, let's just make it official that what we're talking about now is, like, the performance of
Felix (Geth):the approvals, and specifically this in the context of the mempool, but also in, yeah, in general. And I think this is something where we have to
Felix (Geth):in some ways, it's, like, inevitable that under account abstraction, the cost of validating a transaction is higher. I think we just have to acknowledge that the current state of things, where we just have to recover a signature, is very, very cheap compared to
Felix (Geth):anything else that we could be doing. So, it's like, it is pretty much guaranteed that the cost will increase, and we have to…
Felix (Geth):Be… aware of that.
Felix (Geth):And so…
Felix (Geth):what we're trying to do with the frame transaction is just basically give users this way of saying, yeah, your signature can be whatever you want, but obviously, you have to be able to realize that within some gas limit. And especially if we're talking about the mempool validation, there isn't going to be that much gas available. So this will put a…
Felix (Geth):bit of, cap on what is actually possible to do in practice inside of an Approval flow, because…
Felix (Geth):Yeah, like, many things that are really, really nice are not gonna be so easily possible.
Felix (Geth):And we just know that. There's just no other way, because…
Felix (Geth):that's just how it is with account abstraction. We can't allow people to do arbitrary amount of computation before the transaction is considered valid.
Felix (Geth):So, I think what this is gonna be about is just finding a good compromise where we give people enough flexibility to do the things they want.
Felix (Geth):but also give them the ability to do it within a low amount of gas, so that it's possible to accept these transactions in the public mempool. But most importantly.
Felix (Geth):if you're talking… we're talking about the public mempool. There is the possibility of creating specialized mempools, or to have other arrangements to get transactions included that do not adhere to this
Felix (Geth):validation gas limit, and I think this is something that's really important for us, that the scheme should always support this. You shouldn't be limited by this low validation gas, which is available in the mempool when it comes to placing your transaction in the block. It's just that for relaying the transaction over the network before it's included on-chain, we have to be much tighter with the limits.
Felix (Geth):So, I just want to preface this whole discussion saying, like.
Felix (Geth):Yes, it's important to consider the performance, but… It will be… More expensive with account abstraction.
lightclient:Any other comments?
Felix (Geth):Derek is commenting, saying that
Felix (Geth):there should be a standard frame structure for the public mempool. We kind of see it like that also, so the mempool has several choices, to restrict,
Felix (Geth):the transactions, and as a policy, I think
Felix (Geth):One, of course, we will have
Felix (Geth):some kind of validation gas limit, but also I think the mempool will only support specific frame structures that make it… that are, like.
Felix (Geth):supported by it. So, yeah, there will always have to be a verify frame first, and then
Felix (Geth):one or more center frames, but we might even
Felix (Geth):Yeah, I mean, we laid it out a little bit in the EIP, also, what are the possible, like, we gave some examples there of, like, certain transaction flows and what their frame structure is going to look like, and we think it's quite important to have
Felix (Geth):To have the mempool validate that only these specific structures are used.
Brian Bland:How is that impacted by the initial frame that would deploy code?
Brian Bland:Like, if a transaction in the mempool for an account that does not yet have code deployed.
Brian Bland:We now have the, like, an arbitrary code deploy frame before verify.
Felix (Geth):Matt, I think you had that in the e-book.
Felix (Geth):Right?
Felix (Geth):don't we have this in the EIP? Like, this.
lightclient:Yeah, there's an.
Felix (Geth):employment floor.
lightclient:How this… how this works in the rationale section of the EIP.
lightclient:I was just trying to see if I could pull it up to send here.
Felix (Geth):Yeah, so there are basically two flows for the regular transaction. One is if you want to deploy an account, that's equivalent to, like, a create transaction now, that you could do now, and then the other flow is one where
Felix (Geth):you already have a smart account, and you are sending directly to that smart account, targeting the verified frame to that one. And these are the two… at minimum, these are the two things that have to be supported.
Felix (Geth):By the mempool.
Brian Bland:Sorry, I guess my…
Brian Bland:Question, though, was more about the fact that we have arbitrary, like, the range of arbitrary
Brian Bland:Pre-validation, interactions then increases in scope.
Brian Bland:Because now we're including this arbitrary code deploy.
vitalik:Yeah, I think, like, the memcool could whitelist, like, potentially, literally, like, one… like, two or three, or even one proxy, right? It's, like, the proxy people use already, and maybe the EIP7997 proxy, if we decide to add that in.
lightclient:Yeah, I mean, we're not allowing arbitrary code execution there, we're just kind of expanding the things that we allow them to do to, like, deploy
lightclient:you know, some code. And if that code tries to call out to other state elements, then the transaction pool can, like, cut it off at this point.
Chris - Base:Yeah, I think the single allow-listed,
Chris - Base:deployment that's just, like, deploys bytecode and doesn't, like, run init code or whatever, kind of should fix that problem.
lightclient:Yep.
Felix (Geth):So there's a concern by Luis in the chat saying that, like, this seems to be, like, Swiss Army knife, but at the same time, we have to restrict it. I think it's kind of always been this way, somehow. So, yes, we're giving people the ability to do whatever they want inside of their verifications.
Felix (Geth):But at the same time, for the mempool, the requirements are just very different, because we cannot allow transactions that will ultimately become invalidated easily, and things like that. So the mempool environment is just inherently different, so we have to see that what's
Felix (Geth):What's allowed there is not necessarily
Felix (Geth):Like, it's always gonna be much more restricted.
vitalik:Yeah. And, like, this is the approach that Bitcoin has used, basically. It's the beginning, right? Like, it's had a, a scripting language for, for transactions, and, it's, like, every single transaction has, like, at least
vitalik:effectively, like, 10 steps of Bitcoin VM execution that are wrapping the usually sick P verification. But then there's, like, what the VM supports, and then separately there's this concept of standard transactions, which are not part of consensus, but they, are part of default memory rules, and that's been historically restrictive, and, like, sometimes it expands, sometimes it is,
vitalik:Sometimes it even restricts. And, like, that model, like, it feels… like, within the Bitcoin world, it's a relatively known thing that has worked.
Felix (Geth):Okay.
DanielVF - Monad:Yeah.
DanielVF - Monad:Oh, go ahead.
Felix (Geth):No, no, I was just gonna say, who has more questions, but… Okay.
DanielVF - Monad:Yeah, so this is a hybrid kind of response for this topic and what's next on the agenda. But a real quick intro on myself. I've been building on Ethereum since 2017 as a lead smart contract developer and security person for 3 different 9-figure DeFi protocols.
DanielVF - Monad:And, I've been deeply involved in the security side of, Ethereum. I've been helping, protocols with CO911 since it started.
DanielVF - Monad:But I'm very concerned that framed transactions are repeating the same mistakes that have hurt the previous account abstraction attempts.
DanielVF - Monad:on ETH Magicians in one of the early post on Frame transactions, it was talked about a trade-off between building something that
DanielVF - Monad:for users' use cases versus building low-level primitives to build what users need.
DanielVF - Monad:But fundamentally, I think providing nearly infinite flexibility
DanielVF - Monad:Particularly on a per-account basis, is the same as exposing that user to nearly infinite danger.
DanielVF - Monad:as other people on this call have mentioned, even some of the biggest wallets are justly scared to implement 7702 or 4337. I mean, there's just a huge cost to getting a contract that's bulletproof, and even,
DanielVF - Monad:Major providers have had things showed up in their contracts.
DanielVF - Monad:Later on, after being deployed.
DanielVF - Monad:A second con… cost of this flexibility-first approach is that it provides a bad user experience. Both 7702 and 4337
DanielVF - Monad:Have added enough user friction to cripple their adoption, even though, in theory, it seems like it's a little tiny bit of
DanielVF - Monad:Friction. It just, in reality, that what they have is too much.
DanielVF - Monad:So, so much flexibility is actually a downside
DanielVF - Monad:From my point of view, not,
DanielVF - Monad:an upside. I'm really glad we're looking at making frame transactions also able to provide a simple interface. I think that could really help.
DanielVF - Monad:But… Even if we have that simple interface, we're still building the infrastructure and code and…
DanielVF - Monad:Cutting off evolutionary trees that don't fit with the complexity that,
DanielVF - Monad:It provides in the worst case.
DanielVF - Monad:so… having a requirement for Turing-complete compute, plus access to all block state.
DanielVF - Monad:Just makes a lot of ways we might want to go in the future a lot harder.
DanielVF - Monad:Personally, I'm much more in favor of tempo-style transactions that provide a simple, standardized expression of what the user wants to do.
DanielVF - Monad:I think that'd be far more likely to see user adoption, much safer, no fragmentation.
DanielVF - Monad:And doesn't tie our hands for the future, as far as changes we want to make to Ethereum.
DanielVF - Monad:Yeah, that's, my opinions.
DanielVF - Monad:Thanks for listening.
Felix (Geth):So, we do have to know a bit more about these changes you might want to be making in order to understand your concern. Yeah.
DanielVF - Monad:Okay, so… Let's take asynchronous execution, which is something…
DanielVF - Monad:I'm now deeply familiar with, having recently started with Monad.
DanielVF - Monad:if you're executing transactions later, you don't know what goes into a block before you build the block, necessarily. And so.
DanielVF - Monad:Full access to state hurts that a lot.
DanielVF - Monad:It also feels like it comp…
DanielVF - Monad:Make censorship resistance harder, and that you have to build the, censorship resistance into,
DanielVF - Monad:Or, you know, you have to build your censorship resistance.
DanielVF - Monad:With this in mind, as opposed to separately?
DanielVF - Monad:Yeah.
Felix (Geth):Yeah, there are some comments, and also now, regarding the, developer experience, or, like, the frictions. You were talking before that there is some friction. I was curious about what this…
Felix (Geth):What these… what this friction is.
DanielVF - Monad:Okay.
Felix (Geth):So, you can maybe elaborate a bit on that.
DanielVF - Monad:Okay, I think the… The biggest two pieces of friction are, one.
DanielVF - Monad:When you do a 7702, you're basically
DanielVF - Monad:Trusting that account over to some…
DanielVF - Monad:Yet another piece of code. So you're adding another piece of code into the loop.
DanielVF - Monad:That essentially owns your funds
DanielVF - Monad:The second biggest one is simple as
DanielVF - Monad:It takes another transaction in order to set up.
DanielVF - Monad:And even though that seems like that should be so small, I bet that's… Is a tremendous
DanielVF - Monad:hamper to it, to its adoption. Again, very, very small, in the…
DanielVF - Monad:older days, you know, the gas cost of deploying a contract used to be something prohibitive, but I think that's less of a concern now.
DanielVF - Monad:But yeah, so, you know, one thing that is good about this frame transaction discussion discussion we're having right now is having a default
DanielVF - Monad:That at least removes some of that friction.
Felix (Geth):Yeah, so from our perspective, it's more about… also about finding a path
Felix (Geth):towards not requiring people to use so many different types of transactions, we ultimately see that
Felix (Geth):I mean, some of the…
Felix (Geth):Ethereum has had transaction types for a while now, but the thing with transaction types is that it always causes significant pain whenever a new transaction type is introduced, and we would rather just be able to say this transaction is the ultimate one, and we're not gonna change it again.
Felix (Geth):And in order to do that, it just has to be sufficiently general for us not to have to…
Felix (Geth):mess with it again. For example, when we were reviewing the TempoTX proposal, it basically just pulls in every single feature that Ethereum already has in existing transaction types, and then adds, like, 2 or 3 more. We don't really see, like… that's not really how it should be done. Like, what's the next one gonna be like? It's gonna be, like, even more complexity in the transaction, or…
Felix (Geth):Like, that's… for us, it was a big motivator to just say we can define a transaction that is actually simpler than what we have now.
Felix (Geth):But it achieves way more things. And yes, there's a lot of power that you technically have in this transaction, but it doesn't mean you always have to use all that power in every single transaction. Your account can be as simple as a
Felix (Geth):Little proxy that goes to a standardized key verification function, and
Felix (Geth):there's nothing unsafe about that. It's just that it gives you the option later to, for example, say, I want to migrate to a different key, or… but I want to keep my address, or…
Felix (Geth):things like that, or, you know, it gives you the gas sponsoring. So we feel like…
Felix (Geth):It's a good compromise. Yes, there is a lot of power there, but it's also kind of hard, like, constraining power in some ways is hard. So we chose instead to just say, yeah, when we can accept that people can do crazy things with this, but I don't think they will, because… or at least most people won't, because it would just be way too dangerous.
DanielVF - Monad:To some extent, you know, this may come down to a different sense of aesthetics, and so,
DanielVF - Monad:I do feel, you know, still the same way, but you know, as a…
DanielVF - Monad:long time, somebody building Ethereum applications.
DanielVF - Monad:Basically, frame transactions is exactly what
DanielVF - Monad:I would want the front-end guys building.
DanielVF - Monad:Because it's exactly what they want to do, basically.
DanielVF - Monad:I… I understand your desire for, you know.
DanielVF - Monad:never make another transaction type again. But…
DanielVF - Monad:I think that's a path that's likely to lead to
DanielVF - Monad:Actually finding out that you do need to add something else in the future, or…
DanielVF - Monad:Just, yeah, again, the complexity… hurting things. But yeah, you know, we can agree to disagree. Happy to…
Felix (Geth):Yeah, I guess so. It's just more about… for us, it's also just about not hard-coding the…
Felix (Geth):not hard-coding any of the, like, functionality inside of the clients. So, basically, our big goal with this transaction was that the signatures are completely removed from the protocol, and I think this is still one of my key things that
Felix (Geth):when I think about this proposal, I think this is one of the top things that I really, really like about frame transactions, why I got so excited about it, because it gives us the ability to just say, Ethereum.
Felix (Geth):technically doesn't…
Felix (Geth):like, the protocol itself doesn't really even know, like, what a signature is. It's all done by the user. And…
Felix (Geth):In some ways, that's good, because, you know, like, in 10 years or so, you can…
Felix (Geth):there's gonna be different signature schemes, and we… the transaction never really has to be aware of that anymore after this proposal. We can still add these primitives to the protocol in the form of precompiles, or we can provide, other means of accelerated execution, or
Felix (Geth):Things like that, but ultimately, the… the…
Felix (Geth):the signature itself is no longer going to be a key element of the transaction. It is somehow contained inside there, because it's an input to the computation, but the protocol doesn't really know what that input is.
DanielVF - Monad:And, so, yeah.
DanielVF - Monad:What's the fundamental difference between,
DanielVF - Monad:adding a new cryptographic system to the EVM versus adding a new cryptographic system at the transaction level.
Felix (Geth):I mean, the key thing is just that it is more flexible in some ways, because it can be used, by anything, it doesn't have to be on the transaction, so, I mean, it's like, people have… do things in contracts, and
Felix (Geth):The other thing is that we kind of see it in the long term that, I mean, if you were asked, like, I personally think precompiles are an okay compromise, but not everyone sees it that way, so there are also people who are saying, yeah, precompiles are kind of… were kind of a bad idea, and
Felix (Geth):we should just make the EVM fast enough for people to be able to do anything they want, without having to rely on these precompiles.
Felix (Geth):whether or not you see it that way, it's a different debate, I guess, but…
Felix (Geth):What, basically, we're trying to say is that, like.
Felix (Geth):the frame transaction gives you the ability to do whatever you want in the EVM. You can use the fast paths, which we provide, and we can provide more fast paths as the world develops, but ultimately, we wanted
Felix (Geth):To give people the opportunity to
Felix (Geth):Handle it how they want to handle it.
Felix (Geth):And I think that's, like, that's a key difference, whereas, like, if you have it on the transaction, it's like, you have this, like, menu of choices, and this menu has to keep being extended.
DanielVF - Monad:Yep, although, at this point, we're, you know, we're extending it with
DanielVF - Monad:You know, more than a decade of hindsight.
DanielVF - Monad:As to what
DanielVF - Monad:But yeah, I don't want to take everybody else's, anybody else who wants to comment's time, but also, I'd love to answer any questions about my own personal opinions on this.
DanielVF - Monad:If anybody else has them, or if anybody wants to…
DanielVF - Monad:You talking ETH magicians or anything?
lightclient:Thanks, Daniel.
lightclient:We've got about 8 minutes left.
lightclient:Just kind of a couple things we haven't really discussed on the agenda. I don't know if people feel super strongly to discuss the post from Georgios or alternative proposals.
lightclient:to the… to the transaction EIP.
lightclient:If so, raise your hand. If not, I think we're also happy just to finish out the call with more questions and comments about frame transactions.
Felix (Geth):There is something,
Felix (Geth):I just want to quickly highlight, there was a comment earlier, and this was also given on ACD.
Felix (Geth):It's about, it was given by Dano, and it's about the, it's about the…
Felix (Geth):batch validation of signatures. So, this is a big topic, but I just want to quickly highlight it again, because it's one of the challenges that we also have in the design of this transaction type. So, as everyone knows, the post-quantum signatures are quite large.
Felix (Geth):And,
Felix (Geth):because of that, it might not be feasible for the block to always contain all of these signatures. And…
Felix (Geth):In order to… Reduce the size of the block.
Felix (Geth):There will have to be some scheme by which the…
Felix (Geth):Verification of these signatures is somehow proven in another way, and that proof somehow has to be attached to the transaction.
Felix (Geth):I'm being a bit vague, because we…
Felix (Geth):Don't really know exactly the details of how this will be accomplished, but there are some… this is more like a future…
Felix (Geth):topic, so basically we have to second-guess the future here, but we do see it as a…
Felix (Geth):big potential problem in general for the introduction of any post-quantum signature scheme on Ethereum for transactions.
Felix (Geth):I just want to give a quick overview of how we think this will be achieved through frame transactions, and
Felix (Geth):we have taken this account in the design in the following way. So, in the frame transaction, there are the frames, and one of the frame types is the verify frame. And we were very careful to design it such a way that the verify frame
Felix (Geth):itself cannot influence the outcome of the transaction's execution. It is only there to establish the proof of the sender. And because of that, it is technically possible to elide the content of the verify frames when the transaction is placed into a block.
Felix (Geth):But this is possible when The blog also contains some kind of proof
Felix (Geth):That states that the verified frames of the transactions were executed correctly.
Felix (Geth):I'm not 100% sure how this will be accomplished in the long term, But…
Felix (Geth):We will have to figure this part out.
Felix (Geth):We just think that, like, because of this ability to Remove the verify input data.
Felix (Geth):Because, I mean, so the thing is, like, even regardless of whether or not you run the verify frame, since it cannot modify the state in any way, it also cannot influence how the further frames of the transaction behave.
Felix (Geth):So it is actually possible to execute the verify frames in a different order, or batch them together, and do things like that. So this is something to keep in mind.
Felix (Geth):And I hope that Dano is on the call and finds this somewhat satisfactory, and I would also be happy to discuss it further.
Danno Ferrin - Tectonic.xyz:I'm here. Can you hear me?
Felix (Geth):Yup.
Danno Ferrin - Tectonic.xyz:So, let's look at EIP6404 and see what they've done with their setup.
Danno Ferrin - Tectonic.xyz:They've taken the transaction payload and the signature, and they've separated them to two top-level elements. Could a similar thing be done to the frame transaction, where the frames are in one top-level element and the signatures are in another, and instead of putting the signature in line, it's a reference by index to a list of signatures?
Danno Ferrin - Tectonic.xyz:That way, you could take just the payload and execute the payload, like you said, because
Danno Ferrin - Tectonic.xyz:You would just presume that the frames path, because if any frame fails, the whole thing fails when you're considering it, and then you rely on the execution layer or the other validations that include the transactions to prove that all of the attached signatures do, in fact present the claims that are claimed.
Felix (Geth):I mean, yeah, it's possible. I mean, it is… fundamentally, I think we were discussing a bit on ACD, it does require some restructuring in the EIP. I want to mention that the current EIP is not
Felix (Geth):very likely not how it will look in the final iteration. We really just wanted to put out a proposal to basically present the spirit of our approach.
Felix (Geth):But obviously, there can still be significant changes to the encoding of it. And one of the things that were discussed, for example, like you are saying, is maybe we should pack the call data a bit differently, so that it's possible to take it out.
Felix (Geth):like, the frame input data could be packed in a different way to make it possible, or the whole thing could be SC encoded, or whatever. Like, we will find some solution to this that makes it possible to remove the, this data without changing the transaction hash.
Felix (Geth):So we heard that point. I just really wanted to clarify here on the call that this is one of the open problems that we are still kind of thinking about how to best do this, but…
Felix (Geth):our answer to this general concern of, like, aggregating post-quantum signatures is that the verify frame specifically can be alighted in this way. And we think that it's a good enough foundation for us to build out this future
Felix (Geth):Transaction Signature Aggregation scheme.
Chris - Base:On that topic, like, with… because frames can have, kind of, arbitrary ordering.
Chris - Base:And can also see state across the entire EVM? Like, doesn't that kind of break this kind of top-of-block aggregation of signatures? Or I guess that's kind of the open problem.
Felix (Geth):No, I wouldn't say that. It's just that you need a proof of the validity of the verify frame. So, how this is achieved is a bit up to the…
Felix (Geth):I mean, yeah, we have to find a solution for it, yeah? I mean, we're kind of coming back, maybe, to this thing that we were discussing earlier, where…
Felix (Geth):You were also saying, like, it would be nice to have some kind of native verification, so if we had that, then yeah, we would have a much easier time aggregating that, because we would know exact… like, that's the whole… like, maybe this is also something general that should be said on the call.
Felix (Geth):The whole reason why we added the frames is because the frames give visibility into the user's
Felix (Geth):intent by way of splitting up the computation. Like, earlier account abstraction proposals worked by basically adding a new opcode to the EAVM that said, pay the gas to the Coinbase now.
Felix (Geth):or they would have another, like, these kinds of things. So then, basically, the whole transaction would just be a single input, and you would basically execute it in the EVM, and at some point, the validity of the sender and the gas payment would be established by the EVM as it was executing. And these proposals got shut down because it is not possible, really.
Felix (Geth):for the protocol to operate like this, we need some visibility into the user's intent. We need to know this is the code where the validity is going to be established, and this is the gas limit for it, and so on. So that's why we came up with the frame transaction, to basically chunk up this computation in a specific way, which gives us these insights. And so I see it as, like.
Felix (Geth):If we progress on this, and we find that
Felix (Geth):It's basically not possible to do this, to do this… Aggregation…
Felix (Geth):use… with the generalized computation, well, then we just have to add, like, another kind of frame that makes it possible. But ultimately, the purpose of the frames is to chunk it up enough to make these things possible.
lightclient:We're one minute over time now. I think it's probably good for Frangio to go quickly, and then we can kind of wrap up.
frangio:Yeah, thanks. Just a quick comment, on the mempool thing that already came up in this call. I understand that there's a kind of separation about the mempool rules and the protocol rules.
frangio:But I… I…
frangio:this is my only, like, big gap about the CIP, and I think the issue is that from the perspective of
frangio:a smart contract developer or a dApp developer, I think it's kind of all the same, and there should be more clarity about what is or isn't allowed in the mempool, because that's what's going to be the rules for developers.
frangio:And I think that's really glossed over currently in the ERC.
frangio:With 772, there's a similar thing, right? With, like…
frangio:how there's only one outstanding 7702 deletion in the mempool, or transaction in the mempool.
frangio:I feel like we only found out about that later, at least I personally did.
frangio:And I think it would… like, I would be a little bit concerned that…
frangio:one of those things will also come up, you know, later, and that it's going to be a big issue with this one, which is a lot more complicated. Anyway, those are my thoughts. I think there needs to be more clarity about what will be allowed in the public mempool.
Felix (Geth):That's a very good point. We…
Felix (Geth):Yeah, we will surely work on that.
Felix (Geth):I do think that with 7702, it was also, from our end, was very frustrating, because we were aware of these concerns very early on. We hosted several sessions, also with client developers, trying to explain, like, so many times, over and over, that this is really complicated in the mempool, and it requires special handling, and so on. And then, very late in the process, everyone kind of found out, like, oh yeah, if we add 7702, there's gonna be some
Felix (Geth):And we were like, yeah, dope, like, we've been talking about this the whole time. So, it was a bit,
Felix (Geth):But unfortunate how this went. Yeah, with this proposal, that's why we chose to surface it very early on and say, you know what, this… in the mempool, there's gonna be some challenges to make this work, but it has always been a challenge to integrate a kind of fraction into the mempool, and
Felix (Geth):The 4337 proposal solved it by adding the mempool as a completely separate actor that would somehow simulate every transaction and figure out if it's compatible with a huge rule set.
Felix (Geth):I'm not sure if that's the answer, but we just have to…
Felix (Geth):Yeah, I mean, we will see, definitely. We are still currently exploring it ourselves, how it can best be implemented, and what the practical limits are in terms of the frame structure and in terms of the gas, so we will have these things
Felix (Geth):Figure it out, definitely.
lightclient:If you don't want to be surprised, I think that reviewing the ERC7562 standard that the 4237 team put together on the transaction pool for 4237 is a good place to start.
lightclient:Like, I don't think that we're going to have something that's going to be radically more…
lightclient:Capable or allowing than this, type of format.
lightclient:They have thought through a lot of the problems of doing this at scale in a decentralized network, and so if you are afraid of what's gonna happen, and you have no idea what the transaction pool could look like, this is gonna be a good place to start, and that's where we are also starting from.
lightclient:But I think, personally, for frame transactions, it's good for us to…
lightclient:Have the ability to, over time, add support for more things.
lightclient:I don't know if people feel strongly about this, but I think that if we can just get account abstraction onto the network, then we're going to keep solving these problems. If we continue to force ourselves to wait until every single
lightclient:use case that needs to be in a transaction pool solved, then we're probably going to constantly run into this, you know, catch-22, where people will say, well, how do you do X? And then someone proposes, and we don't have a production network to, like, actually test this stuff out on.
lightclient:So I do think that there is a lot of value in just making sure that we can do the important bare minimum things in the decentralized transaction pool, and then over time, continue to add more support for that type of stuff.
lightclient:We're 5 minutes over time now. I want to be respectful of everybody's time. A couple closing points I just wanted to mention.
lightclient:We're gonna discuss this proposal again on Allcore Devs, the Execution Layer Edition, next Thursday.
lightclient:if you are in support of it, if you're not in support of it, if you are from the community, this is, like, a great time for you to voice your thoughts more widely. Like, this was a nice breakout session, I think it's helped us formulate our understanding of how clients and other, you know, community groups are thinking of this proposal, but…
lightclient:All Core Devs next week is hopefully where we will make a decision on what the headliner for Hagota is going to be.
lightclient:So if you feel strongly about this, we would really ask that you come, and if you're in support of it, then I think it's especially valuable if you're a community member, because I think many client teams have voiced this question, like, does the community support frame transactions? And it's always somewhat difficult to expose that information, so…
lightclient:The most clear way that you could do that is just coming to all corporate devs and sharing your opinion, either in text chat or on voice.
lightclient:Okay, with that said, let's wrap this up. Feel free to message me directly, tag me on AA Mafia.
lightclient:or ETHRND Discord, and we'll keep working, figure out how to do the default EOA interaction, in the best way.
lightclient:And yeah, I'll see you guys next Thursday.
ivo Georgiev @ ambire:Thanks, everyone.
Parthasarathy Ramanujam:Thanks, Todd.
ivo Georgiev @ ambire:Excellent.
jvn:Thank you, Grace.
Chat Logs
00:05:21
lightclient:https://github.com/ethereum/pm/issues/1954
00:07:48
frangio:https://github.com/ethereum/EIPs/pull/11379
00:09:51
lightclient:Yeah I think I’m happy with how easy it is to support EOA in frame tx based on Derek’s PR. It also gives us some ability to continue improving EOAs w/o more tx types in the future
00:11:43
frangio:would this be equivalent to adding an authorization list to frame transactions, and including a delegation for the account in the same frame tx?
00:12:15
lightclient:I don’t see it like that. I think of it more like a ephemeral set code for the EOA just to orchestrate some validation and maybe a batch execution
00:12:31
Peter:Migrating an EOA to post-quantum keys will require 7702 (migration) + ecdsa key deactivation.
This proposed feature just allows EOAs to benefit from other features of 8141.
00:12:52
lightclient:Yeah we will also introduce a permanent SETCODE operation, but it won’t be a headliner
00:12:52
Nicolas Consigny:https://github.com/ethereum/EIPs/pull/11379
00:14:31
Nicolas Consigny:Replying to "Migrating an EOA to ..."
Yes these should be treated as two separate problems. You would still need the ecrecover modifications etc.
(I personally tried to bundle both at some point and it is ugly)
00:14:57
Barnabas:Replying to "https://github.com/e..."
sounds like a no brainer
00:14:58
DanielVF:Good defaults are extrodinarily imprortant.
00:15:29
Parthasarathy Ramanujam:Wouldn’t that make a user lazy not ever upgrade their account? We’ve seen this even with 7702, no?
00:16:21
Barnabas:Replying to "Wouldn’t that make a..."
The user shouldn’t need to know what EIP they are using imo.
00:16:43
ivo Georgiev @ ambire:Replying to "Wouldn’t that make a…"
They don’t need to upgrade their account with this setup
00:16:53
ivo Georgiev @ ambire:Replying to "Wouldn’t that make a…"
All accounts would get sponsorship and batchign
00:17:13
Parthasarathy Ramanujam:Replying to "Wouldn’t that make a..."
They don’t need to. But they will need to when PQ signatures goes live, no?
00:17:23
ivo Georgiev @ ambire:Replying to "Wouldn’t that make a…"
Yep
00:17:39
lightclient:Felix’s point is important about all account types being able to use 8141: the guarantees good support across many areas like dev tooling, apps, clear signing, etc
00:17:43
Doris Hernandez | Functor:Agree on Derek proposal to add EOA support in 8141 instead of using 7702.
00:17:54
Parthasarathy Ramanujam:Replying to "Wouldn’t that make a..."
Also, a user may continue to use regular EOA without using frames.
00:18:17
lightclient:Replying to "Felix’s point is imp..."
And hw wallets, good point
00:18:37
DanielVF:Agree, good tradeoff
00:19:03
Barnabas:8141 basically makes 7702 obsolete
00:19:05
jvn:with 8141 , does it make sense to drop 7702 ?
00:19:18
Derek Chiang:7702 is still important for eventual EOA -> Smart Account migration, right?
00:19:19
ivo Georgiev @ ambire:I wouldn’t say so
00:19:41
Derek Chiang:We just need an extra EIP to revoke EOA root key
00:20:09
Nicolas Consigny:Replying to "We just need an extr..."
https://ethereum-magicians.org/t/eip-7851-deactivate-reactivate-a-delegated-eoas-key/22344/24?u=colinlyguo
00:20:20
Doris Hernandez | Functor:7702 give EOA options to upgrade but from a UX perspective it’s not the best.
00:20:32
Nicolas Consigny:Replying to "We just need an extr..."
we reworked the eip to make it permanant
00:20:44
Nicolas Consigny:Replying to "We just need an extr..."
But we would also need to change ecrecover
00:20:49
ivo Georgiev @ ambire:Still plenty of reasons to use 7702
migration to SA / PQ accs
Conditional delegations
Extra signing keys, eg add a passkey
00:21:01
ivo Georgiev @ ambire:Conditional delegations = mm delegator
00:21:07
roy:EIP-7702 can be turned off only when EOA are turned off...
00:21:45
jvn:I see some cases where , If a 7702 delegation is active on my address, it has code which means the 8141 EOA fallback won't trigger right ?
00:21:53
ivo Georgiev @ ambire:And generally speaking it’s not very Ethereum to assume the default implementation will be sufficient for everyone and everything
00:22:09
ivo Georgiev @ ambire:Replying to "I see some cases whe…"
Correct
00:22:09
DanielVF:It's a big boost.
00:22:18
Parthasarathy Ramanujam:I think most of the people attending this call were already sold on 8141 :-)
00:22:51
Nicolas Consigny:We would also need other EIPs for the PQ migration we would need something like https://ethereum-magicians.org/t/eip-8151-private-key-deactivation-aware-ecrecover/27690?u=colinlyguo
And the EOA with a system contract https://ethereum-magicians.org/t/eip-7851-deactivate-reactivate-a-delegated-eoas-key/22344/24?u=colinlyguo
00:23:06
Lukas:need more apps to support eip5792 too. I think incentives are hardly there for wallets to do the effort to upgrade their users' accounts but gets more interesting if most apps are batching + sponsoring
00:23:53
Parthasarathy Ramanujam:@lightclient I’m curious. Earlier you mentioned considering making a precompile the default. How would that help?
00:24:21
Doris Hernandez | Functor:Very happy about the 8141, qq, how the signature validation will work? Currently with 7579 we use modules to validate a passkey, how will this happen with the 8141?
00:24:22
lightclient:Replying to "@lightclient I’m cur..."
It’s more a choice: do we want the EOA default account defined in native language (go, rust, etc) or in EVM code
00:24:32
Parthasarathy Ramanujam:Replying to "@lightclient I’m cur..."
Ah ok. Got it.
00:25:27
Brian Bland:Would we expect hardware wallets to meaningfully support 8141 smart account transactions if the account's code cannot be known offline?
00:26:11
Parthasarathy Ramanujam:How will signature verification work for default code with frames? Will eip1271 or 6492 signatures still be valid?
00:28:00
ivo Georgiev @ ambire:Replying to "How will signature v…"
It’s not really conflicting in any way. The ephemeral code will not be there while validating signatures
00:28:05
lightclient:Replying to "Would we expect hard..."
From initial talks with them, yes
00:28:07
ivo Georgiev @ ambire:Replying to "How will signature v…"
So you’ll just validate as a regular eoa sig
00:28:42
lightclient:Replying to "Very happy about the..."
You would verify the signature in a VERIFY frame by calling the user’s smart account and have it emit an APPROVE to denote it approves the operation
00:31:43
Derek Chiang:There was an iteration of my PR where VERIFY targets precompiles so we can have “passkey EOAs” via P256VERIFY: https://github.com/ethereum/EIPs/compare/master...derekchiang:EIPs:eip-8141-precompiles#diff-fa7f710dbdc2909318c31c817ef313f90df424946ea1a162d13406806b7f1d92R112
00:32:25
Danno Ferrin - Tectonic.xyz:If we are going to batch validations we need to put signatures in a place in the transaciton where trimming them off is feasable, not in-line as part of a validate frame.
00:33:02
roy:Relying on a precompile for verification frame means it requires a fork to deploy that new precompile for every alternative signature scheme.
One precompile that is a cood idea is ECRECOVER_VERIFY precompile, as it gives EIP-8141 batching capabilities to EOAs.
00:33:35
lightclient:Replying to "If we are going to b..."
I don’t see why this is a major issue? We already need to deserialize over the wire in the block builder to build the block then reserialize to share. Seems okay to elide the data field in VERIFY frames like this
00:34:02
Felix (Geth):Replying to "If we are going to..."
we will get to this on the call!
00:34:11
Danno Ferrin - Tectonic.xyz:Replying to "If we are going to b..."
It’s prone to errors. Something like what 6404 is propsoing
00:34:50
Felix (Geth):Replying to "Relying on a preco..."
I want to highlight that the precompile is not a requirement. It is just a way to get an account that uses the absolute minimum gas possible.
00:37:16
DanielVF - Monad:State is also a concern, not just the gas.
00:38:34
Derek Chiang:Do we think we should propose a standard frame structure for the public mempool? Like DEFAULT (deployment) -> VERIFY -> VERIFY (sponsor) -> SENDER(s)
00:38:51
Doris Hernandez | Functor:Replying to "Very happy about the..."
Ahh so instead having to use verifier module, we just use the verify frame ( I will assume that there will be “standard” verify frames for different signature schemes as passkey for example)
00:39:55
lightclient:Replying to "Do we think we shoul..."
You can see the frame structures we are currently imagining in the EIP rationale
00:40:23
jvn:we use Default Frame
00:40:26
jvn:to deploy first
00:40:57
lightclient:https://eips.ethereum.org/EIPS/eip-8141 example 1b in rationale
00:41:57
Luis Pinto | Besu:So to me it seems we are giving a Swiss Army knife for account verification but at the same time need to impose limits to what users can do. Has this been researched? How much gas is enough? How will that impact gas limits?
00:42:49
Derek Chiang:Replying to "So to me it seems we..."
The mempool rules are just for L1; L2s are free to do what they want and can potentially support very different frame structures
00:45:15
FLCL:stupid q: can new verification logic allow to escape simulation and provide different results on simulation vs execution, like if time passed is more than usual time spent on approve go steal all funds path?
00:46:01
lightclient:Replying to "stupid q: can new ve..."
Only if you somehow deployed a smart account that is malicious
00:47:45
Parthasarathy Ramanujam:Curious, How does Tempo transaction solve the said issues?
00:47:56
Derek Chiang | ZeroDev:@DanielVF - Monad wouldn’t most developers not be dealing with frames directly, but rather indirectly through account/wallet toolkits like Viem, which would provide sane defaults for frames?
00:50:34
lightclient:I don’t think async execution is currently on ethereum roadmap
00:51:17
ivo Georgiev @ ambire:I won’t take call time since it’s not completely on topic but I don’t agree re 7702 frictions and they sound like the poor perceptions that lead to its poor adoption
Saying “trusting another piece of code” isn’t really fair because this code is delegated by the wallet and the wallet alone, not by anything or anyone else. The wallet has thousands of security critical lines of code
00:52:04
ivo Georgiev @ ambire:The other point was “another transaction” - not really accurate. There is the authorization message but you don’t need an additional transaction. You do need an additional txn TYPE if that’s what you meant
00:52:49
v2:Replying to "I won’t take call..."
Also, 8141 protocolizes ~90% of the complexity of a smart contract wallet today, eg. if you want secp256r1, then it becomes just
assert(secp256r1(sighash(), calldata[0:65]) == sload[0])
00:54:09
Danno Ferrin - Tectonic.xyz:Replying to "I don’t think async ..."
On the Straw Map “Distributed Block Building” in CL longer term tasks has the same needs as async execution
00:54:18
Justin Florentine (Besu):far easier deployment
00:54:20
Luis Pinto | Besu:If you add precompiles we are back to square one. This needs protocol changes and support from core devs
00:54:53
Danno Ferrin - Tectonic.xyz:Replying to "I don’t think async ..."
Low level details for distributed building may be different from monad’s pipeline, but high level needs align.
00:56:16
FLCL:how well it will displayed as a sum of intents in wallets? eip example contains quite technical steps as frames
00:56:58
lightclient:Replying to "how well it will dis..."
This is mostly being handled by ERC-7730 clear signing
00:57:28
lightclient:Replying to "how well it will dis..."
The frame tx will also be support by 7730
00:58:09
lightclient:Replying to "how well it will dis..."
(If accepted ;))
00:58:26
Parthasarathy Ramanujam:I keep hearing that Tempo transactions are better than Frame transactions proposal. How Tempo transactions solves concerns people have with frame transaction. However, I cannot find a single technical write-up on why it is so? Only “trust me bro” posts. Can anyone point me towards such a write-up (if one exists).
00:59:30
DanielVF - Monad:Replying to "I keep hearing tha..."
I'll write it up in eth magicains
00:59:39
FLCL:Replying to "how well it will dis..."
for sure it should be
00:59:42
Parthasarathy Ramanujam:Replying to "I keep hearing that ..."
Looking forward to it.
01:01:43
Barnabas:so are we doing frame tx for hegota?
01:02:08
lightclient:Replying to "so are we doing fram..."
🚢
01:02:53
wolovim:Replying to "so are we doing fram..."
find out after this commercial break!
01:04:57
v2:we don't need another frame type for aggregation (if we can't aggregate evm), an opcode is better
01:05:05
v2:Because that way non-validation use cases can also take advantage of it
01:05:17
DanielVF - Monad:Agree strongly
01:06:01
v2:There is a decent case for doing it that way: if we aggregate ONLY signaures and starks, then we would be able to reuse the lean consensus infrastructure
01:06:57
frangio:FWIW I dont think it is clearly stated in the EIP
01:07:38
DanielVF - Monad:One of my concerns with Frame TX's is from working with 7702. 7702 seems so simple on paper, but adds a lot of fractal complexity everywhere it touches.
01:08:54
Barnabas:Replying to "One of my concerns w..."
nobody argues that frame tx is going to be an easy implementation tho
01:08:55
fe:Replying to "One of my concerns w..."
Tempo tx doesn't support many use cases like post quantum signature schemes
01:09:27
Danno Ferrin - Tectonic.xyz:Replying to "One of my concerns w..."
Tempo can just add PQ schemes.
01:09:29
v2:I'd also add privacy protocols :D
(intermediary-free privacy protocols that can natively benefit from FOCIL are like 35% of my motivation for 8141)
01:09:44
ivo Georgiev @ ambire:Replying to "I keep hearing that …"
All arguments are “muh complexity”
01:10:04
fe:Replying to "One of my concerns w..."
Which again locks you to specific implementations
01:10:24
v2:Thank you all!
Summary
17 highlights
· 3 action itemsExperimental
Summary
17 highlights · 3 action itemsExperimentaleoa support proposal
- Derek proposes adding EOA support to 8141 via default account behavior00:06:02
- Default code applies only during frame tx execution; not persistent00:11:14
- Removes friction of 7702 account implementation selection and deployment tx00:15:58
- Strong support for EOA default account; improves adoption story significantly00:22:11
technical design
mempool and standards
- Mempool will enforce standard frame structures; similar to Bitcoin standardness00:34:02
- Derek: Standard frame structure needed for public mempool validation00:38:34
- 7562-style mempool rules expected; allows-listed deployment proxies only00:45:18
- Frangio: Mempool rules need clarity in EIP; learned from 7702 experience01:05:17
relationship to 7702
adoption and ux
- Hardware wallet support critical; frame tx provides escape from 7702 implementation whitelisting00:46:01
- Daniel raises concerns: infinite flexibility creates security/UX friction like 4337/770200:48:30
- Felix: Frame tx removes signatures from protocol; enables future-proof cryptographic flexibility00:52:04
Decisions
- Strong consensus to add EOA support to 8141 via default account mechanism00:22:48
Action Items
- 8141 authors and community (GitHub/AA Mafia/ETHRND Discord): Finalize default EOA account format (precompile vs EVM code)00:23:09
- DanielVF on ETH Magicians: Write technical comparison: Frame tx vs Tempo tx addressing concerns00:58:28
- All community members and client teams: Review 8141 and voice support/concerns on ACD Execution call next Thursday01:09:06
Targets
- Next Thursday ACD Execution - headliner decision for Hegotá fork01:09:26