lightclient:Probably enough people here to start.
Transcript
lightclient:If you haven't seen… We put together some documents on the…
lightclient:proposed transaction pool for frame transactions?
lightclient:This was one of the points that was brought up on all core devs, about 2 weeks ago now.
lightclient:So, the first document, if you haven't seen it, it's a HACMD where we enumerate a few strategies that we believe would be sufficient, both in terms of safety and in terms of providing some good usability for frame transactions.
lightclient:The first strategy that's outlined is allowing only the sender to pay for the gas of the transaction, so there's no paymastering, no gas abstraction.
lightclient:And we feel this is, like, the most straightforward way to enable frame transactions in the mempool. The exact rules are kind of specified in that document. But it's important to note that
lightclient:Even this first strategy gives us
lightclient:most of the functionality that we're trying to provide with frame transactions, with account subtraction, broadly.
lightclient:The second strategy is the one that we're currently recommending as our preferred approach, but I'm happy, like, to discuss this more, and…
lightclient:you know, it's up for debate to talk about the best approach. Here is. But the second strategy is that we also allow a canonical paymaster.
lightclient:And so we had the insight that
lightclient:with 7562, which is the third strategy, the full AA transaction pool that has, you know, totally permissionless support for any contract code running as paymasters, or as validation code, the insight that we had was that a lot of the machinery of that ERC was focused on building a reputation system around
lightclient:paymasters, and, you know, run around untrusted Paymaster code. And so, we feel that we can come up with a canonical example of a paymaster, either as an ERC, in a, you know, a solidity contract, or as some sort of pre-compile.
lightclient:And that canonical paintmaster can… conserve 90… 5 plus percent.
lightclient:Oh, sorry.
lightclient:That Paymaster can serve 95 plus percent of the use cases that people have for account subtraction, and we can very safely do that in a much simpler way in the transaction pool. So that's what the second link is, is that's the PR to the EAP to actually add that strategy, you know, fully specified in the EAP.
lightclient:And then there's the last strategy that I kind of mentioned. This is just the, you know, everything strategy, the 7562 as outlined, you know, more or less, just adopting it as 8141.
lightclient:So those are kind of the strategies that we've looked at. I was talking to Julie a little bit, and one other strategy that maybe is worth mentioning is that
lightclient:We can continue to ship frame transactions in the protocol, and do a lot of the hard work needed to…
lightclient:Delivered as a protocol feature, but we don't have to, on day one, even support it in the transaction pool.
lightclient:My preference is probably to not do this, and to have some support for it in the transaction pool, but, like, it is a valid option that I think we're open to, if that's how clients feel we need to approach this to get this done safely.
lightclient:Okay, so that's kind of what we've been up to the past, you know, week and a half.
lightclient:I'm happy to open the floor now to answer questions about that, or just, like, any questions broadly about frames or A. Seems like we have a lot of people here.
frangio:Can you clarify all of these, strategies?
frangio:also use… Like, tracing to validate the storage accesses and so on.
Felix (Geth):I wouldn't say necessarily tracing, so it's the question of, like, does… either the… this can be done with tracing, or it can be just done by adding some kind of policy to the EVM that basically signals when one of these rules is met.
lightclient:Yeah, I don't know if there was, like, specific motivation for that question.
lightclient:Is it, like, about the tracing mechanism itself, or is it, like, this complaint around needing to do tracing in 4237?
frangio:Yeah, I was asking because I have heard that as one of the points about
frangio:You know, how this is not viable in the mempool,
frangio:But, yeah, just wanted you to elaborate.
lightclient:I think maybe one other thing I can add on is that it's important to understand, like.
lightclient:The way that 4337 was introduced to clients was very much like a bolted-on
lightclient:thing. It's not something that was really implemented natively, at least not in Geth. Like, we had… we did build a tracer that was focused on this, but it was using our tracing system, which is built to be extensible.
lightclient:And, yeah, maybe there's, like, some complaints, I don't know if it was about the Geth implementation of that, or if it was about the implementation of other clients, but, like, it's just important to say that, like, with frame transaction, this is a core protocol change, and this type of things are being…
lightclient:You know, integrated natively into clients.
lightclient:So tracing, like, we don't… I wouldn't, like, call this, us implementing tracing. It's kind of like Felix said, like, yeah, you know, we have to look through the transaction, but it's not like we're using a RPC trace call and having, like, the brittleness of this that people experience with 4337.
Felix (Geth):Yeah, this is a good point, because in 4337, they built the mempool to be an external thing that sits outside of the full node, and operates as its own process, and submits the transactions that it sees to the… to this node via the tracing and…
Felix (Geth):we don't… we wouldn't really do it like that. I mean, it's just… it has way deeper integration with the mempool, and I also don't think it's gonna be that complicated.
Felix (Geth):In the end, to enforce these restrictions, because basically what this mode of operation is like, is like, it has some very natural boundaries, and it is kind of easy for us to…
Felix (Geth):Ultimately, it's a bit similar to the static call as well. Like, in static call, we have this… this is one way of implementing it, definitely. Like, with static call, there are restrictions on execution, and these restrictions are applied directly in the EVM.
Felix (Geth):And you can either implement like that, or you can use, in Geth, for example, it could also be implemented by using the tracing facility internally, but it wouldn't also incur as much overhead as submitting it to another process via RPC, because the tracing in itself isn't going to be, like, the slow thing there.
Derek Chiang:I also want to point out that there's another approach that has been explored by some other AA proposals to minimize the overhead of
Derek Chiang:you know, this, you know, whether we call it chasing or, like, some other process. But basically, you know, this other option is to essentially whitelist.
Derek Chiang:a certain validation logic, right? You know, so, so for example, like, one idea that has been discussed is that, like, maybe firms can, target precompires directly, right? And, and if they do.
Derek Chiang:then the manpool can simply, whitelist a set of precompires, which have non-validation cost, right? You know, so, so just wanted to flow that as, like, another potential
Derek Chiang:Another potential idea to explore, you know, if we want to, you know,
Derek Chiang:Really, really, really, really minimize the mempool.
Chris - Base:I think on, that, like, targeting precompiles would be awesome. Where in… where would the configuration live for, like… I know we can't, you know, trust that, and we know that not all
Chris - Base:Validation can do, like, a recovery, of an Ethereum address.
Chris - Base:Or, I mean, you know, you could pass the public key and have some sort of…
Chris - Base:Address be spit out or something, but, like,
Chris - Base:I haven't seen that proposal for 8141 yet,
Chris - Base:Just wondering if there's been any more thinking on that.
lightclient:I don't think I got the question.
Felix (Geth):Yeah, can you repeat the beginning of it?
Chris - Base:Derek's just saying that,
Chris - Base:you know, targeting precompiles with frames. I guess I'm just asking, like.
Chris - Base:I haven't seen that, discussion, of how that would work.
Felix (Geth):So it would… it would work. We have moved a bit away from this in this particular proposal, because it is one of these options that is there, and it makes it very easy to… to do this, like.
Felix (Geth):allow listing in a mempool, because you can basically just check if the… if… if the… what… now in the… in the… let me, actually give a wider point. So, in Matt's document, if you have seen it, he defines this term, which is the validation prefix of the transaction.
Felix (Geth):So we really want to stress in this document that, there are certain frames in the transaction which are related to its validation, and then there are other frames in the transaction which are related to its execution. And, I mean, it's one of the things about the frame transaction proposal, is that these things can be a little bit mixed.
Felix (Geth):Which is good in some cases, it enables certain use cases that, like, frames have this, like, multiple purposes.
Felix (Geth):And we also consider it elegant, but for the purposes of the mempool, we have to basically determine what is the validation prefix of the transaction, and the validation prefix is exactly these frames that contribute to the validity status of it.
Felix (Geth):And it is very easy to analyze the frame structure, and it's basically free in the node as well to do that, and you can just walk it and then say, okay, I have determined that it is the validation prefix of transaction considers of these frames, and then you can just check that the target of these frames
Felix (Geth):belongs to a specific set of precompiles. And this is a valid strategy, but it does lock you into, first of all, having to define these precompiles, which we haven't done yet, so that would be something these precompiles would have to specifically be designed to perform the transaction approval. So…
Felix (Geth):We haven't spent too much time defining them, but it is pretty easily possible.
Felix (Geth):And then the other thing with these precompiles would be that, I mean, in some ways, it kind of locks your chain into this very specific way of handling the approvals, and so, I mean, ultimately, it shapes…
Felix (Geth):I mean, it kind of shapes, like, how this is supposed to be used, and we were more trying to see, like, for us, this is kind of like, we would go there if there's no other option, but we would just prefer to see how far can we get without restricting the user's choices too much.
Felix (Geth):And we feel like just by having the validation gas and predefining these patterns and so on, we basically allow the user to employ any mechanism that they choose to validate their transaction.
Felix (Geth):While, at the same time then making it
Felix (Geth):yeah, like, possible to optimize, like, some of these things more specifically. With the precompiles, we basically, again, back to this thing where we're giving them a fixed set of choices that they can use.
Felix (Geth):So, yeah, I don't know. We're basically not really looking into this too much, but I want to highlight that, yes, this is very much an option, and it is kind of easy to implement as well.
Chris - Base:And with that initial exploration of that, like, is that…
Chris - Base:Is, like, key rotation still possible using this pre-compile path? Like, it seems like there needs to be…
Chris - Base:A configuration for the account, live somewhere, such that.
Felix (Geth):Yeah, well, that's kind of the thing. It's more the… the question then is, like, how do you specifically structure this so that it becomes possible? And yeah, I mean, with the key rotation.
Felix (Geth):in some way, it's not really possible. Like, with the precompile, it would be more like… I mean, yes, it's possible, everything is possible with precompile, it just depends on the complexity of the precompile, but kind of what we were thinking about in this initial idea, like, when I voiced this particular idea early on, I was mostly thinking that this precompile would be used to determine if the sender address is somehow related to the public key.
Felix (Geth):in some kind of obvious way. So basically, for example, you could have a precompile that checks that the hash of the public key that made the signature is somehow related with this address that is submitting the transaction.
Felix (Geth):And this is something that can be done by the precompile very easily.
Felix (Geth):So… but then it's not… if you do this, then the key rotation is out. Like, there's…
v2:Ihs…
vitalik:Sorry, apologize for the bad microphone. I, thought I would, also share a different, idea, like, basically the, thing that I just, shared on the side, which is basically that, if you, do in-protocol enshrined, code delegation, which is, like, itself a very easy EAP that we,
vitalik:that has a lot of benefits for other reasons, then user accounts would be able to just delegate themselves to a precompile, and
vitalik:And so, like, that basically gives the same sort of UX and API as, as accounts declaring their account types. And, the, yeah, pre… to every precompile that represents a signature scheme, which would include K1, it would include R1, it would include, like.
vitalik:other things that we do. Then, basically we just modify those pre-compiles so that if they get called with approved bits, then they, yeah.
vitalik:like, also assume that there is a SIGH hash, and they essentially do the signature validation. And if you do it that way, then one benefit is that if you
vitalik:if you do the, enshrined delegation EIP in a way that supports, upgrading, then, like, basically, you do get, upgradeability for free, and, like, probably upgradeability just is the, the most natural way to do key rotation.
vitalik:So
vitalik:Yeah, I mean, in terms of, kind of features, like, yeah, like, that kind of approach definitely would limit you to a single key per account, I mean, if you wanted to do multi-sig, I mean, realistically, I mean, obviously, you know, we always have the…
vitalik:theoretical option to make a precompile for everything, but probably the realistic thing is, like, you just have a piece of EVM code that's,
vitalik:Makes multiple calls, and, realistically, that's, like.
vitalik:50 EVM steps, and it's, and it's not that bad, and that's one of the… one of the things that… that you could whitelist. I mean, you know, there's… there's always a boundary of, like, at some point, you know, if you want to start supporting more complex things, then, like.
vitalik:by far the easiest way is to ju… is to just open up the EVM for it, but, you know, there is, like, there is a flexible space before that.
vitalik:Mmm.
Chris - Base:I think, like, on this topic, like, there was that recent, schemed transactions EIP that
Chris - Base:Broke down, the, like, gas requirements for some quantum types,
Chris - Base:basically running in the EVM versus natively.
Chris - Base:I haven't, like, you know, actually double-checked that those numbers were, like, super accurate or anything, but, I think it kind of comes back to, like, we're really looking for,
vitalik:Hmm.
Chris - Base:That base, like, you know, native performance, and 8141 is just hard to… Get that, I guess.
Chris - Base:Yeah.
Nico mobile:I made change. Oh.
Nico mobile:Sorry, go ahead.
vitalik:No, go ahead, Dave.
Nico mobile:Okay, so actually the numbers are quite incorrect in the…
Nico mobile:I think you're mentioning the EIP proposal from Julio?
Nico mobile:Yeah, he missed a few things.
Nico mobile:A big one being the… Public key…
Nico mobile:is, like, in his accounting, he puts it in the call data, you can… you can do it, yeah, yeah, I expected this. So you can do it differently, you can actually have a contract where you store the…
Nico mobile:The public key, and then you can just, do one…
Nico mobile:excise copy, and you don't need to have this individual data all the time, so he… yeah, he did a few…
Nico mobile:few mistakes on the calculations, and so we are probably also not going to pursue the entity precompile in favor of a more generic solution.
Nico mobile:And he also forgets to… so in… his conclusion is that Falcon is the best team.
Nico mobile:Which, by gas number, is true, but, Falcon has also a bunch of, drawbacks, because Falcon is not, very easily implementable on hardware, so you can have side-channel attacks, and yeah, so it's…
Nico mobile:It is a good scheme, but it's not an ideal one for a blockchain use case, so we could not have a hardware signer, or it would be very complicated to have a hardware signer. So yeah, the…
Nico mobile:As someone who has been working quite a lot on these, different, schemes, yeah, I think he missed a few things in both in the gas calculation and in the… in the conclusion. That being said, I would love to see some of these schemes, make it into the, Ethereum one day, but yeah.
vitalik:Yeah, I think a couple of things I would add is that there's…
vitalik:there's, like, two possible paths there, right? One path is that we do just, add the Falcon as a precompile, that's kind of the boring base case, right? And if you do that, then, basically you
vitalik:like, I would argue that, like, it has an important advantage over just, like, Falcon as,
vitalik:a transaction type, because you get to support Falcon.
vitalik:like, single-key Falcon, just by default, but then you would also be able to support, multi-key Falcon, with, like, basically the same precompile, plus a tiny bit of EVM code, like, the same multisig. But there's also, like, something, a more ambitious approach, and this is, like, really new information, and,
vitalik:it's quite cool. So this, this promising new approach, it's, so it's, a vectorized math precompile, so it's, like, for Python developers, the way to think about it is, like, it's basically NumPy, and, or at least, you know, like, the small subset of it that lets you do stuff like NTTs and, everything that you need in Falcon, and…
vitalik:And, it's looking very possible that, with that approach, you'll be able to get gas costs down to the point where it's, like.
vitalik:Call data cost as… of the signature is, like, is…
vitalik:potentially have for even dominating. And, you know, like, the benefit of this kind of approach is basically that we don't have to commit to Falcon
vitalik:in this kind of hard way in the protocol, like, you just have one precompile, and then if, like, 8 months later, suddenly the world decides Falcon sucks and it goes to FNDSA, then the exact same precompile works, or…
vitalik:If, the world decides that, lattices suck, then actually the exact same thing also works for accelerating Poseidon hashes. So, it's,
vitalik:Yeah, so it's a super flexible solution in that way. So, we have both paths, and I think if we take the 8141 approach, then the actual decision point for choosing one of the two is still quite far off.
Felix (Geth):I just want to highlight that for us, specifically, like, in our group, who is behind the 8141,
Felix (Geth):It was the main motivator for us that with the frame transaction, the users are able to experiment with
Felix (Geth):signature types, And it doesn't require a fork to do that.
Felix (Geth):And if a certain… if it… the… we cannot foresee the set of precompiles that will be in the chain in the future, but I definitely have seen it in the past, that, like, adding precompiles is kind of an easier extension point than other things, and for us, it…
Felix (Geth):Basically, as soon as enough support is added to the platform to make certain signatures possible, they can already be used in basically every possible scenario. So, for example.
Felix (Geth):if we make it… if we… if we were to add a Falcon precompile, then immediately you would be able to use the Falcon not just for signing the transaction with 8141, but also with, for example, using with another contract, and so on. So it kind of gives you, like, this… this idea where you have a single extension point.
Felix (Geth):Which is these precompiles that add features to the platform that would be impossible or, like, prohibitive to implement directly in EVM.
Felix (Geth):And then, at the same time, you can do all the things, like key rotation, multiple signatures, having…
Felix (Geth):signing things other than transactions, all of that. Whereas with the, if you only support signature schemes.
Felix (Geth):a selected list of signature schemes, for the transaction signing, then you still need to solve that other bit in a different way. And I think this is kind of where this, for us, is, like, the key thing with the frame transaction, that, like, this… it can leverage the existing extension points that we have in the protocol to enable all the signing, including the transaction origin.
Chris - Base:Yeah, I think I'll just, also add, like.
Chris - Base:We, we made, 81.30, Which…
Chris - Base:I mean, the key property that we like about it is, like,
Chris - Base:People can still permissionlessly deploy validation logic as a contract, and then wallets can, like.
Chris - Base:add that configuration to accept that. But when a transaction comes in in 8130, we can see, just because it's explicit in the transaction.
Chris - Base:what the validation logic is, and that means, like.
Chris - Base:We get this kind of nice property where people can experiment on this, like, slow path, expensive path.
Chris - Base:With contract EVM logic, and we can also just add a native override without having to, like, trace anything for, you know, specific pieces of validation logic. And that means, like, you know, we…
Chris - Base:If we went with 8130, we would, you know.
Chris - Base:roll out with, you know, a K1 native validator.
Chris - Base:WebAuth, P256, like, you know, kind of all the main ones that we would care about. And, you know, a new standard developed.
Chris - Base:We could just, you know, automatically upgrade all wallets to using this native path, instantly with a fork or whatever.
Chris - Base:And it's also beneficial to…
Chris - Base:Mempool rules as well, because then it's just easier for nodes to know,
Chris - Base:Exactly kind of what validation logic we'll run.
Chris - Base:And that's kind of the one… Yeah, go ahead.
Felix (Geth):I think that the 8130 proposal is, like, for me, it's more like… I think it could, like, with 8141, it could… the 8130 could also be done as an ERC. So then it would be, like, a really strong thing where you say, users are really supposed to use this registry.
Felix (Geth):And it's gonna be something where you can… that can feed into also the mempool rules and everything. Like, we could still decide to go with, like, A1… 8130 and just be like, this is the canonical way to declare what your account wants to be validated by.
Felix (Geth):But I don't see it as a proposal that, like, I don't think it should be entrined, and the… the… the…
Felix (Geth):8130 has…
Felix (Geth):also a lot of complexity, which is then all these specific details that can also be resolved in the EVM.
Chris - Base:Yeah, like… I think this is where, like, you know.
Chris - Base:I would… it would be great if we could agree on some place that this configuration should live. Like, 8130 is, probably more complex than it needs to be because
Chris - Base:it's trying to maintain, you know, portability across the EVM without, you know.
Chris - Base:the L1, blessing of, like, okay, let's… this is the place where an account can delegate, its validation logic to other contracts, or whatever.
Chris - Base:I feel like, you know, if that piece was present, then, like, That…
Chris - Base:gives base the ability to really optimize, and, you know, try to compete on transaction throughput with
Chris - Base:you know, chains like Tempo that have, you know, fully native validation, etc.
Felix (Geth):is prohibitive. You can still, even with, like, if we… I think 8… the way we see it, or I see it specifically, is that the frame transaction is, like, the… the…
Felix (Geth):lowest common denominator in terms of infrastructure, and you can do a lot of things on top, including this type of registry. And it makes your job a lot easier, actually, because you can all do it in the user space. And you can put as many policies as you want. You can even put the policy in your block processing logic that only allows transactions which specifically use this registry. Like, you can make it as strict as you want, but the… the…
Felix (Geth):The point-sale stance is that we see that, like, the 8141 is kind of a superset of a lot of these proposals, because you can ultimately just implement them, and it just requires, like, aligning on the specific thing that we want to do.
Felix (Geth):For the validation, but it's, for me, is somewhat independent of the protocol-level mechanism of implementing this.
Chris - Base:like, I do agree that, you know, it would be… I think where there's a disagreement is, like.
Chris - Base:8130… in 814… sorry, 8130 cannot be implemented in 8141 as it is today, because the restriction of the frame being…
Chris - Base:Requiring it to go to the, approver, sorry, of the wallet.
Chris - Base:like, there's no delegation method anywhere, so it can't be done as an ERC.
Chris - Base:In 8130, we only run the validator logic.
Chris - Base:and the… Configuration is in a single, like, you know, it's in a known state in the account.
Felix (Geth):Yeah, I understand that. It has some advantages to do that this way. We actually discuss it a lot. Like, it's the difference between having to… for example, in a lot of cases that I have analyzed, when you are building your account with 8141, then the account basically
Felix (Geth):will…
Felix (Geth):the… you will pretty much always have to store something in the storage of your own account to configure, for example, which key is currently used. Like, the public key which is being used is very likely gonna be held. Like, in 99% of cases, it's gonna be held in the storage.
Felix (Geth):of the account itself. And then, this is one of the key learnings for me from 8130, that it could also be done in another way, where you basically have a global table of which key is associated with which account. It's just another way of storing the same information, so that's kind of how I see the difference between these proposals. And then, yeah, there has to be… if you want to do that on 8141, then there has to be this link between the account and the
Felix (Geth):table.
Felix (Geth):But that is something where, like, for example, delegating to a precompile could come in, or, like, there's many other ways to do that. But for the… there are advantages to having everything in one table. One of these advantages is these ideas like validator.
Felix (Geth):validation-only state, like the VOPS that was discussed, so they can have a node that basically only holds this table in memory and doesn't have to hold all the storages of all the accounts to look up their keys. So, yeah, there are some advantages to that, and I'm really open to discuss it, but…
Felix (Geth):From my point of view, it's like 8141 is kind of like… it's like a… it's like a slightly different angle, basically, what we're trying to get in, where it's, like, more…
Felix (Geth):Fundamentally about this, agreeing on this platform that we can then execute these ideas on top of.
Chris - Base:Yes, and I agree with that, I'm just saying,
Chris - Base:in its current form, we can't build 8130 on 8141. And I understand, like, you know, there could be a new EIP to, like, extend that configuration somewhere, or input it somewhere.
Chris - Base:But it's just not there today, so I'm just… Yeah.
v2:Yep.
Felix (Geth):Maybe something fundamental here. The thing that, like, for me is very confusing is.
Felix (Geth):we are bringing up 8141 as a proposal for the headliner, but we don't see it as a finished EAP. It's like, we see it as… this is, like, the starting point where, like, the discussions can start. We do have some…
Felix (Geth):strongly held points, which is, like, for example, we really want to do it with, like, via the frames, because we feel like it gives… like, there are some things there where we thought a long time about this, and we feel like it's kind of the distilled knowledge from many attempts at account abstraction, so we feel like certain things
Felix (Geth):we're gonna have a really hard time paddling back on. But at the same time, I do see that the specifics of how exactly accounts are gonna work, we don't really have too much of an idea how that's gonna be. We wanna leave that open. It's just much more for us about, like, making this EIP the focus of the
Felix (Geth):fork after the next fork, so that there will be ample time for the core devs and also the ecosystem to work out what account abstraction will look like when it comes
Felix (Geth):to the mainnet natively. So we… in some ways, I feel it's a bit weird that now we have to prove it, like, right on the deadline, that everything is going to be perfect, but literally all we want to agree on is just, like, this is going to be our focus. We don't… we don't actually want to agree on all the details right now.
Felix (Geth):So to that end, I mean, the main thing that we have to agree on is that, like, somehow this EIP has to make it possible to do all these things that we want to do, so there has to be…
Felix (Geth):post-quantum cryptography on-chain, like, and that means, for example, eliding signatures from the block, ultimately, or having some kind of mechanism to compress them, like, that has to be possible with 8141. Sponsoring, like, gas sponsoring of transactions has to be possible with 8141.
Felix (Geth):You know, like, account configuration has to be flexible enough to, like, so that when we ultimately figure out the scheme that everyone's supposed to use, then
Felix (Geth):Like, that… that has to be working, like, possibly this, like, pre-compiles this validation, like, all of these ideas, they have to be possible with the proposal, so they will shape the proposal for now, but I don't think we really have to agree on, like, how exactly it's gonna look.
Felix (Geth):So that's, for me, just, like, really important. And that's kind of also what I like about A141, because so far, we have been able to mostly do everything we would ever want with it.
Felix (Geth):Like, it's been pretty rare that we hit some limits where we're like, oh yeah, this is not possible. And if…
Felix (Geth):if we hit that limit in our internal discussions, for example, we were always like, oh yeah, how can we change the proposal to make that possible while maintaining the properties, like mempool safety and so on? Like, this… this is, like, the balance that we really have to strike. Like, everything we're discussing here comes with the pretext that ultimately it has to be compatible with the mempool, it has to be safe,
Felix (Geth):And so on. Like, there are some of these core things that we want to achieve, but we kind of intend to make this proposal flexible enough to do all the ideas that people have and want to do, and we're really open to be discussing these ideas.
lightclient:work I ask a question, who is responsible for finalizing the proposal between now and the fork? I mean, I think it's mostly the authors, the authors of 8141, but…
lightclient:in terms of, like, you know, finalizing what does that mean? We're making a decision tomorrow on all core devs to decide if Frames Transactions is going to be the headliner, and at that point, it's the question of…
lightclient:the client teams, like, is this something that we want to work on going forward? I don't think there's, like, an expectation that the EAP is totally final.
lightclient:When it's picked as a headliner, like, we're still over 12 months away from when this would go live, and things will come up over time as we actually implement everything.
lightclient:But it's basically a matter of getting it to a place between now and tomorrow where client teams are supportive of the frames, and then from there, it'll be mostly on the authors in the beginning months, and then all client teams as we get closer to the fork to get it into, like, a finalized position.
lightclient:So, Lucas is saying that things that they, the Nethermind team, dislike about frame transactions is, one, run an EVM transaction in the pool, complex rules to potentially do it safely, and two, complex rules on special mode to run
lightclient:Authorization frames… I don't think I understand the second one.
lightclient:Do you… do you mind explaining that?
Łukasz Rozmej:Mmm, they're, like,
Łukasz Rozmej:rules on what is allowed and not allowed, that is different than the normal mode, right? So…
Łukasz Rozmej:It introduces a lot of complexity.
lightclient:But you're talking about in the transaction pool still there?
Łukasz Rozmej:Not sure, would have to look it up, but, in the spec. I think it's not related directly to transaction pool.
Felix (Geth):Yeah, I think what Vukash means is the approval. So, we have been working on the approval for a bit now. The current state of the EIP, the way the approval works, we are not super happy with it either, because it kind of has, like.
Felix (Geth):this has been feedback, especially from Derek's side.
Felix (Geth):that, working on this for a while, it can look very confusing. In the end, it's not that confusing if you look at it very closely, but basically, there is this problem in the EIP, as it is structured right now, that there are two main places where the rules are sort of laid down. One of them is this, what we would call the frame execution loop, so this is in this top-level section called behavior.
Felix (Geth):So, in the EIP, in this section, we detail how exactly the frames of a transaction are processed while running a block.
Felix (Geth):And then it has these variables there, payer approved, and execution approved, or sender approved, or whatever.
Felix (Geth):And then, so basically, these variables are influenced by the execution of the frames. So, we want to note that this loop specifically is the logic that runs while executing a block. So on its own, this loop is not that complex, but the way the text is written makes it look, like, pretty complex, but it's actually, like, in code, it's not very complex.
Felix (Geth):And then there… we have the other big place where the logic is, and that is the approve opcode. So the approve opcode has some specific restrictions in place that basically tell
Felix (Geth):When this op code can be used with a certain approval scope.
Felix (Geth):And I agree that, first of all, between these two places, they are not right next to each other in the specification, so it's a bit confusing, but also the interaction between these two things seems complex, but actually it's not really complex. In the end, it's just that at some point in the transaction, the approved opcode has to be used with both scopes, and the limitations on the approved opcode make this whole thing kind of safe.
Felix (Geth):And we spent a lot of time optimizing it, but we also heard the feedback from multiple people that the way it's written now is… it is kind of hard to understand it, and it seems like this opens up a lot of big matrix of cases that have to be considered. But actually, when you break it down, it's not really the case.
Felix (Geth):This is something that we heard, and we are working on improving the EAP.
Felix (Geth):to make it more clear how this is meant. And, for example, there's a proposal from Derek to simplify the approvals, and…
Felix (Geth):Yeah, I mean, it's… it's… we are… basically, we are aware of this problem.
vitalik:Yeah.
vitalik:Also, I, yeah.
vitalik:I have just wanted to share a bit, more of, kind of, big picture philosophy, right, which is that, there's a lot of use cases here that, that,
vitalik:Some of them get into this long tail of needing more programmability and, a lot of this, kind of,
vitalik:of, like, custom logic that you can't really… you can't really fit into existing frameworks easily, right? And so, like, for example, one of the…
vitalik:things that excites me is that I use privacy protocols often, and privacy protocols today have this weakness that they all rely on this public broadcaster mechanism, and that's, like, this very specialized set of intermediaries for this one thing, and so half the time it breaks, and so on average, I have to, like, try five times before a
vitalik:a railgun transaction works, and one of the many things that, can happen is, basically that, like, you can… you can make a… like, you can make
vitalik:privacy protocols work inside of frame transactions with, a… either a Paymaster's or the 2D nonce mechanism, right? And,
vitalik:The, and then, at the same time, there's clearly all of these, sort of much more normal, or, like, much more of a small deviation from the status quo kind of use cases, so things like supporting R1, things like supporting post-quantum algorithms, things like supporting
vitalik:multisigs, and the, yeah, general kind of framework that I think we're advocating for is to basically say, do the generic thing in protocol.
vitalik:And it turns out that in protocol, the generic thing is only a relatively small number of spec lines of code. And then, at the same time, like, yes, be very restrictive in the mempool, and the mempool can be, you know.
vitalik:the strategy 1 or strategy two, the mempool can be a whitelist. The, mempool can basically just be the equivalent, like, a whitelist that is equivalent to the thing that something like Temple transactions could include. It could even be just K1 and R1 and Multisig, and…
vitalik:basically, once this is done, then people who care about the more complicated things have their own space to cook, right? And, basically, yeah, there's this… they'll have their own space, or I guess we will have our own space to go work on figuring out an ideal universal mempool that covers everything safely.
vitalik:and that's…
vitalik:something that happens separate from the protocol that all of the nodes would incorporate into the mempools by default, and people are free to opt into it, people are free to not opt into it, and basically more and more things
vitalik:could get inducted into the mempool over time as we become confident that they're safe, and all of that can happen without hard forks, right? So…
vitalik:Right, base… yeah, so I think that that's kind of the top-level vision, right? Yeah…
vitalik:And then, I think for each of the individual use cases that gets, kind of talked about, right, the maximum allowed timestamp, like, there's ways to make safe memples for each and every one of, each and every one of those things, and I think the, exact shape of
vitalik:the SafeMan pool is, gonna depend a lot on the balance between, basically,
vitalik:how strong the level of, like, comfort or discomfort with, even, like.
vitalik:even limited amounts of EVM validation is, and what kinds of use cases people want, people wants to enable quickly, right? But essentially, we,
vitalik:gets to set up this environment where the default mempool is one set of decisions, and then separately, people who wants to do things that are more ambitious than
vitalik:the default mempool are free, like, have their own space to go and, do… to go and do those things by themselves, and then, and then convince, you know, like, either the default mempool, or independently convince nodes and fossilers and builders or whoever else to support it. And so, it's, this, kind of…
vitalik:Basically, a free market approach that really minimizes the need for any, sort of…
vitalik:or at least much central planning of these use cases once the, like, at least the basic position of the framework is made. And I think…
vitalik:Yeah, and from, like, within that kind of scope, there's a lot of options to make sure that, like, specific use cases that, I mean.
vitalik:Add up to, you know, like, 95% of, like, current usage or people… individual projected usage, then,
vitalik:that can be done, and like, the… and there is ways to make FastPass for it, so that, like, for example, EVM cannot… does not have to be required at all, and… and, so forth.
Ben Adams:The EVM would still, regardless of the mempool, the EVM would still have to validate all the rules.
Ben Adams:One including the transactions and the block.
vitalik:The… right, the EVM would need to run the verify frame, but that's just, but that's an EVM call. Like, that's,
vitalik:No, like, within the EVM, that, like, that EVM call is just an EVM call.
Ben Adams:Okay.
DanielVF (Monad):So, in talking about the split between the clients and the mempool.
DanielVF (Monad):From the point of view of everybody who's not a client, but from wallets, applications, users' point of view, it's really the combination of
DanielVF (Monad):what the client does with frame transaction, and what the mempool allows, the interface that they use. And so, I think it is very important to actually work to define what those mempool rules initially would be, because that's going to be actually the API that everybody sees.
DanielVF (Monad):And enforcing those mempool rules is a part of what the work that,
DanielVF (Monad):Client teams will need to do.
DanielVF (Monad):And… I know we want to end up with a free market kind of
DanielVF (Monad):environment, or, you know, something I've heard a lot, but…
DanielVF (Monad):It's really important that there's a standardized core that everybody can implement to, so that you don't have to, you know, if you write one set of rules, it only runs in one place. Now, when you're pushing the boundaries and,
DanielVF (Monad):inventing new things, that's great, to be able to do, but you do have to have that core that everything runs off of, and that core is basically the rules, you know, the combo of the mempool rules and the EIP rules.
DanielVF (Monad):Just throwing that one in there.
vitalik:Yeah.
vitalik:Yeah, I think that's very reasonable. I think, I mean, like, as I might have mentioned before, right, like, Bitcoin, does something similar where it has, the concept of what the blockchain allows, and then separately it has the concept of standard transactions.
vitalik:And, standard transactions is, something.
vitalik:much… much more restrictive that, I mean, like, bans a huge number of complicated things. Yeah, and I, like, I think there is a, path here where we, basically, like, agree to.
vitalik:come to a decision point at some point pretty soon of, basically, are we going with a, default mempool that incorporates, like, some level of, EVs,
vitalik:some support for EVM with some… with, some restrictions, or are we going for… are we going for a whitelist mempool? And, that's, like…
vitalik:We get… we get to that…
vitalik:to that decision point, and then we, you know, whichever of those approaches we choose, we can disagree and commit to it, and
vitalik:everyone who finds themselves outside of, of, that can, feel free to coordinate separately on custom mempools.
DanielVF (Monad):Yeah, and I think, you know, defining that is a core part of actually defining what work clients have for implementing,
DanielVF (Monad):8141. So, yeah, it's critical that it actually goes in basically at the same time.
vitalik:Yeah. So, I saw Matt, you know, like, wrote up the documents today with, three possible strategies, right? I guess I'll just repost it for convenience, I guess. Would,
vitalik:One thing,
vitalik:be helpful is, kind of also extending that and adding, you know, like, strategy 4… Strategy 4 and 5, and, options that are even more restrictive and whitelist-based, so that we have something concrete on, on that side of things that people can look at and see if they're comfortable with them or prefer them.
Ben Adams:I mean, obviously the mempool's a dangerous place in terms of MEV and so forth.
Ben Adams:But, one concern I have… so, for instance, for the
Ben Adams:Strategy 1 there, it's sort of saying, sponsored transactions will still work, but only through bundler's private flow.
Ben Adams:I'd prefer that we're… Open enough rules that worked in the mempool.
Ben Adams:Where you didn't need to rely on
Ben Adams:The only way to achieve inclusion or use of this is,
Ben Adams:Through a third party, if that makes sense.
Ben Adams:It's…
lightclient:I mean, that's… that is what's within there, though, right?
vitalik:I agree.
lightclient:Like, that is strategy one. You can yourself relay the transaction through the mempool.
vitalik:Right, Strategy 1 says that it's, sponsored transactions that, require bundlers.
vitalik:And…
vitalik:One thing that I think we can, again, also add is that, like, we do have the option to mix and match different dimensions. So, for example, I think it's a totally valid choice to say we're going whitelist on signature algorithms, but at the same time, we're going option to style and saying that gas-sponsored.
vitalik:Transactions, that, that, that, whose signatures are…
vitalik:Within the whitelist can be included in the public mempool.
vitalik:Like, I think that is a choice that we totally can make.
lightclient:like, what I understand you describing is an option that wasn't specified, but is a possibility if people wanted this, which is…
lightclient:to just not let people submit frame transactions in the public mempool. Like, that wasn't specified as a strategy, but it's… if that's what we need to do…
lightclient:to start with.
Ben Adams:No, no, I think that would be completely the wrong way, because then it's only a feature that can be used by third parties. It's nothing… it's not…
Ben Adams:In protocol.
lightclient:Okay, I think we agree on that.
lightclient:So strategy one is that users get to use frame transactions, and they get all the account abstraction benefits, they just have to pay for their own gas.
lightclient:If you don't want to pay for your own gas and you want to use a paymaster, then in strategy one, we would rely on a bundler like today.
lightclient:it's not our recommended approach, but I can appreciate that it adds, like, allowing the paymasters in the mempool does add more complexity than some clients might be willing to undertake in the first iteration of this.
Ben Adams:Yeah, but…
Ben Adams:Having it in the mempool therefore gives you that standardization that people can iterate on, whereas if it's, you know, something only
Ben Adams:Oh, you only get if you're submitting to Titan Builder, and they've got all the private order flow, then it's… it's not a good feature. It's… it's…
Ben Adams:what I'm highlighting.
lightclient:I guess I don't understand the difference of that versus today. Like, we're trying to move away from that.
lightclient:That's the goal. But, like, that is how it works today.
Ben Adams:You mean, yeah, and I'm just saying, so we shouldn't be developing a feature that will only get picked up
Ben Adams:by that private order flow. It should be… I accept what… yeah, I accept what you've said, but I'm saying…
Ben Adams:Yeah.
lightclient:So, you prefer strategy 2?
lightclient:To allow paymasters in the public transaction pool.
lightclient:Okay.
lightclient:There's a question, what's the issue with the canonical paymaster?
lightclient:My…
lightclient:thought on the issue is that some paymasters want to have some different functionality and behavior, and in general, when we say that there is, like, one universal way of doing something, that that usually can't describe the nuance and complexity of everybody's use case.
lightclient:I think that's the main, issue with the economic paymaster.
lightclient:I think my argue against that is that Paymaster is a pretty, like.
lightclient:Single-dimensional role in most ways, and…
lightclient:If we were to canonicalize something, that that's probably… an okay role.
lightclient:Alright.
lightclient:Any other questions, guys?
lightclient:Yep.
frangio:A bit of a technical detail, but when people say full 7, 5, 6, 2…
frangio:One of the rules there is about, what they call associated storage, which is storage outside of the account. Is this included when you guys say full 7562?
lightclient:That's my intention?
frangio:Okay.
lightclient:Any last comments or questions, guys?
lightclient:I think you have to tune in tomorrow, Barnabas.
Łukasz Rozmej:I have a question, because, you mentioned that there should be only one frame transaction per sender. Why is that? Can you give more…
Łukasz Rozmej:Reasoning about this?
lightclient:Sure. The reason that we're intending one frame… pending frame transaction per sender is because the frames are a native batching mechanism.
lightclient:And so, any type of…
lightclient:like, you know, stacked transaction flow that you have today, you should be able to represent in a single frame transaction. And even if you do it where you submit your frame transaction, and it's still pending, and you want to append more methods, then you can always do replace by fee.
lightclient:So, like, we generally don't feel like…
lightclient:There are many use cases to have multiple pending, I think that, like.
lightclient:it's not a hard requirement that it's one pending transaction, but I think it's a trade-off of, like, the more pending transactions you have, the higher the…
lightclient:you know, resource usage and risk is. Like, if the verified gas is $100,000, and we only allow one pending transaction, I don't see why it wouldn't be also okay to have two pending transactions at $50,000. Or, like, you know, some… some, like, reasonable decision there.
lightclient:So that's kind of, like, how we came up with one, but if we need two, like, we could potentially do two.
Łukasz Rozmej:Okay, interesting. Do you think it will potentially clash with the 16 million gas limit?
lightclient:Why's that?
Łukasz Rozmej:I don't know, because, well, if you're boundling things, etc, you know, you can probably easily go…
Łukasz Rozmej:Beyond that limit, right?
lightclient:Yeah, I mean, I think this was, like, one of my arguments against the 16 million limit in the first place, but my thought was more that it was a problem if you have, like, multi-user bundles, and I think we're actually moving away from the multi-user bundle, because that's, like, how 4337 works. 4337 is, like, really the main or only use case of having, like, multiple different user ops in the same transaction.
lightclient:Which is, like, what I was afraid of.
lightclient:But with Frames, we're trying to actually, like, decentralize the bundler more, and have it be, you know, the users interacting directly to
lightclient:the block producers?
lightclient:Or the, yeah, the block producers. And so, in that case, you know, the block producer is doing the bundling of all the user ops and the transactions, just like they normally would do. And in that case, like, you don't need to have multiple user ops in the same transaction, typically. So, like, will a user want to consume more than 16 million gas?
lightclient:It's possible.
lightclient:But I think that, you know, that's the same question that we also had with…
lightclient:pre-frame situations. Like, if a user wants to use more than 16 million gas, it's just not possible. I don't really think there's many users who are trying to do, like, a batch of operations that cost more than that.
lightclient:Okay, we're one minute over now.
lightclient:I'm happy to answer more questions asynchronously on Discord, in the Ether R&D, or in the Telegram, AA Mafia, or feel free to DM me.
lightclient:We will have all core devs tomorrow, 1400 UTC. I'll share the link in the relevant places before then. Please come on, if you're not a client developer and you have
lightclient:You know, perspective that you want to share with the core devs about supporting or not supporting frames?
lightclient:We would appreciate that.
lightclient:And otherwise, I will talk to you all tomorrow.
v2:Thank you.
lightclient:Bye.
Chat Logs
00:10:52
lightclient:https://hackmd.io/@matt/frame-mempool
00:10:57
lightclient:https://github.com/ethereum/EIPs/pull/11415
00:15:23
DanielVF (Monad):I like #2 + eoas.
00:15:57
Parthasarathy Ramanujam:Canonical paymasters will also support gasless? If so, which tokens?
00:16:18
Jeevan (jvn):IMO having a canonical paymaster at start might mitigate a lot of problems at first
00:16:36
v2:I don't think anything needs "tracing" per se, I think what it looks like in practice is: the EVM implementation gets a new "call type", similar to StaticCall, but that call type is not in the ethereum protocol, it's only ever used by mempool nodes
00:17:25
v2:yeah, "tracing" has the overhead of writing out 50 things into stdout per EVM opcode, that was needed in 4337 only because they were trying to make everything work with zero node changes
00:19:15
v2:(I personally prefer 8141 + whitelist in default mempool to any non-8141 AA
and yeah whitelist-based is fully tracing-free and does not require new EVM call types)
00:21:52
Chris - Base:Can share that doc?
00:22:08
Derek Chiang:Precompiles automatically approving based on the approval bits could be interesting
00:23:06
v2:right, we could take every existing signature precompile (k1, r1 ...), make it approve if called with approval bits, and then in-protocol enshrined delegation, which would allow wallets to just set a precompile as their address
00:23:51
Derek Chiang:@Chris - Base we could do either configurations, or the EOA address is derived from the precompile
00:25:21
Chris - Base:Single key per account then?
00:26:53
DanielVF (Monad):Yes, I'm fine having the "multisig" at the EVM level - as long as it's not controlling transaction inclusion into a block.
00:27:44
Derek Chiang:@Chris - Base would the precompile idea address Base’s concern?
00:28:04
Chris - Base:https://ethereum-magicians.org/t/frame-transactions-vs-schemedtransactions-for-post-quantum-ethereum/28056
is the one I referenced
00:30:11
Danno Ferrin:Don’t add falcon, wait for FN-DSA. This will be keccak/SHA3 all over again
00:32:09
Nico mobile:Totally agree !
00:33:13
Chris - Base:We want key rotation, multiple owners (of different types). We are trying to provide tempo level native tx but also flexibility which is what led us to 8130.
Hard to optimize 8141 (keep fully in protocol validation)
00:33:32
Nico mobile:And we also get the privacy protocols withdrawals !
00:33:40
Jeevan (jvn):I didn’t initially like the idea of going all-in on Falcon for several reasons. While its smaller size is a clear advantage, it also comes with trade-offs. Adopting it would shift our focus from hash-based approaches to lattice-based ones, and I’m not sure we’re ready yet to commit to a specific post-quantum algorithm currently
00:33:49
v2:Replying to "We want key rotati..."
it should be not hard to make sure the defailt mempool provides that!
even the whitelist approach should
00:33:51
Danno Ferrin:I don’t share the optimism that a NTT precompile plus evm logic will get standard FN-DSA or Falcon signatures below calldata cost. There is too much small size bit twidding. A vector API to ahdnel that would need bit level strides, not byte. Plus the falcon signature compression logic is not vector friendly.
00:34:32
Giulio:Guys I am outside
00:34:40
Danno Ferrin:Replying to "I didn’t initially l..."
Cryptographic Agility is table stakes for sustainability. If we commit to one signature we’ve done it wrong.
00:34:46
Giulio:I cannot hear. Can someone tell me what’s up?
00:35:10
Jeevan (jvn):Replying to "I didn’t initiall..."
yeah , completely agree with that
00:35:23
Giulio:If it is pricing. 2 things: 1) sig bytes should cost less than call data if you target worst case block 2) pricing is targeted at 350mgas/s on an M4
00:35:29
Giulio:So probably too much
00:35:51
Giulio:Sorry too little I mean
00:36:08
Luca Donno | L2BEAT:Replying to "I cannot hear. Can s..."
you can try this
[Full message cannot be displayed on this version]
00:36:25
Danno Ferrin:Replying to "If it is pricing. 2 ..."
Making sig bytes less than call data is a bad idea. Apart from performance conerns at load it opens up inscription vectors.
00:36:49
lightclient:the configuration should live in the user account?
00:37:31
Renaud-ZKNOX:Répondre à "If it is pricing. ..."
Agree with Danno. First thing would be to exploit SSTORE2 style to reduce cost for other purposes
00:37:55
Renaud-ZKNOX:A réagi à "Making sig bytes l..." avec 👍
00:39:15
DanielVF (Monad):You'd have to deploy a contract to the account, that then uses are registry of validator contracts
00:39:19
Derek Chiang:@Chris - Base that restriction would be lifted if we start allowing VERIFY frames to target precompiles, for example
00:39:47
Chris - Base:Still needs a place to register configurations for keys
00:40:20
Derek Chiang:Replying to "Still needs a place ..."
Right it basically comes down to whether there’s in-protocol support for key rotation
00:40:24
Filip (Biconomy):Singleton contract? One per sigscheme so that already by the frame target - nodes know a lot upfront
00:41:33
Chris - Base:Frames are good yes
00:42:07
Giulio:Replying to "Singleton contract? ..."
This is schemes transactions
00:42:37
Derek Chiang:The only fixed part of 8141 is the 3 axioms:
A transaction is a series of frames
Frames can approve / pay gas for the transaction
Frames can introspect one another
Everything else can change without 8141 becoming a new EIP
00:42:41
v2:@chris on your specific question ("we cannot do 8130 on top of 8141 today because of delegation"), would also doing an EIP where contracts can specify their code by pointing to another address solve that?
00:43:46
Chris - Base:Ideally accounts can specify a set of validation contracts that can validate transactions for itself
00:44:10
v2:Replying to "Ideally accounts c..."
a set, meaning being a 1-of-N multisig between different schemes?
00:44:15
Orca 0x:who would be responsible for finalising the proposal between now and the fork / how would that work?
00:44:41
Parthasarathy Ramanujam:What is the position of the Besu team now? They had some concerns and reservations with 8141 as a headliner during the last call.
00:44:42
Derek Chiang:Replying to "Ideally accounts can..."
If an account can delegate verification logic to another contract, then the registry logic can just be implemented inside the contract, right?
00:44:49
Chris - Base:A set being like:
owner a is k1 key
owner b is p256 key
owner c is some recovery mechanism
00:44:50
Felix (Geth):sorry I have to leave call now because I have an IRL appointment
00:44:51
v2:Replying to "Ideally accounts c..."
yep
00:45:35
Jeevan (jvn):Replying to "What is the positi..."
Also would be good to know the pov of reth I guess
00:45:54
Danno Ferrin:Must it be a headliner? Can it be worked on in a non-headliner state?
00:45:59
Chris - Base:Replying to "A set being like:
..."
each being a "full" owner
00:46:04
Felix (Geth):Replying to "Things we dislike ..."
I agree this part is not easy but doing this buys us so much!
00:46:17
DanielVF (Monad):All the opcodes you can't call
00:46:20
Felix (Geth):Replying to "Things we dislike ..."
So it is a tradeoff, yes.
00:46:30
Barnabas:Replying to "Must it be a headlin..."
I’d think so.
00:47:12
Danno Ferrin:Replying to "Must it be a headlin..."
There was two questions where yes means different things ;)
00:47:38
Parthasarathy Ramanujam:Replying to "Must it be a headlin..."
The fear is that if 8141 isn’t a headliner, we may end up with status quo.
00:47:41
Łukasz Rozmej:Replying to "Things we dislike ab..."
yep I mean approval
00:48:17
Chris - Base:Small question - for tx expiration, is an account expected to call some canonical expiry contract so that can be traced?
00:48:50
v2:Replying to "Small question - f..."
tx expiration, meaning, txs setting a max allowed timestamp/slot?
00:49:22
Felix (Geth):sorry really have to go now
00:49:25
Felix (Geth):bye ~~
00:49:33
Chris - Base:Replying to "Small question - f..."
Yes, would violate 7562 rules / trivial DoS vector?
00:50:35
Parthasarathy Ramanujam:Replying to "What is the position..."
They are clearly not in favour of 8141. AFAIU, only Nethermind and Besu are still on the fence.
00:51:55
frangio:Replying to "Small question - f..."
yes using a canonical expiry contract for the sender verify frame would be a simple way to enable this in the mempool
00:52:34
Orca 0x:is it still the intention that you can call APPROVE in non-Verify frames? (this seems to add a decent amount of complexity, and it might be cleaner just to have APPROVE in verify frames)
00:52:45
Derek Chiang:I think privacy and multisig are the two use cases that can really benefit from EVM-based validation. Multisig can arguably be enshrined but in practice there are so many different multisig use cases like owners with different weights, conditional multisig (e.g. requiring a co-signer only for certain transactions), that it’s hard to properly enshrine it
00:52:59
frangio:Replying to "Small question - f..."
i'd think it needs to be the verify frame's call target though. not called inside
00:53:42
Jeevan (jvn):Replying to "is it still the in..."
I thought it was only called in verify frame , Maybe im missing something : |
00:54:57
Daniel Lehrner (Besu):Replying to "What is the position..."
At Besu we have not changed our opinion. We talked several times about it since last ACDE, but the majority is still in favor of no headliner.
00:55:36
v2:Replying to "Small question - f..."
I feel like I have a memory that yoav thought about how to add timestamp limits to 7562
00:55:50
Orca 0x:Replying to "is it still the inte..."
currently I can’t see that constraint in the EIP. I think if it was there we could do without approval bits which would be a nice simplification
00:56:01
Danno Ferrin:Replying to "is it still the inte..."
Approve reverts if not in a verify frame. Nothing in 8141 prevents approval contracts from being called, so a revert is the cleanest fix.
00:56:07
Derek Chiang:Replying to "is it still the inte..."
Yeah it’s still the intention that you can call APPROVE in any frame. In practice, since SENDER frames require the sender having been already approved, you can’t approve the sender in a SENDER frame, but other than that there’s no restrictions
In terms of use cases, it would allow for stateful approvals. These are long-tail use cases but they are conceivable
I’m personally open to simplifying the proposal by restricting APPROVE to only VERIFY frames but it’s not a common opinion shared by all the coauthors yet
00:56:21
Parthasarathy Ramanujam:But you aren’t against EIP 8141 per se?
00:56:57
Danno Ferrin:Replying to "What is the position..."
That’s not the question that has to be answered tomorrow. The question is “what is the headliner” not “do you like 8141”
00:57:15
Luca Donno | L2BEAT:Replying to "is it still the inte..."
do you have an example of such stateful approval use case?
00:57:18
Daniel Lehrner (Besu):Replying to "What is the position..."
No, we would not block it. If the majority is for it, we are willing to go ahead with it.
00:57:39
Daniel Lehrner (Besu):Replying to "What is the position..."
It’s just that our favourite is no headliner
00:57:51
Renaud-ZKNOX:Beside PQ, classic ECC sigs should be enforced at wallet level, nothing on chain, using FROST. Schnorr with AA is almost equivalent to ecrecover, and is standardized now.
00:58:49
Danno Ferrin:Replying to "I think privacy and ..."
CRQCs will spill all the ECC secrets when they show up. Elliptic Curves won’t keep your secrets.
00:59:07
Renaud-ZKNOX:Répondre à "I think privacy an..."
yep, i said beside.
00:59:12
v2:https://hackmd.io/@matt/frame-mempool
00:59:41
Orca 0x:Replying to "is it still the inte..."
as VERIFY frames are static calls I don’t see a reason why it’s not cleaner to just have one at the relevant point in the transaction
01:02:02
Chris - Base:What is the suggested initial allowlist in this case?
01:02:32
frangio:what's the issue with the canonical paymaster?
01:03:13
v2:Replying to "What is the sugges..."
k1, r1, PQ, multisig
allow a single canonical paymaster
and then do the EIP that allows contracts to specify another address (incl precompile) as their code address
01:04:45
v2:basically we can do:
(1A) whitelisted signatures, no paymaster allowed
(1B) EVM in validation, no paymaster allowed
(2A) whitelisted signatures, single canonical paymaster
(2B) EVM in validation, single canonical paymaster
(3) full 7562
01:04:46
Chris - Base:Replying to "What is the sugges..."
The allowlist is on the bytecode then?
Or what is the mempool using to do this allowlist - signature itself?
01:05:10
v2:Replying to "What is the sugges..."
right, allow list is on the allowed account codes
01:05:12
Derek Chiang:There can even be a more relaxed version of strategy 1, say strategy 1.5, where you can use one of your accounts to pay gas for another account. So each paymaster is restricted to sponsoring gas for at most one account at a time.
But personally I think strategy 2 is fine
01:05:14
Chris - Base:Signatures dont give a solid proof that its not doing some other validation method
sorry its bytecode allowlist suggested
01:06:16
Barnabas:so are we doing frames?
01:06:29
Orca 0x:Replying to "so are we doing fram..."
no spoilers
01:08:25
Chris - Base:Gotta run - thanks all!
01:08:38
v2:Empirically speaking, almost all transactions are far less than 16M
01:08:56
v2:and I think it's fine to say that if you have an exceptional super-crazy big tx, then you have to submit it individually
01:09:46
Łukasz Rozmej:Replying to "Empirically speaking..."
well empiricly speaking ALL transactions are less than 16M as it is a cap ;)
01:09:56
v2:Replying to "Empirically speaki..."
hehe I meant far less :D
Summary
23 highlights
· 2 action itemsExperimental
Summary
23 highlights · 2 action itemsExperimentalframe transaction proposal
- Three mempool strategies proposed: sender-only, canonical paymaster, full 756200:10:41
- Strategy 2 (canonical paymaster) recommended; serves 95%+ use cases safely00:12:03
- Option to ship frames in protocol without day-one mempool support00:13:58
- Three fixed axioms: frames series, approval/gas payment, frame introspection00:42:37
validation and security
- Canonical paymaster avoids 7562 reputation system complexity for untrusted code00:16:54
- Native client integration planned; not bolted-on like 4337 tracing00:17:33
- Precompile approach: whitelist set with known validation costs00:18:51
- Mempool safety and protocol flexibility must balance; approval complexity acknowledged00:46:45
signature schemes and precompiles
- Proposal: existing precompiles (K1, R1) auto-approve with approval bits00:23:06
- In-protocol enshrined delegation enables precompile-based validation00:25:10
- Falcon signature analysis has calculation errors; concerns about hardware implementation00:28:04
- Vectorized math precompile (NumPy-style) enables flexible PQ algorithms00:30:00