Antonio Sanso:All right, I'll start. Cecil, I will have a few more… few slides.
Transcript
Antonio Sanso:And then we'll start with the meeting per se. So today is the fourth occurrence of this post-quantum transaction signatures.
Antonio Sanso:We had the first trade,
Antonio Sanso:Here are the topics we already touched. First one, lattice solution. Second.
Antonio Sanso:hash-based solution, and last one, we had, entity and non-prepared compiles.
Antonio Sanso:And today's topic is about account abstraction.
Antonio Sanso:So I'm sharing again the strong app that was shared, like, a few weeks ago.
Antonio Sanso:And, again, for us.
Antonio Sanso:the part that are interested… interesting are the precompile part that leveraged and piggyback on the native ACAND abstraction. Last week, we have seen the entity precompile, and today we see a bit of account abstractions.
Antonio Sanso:So we will have, basically, two presentations. The first one is from Mattel.
Antonio Sanso:It's about 10 minutes presentation about one solution that can be already deployed right now.
Antonio Sanso:That involve a kind of traction.
Antonio Sanso:And then we'll have a lead client that is one of the authors of the frame transaction, EAP8141.
Antonio Sanso:And this will leave some space, hopefully, for open discussions. Another thing is, I created this Telegram chat for the future, so to have conversations. I will share in the chat of, of,
Antonio Sanso:of Zoom, if you want to join after.
Antonio Sanso:Hopefully, we'll have an interesting discussion in the future.
Antonio Sanso:And this is basically everything.
Antonio Sanso:From my side, and I will leave the stage to… to Mateo and Alessandra, I guess, at this point. You guys have 10 minutes. I will stop sharing. Thanks.
Alessandro Baiocchi:Okay.
Matteo Vicari:Okay?
Matteo Vicari:Okay.
Alessandro Baiocchi:Okay.
Alessandro Baiocchi:You should see my screen, then?
Matteo Vicari:It's all good.
Matteo Vicari:Nice, everyone. Today, we want to present a design for a femoral key rotation and a count abstraction, a possible way to bridge to a postume quantum security. I am Matteo Vigari, and this is Alessandro Bajoki, and we try to show us our idea.
Matteo Vicari:First, before we start, I want to make some clarification, because I don't want to upset nobody.
Matteo Vicari:So, our solution is not a replace for the needing of post-quantum signature, or the research of the post-quantum signator. Today's solution is for make the security asset of the people, today inside the chain.
Matteo Vicari:It's not a replacement for the work on the consensus layer, it's something more simple. So, I let Alessandro talk and illustrate the idea.
Alessandro Baiocchi:Yeah, thank you, Mattel, for the introduction.
Alessandro Baiocchi:So, as we all know, in a post-quantum world, public regulatory is not safe anymore, because private keys can be recovered from public keys.
Alessandro Baiocchi:And this also means that you need the public key to record the private key, so if a wallet didn't broadcast any transaction, the wallet is still safe in post-quantum world.
Alessandro Baiocchi:And we would like to use this to, like, achieve quantum security, but the issue is that to interact with basically anything on-chain, we need a stable identity. The protocol we're interacting with can identify us with.
Alessandro Baiocchi:So what we want to do is basically leverage account construction to decouple the on-chain identity, which would be the smart account address, and the signer address, which will be changed, and we'll see how.
Alessandro Baiocchi:So, this is our basic scheme of the idea.
Alessandro Baiocchi:And let's say Alice wants to send a transaction chain, and she has a smart contract wallet that's owned by Signer 1, and let's say, like, for the sake of this example, let's say signal 1 is the first address of a delegation path.
Alessandro Baiocchi:that's owned by Alice, but that's not actually necessary, it can, like, you can use, addresses, but let's say it's a degradation part, because it's more convenient.
Alessandro Baiocchi:And what happens is Alice will sign her transaction containing the user group she wants to execute, and the address of signer 2.
Alessandro Baiocchi:And sinex2 being the next address in the delegation path.
Alessandro Baiocchi:And…
Alessandro Baiocchi:what happens is that the smart contract holder will authenticate Alice, authenticate that the transaction is being signed by the owner, which is signer1,
Alessandro Baiocchi:And then, after executing the user operation, we'll change its owner to signX2.
Alessandro Baiocchi:And notice that we are just sending SENX2 address on chain, so the public key is still not being broadcast. This is just the address, there is a Nash in the middle, so we're still safe, even in a post-quantum world.
Alessandro Baiocchi:And what happens is now, Sanaguan Public Key is public.
Alessandro Baiocchi:And so is its private key, if the package is quantum capable. But, the smart contract wallet is no longer owned by San X1, it's owned by SanX2, so Sanc1 private key is now useless.
Alessandro Baiocchi:And this method can be integrated, basically making each keeper in the delegation path disposable. We only use it to sign one transaction, and after that transaction, the next signer will become active.
Alessandro Baiocchi:And this is a very simple idea. It's, the main appeal of this idea, it's simplicity. It relies on HCSA,
Alessandro Baiocchi:which has several benefits. For example, there is no need for product 11 changes, so no need in… to change anything in the scheme to use this. And using SCDSA has some benefits, for example.
Alessandro Baiocchi:We… we know it's a battle-tested signative scheme. It is classically, secure. We know it, up until now.
Alessandro Baiocchi:And, it has… it is cheap to verify on-chain, because it's the program standard for sign… for signatures.
Alessandro Baiocchi:And…
Alessandro Baiocchi:being the Korean standard for Signal means this is implementable as of today, without needing protocol-level changes. Of course, being this simple also has some
Alessandro Baiocchi:drawbacks, for example, we… the fact that we use, a PEC quantum, let's say ACCDSA, which is not a post-quantum signal.
Alessandro Baiocchi:Means that if the public key of a signer that still has not processed a transaction becomes public, for example, if the transaction is broadcast but reversed because of a wrong nonce.
Alessandro Baiocchi:Or the use of the public key is sniped from the mempool before the transaction is executed, the private key could become vulnerable.
Alessandro Baiocchi:But, for example, for the, the mempool example.
Alessandro Baiocchi:it's, the time frame for the attack becomes much smaller, of course, because it, it's, the attacker would have 12 seconds to… to… if you are on, on Ethereum, or if you're on L2, even less, to steal the private key, and, from the user, so even in that case, the attack window is
Alessandro Baiocchi:extremely reduced, even if the attacker has quantum capabilities. But in any case, it's important to acknowledge there are still, shortcomings that come from this simplicity.
Alessandro Baiocchi:As I was saying, this is implementable today, we did it, we started from a simple wallet, and we made a few modifications that allow us to integrate the user rotation feature.
Alessandro Baiocchi:And…
Alessandro Baiocchi:We tested it and deployed it on base Sepolia, so testing and gas measuring. We measured some simple object, a simple operation, which is XC20 transfer.
Alessandro Baiocchi:And we've seen that, with respect to a transfer made from an EOA, adding the whole account of Russian stuff, and with sign and rotation, adds less than 100K yes.
Alessandro Baiocchi:to the total cost of the transaction. And, of course, this comes without adding the whole account abstraction features. If you already have an account, smart contract wallet, and you just need to add the only accrotation, the cost is easily negligible, like, almost negligible.
Alessandro Baiocchi:And we also built a live demo, public demo, you can try at this link. It should be in the shot, and I'll leave it to Mattel for this one.
Matteo Vicari:This is a simple demo. We create, Smart Concept Wallet, through, a mnemonic.
Matteo Vicari:We create the mnemonic, okay? So we have the account.
Matteo Vicari:We mint some token to this account for, see all the transactions work on chain.
Matteo Vicari:And then we started to execute some transaction, we send tokens to one address, really simple. What we can see, there is an active signer, is the first signer, and then when we make a transaction, the send transaction, the active signer is not long one, but
Matteo Vicari:it becomes 1 to 0. If we do, every transaction we do, we change the signer. Pretty simple. This is really cheap, and if, for example, in the next transaction, we finish the balance of the token, so the transaction reverts.
Matteo Vicari:This revert is different, because this revert, it occurred inside the user operation, it's not inside the… for example, we finish the gas, or we put a wrong nonce. The transaction is still managed.
Matteo Vicari:and what we can see is the transaction also rotates the signer. If, for example, we go to the logs, we put any event that, show
Matteo Vicari:The rotation of the wallet.
Matteo Vicari:And, all you can see in the first tab, the gas consume of this transaction is, pretty low. Instead, the other solution.
Matteo Vicari:You can try, it's simple, all the demo is leveraging the account abstraction, you don't have to,
Matteo Vicari:put nothing, do all the stuff alone. We also have the discussion open inside at Research, so if you want to ask some questions or stuff like this, you can go there.
Matteo Vicari:So, the next step. We create, RC7579 modules for this feature, which I already put inside Git, so if you want to use it, it's there.
Matteo Vicari:And also, we want now working, mitigate some, some issue. For example, using the encrypto mempool for, or private mempool for not propagate the transaction, when we send the deficit transaction.
Matteo Vicari:And also, we want to try to address the problem to have the revert if the transaction, the old transaction is not executed correctly, for example, is going out of gas. And also, we start working, the comparability.
Matteo Vicari:of this system with the frame transaction. And then we want to
Matteo Vicari:Some edge case and stuff like this.
Matteo Vicari:Thanks for your attention. If you have questions or other stuff, you can send an email, there.
Matteo Vicari:We put all the link inside the chat.
Matteo Vicari:Dan, if we want to have some questions, we… in the last part of the… I don't know, work Antonio today.
Antonio Sanso:Thanks a lot, guys. This is actually a really nice, simple idea, but effective. Actually, I was really glad to learn they use, like, they can actually somehow hijack account abstraction with this simple idea and having something work.
Antonio Sanso:Great stuff. So if you guys have questions, you can leave in the chat, and we had actually a great segue for Lite Client.
Antonio Sanso:For a frame transaction that was mentioned in the last slide.
Antonio Sanso:So, I've seen Lite Client here before.
Antonio Sanso:If you're here, you can share your screen, and go ahead.
lightclient:Cool. Thanks, Antonio.
lightclient:Alright.
lightclient:Hey guys, I just want to give a high-level overview of the frame transaction.
lightclient:Today, I assume a lot of you have… Dean a bit about…
lightclient:the frame transaction, so I'm happy to also spend some time at the end and go more in-depth and answer
lightclient:Any questions that, that you guys might be having.
lightclient:In general, The reason that we are pursuing frame transaction today is…
lightclient:post-quantum, which is a lot of the reason that Antonio invited me to this call, I think.
lightclient:at many layers of the Ethereum stack, we're thinking about how to deal with quantum computing, becoming much more of a threat, and on the execution layer, we…
lightclient:Obviously, I have a lot of elliptic curve cryptography, which… We need to have…
lightclient:Clear solutions to deal with.
lightclient:And… The clearest one is the transaction signature.
lightclient:So, the frame transaction…
lightclient:is not the simplest way to deal with post-quantum. I think that we've kind of, like, seen this with other proposals on…
lightclient:adding different…
lightclient:cryptographic algorithms to the signature, to the transaction signature. There's certainly, like, simpler ways to do this if, you know, we're only trying to solve for post-quantum.
lightclient:But I think it's important to know that, like, even though the…
lightclient:primary goal of Frame Transaction is to…
lightclient:You know, begin this long migration of…
lightclient:accounts to a post-quantum world. We're also trying to do other things.
lightclient:And, in particular, we're trying to deliver
lightclient:this, like, broad account abstraction idea to the users of Ethereum.
lightclient:Because there are, many… there are many use cases that… that we believe are valuable that come out of that.
lightclient:And it feels like a loss to just solve post-quantum and, you know, not give users a lot of these nice new capabilities, which have been worked on as well for the last 6 to 8 years.
lightclient:So with that said, like, what… what is frame transaction? What's different about this versus, like, other ideas for native accounts abstraction?
lightclient:I think that, you know, the biggest thing
lightclient:to me about frames is that when we used to work on account subtraction before 7701,
lightclient:We always struggled with how can the protocol introspect
lightclient:The transaction, and, like, reason about it better.
lightclient:You'll probably see, like, I'm just gonna talk about the consensus
lightclient:Changes that need to be made to make frame transactions possible, but
lightclient:The complexity of framed transactions is often outside the protocol, in the transaction pool, and it was always a bit of a complication, like, how can we reason about
lightclient:how can we reason about the transaction in the transaction pool? And so with frames, we kind of had this insight, by looking at 7701 pretty deeply, and we kind of realized, as we were implementing 7701 that
lightclient:A lot of the different phases of 7701 are similar.
lightclient:you know, if there's a phase for the user to maybe deploy their account, there's a phase to validate the operation, there's a phase to, have the Paymaster validate the operation, execute the operation, all of these things. And so we realized that
lightclient:A lot of these things are, like, basically the same. We're just changing some environmental variables about the EBM.
lightclient:And that kind of led us to…
lightclient:thinking about this generalization, which we've kind of called frames. And yeah, this is a bit of a…
lightclient:You know, collision with the concept of a call frame.
lightclient:But in some ways, it is very much like a call frame.
lightclient:And, yeah, not to get them, like, too confused, we'll kind of see how…
lightclient:call frames play into it later. But yeah, we think about frames as, like, individual instantiations of the EVM.
lightclient:And we'll kind of see how that works out in a few slides.
lightclient:On top of the frames, like, we're trying to address, like, general concerns that the community has around the adoption of this technology, around the standardization of using this technology, and that's why we're also trying to add things like a default account.
lightclient:So the default account, as currently proposed, is not a post-quantum account. It's really just a very simple EOA account using the same cryptography that that Mainnet has today.
lightclient:But it gives users the account abstraction features that they kind of are expecting to have, things like, you know, native batching.
lightclient:And maybe we can add more things to this, like… Key rotation.
lightclient:And when the time comes where we have the post-quantum cryptography in the protocol as a precompile, and we're ready to…
lightclient:You know, kind of back a specific algorithm, or, like, a set of algorithms, then it might also be very possible for us to use the default account to help ease the transition for those users into using post-quantum cryptography.
lightclient:So that's a simple summary.
lightclient:Goals… kind of mentioned this as well in the simple summary, but, like, we need the answer to post-quantum on the execution layer. We're reusing a lot of the ideas in accounts abstraction. They go hand in hand.
lightclient:It's important to note that in Hagota, we have accepted Fossil as the headliner on the consensus layer.
lightclient:And we also believe that it's important that all
lightclient:account types in Ethereum can utilize these, like, new native functionalities. And today, if you want to use Fossil as a smart account, then you would have to wrap your operation or find a bundler who is willing to submit your operation to Fossil, to the Fossil mechanism.
lightclient:And so we want to make sure that users can use these native protocol features without finding intermediaries to go through, and without, like, you know.
lightclient:seriously degrading the… the UX that we're trying to create with smart accounts. So that's one other, like, big reason that, you know, we're talking about native account abstraction now.
lightclient:One final goal that we care a lot about in the frame transaction standard that, again, doesn't really have much to do with post-quantum, but has a lot to do with the user experience, is we do care about having trustless, permissionless gas abstraction.
lightclient:And this is kind of, like, building on all of the work from the ERC4337.
lightclient:Where they built, basically, this entire protocol.
lightclient:outside the protocol, on top of the Layer 1 and the Layer 2s, to do account subtraction without
lightclient:Even a protocol change. But it does create its own system, and depending on, like, the lens you look at it, like, there are intermediaries in that system. Yes, it has a path to being permissionless and decentralized.
lightclient:But it will always be bolted on top of the Layer 1, and so we believe it's important to try and dissolve that gap between
lightclient:The 4337 world and the native protocol.
lightclient:So that's another important goal that we are thinking a lot about with the frame transaction.
lightclient:Okay, what is the frame transaction?
lightclient:This is a diagram that basically shows all of the elements that exist in the frame transaction. I won't go into detail on every single one, because a lot of them are just standard values that exist.
lightclient:In particular, the, like, quote-unquote, outer values, this, like, list, chain ID, non-sender, etc, like, these are all things that…
lightclient:every transaction type has. With the exception of sender. And so, Sender is kind of, like.
lightclient:equivalent to the result of doing the EC recover on transaction signatures today, right? Like, we don't need to say who the transaction is coming from, because it's trivial for us to do an EC recover and determine this.
lightclient:With the frame transaction, we will want to make the validation
lightclient:arbitrary. We want to allow users to define whatever validation scheme they want. And so…
lightclient:In our case, like, we… we can't…
lightclient:always know how to recover the sender. Maybe there isn't, maybe the cryptographics doesn't allow the sender to be recovered, and so we need to kind of, like, understand who this transaction is intended to be originating from.
lightclient:And the reason for this is that
lightclient:in some earlier revisions of this standard, there was this idea that maybe the transat… you know, maybe we didn't need to think about a transaction as originating from a single person. Maybe we could just, like, be maximally generic here.
lightclient:And we could just, you know, treat it as, you know, a list of frames, and if the frames somehow coordinate and decide they want to pay for the transaction execution, we just let whatever happen happen.
lightclient:And an issue that we found with this is that it totally breaks the way that
lightclient:all of the clients, all of the downstream tooling, like, it's a 180-degree turn away from how people think about transactions. We think about transactions as something that someone sent, that some entity sent.
lightclient:And so we kind of realized it's actually pretty important to think more about a transaction as having one sender, rather than having, like, a list of senders.
lightclient:And so that was, like, an important, an important distinction that we… that we made early on.
lightclient:So that's the frame transaction object. I want to look more in detail about the frames now, because I think the frames are…
lightclient:The kind of novel part.
lightclient:Also, if you guys have some questions, feel free to just jump in. I saw some chat bubbles popping up.
lightclient:Okay.
lightclient:So the frame has 4 elements. It has mode, target, gas limit, and data.
lightclient:The mode basically says What… you know, it kind of conveys what the frame is attempting to do.
lightclient:And this goes back to the goal of having good introspection at the protocol layer about what a transaction is doing.
lightclient:And so right now, we have 3 modes. We have a default mode, which is basically just, it does a regular call.
lightclient:We'll see, like, some examples later, like, how exactly that one might be used, but it's basically just, like, a…
lightclient:It's a way to do some execution within your frame transaction.
lightclient:We have Verify, which is…
lightclient:The mode that signals the user is going to do some, like, cryptographic verification here.
lightclient:And… We, you know, don't… Constrain the types of cryptographic validations they do.
lightclient:But we do require that they, decide at the end. They make, like, a binary decision.
lightclient:is this successful or not? And they call an opcode called Approve.
lightclient:And there's a couple types of approves that we can have, and we'll look at this in a second, but basically, you can approve as a sender.
lightclient:You can approve as a payer, or like a paymaster, and then you can approve as both.
lightclient:And the analogy is probably, like, if you're approving as both, you can think of this as, like, a transaction today. If you sent an EOA transaction today, you are signing over the transaction and, like, implicitly approving both
lightclient:that you are willing to pay for that transaction, and that you desire to execute that transaction as the sender. So that's kind of what the, both
lightclient:the… the both,
lightclient:type of approved is. Then there's the sender and the payer that's kind of separating the two types of users there in this, like, paymastering world, where you might want to send a transaction, but you don't want to pay for it. Or you don't want to pay for it with ETH, you want to pay for it with a stablecoin.
lightclient:And so in that world, you might, have a verify frame which approves the, execution.
lightclient:And then a paymaster would have a…
lightclient:frame that approves the payment, the deduction of the Ether from the balance.
lightclient:So that's executed in a static call.
lightclient:That means that you can't actually write to any of the storage slots. You can read from storage slots. There's a lot of rules around what you can read that aren't encoded in the core protocol, so I'm not going over it in depth here, but are
lightclient:You know, applied…
lightclient:during the validation in the public transaction pool. And that's an important distinction, because in the public transaction pool, we want to have
lightclient:Robust transaction propagation, which is safe.
lightclient:And censorship Assistant, and permissionless.
lightclient:And that means that we have to constrain the types of interactions that users can come up with.
lightclient:But we want to keep that outside the protocol, because we don't want to pretend that we know the best way to, like, utilize these powerful primitives. And so we kind of allow a lot more things to happen.
lightclient:You know, in the protocol than would be possible in just the mempool.
lightclient:And…
lightclient:Essentially, what that means is that if you're a block builder, if you're an RPC provider, you might be able to come up with, like, nicer services to provide to the user, which maybe they can't go through the transaction, the public transaction pool, or maybe they can't go through the public transaction pool yet.
lightclient:Maybe it's something that, once we see that there's use of it, then we try to integrate into the public transaction pool.
lightclient:An example of this is something like a transaction assertion. If you want to assert at the end of your transaction that some behavior during the transaction happened and nothing else. Like, if you want to, you know, ensure that you swapped some token for Aave, and you received at least some amount of Aave.
lightclient:This would protect the, like, the swap that happened last week, where they…
lightclient:lost a lot of… a lot of money on an Aave swap.
lightclient:This is, like, kind of a revert protection style that could be offered by RPC providers or bundlers to users who have smart accounts.
lightclient:So we try to keep the protocol simple and very allowable, and then we apply more constraints in the transaction pool.
lightclient:So that's the verify frame, then the sender frame is the frame where the user action happens, essentially. This is, like, the permission frame where we actually set the message.sender to be the transaction sender.
lightclient:So if you, if you want to send an ERC token, an ERC20 token, then, you know, it's going to use the message.sender to authorize the send there. And so, the sender frame kind of, like, replicates that behavior that we have today with EOAs and with smart accounts.
lightclient:And that frame can only come after Verify has approved a sender, because, you know, you can't… you shouldn't be able to send a sender frame on behalf of someone… someone else. So you do have to go through, like, the verification process and calling approve.
lightclient:Okay, those are our three modes, our three, frame modes.
lightclient:Also in the frame is the target, that's, like, you know, the to address.
lightclient:to reduce on some call data, we also allow sending OXO as the TX sender, so that TX sender value just fills in if you submit, like, an empty target. Otherwise, that's, you know, the actual target address. And then we have the call data.
lightclient:And this gets passed in to that specific frame.
lightclient:We'll see a bit later, but one interesting aspect about the data is that for the verify frames, we allied the data.
lightclient:So, we actually don't allow the transaction to see what the verified data is during execution, unlike the other frames. The other frame types, you can look at the data, and you can kind of, like, reason about
lightclient:you know, is this person transferring ERC20 tokens? Are they doing a Uniswap transfer? Whatever. We don't… we don't allow this, for the verify, both in transaction RAM opcode.
lightclient:So, like, during execution, or with the signature hash.
lightclient:Which makes sense to a degree with the signature hash, because the signature hash is the hash that we're gonna sign. And so you can't… you know, if the verify frame call date is gonna have the signature, then you can't really…
lightclient:You know, hash the signature before you have it.
lightclient:One last thing to note on frames is that each frame It produces its own receipt.
lightclient:And this goes back to our, like, goal of trying to just make
lightclient:account abstraction more seamless for users. It's been a big complaint with 4337 that, you know, if you send a bundle of a bunch of users… user operations together, then it's very difficult to parse out which user operation is associated with which receipt.
lightclient:And even with batch calls, to a degree, like, users complain that if they submit a handful of calls and they get receipts for all of them, they are just jumbled together in one list today.
lightclient:And so with the frames, we're gonna introduce, like, per-frame receipts as well, in the receipt object.
lightclient:Okay, that's the frame.
lightclient:So the transaction param, this is an opcode that we're adding, which gives introspection about
lightclient:the transaction broadly, so it tells you basic elements of the transaction, gives you the max cost. These are things that help with paymastering, sponsoring transactions. There's, like, frame information, so you can get the current executing frame.
lightclient:And then there's the SIGH, which…
lightclient:it's a built-in function that constructs the hash of the overall transaction, you know, minus the call data in the verify frames. And we're hoping that, for the most part, wallets will use SIGH
lightclient:Directly, instead of constructing their own hashes for, you know, their own transaction hashes.
lightclient:For signing. And the reason is that we got tons of feedback from smart account developers saying that
lightclient:code to actually build a signature hash that's just really complicated for them. And it's, like, extremely critical, like, if your signature hash is poorly designed, or has, like, edge cases, then this is, like, a major security issue.
lightclient:And so one goal that we're trying to have in the frame transaction is
lightclient:have a… have good built-ins, have some batteries included, give the smart accounts a signature hash. They're free to freestyle if they believe they need more information in the signature hash, or they need a different type of signature hash.
lightclient:We don't treat them as second-class citizens, they're still first-class citizens, they just have to implement that logic themselves. For the vast majority of users, they get this, like, built-in signature hash scheme, which should work great for, like, 99% of cases.
lightclient:Any questions? I see a couple chat bubbles popping up.
Antonio Sanso:There's one on the chat, Matt, if you want to ask for now or later, it's up to you.
lightclient:Yeah, I can answer. I can answer now.
Antonio Sanso:So, basically, the question is, like, if the… if all the bundlers are gonna die, or move to the… to be broadcasters, like…
Antonio Sanso:The question is…
lightclient:Is… is that going to happen, or…
Antonio Sanso:No, if it's the bundlers are gonna die, basically.
lightclient:So the question is, will bundlers die?
Antonio Sanso:Yeah.
lightclient:I see.
lightclient:I don't think bundlers will die.
lightclient:It's a good question, though.
lightclient:I think that… It depends how…
lightclient:We implemented public transaction pool, because…
lightclient:Implementing the public transaction pool in a way where you can do paymastering.
lightclient:Efficiently is not the easiest challenge.
lightclient:And 4337 saw this. Like, 4337 defined this transaction pool. Like, we're using a lot of the ideas from the ERC7562.
lightclient:But it's not something that, like, is really in production, right? You know, no one is submitting user ops to the…
lightclient:4337 transaction pool.
lightclient:And I think it's because it's, like, it's complicated.
lightclient:Users don't value it too much, it seems. Or operators don't value it too much.
lightclient:And so it is a bit of a question, like, how much of this do we support in the core protocol?
lightclient:Over time, we'll probably add more support for… for it. But even if the core protocol does support it, which right now…
lightclient:We are proposing, like, some limited support of paymastering, of, like, you know.
lightclient:propagating Paymaster transactions in the public end pool. I think bundlers will still exist, because I think that there are many times where you have special relationships with particular bundlers.
lightclient:Like, if a bundler is willing to offer some service that goes above and beyond what the core protocol is offering, or if you're interacting with a dApp who wants to provide a specific service to their users, then I think, like, those bundlers will continue to exist. I don't really expect that type of bundling to go away.
lightclient:I just expect maybe over time, the type of bundling that goes away is, like.
lightclient:no, you know, I'm just trying to pay for a transaction with USDC, I don't care about bundlers, I don't care about a specific DAP, I just want to have this, like, kind of trustless interaction, then maybe that type of bundling starts to, like, come closer to the protocol.
Antonio Sanso:There's as well a question that's probably simple to answer. Is there a testnet already or not?
lightclient:There's not really a testnet. I think maybe ETHREx implemented frame transactions last week and said they had something?
lightclient:But there's no, like, yeah, there's not, like, an official playground yet for this. We're kind of working on that, hopefully in the next few weeks, that will exist.
Antonio Sanso:Alright, thanks.
lightclient:Cool.
lightclient:Yeah, we're trying to vibe code it.
lightclient:Alright, approve… So, the approve opcode is kind of the… driver of…
lightclient:Authorization in this new frame transaction world.
lightclient:It's only valid in the verify frames.
lightclient:this is mostly to do with the introspection that I mentioned, like, the point of the verified frame is for us to, like, kind of really know that what's happening in the frame is the, the approve, the, like, signature verification.
lightclient:So, if you call approve outside of that, then that's, like, an exceptional abort. The…
lightclient:The frame will immediately abort.
lightclient:And exit out.
lightclient:As I mentioned, there's 3 types of approves. The sender only, the payer only, and then both sender and payer. I think we've kind of explained when you would use each of those.
lightclient:Then, a few more constraints that we've put on top of approve.
lightclient:For one, we're forcing it to be invoked by the frame.target.
lightclient:That basically means that if you have a verify frame.
lightclient:You can reason about who is approving.
lightclient:A concern we had is that if you let anybody, any, any,
lightclient:Any contract call it, is that it might be very deep within the call stack.
lightclient:And it's harder for the user to reason about signing the transaction.
lightclient:It's harder for the protocol to reason about, you know, maybe balances of the target.
lightclient:So it just makes things a lot simpler to kind of know who is in question here for the approved.
lightclient:Then there's also an implied ordering of how approve happens. So, if you don't do approve to by approving both sender and payer, then you must approve the sender before the payer.
lightclient:And… I don't know if there's, like…
lightclient:I don't know if there's a specific use case that you would want the payer to pay before the sender, but in general, since we've moved to this, thinking that there should only be one sender per transaction.
lightclient:And we're kind of gating the entire validity of the transaction, you know, the ability for the transaction to continue to execute on payer.
lightclient:then it just doesn't make sense to potentially have the transaction valid for execution, but maybe it never approves the sender. Like, those types of transactions we just didn't want to support because it doesn't make sense in that framework.
lightclient:And so we've, basically created this implicit ordering.
lightclient:And you'll see in some of the examples that that makes sense.
lightclient:It's just, like, the natural way that people would want to use this.
lightclient:So then we get to the heart of the frame transaction proposal, which is how do you actually process these things?
lightclient:And we can go over this kind of quickly. It's, for the most part, fairly straightforward, and it's not important to, like, understand, every single detail.
lightclient:Deeply right now.
lightclient:But, essentially, you can think about it as you… we have a list of calls.
lightclient:We… instead of, like, thinking about block processing as we have a list of transactions, now we have another nested loop inside of it. And so, once we begin executing a frame transaction, we have this list of calls. And for each of those frames, we need to execute the call with the environment that's defined by the frame.
lightclient:So, the mode, we have to call the target address, there's the specified gas limit, we have to pass that data.
lightclient:And we're kind of doing all of this processing. There's, of course, like, the sender mode, where you set the message.sender equal to tx sender, like, all of these things. But the overall goal is just to, like, work through this framed transaction.
lightclient:to reach a point, in 2, which is making sure that… or, sorry, in the italic at the bottom, we're just, like, working through this frame, all of these frames, to find, when the payer approved is equal to true.
lightclient:And in the transaction pool, we have, like, pretty specific ordering of the frames that we would expect payer approved equal true.
lightclient:To be reached at, like, a pretty fast point, but we're…
lightclient:In the consensus protocol, in the, like, actual implementation.
lightclient:open to the payer being approved at the very end of the transaction. Like I mentioned, this transaction assertions idea, that could happen at the very end of the transaction. And so the protocol, when it's processing the frame transaction, it's just working through these frames, waiting till it gets to the payer.approved.
lightclient:until it reaches payer approved, like, it's continuing to execute. Like, if it's processing a block, then it has to just assume this block is valid until it realizes it's not valid. But the frame transaction, it assumes it's invalid until payer approved flips to true.
lightclient:So if you process all the frames, and payer approved is never flipped to true.
lightclient:Then that transaction is just invalid.
lightclient:And it's invalid in the same sense that, you know, if you were processing a block today, and you had an EOA transaction, and you saw that the nonce was not equal to the nonce that that user had at that moment, based on the state that you knew.
lightclient:you would also consider that transaction valid. And as a byproduct, you would consider that overall block to be invalid. And so frame transactions is, like, the same. It's just that instead of encoding the specific
lightclient:you know, nonce checking the specific balance checking, you know, instead of having that hard-coded, we are trying to allow people to define it arbitrarily. So that's kind of the, you know, main idea that you can take away from how frame transactions are processed.
lightclient:Happy to answer any questions on that, now or later. Feel free to just jump in.
Antonio Sanso:Right, one thing's, Matt, probably we will not… so we are kind of three-quarters of the calls, we probably will not have time to answer all the questions. I will copy some of the questions that, we don't have time to answer into the channel that I created.
Antonio Sanso:And, okay. Actually, like, I will have a question myself, and, how long is, like, the presentation lasting more? And, I'll tell you why, because, I want to…
Antonio Sanso:double-check with, with Dano, because, he had some, I remember, like, in one of the previous calls, he had some suggestions for, for the Freeman transaction. I don't know if Dan wants to…
Antonio Sanso:Have you interacted with him already about this kind of, of.
Danno Ferrin - Tectonic.xyz:Let's continue… let's continue with the frame transaction.
Antonio Sanso:Right.
Danno Ferrin - Tectonic.xyz:Discuss is good.
Antonio Sanso:Alright, now, yeah, just, like, be mindful of time. I don't know how much of presentation's still left, that's what I'm.
lightclient:I don't know, maybe, like, 5 minutes or something.
Antonio Sanso:Right.
lightclient:Okay, so, couple quick examples.
lightclient:simple transfer, like, you can think of the frame structure like this. We have a verify frame and a sender frame. Obviously, like, there's data in this, but if we're just thinking high level, like, this is what the frame structure would look like. So, you process the verification.
lightclient:you know, does the same type of stuff we do for EOAs today, and then we have senders, the sender frame, and that processes the actual operation for the user.
lightclient:A more complicated frame structure that we kind of recognize is this paymaster transaction. This is sort of what we've been talking about a lot through this whole presentation. But basically, we can think about it in these five frames. This matches super closely with how 4337 works, and how 7701 was proposed to work.
lightclient:So basically, in the first frame, we do the, approve0, so that's the sender approve. It's kind of like the entry point calling the validate user op.
lightclient:Then we do the Paymaster signature.
lightclient:You know, they check the overall transaction to make sure, is this a transaction that we've signed?
lightclient:and that we, you know, expect to get paid, paid for, you know, or whatever the agreement is, and then that is approved one. And so at that point, like, payer is approved, so, like, those first two frames.
lightclient:have completed the entire, like, validation of the transaction, and then the remaining 3 frames are just the execution of the transaction. So you process, you know, any ERC20 token payments.
lightclient:Then you do whatever user operation that the user had desired, and you finish with any post-processing. So maybe you refund some of the ERC20 if all the gas wasn't used.
lightclient:So that's kind of, like, a more complicated example.
lightclient:Future work that we're thinking about is the… is doing signature aggregation. So, obviously, like, post-quantum signatures are very large, and we want to keep the bandwidth light.
lightclient:So, an important goal of 8141 is to…
lightclient:Support that, be future compatible with that.
lightclient:We're not… it's not something that's, like, likely to happen in A141 itself, the frame transaction itself.
lightclient:But we also need to make sure that what we do in frame transaction isn't going to inhibit our ability to do it in the future. And so, basically, our idea today is that if we allied the data in the verified frames from introspection, that means no one can depend on the data.
lightclient:And if nobody is depending on the data, that gives us a lot of, a lot of latitude in the future to actually change what that data is, remove that data, etc.
lightclient:In the future, hopefully, we have block builders that understand some of the, like, validation logic, and are able to parse out, post-quantum signatures from call… from the verify frame call datas, and then construct aggregation on those signatures.
lightclient:it's still a bit TBD, like, how do you expose this back to the EVM to know that that frame was valid? And there are some ideas there, like, you can either do this, like, you know, still execute the frame to a degree, but somehow, like, have an opcode that pops validation results.
lightclient:Or you, like, you know, inline the validation results without having to, like, have the entire signature in the transaction.
lightclient:Alternatively, like, maybe there's, like, some ZK proof that we can, generate just over the verify frame, so instead of, like, having to execute the verify frame at all, all we do is, like, have this, like, one ZK proof that proves all of the verify frames, for all transactions in the block.
lightclient:So those are some ideas that we're thinking on signature aggregation.
lightclient:Curious to, like, know what other people think about this, or if they have any good ideas here.
Antonio Sanso:Coincidentally, today, we published, actually, a post on aggregating signatures using Labrador, so we're Falcon signatures, so Labrador is specific to Falcon. Well, there's some… it's not as good as BLS, but yeah, you can see the… I put the link in the chat as well.
lightclient:Okay, cool. I'll check it out.
lightclient:Yeah, so that's pretty much it.
lightclient:Just in summary, frame transactions are agnostic to the exact post-quantum algorithm.
lightclient:It would be great if we had something to bundle with it in Hagota. I don't know if people on this call think that there will be.
lightclient:A specific algorithm that is sufficient to, you know, sufficiently ready to
lightclient:put as a precompile in Hagota, but I think that that would be a great opportunity to say, you know.
lightclient:Prime Transaction is trying to support people who are doing post-quantum, but also there's, like, now kind of an efficient way of doing it. Maybe it's not, like, EOA levels of efficiency, but hopefully, like, orders of magnitude improvement over what we have today.
Antonio Sanso:Right, we are… probably you've seen as well the strong map, that we are kind of targeting I-Star, but maybe this might tie together with the previous presentation of Matteo. That potentially will be ready today, right? Because it's just, like, an ephemeral way of using elliptic curve signatures.
lightclient:Right.
Matteo Vicari:Yeah, it will be now nice to work with the frame transaction and our idea. We… first step, work on account abstraction today, but we won't jump also in the frame transaction. It's very interesting to have,
Matteo Vicari:This kind of instrument for making the frame more secure also.
Antonio Sanso:Anyway, thanks a lot, Matt, for the presentation. This was really nice.
Antonio Sanso:I don't know, again, like, just, like, summarizing, like, in the… some of the previous call, like, Dano had, some kind of idea. I don't know if Dano, since you have a lead client here, if you want to… to share some of your ideas, or
Antonio Sanso:We can take this offline.
Danno Ferrin - Tectonic.xyz:So, I did publish, EIP, well, it's in PR mode right now, 8197, which is the structure of the CADX transactions I talked about on the first call.
Danno Ferrin - Tectonic.xyz:And, if one of the concerns is stripping signatures, I mean, this EIP was written for the idea that all signatures could be stripped from any transaction format. It separates the body from the signature, so the,
Danno Ferrin - Tectonic.xyz:The frame transaction will be written as a payload, and instead of putting the signatures in line, you would reference which signature number in the signature section it's referencing. And that makes it much easier to strip the signatures and replace it with a ZK stub that says, I am this address, and I am this index in the ZK aggregation, and all the information that's necessary to run it through the ZK proof.
Danno Ferrin - Tectonic.xyz:So that's kind of, you know, approaching from a completely orthogonal lead of what frame transaction is doing with account abstraction, and focusing more on how do we separate the specific signatures from all transactions, not just the new frame transaction.
Danno Ferrin - Tectonic.xyz:And so that's, you know, there is a way the frame could come in and use that if it wanted to, but I think the future needs. My experience is we're going to have to look into signature aggregation.
Danno Ferrin - Tectonic.xyz:Or the blockchain is going to need to, like, 10x its data load, which is also not a…
Danno Ferrin - Tectonic.xyz:you know, above and beyond, that's just for signatures, not even for payload. These post-quantum signatures are going to be large, we're going to do other fancy things, like store,
Danno Ferrin - Tectonic.xyz:Store the keys in the accounts, the public keys in the accounts, and have the transactions
Danno Ferrin - Tectonic.xyz:it's… there's so many unresolved questions that making it so the transaction is not deeply embedded in the trans… the signature is not deeply embedded in the transaction is something that's going to provide lots of, ease future… in the future. So, that's kind of, you know, what I wanted to talk about, and…
Danno Ferrin - Tectonic.xyz:You know, there's not much to summarize beyond just that, that
Danno Ferrin - Tectonic.xyz:Separating that, and so to put it in the frame transaction, you just…
Danno Ferrin - Tectonic.xyz:would reference this table on the outside for your signatures, and honestly, there's only two frame types. Do we even need to have the verified type? There's only ever going to be two types, and you can just assign them to type 1 and 2 if they're always present? There's just some design questions that come up with that.
lightclient:There's 3 types, right?
Danno Ferrin - Tectonic.xyz:default, which does both. There's… there's execution, payload, and then both payload and execution. You're never gonna have more than two frame… two verify frames in a frame, right?
lightclient:Oh, I see, I see.
lightclient:I don't think so.
Danno Ferrin - Tectonic.xyz:What are the constructions that would have more than two verify frames?
lightclient:So, originally, we, like I mentioned, we…
lightclient:Imagine that you might have multiple, senders in transaction, and so in that case, like, you would have, like, multiple verifies, and you, you know, if you had a batch of many user operations, many different user operations, you would verify that, and then do a sender frame as that user, and then you have a new verify to change the
lightclient:authorized to sender. But since that's not really part of the standard anymore, I don't see a reason you would have multiple verify frames.
Danno Ferrin - Tectonic.xyz:You'd have one for Paymaster, you'd have one for Execute, and that's the maximum.
lightclient:That's the max that I can imagine.
Antonio Sanso:Right. Anyway, the… I think, like, if there is something to be accommodated for the specific post-quantum signatures, I think there's still, kind of.
Antonio Sanso:space, right? I mean, I think, frame transaction is targeting Agota, so if there's something specific that will be… need to be done, there's still time, right?
Danno Ferrin - Tectonic.xyz:Yeah, and it could just be as simple as rewriting the frame transaction, not specifically within CADX, but to have the transaction signatures outside of the mainframe, so it could be stripped. Another thing that the CADEX does is
Danno Ferrin - Tectonic.xyz:the bytes that go into the hash are actually in the transaction. You don't have to rewrite the transaction. And that's another source of friction that's going to cause a lot of bugs, and so we keep asking people to rewrite transactions, someone's going to screw it up.
Danno Ferrin - Tectonic.xyz:So if we keep the bytes to what is in the transaction as a subset string, as a slice.
Danno Ferrin - Tectonic.xyz:That's gonna make things, less bug-prone.
Antonio Sanso:Is there any breakout room for a frame transaction? Stuff like this could be discussed?
lightclient:We don't have a recurrent one, but we're thinking of doing another one next week before ACD.
Antonio Sanso:Okay.
Antonio Sanso:So…
Antonio Sanso:Right. So, Dan, maybe, like, if you are strong on these ideas that would be useful, you can… Right.
Danno Ferrin - Tectonic.xyz:Well, and the craziest idea, which isn't that crazy, actually, is to make, make it an SSD transaction, and then you can do a partial proof and just get rid of the signatures that way.
Antonio Sanso:Right, again, like, probably it will be more… more appropriate to discuss this on the frame transaction. And I have a question, myself. Do you think, like, you were saying that for Agota will be a really nice use case to have some post-quantum transaction error. This probably is not gonna be…
Antonio Sanso:possible, but I probably wasting already the question before. Do you see, like, any chance to have, instead of a real post-quantum signatures, a kind of
Antonio Sanso:Ephemeral signature, like the presentation before, will be a use case, a valid use case for…
lightclient:Yeah, definitely.
Antonio Sanso:I mean, again, it's not going to be real post-quantum, but having the ephemeral key should be enough from the beginning.
lightclient:Yeah, I mean, that's the nice thing about the frame transaction, is that we are making room for people to define a validation in any way.
lightclient:And that lets people innovate.
lightclient:And find the best solutions, rather than us trying to decide, a priori, what the, like, preferred cryptographic algorithm is gonna be.
Antonio Sanso:Alright, so…
lightclient:This is a good option, if that's what's available in Hagota.
lightclient:As new options come around, we can add precompiles to do these things, and if there are trade-offs, like, some are compute-heavy, some are data-heavy, like.
lightclient:We can get… let the users decide, or, like, let the users' wallets kind of make those trade-offs, themselves, rather than the protocol just having, like, one uniform way that this is how it's done.
Antonio Sanso:Beautiful. Dano? Did you raise your hand again?
Danno Ferrin - Tectonic.xyz:Yeah, I just wanted to chime in with the ephemeral transactions. One thing that if they're going to use ECDSA keys, they probably need to put in their security stance and consideration of long exposure versus short exposure, which is the approach that Bitcoin's taking right now. So that would, you know.
Danno Ferrin - Tectonic.xyz:I'm not wild about using ECTSAs in the light of the coming CRQCs.
Danno Ferrin - Tectonic.xyz:But…
Danno Ferrin - Tectonic.xyz:you know, if you frame it properly, it has a longer shelf life, and that's what the approach Bitcoin staking with their longing short exposure.
Danno Ferrin - Tectonic.xyz:Which is basically what you're pitching.
Antonio Sanso:I mean, if I understood correctly, like, they're exposed, the, the public, really, for a few seconds on the, on the, on the, on the main pool. Yeah. Yeah.
Matteo Vicari:The problem is, the only… you are exposed only in the man pool.
Matteo Vicari:So, on the new type of manpool with the frame transaction, if we can have small windows, or we use a private manpool, or encrypted manpool.
Matteo Vicari:This, window is, more…
Matteo Vicari:The problem with the HEDSA is the long-last term. If a user make one transaction to 27, you have the time for front-run the transaction.
Matteo Vicari:break the cryptography. It's a lot in a few seconds. I, I don't know. I know.
Danno Ferrin - Tectonic.xyz:And that's the…
Matteo Vicari:No, it's a problem.
Danno Ferrin - Tectonic.xyz:But that's the exact argument that Bitcoin's making for their BIP360 right now. So they have a lot of security analysis going in there that could probably bolster your position if you speak to it properly.
Matteo Vicari:Hmm.
Antonio Sanso:Anyway, I think we're at time for this week again. Matt, I will ask you, let's ask you a favor, like, in copying some of the questions, we will not… we're not having time to… for today in this new chat.
Antonio Sanso:And if you could join lately, late, later, and Android will be again.
lightclient:Sure.
Antonio Sanso:Okay.
lightclient:Thanks a lot for having me.
Antonio Sanso:Thanks for your presentation, thank you guys for joining, and see you in two weeks, and we'll be about hardware wallets.
lightclient:bio.
Matteo Vicari:Thank you.
Antonio Sanso:Thank you, bye-bye.
Matteo Vicari:Bye bye.
Conor Deegan:Thank you.
Alessandro Baiocchi:Thank you, bye.
Miha Stopar:Hi, thank you.
Chat Logs
00:13:35
Fireflies.ai Notetaker Andriia:Andriian invited Fireflies.ai here to record & take notes. By continuing, you agree to https://fireflies.ai/privacy.
Type:
'/ff pause' - pause recording
'/ff leave' - to stop recording
View Realtime notes here: https://app.fireflies.ai/live/01KKVTXT6D8KKR9BZD6B8H70PR?ref=live_chat
00:14:55
Antonio Sanso:https://t.me/+ozVdiAeQleBhZDg0
00:21:45
Matteo:https://nicetry.xyz/
00:22:13
Matteo:https://ethresear.ch/t/achieving-quantum-safety-through-ephemeral-key-pairs-and-account-abstraction/24273
00:25:04
Oleg Lodygensky:The beauté of simplicity 🙂
00:35:15
Renaud-ZKNOX:It is possible for FALCON to have a recovy like ecrecover
00:36:00
Benedikt Wagner:Replying to "It is possible for F..."
Yes, there is a mode for that. Falcon spec Section 3.12: https://falcon-sign.info/falcon.pdf
00:38:03
Renaud-ZKNOX:A réagi à "Yes, there is a mo..." avec 👍
00:44:29
Renaud-ZKNOX:Seems great.
It seems lighter and solving a lot of 4337 complexity.
Are all bundlers gonna die ? Or move to be broadcasters like ?
00:45:54
Renaud-ZKNOX:Other question: is there a testnet for this ?
00:48:50
Giulio:Just vibe code it
00:49:21
Renaud-ZKNOX:A réagi à "Just vibe code it" avec 😂
00:50:55
Renaud-ZKNOX:Are the APIs designed to facilitate migration from 4337 to frame ? (having cross the styx, would like it to be easy,or would say easy for Claude :D ).
00:52:36
Giulio:Curiosity: have you found a way to make mempool validation sane since last ACDE?
00:54:01
Renaud-ZKNOX:Ultimate question: what is the cost of a frame transaction, compared to a 4337 one ?
00:54:43
alan xu:Will frame tx only increase the nonce of the sender, not the nonce of the payer ?
00:55:05
Antonio Sanso:I am probably going to move the unanswered questions in the telegram channel (assume we do not have time for all)
00:55:30
Renaud-ZKNOX:Could you give link to tg plz ?
00:57:19
Antonio Sanso:https://t.me/+ozVdiAeQleBhZDg0
00:59:16
Antonio Sanso:Aggregation wise we released this post today https://ethresear.ch/t/revisiting-falcon-signature-aggregation-for-pq-mempools/24431
01:00:00
Danno Ferrin - Tectonic.xyz:The validation frame gets the signature in the calldara, correct?
01:02:04
lightclient:Replying to "The validation frame..."
Right now yes
01:09:31
lightclient:If you frame it right ;)
Summary
15 highlights
· 3 action itemsExperimental
Summary
15 highlights · 3 action itemsExperimentalephemeral key rotation
frame transactions
- Frame transactions (EIP-8141): native account abstraction targeting Hegotá00:26:05
- Frames enable protocol introspection; three modes: default, verify, sender00:28:04
- Sender field required in transaction; validation fully user-defined00:35:15
- Per-frame receipts address 4337 UX complaint of jumbled logs00:42:19
- Signature aggregation compatibility: verify frame data aliased for future ZK/aggregation00:58:15
post quantum readiness
- Frame transactions agnostic to PQ algorithm; allows user/wallet choice00:25:50
- Falcon supports key recovery mode (ecrecover-like) per Section 3.1200:35:15
- Labrador aggregation for Falcon signatures published today on ethresear.ch00:59:16
- Hegotá opportunity: bundle PQ precompile with frame transactions01:00:41