Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, Web3 Galaxy Brain is now accepting sponsors. Podcast sponsors get a unique opportunity to speak directly to influential EVM devs whose decisions have ecosystem-wide impact. If you're trying to increase adoption of your dev tooling, hire for a new position, or get the word out about a new initiative, Web3 Galaxy Brain sponsorship is one of the most targeted and cost-effective ways to get your message to the brightest builders in and around Ethereum. Email sponsor at nftstory.life for pricing and details, or DM Nicholas with four leading ends on Telegram. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Today's special episode is a roundtable discussion about EIP-3074, auth and auth call, and EIP-4337, account abstraction using alt mempool, two very different approaches to enabling smart contract accounts. To discuss the past, present, and future of 3074 and 4337, I'm joined by Matt Garnett, aka Light Clients, a developer contributor working on GoEthereum, Gregory Marcoux, aka Greg the Greek, CTO at blockchain development firm ChainSafe, and Joseph DeLong, CTO at Astaria and former CTO at Sushi. It was fantastic getting these three talented and opinionated developers to the table to discuss the social and technical processes it takes to improve the EVM. My thanks to Pedro Gomez for helping. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Light Client, Greg the Greek, and Joseph DeLong are all here to talk about 3074 versus 4337. I'm very excited. Are you guys excited?

Joseph Delong: Totally. Yeah.

Nicholas: I can hear it in your voice. Okay. I'm ecstatic. This is as ecstatic as it gets, huh?

Joseph Delong: Nothing like the antics, you know, EVM mob codes.

Nicholas: Oh my God. This is going to be a great one. Okay. So today, Light Client will be repping 3074. Greg the Greek will be repping 4337. And Joseph, I think, will be taking pot shots opportunistically. Is that right? I don't know.

Joseph Delong: I think I'm all in the, on the 3074 camp. Oh, really?

Nicholas: Okay. Wow. Okay. So it's two.

Gregory Markou: I'm actually in both. I think they have their specific. I actually think they each have their own unique benefits, but I'll get into that in a bit. All right.

Nicholas: Awesome. So we're going to have a variety of opinions. Before we get started, just in case, you know, maybe there's listeners who don't spend all day on Twitter. Maybe let's run through the room. And if you can just say where you work, where you got your handle, and maybe what it is about blockchains that motivates you. I think that'll help frame the conversation a little bit. So maybe we start with Light Client. Matt Garnett, where are you working?

Matt Garnett: Hey, thanks. Yeah, I'm working on the GoEthereum team these days. I've been with them for a little, like a year and a half now. Before then, I worked at ConsenSys on a team called Quilt. That's where we did a lot of our work around 3074 and account obstruction. We worked on this EIP-2938 three or four years ago now, and yeah, still trying to push these things along however I can. And I got my handle by trying to find a nice GitHub username because I used to be called Color with hyphens between every letter. And the people I was working with at the time said that they couldn't be bothered to type all those hyphens anymore. So I had to go on a journey to find myself a new name. And I think Light Clients are pretty neat.

Nicholas: UX improvement.

Matt Garnett: Yeah, that's what I live for.

Nicholas: And yeah, what is it about blockchains that motivates you primarily? If you can narrow it down to one thing.

Matt Garnett: I like that. we're creating a new way for humans to organize. We've never had the ability to have unstoppable agreements between different humans. And so I think that's a pretty interesting aspect of it.

Nicholas: Awesome. All right, Joseph, you want to go next? I guess your handle's not that exciting, but where are you working?

Joseph Delong: That was my Christian name, you know? So yeah, I co-founded a company called Astaria. We work on NFT collateralized lending. And I cut my teeth and, you know, eat core development. And that's why this subject really interests me in particular.

Nicholas: Great. And that's what about blockchains excites you too?

Joseph Delong: About blockchains? Yeah, I think what Matt said is pretty interesting. Yeah, self-sovereignty, like the ability to basically, there's no like, there's no real, like, legal layer for mediation on it. And I love that aspect.

Nicholas: Great. And Greg Marku, Greg the Greek, where did you get that name?

Gregory Markou: Hey, hey. Yeah. I'm really big into frat life. A long, long time ago, like in high school, maybe before that, it was just a play on of someone else doing like their name and their like nationality or something. So I'm Greek. That's, there's not much more to it. Got it.

Nicholas: And ChainSafe, what does ChainSafe do, and what do you do there?

Gregory Markou: Yeah. I'm one of the co-founders of ChainSafe and the current CPO, and so I focus on the product side. You know, we do a bunch of stuff in terms of the R&D world. So we kind of got like our claim to fame, so to speak, when we were building reference implementations of different blockchains. So for like Ethereum Consensus, Polkadot, RM. And Filecoin. And then outside of that, we maintain a bunch of libraries in the Unity space. And as well as we've been maintaining some like Web3.js for the last couple of years. But I could ramble for a while. But anyway, yeah.

Nicholas: And what is it about blockchains for you?

Gregory Markou: I mean, I think everybody else kind of already hit it. I think one of the more interesting sides, though, for me right now is the fact that we're able to work on so many different pieces of like new emerging tech. And I mean, as in, you know, like an engineer, developer brand. But originally, the ability to work on all that cool stuff is amazing. But with the amount of capital injection we're getting, we're honestly like advancing a lot of different parts of technology so much faster than they would have happened before. Like ZK probably wouldn't even be around right now if it wasn't for us. And I'm really excited for like things like that.

Nicholas: Awesome. All right. So I guess maybe, Matt, do you want to get started? Or you guys tell me. But I think one of the things that I'm really excited about is the fact that, you know, one first question might be like, where did 3074 come from? What was 2938? Matt, you want to take that?

Matt Garnett: Yeah, I can give a pretty quick summary. And then we can just dive into the debate. Or I guess I can give an introduction to 4037. But yeah, so 2938 was born out of some work that we were doing with ETH2 Phase 2 execution And it was sort of a combination of some ideas that had come from there and some ideas early on from Vitalik. From the very beginning, I think even in 2015, Vitalik had this post called On Abstractions. And he talked about trying to build a blockchain that abstracted as many of the different elements as possible. Because that was really the special thing about Ethereum was that you had this virtual machine and you could create any kind of abstraction that you wanted. And so with 2938, we tried to take those ideas that he had had about, you know, you know, about abstracting what accounts were and what it meant to have a transaction included on chain and sort of. come up with this minimal idea of how could you completely abstract the validation logic in a transaction. Because that's really what account abstraction was back then. It was we wanted to abstract the cryptography or the way that we decide the transaction for certain accounts is valid. And it's more to mean a lot of different things. Since then. But that was the original thought process. And so 2938 was this relatively simple EIP that proposed a way to integrate account abstraction to the core protocol. And it addressed like a lot of the problems of 4337, you know, that just generally comes from account abstraction. And 4337 sees these things particularly around. how do you deal with denial of service attacks on bundlers. And in 2938's case, denial of service attacks against the miners or the block builders since we didn't really have the concept of bundlers back then. And we found some interesting things there. And some of those things were brought into 4337. And around that time, we realized that 2938 wasn't really going to fit into the hard fork meta in the near future. And we started looking at other ways to try and improve that. And so I went down this rabbit hole of trying to come up with these like bespoke transaction types that would allow for people to sort of aggregate the operations they wanted to do into some like batched transaction type. And it allowed for somebody to sponsor that transaction. And it was a super rigid thing. And at the same time, my co-worker Sam Wilson was thinking about similar things and also, you know, with 2938, there wasn't really a good way to sponsor accounts abstraction transactions. And so he was thinking maybe there could be a combination there. And so Sam actually came up with this idea for 3074. It started out as a pre-compile and sort of morphed over time. I came on board like relatively quickly because it seemed like a really good idea. And it sort of morphed over time to this thing that we have today, which has these two op codes and takes a signature from EOA and lets that EOA perform with other tasks. On Ethereum. And so 3074 isn't really accounts abstraction like the truest sense, but in the way that a lot of people have come to understand what accounts abstraction is, which is like really allowing smart account features, things like batching of transactions, things like recovery of transactions, 3074 does provide those things to most users.

Nicholas: Great. And do you think you could explain like in detail the off and off call and really how 3074 works, what the proposal is?

Matt Garnett: Yes. So the proposal for 3074 introduces the two op codes, like you said, off and off call. And the TLDR of how those two op codes work is auth takes a signature, an ECDSA signature, and does a recovery on that to figure out who signed. It takes a signature and then the message. And so it does an ECDSA recover to figure out who signed that message with that signature. And it saves that address, the signer, into some sort of context variable within the EVM inside your frame. Inside your frame, you have a lot of other contextual information, things like the memory usage, things like who the message sender is. And so we just extended it to include the currently authorized account. And so after you have used the auth op code and you've recovered that address into this context variable. Then you can use the auth call op code, which would perform a call just almost exactly like the normal op code. call works, except instead of the message dot sender being the contract which is invoking auth call, it's actually the sender set to be the signer of the auth message.

Nicholas: And this is a relatively simple idea.

Matt Garnett: It's a very powerful primitive, which allows externally owned accounts to sign arbitrary messages. It's totally just, it's just up to the smart contract, which we call an invoker because it is invoking the auth and the auth call op codes. It allows the EOAs to bestow a lot of power upon an invoker to do complicated tasks, things like transaction batching. And so you can imagine you write a smart contract that says, if I receive a signature over a batch of messages, then I will verify that that signature over the batch of messages, make sure that's correct. And then I will give it to auth, which because the signature was already correct, we know that the auth will set the next sender to be this address. And then I can call auth call and I can just go through a for loop and iterate through each of those operations and execute them in this batch form. So there's a lot of more advanced ways of utilizing auth. And I think there's like cool things that can be done, like signing one message off chain and using that later as an account recovery mechanism. But that's kind of the rough EVM level description of how it works.

Nicholas: Great. I don't know if Joseph or Greg, you want to jump in with any more context on 3074?

Joseph Delong: I'd just say for 3074, the interesting aspect for me is that it essentially lets another contract like LARP as you, as the, as the, like the messaging. It's kind of like theandash.origin which would be the normally the signer or, you know, whoever signed for that message. And, and like, basically, that, like, it's such a simple solution, right. Like I would say that the original sin of, you know, Ethereum was ERC 20 approvals. And this essentially like undoes that aspect. In fact, I can't actually count the number of hours that I've spent fighting the approval abstraction in contracts because it basically creates you. You need to be the message dot sender to approve in ERC-20s, 721s, and 1155s, but you don't have that ability to do that as a contract. Basically, whenever you go to Uniswap or wherever, and the first thing you do is an approval transaction, the reason that you have to do that as its own transaction, is because of that design. That's the key piece that this eliminates. Yes, I think 3074 definitely enables a pathway for account abstraction, but it's not explicitly account abstraction. It has properties that allow individuals to develop their own account abstraction. I think an appropriate analogy might be something. EC-Recover allowed us to build EIP-712 and not the other way around. It's a simple tool that's used to make maybe a more complex standard.

Nicholas: Just to clarify, basically, once you authorize a contract to act on your behalf, that contract can be the TX, or you will still be the TX origin when a transaction is propagated by someone other than an EOA?

Joseph Delong: Yes, totally. You'll still be TX origin, but you're allowing that contract to act as message.sender, whoever signed the message. Typically, what we're saying is that's going to be the same person who's TX.origin.

Nicholas: Got it. Maybe could you spell out exactly how that solves the approval problem that you were dealing with?

Joseph Delong: Yes, totally. If I have an invoker, then I allow that invoker to act as me. I allow it. I allow it to act as my EOA. That invoker contract can do an array of transactions. There's actually no real design constraints on being able to execute multiple meta-transactions in a single transaction using one contract. That's actually a pretty common design. The problem is that the approvals always have to come. You have to be able to execute multiple EOAs from the message.sender, and then by basically letting the invoker wear the message.sender mask of me, my EOA, I allow it to do approvals, and then in the next step, do something like the transaction that you actually want to do. Maybe it'd be a swap or whatever.

Nicholas: Got it. Greg, I don't know if you wanted to jump in here.

Gregory Markou: Yeah, I mean, the elegant design of 3074 is that it protects EOAs. It protects EOAs and doesn't require users, in the sense that you don't need to move funds, change wallets, migrate accounts. Everything's just there for you, because it's fully backwards compatible to the existing EOA model. That's what I really like about it, is that on 4337, in order to really use it, you have to go through that process of saying, I am comfortable and ready to migrate all my funds from maybe my cold storage wallet. To a brand new smart contract wallet.

Nicholas: So 3074 is basically adding functionality, adding the ability to delegate to contracts, but without requiring a transition process.

Gregory Markou: Yeah, exactly, which is honestly the really, really nice aspect of it.

Nicholas: So we should get into talking about 4337 and give the high level of what it is, but why did 3074 not, or why has it so far not had traction in the same way that 4337 has, if it's so much simpler?

Gregory Markou: Core devs don't want to add new EIPs, sorry.

Joseph Delong: My impression is that the research began on 4337, and that was a preferred design, but I think the initial research on that design began with, I would say, to steel man. the 3074 case, is if I can allow a contract. To LARP as me, right, then I can basically have the user sign one transaction that can like, you know, it can like yoink all of their assets from their wallet, right? So that's, that's a, that's a pretty huge design flaw. But I think that the 4337 design initiated essentially from a standpoint of, oh, you know, we don't have that kind of like design flaw, but essentially it's a, it's an emergent property. Of account abstraction that, you know, allows you to do this. It basically, every, every account abstraction design at its core, like has the same fault, right? And, and 4337, I think started from the standpoint of like, oh, we won't, you know, we won't be vulnerable to such a thing and, and kind of, and eschewed, you know, 3074 is, you know, kind of being exposed to this vulnerability. But, you know, now. Especially with, with the talk of enshrinement, you know, it's, it's basically subject to the same, the same exploitation. Okay.

Nicholas: So I think we should give an overview of 4337 now. I don't know if Greg, you want to take this, but what is the abstraction in account abstraction in terms of 4337?

Gregory Markou: If I would like, if hand-waving and giving a very light example, 4337 is effectively supercharged meta transactions. Okay. What's, what's really happening under the hood is that you have a, a 4337, the standard defines a smart contract wallet, kind of similar to Gnosis Safe. And it defines a few extra parameters on how someone can interact with it. And so there's kind of like two key players in this ecosystem. There are now what we call paymasters and there is an entry, an entry point contracts. Entry point contracts. Entry point contracts act as this gateway. that is very similar to how Matt described the 3074 invokers. So it's this gateway contract that allows paymasters or EOAs just own like the owner of like an EOA as an owner to submit transactions to their 4337 wallet. Very lightly put with a gate, with an entry point, you can, uh, a paymaster who's doing, kind of like meta transactions, so to speak, can just sponsor your trend, your operation on your behalf via the entry point contract. So it adds this like trustless layer of allowing people to, um, do that. That's basically all it is in essence.

Nicholas: Um, there's a lot of stuff built on top of it. Yeah. It introduces like, it's a much more complicated thing in the sense that it introduces like a whole new mempool of these user operations. Right?

Gregory Markou: Yeah. Yeah. So like that mempool doesn't really exist right now. It's just a, it's just a centralized services. So you kind of, you would pick your service provider and just submit the user, the signed user ops to that service provider. We don't have really a decentralized mempool. That's, that's more in the wishlist to come section of it.

Nicholas: I see. Uh, I don't know if anyone else wanted to jump in at this point.

Matt Garnett: This might be a good moment just to say that comparing 3074 and 4337 isn't. A completely fair comparison because they are doing a bit different things. And maybe an analogy could be that 3074 is like a screwdriver and 4337 is like a full tool set with a box of screws and a manual for best practices for using your, your hardware. And I say that because I think that 3074 would like to, to utilize the screwdriver to utilize 3074. To the similar extent you would have floor 37, you would have to do a lot of similar things. And so this infrastructure they have around the pay master, this infrastructure that they're trying to build to come up with a permissionless transaction pool of user operations. This is stuff that 3074 as a good protocol, only EIP doesn't discuss at all. It is really just a tool that can be used by people who want to build more fully featured ecosystems. Whereas. 4337 is a much more opinionated application level standard, which is trying to repose what this whole world would look like. But I think that's why, I think that's why these things look a bit different. I do think there are benefits to 3074 versus 437, but the simplicity aspect, I'm not sure if it's like a completely fair, uh, argument for 3074.

Nicholas: I see. And if we were to like strip away some of the additional. Um, parameters that are, are suggested by the spec in a 4337, what are the kind of design philosophy differences between 3074 and 4337 at the basic level?

Matt Garnett: I think in 4337, it tries to be a more account driven design. And what I mean by that is if you look at the control flow graph of a transaction that utilizes 4337. Then you'll sort of see that the machinery will go through that accounts wallet. So there will actually be an account in the state try, which has some smart contract wallet code. And after the pay master processes, the validation, it will call that accounts to execute its transactions. And so as you're following that control flow graph, you go from the pay master over to your smart contract wallet, and then your smart contract wallet will then send it to batch of. User operations out to the various smart contracts, and that's a nice story. And it's extremely clear if you're able to look at that kind of flow in a graphical way, but, uh, 3074 takes a different approach and it's a little bit more validation focused. So I wrote a post a few years ago in response to a post Vitalik had written sort of critiquing 3074. And. I proposed a bit of a different way to think about what a smart contract wallet should do, or, you know, what is this special thing that they're doing? And the argument I tried to make was that smart contract wallets, really what they do is they do validation. And so we should lean into that. And so for EOAs, we don't really need to call anywhere to validate if an EOA signs something properly, because we already have this cryptographic mechanism available to us with EC recover. And so it's. Sure. Straightforward to just figure out, uh, if an EOA signs

Nicholas: something correctly,

Matt Garnett: but for a smart contract wallet, we would in the 3078 world for a world have to call out to that smart contract wallet and ask them, is this a valid signature for the domain it's signing and for like, whatever your, uh, special access policies are. And then it would come back to the 3074 invoker. And then that invoker would process that, that, that user's operations. And if you look at that in a graphical. Way, it doesn't really look as clean and nice. Like there's kind of this, you know, leg that goes out to the wallet and it comes back to the invoker and the invoker does some things and you sort of have to tilt your head and look at the from address on those calls to see that's not from the invoker. That was a special call from, from the wallet. And so, yeah, in that sense, there's some critiques that it's a bit hacky. It's not as clean from the theoretical sense. It might require. A different way to fully reason about how, how things are, are, are acting in the EVM. And so, yeah, I think that that would probably be the best way to just describe those differences.

Gregory Markou: Yeah, I think the, like the biggest fundamental differences, like, because they are solving two different problems, 3074 allows us to take existing key pairs, like from the, from the, uh, like sec P curve and just basically say there's, and basically I'll just like, give us like

Nicholas: full control

Gregory Markou: over effectively just message that sender. And that's the benefit, right? It's gives like sec P message that sender privileges throughout smart contracts to like basically fix bad standards set in the past. And I think that's like the key difference. Whereas like four, three, three, seven is just saying, Hey, we need to. Standardize how smart contract wallets work. And in doing so, we've added a bunch of like additional complex logic on that. for like, and like, I see four, three, three, seven is like onboarding, like an onboarding tool. Whereas like 3074 for like the next, you know, like, you know, cliche, well, like next million people or whatever, but it's actually is, cause I don't think we're going to see traditional key pair, like sec P curve key pairs being used in the next, like two years. Whereas like 3074 is entire, like the real meat and where it like gives us a huge benefit. Is to say like, let's still allow sec P curves to have usefulness and get around bad, smart contract design patterns that have like emerged.

Joseph Delong: Right.

Matt Garnett: And I don't want to come off and act like I'm a big K you know, K one bull. I think that trying to move to pass keys and trying to move to other ways of authenticating transactions is something that good and something that we should be doing. Yeah. For me, something that 3074 really provided that I think the four, three, three, seven is still not quite provided and that we're generally lacking is that it creates a, a really easy and straightforward shelling points for wallet developers, application developers, smart contract wall developers to focus their energy on developing standards around wallet interaction. I mean, even with all this four, three, three, seven stuff, and you know, it seems like every season is like accounts abstraction season. We don't really have a lot of native integration of accounts abstraction with dapps. And I've asked for a long time if we could have, you know, something like unit swap where instead of doing this weird thing where you just treat every operation as if it's going to be a transaction, like it would be for an ELA and you just like aggregate them into your noses safe. And then you send that off later. Once you've got enough. Operations, I would rather be able to see like in the UI that this is going to be two different operations. And if you have a wallet, which supports a batching, and it's going to submit that as a batch, and if you have a wallet doesn't support batching, like it either way, then this is, these are going to be, you know, two continuous transactions sent. And I think the reason that we don't have that type of, uh, work happening is that the U user base of smart. Contract walls is still really small in comparison to EOAs, you know, especially if you think about it in terms of volume transacted and like who are the most valuable users. Um, and so 3074 to me unlocks every user on Ethereum to interact with dapps in a different way. And I think that's just the big catalyzing thing for developers. Like the developers don't want to put a lot of work in for something that's only useful for safe user. Which are, you know, whatever, a small percentage of total users that is, they want to build stuff that's useful for everyone. And so if all of a sudden everybody had a smart contract account, uh, a smart contract wallet account, then I think they would be more excited.

Nicholas: That's interesting because you're saying that basically by 3074, because it's offers such an, if adopted would offer such an easy upgrade path or not even an upgrade, no, no upgrade required that suddenly everybody, all existing install base would be, um, like potential users of something like a smart contract wallet. Um, but it does, it does, it does treat the, like with the four, three, three, seven, it seems like we're moving to really separating the notion of wallet or signer from the account more clearly than it was in the, uh, easy recover world. I don't know if you have any thoughts, anybody on that.

Gregory Markou: So, I mean, like, first of all, I do like to like, make this clear that I don't like the word account of the phrase account of traffic is super, super nuanced, like depending on the ecosystem here. And, and how you do it, it's very differently done. Um, I think like near and substrate, for example, have like really elegant key management solutions natively that offer and give what I think is like what account abstraction should look like. Um, four, three, two, seven is just smart contract. Well, it's, but to answer your question, I mean, the benefit of four, three, three, seven on like standalone is simply the fact that we can now submit arbitrary. Like not arbitrary, but like very different key sets. Right. And that's like why pass keys are making such a huge wave right now. And I think that's the important part is like, this is just a giant UX unlock for onboarding. And that's why I also think 3074, I think honestly, once four, three, three, seven lands more officially and kind of like cements itself, we're going to see a 3074 like EIP. If not 3074 land is land into the EVM to basically unbrick. Standard sec P EOS, because they're going to, that is going to be a fundamental problem.

Nicholas: When you say you mean K one? Yeah.

Gregory Markou: Sorry. K one. Yeah. That's a much better, elegant way to say it. Cause like, they're going to be, they're not going to be bricked, but they're going to be, there's going to be so many problems with like actually the existing key sets on K ones.

Nicholas: You're saying post post enshrinement, even a four, three, three, seven.

Gregory Markou: I mean, I, as much as I like four, three, three, seven, I think enshrining it is a big ask.

Nicholas: Oh, so why would the K one, why would they be bricked? Why would the K, why would the K one, uh, keys be bricked by four, three, three, seven?

Gregory Markou: Not necessarily, not bricked, that's the wrong usage of terms, but I mean like their functionality is just so limited compared to like what's available through four, three, three, seven. It's going to be like pretty obvious that like 3074 adds, cause here's one of the big counterpoints I think Vitalik even made was the, that entry points or sorry, the, was the, um, Matt, what do we call it? The contract, uh, the invoker. The invoker was going to be like a bit of a security question, but like entry points are the exact same thing. That's a huge, like, you know, everybody's using the exact same audited entry point. There's no problem here. I think four, three, three, seven will pave the way for the 3074 like EIP to get back in and basically give superpowers back to K one wallets, which are like the, the, like the standard, just like, yeah.

Matt Garnett: I mean, I think that's a, uh, it's a good take and I think it's important to highlight that 3074 and four, three, three, seven are not mutually exclusive things. You could totally have a world where a 3074 invoker implements a similar interface that the paymaster requires. the, sorry, the entry point contract fires. And I think that's a pretty interesting world because like Greg said, it does unlock a lot of functionality, which hopefully gets built up. Uh, around this fourth, three, three, seven ecosystem back to the people who have EOAs, like, I don't know, we're kind of demonizing having an EOA, but having an EOA isn't necessarily a bad thing. until it's extraordinarily cheap, if not free to have a smart contract wallet on Ethereum, then we're going to continue onboarding a lot of people with EOAs. And I don't think that's a bad thing and I don't think there's that much that we can really do about it. And so we should try to embrace it by allowing them important functionality like batching. And social recovery and, you know, I can highlight another one of Greg's points, four, three, three, seven is not going to get enshrined into the protocol as it currently stands. I've looked at the EIP proposal and it's just a far beyond anything that has been included into a protocol change in the refund path. So I mean, it's an extremely big ask to add onto that.

Gregory Markou: It's an extremely big ask. If we. Can't even get BLS pre-files, which I've been fighting for, for like, I mean, I gave up on the fight. I think Alex Stokes took it over and like, I think he's even given up on that fight and it's been like three years. So like the EV to get enshrined into the EVM is unbelievably challenging because of the amount of security overhauling that needs to be done. And I just don't think that. That'll happen. Not anytime soon.

Nicholas: How many humans need to be convinced of something for it to be enshrined? Roughly.

Gregory Markou: Oh, you're not going to bring up this, are you? You just, oh God.

Nicholas: I'm just curious. Like, is it 50?

Gregory Markou: I would say you, I would say you need to convince all the core developers that need to wake up at like 2 a.m. Because your EIP that you tried to enshrine into the protocol. Was incorrectly spec'd, which is the argument why BLS didn't make. it was because there was some really, really funky math. And I believe, um, one of the, I believe it was Martin from Geth was just like, listen, like. I can kind of understand this, but I don't think anybody, any other protocol developer can. So what happens when there's an implementation bug in it and the more complex you're enshrined. Ask is into a protocol, the less chance you're going to get, to get that enshrined.

Nicholas: So it's not so much about the number of people, but their degree of caution. Yeah.

Gregory Markou: It's just like how many people can save a chain split at 3 a.m. And how much knowledge do you need to be able to do that? You know, if jump or call had an, had a bug, you got like, it could be fixed pretty quickly. Cause like everybody understands how that works. Right. Like anybody could probably patch that bug and submit it to the client that has a problem. But if you have a super complicated 437 implementation enshrined in the protocol and it fails, I don't know how many people would be able to just like make that patch, review it and get it back out in time. It poses a huge, huge chain liveliness concern.

Joseph Delong: That's interesting. I mean, um, like, uh, I mean, how many, how many, um, core developers do you think understand? Uh, SCCP two 56 K one, like fully like in the math and bounds and everything. There's lots of, you know, gotchas in that design as well. Um, yeah, but I think we're, we're okay with that because we've had it. Sorry. No, I'm just like, yeah, just if we're okay with that because we've had it for forever or, or is it just, you know, um, well, I think that, I think the difference there is like, that's crypto that's been rolled and hardened.

Gregory Markou: Right. Versus like. Or trade code, but like, I also agree with you. I mean, I think the big thing with BLS, maybe that's what you're hinting on is the fact that like the problem with BLS was just like that curve and the way it was doing like the G one G two point was just super new. And it was just like, yeah, that's a good point.

Joseph Delong: Yeah.

Gregory Markou: Crazy math, you know? Yeah.

Joseph Delong: I think BLS is something like 10 years or less old. Right. It was like 2014 or something. Yeah.

Gregory Markou: And I mean, I think there was only one reference implementation when you and I were still, when you were, and I were working on what was each two at the time.

Joseph Delong: Yeah, that's how we did our, our client. Yeah, we, yeah, exactly. Yeah, exactly.

Gregory Markou: Yeah. There was only one implementation that anyone could use. So like, that's the pro that, that's where the problem is. And like, you can translate that back to the four, three, three, seven and trying that, like, there's not many implementations of it.

Joseph Delong: Yeah, totally. I mean, if you look at other protocols out there for enshrinement that are a lot more aggressive with enshrinement, like flow, for instance, uh, is, is a great example. Some of their base. Uh, primitives like a, um, fungible and non fungible token are, are, um, uh, are, are, uh, pre compiles, um, that are, uh, that are accepted or sorry, are enshrined. And I think that's pretty great. We waste a lot of gas on, um, ERC 20 transfers and seven 21 transfers and 1155 transfers and optimizations around those. Like how much like developer. Like. Yeah. EVM developer time has been wasted, like trying to optimize, uh, ERC 20s instead of like enshrining them as a, as a, like, uh, uh, primitive.

Gregory Markou: Oh, I, I, I have no idea, but probably a stupid amount. I mean, like I made, like, I made that website, like what, uh, approvals.wtf just to like, see how much wasted approval gas you've spent. And it was like, some people were returning like multiple single digit values of these. I can be nice about that stuff. I'm trying, you know, but I think it's a problem of just like having an old network, right? That's why most of the researchers are telling everybody to just like, not use Ethereum anymore and just use it as a settlement layer so that these L twos can get innovative. Like, I think it's like been pretty innovative on AA.

Joseph Delong: Oh, interesting. I, from what I've seen, like on the, uh, optimistic roll-up side, they, they appear often to be more conservative because they're kind of like wanting to be. Maintain compatibility between the, the base layer and the L two. They

Nicholas: are talking about, uh, OP stack in 2024, adopting seven, two, one, two ahead of L one, or maybe if L one were ever to do that, but the L twos do seem to be experimenting with that kind of thing, given they're trying to onboard a broader number of people. It's just the R one curve. Um, Greg, you mentioned that near and others have interesting or more elegant account abstraction solutions. Can you. Say what? Appeals to you about those?

Gregory Markou: Yeah. Um, so like in near, for example, they have this like disassociation of your account and the keys natively in their VM. So you would, you like register an account against, sorry, you, you like, it's kind of the idea of like key rotation or adding owners, but it's like natively built into the protocol. And so you really simply put, you just are basically like. Like registering a key, like a key pair against, um, an account that holds balances and things like that. I mean, so they have that built natively and, and substrate doesn't have it necessarily yet, but the way they do their key management allows you to be quite expressive. Um, and so there's been some nice designs that have been put out there, but I think like the near design is quite nice. Uh, ZK sync also has, um, a pretty decent implementation there, which the clave team. Um, uh, it's been like really spearheading a lot of efforts.

Nicholas: Hmm. Oh, they're also coauthors on the seven, two, one, two, uh, EIP. So essentially that's like an, like something like an enshrined four, two, three, seven in the sense that, but it's, it has a kind of canonical account implementation, I guess, is what you're saying on near.

Gregory Markou: Yeah, I mean, yeah, exactly. And I'm, and you know, four, three, two, seven, again, covers it's four, three, two, seven is mainly about the like TX pool, TX ops and the entry point coverage. Right. Whereas the, and that's why I don't say it's like, like true account abstraction cause it kind of structure would be that like your keys. The way your queue interacts with the account natively is by default.

Joseph Delong: Um, very configurable.

Gregory Markou: Right. And that's what near does. for example, is they have that like really configurable right at the base layer, um, without adding all this additional added complexity on top. Right.

Nicholas: I mean, I guess one thing we were getting to through this conversation is the direct comparisons. Okay. between 3074 and 4337 are not appropriate, but maybe their intentions are something that we can contrast. So 3074 mentions that UX improvements are ancillary and that the leading motivation is really the sponsored transactions. And 4337, as you're saying, is more about this user op mempool. I don't know if anyone has any observations about those two different motivations and why one is proving more successful or I guess your personal interest in either of them.

Joseph Delong: Somewhat controversial, I think, in recent years, we've allowed more of this less decentralization and more, I would say, if we're reflecting on MEV and the direction that we've gone with that, we're kind of allowing there to be, I don't know if I want to call them centralized operators, but operators who particularly benefit from, let's say, if it was like builder-proposer separation or bundling, right? And I think that EIP-4337 goes a lot more towards that direction and kind of like creating an environment where a centralized operator can take some like advantages as opposed to kind of having more of a decentralized mempool.

Gregory Markou: Yeah, I mean, that's a really good point. And I don't think that's a bad point. even controversial i think that's straight up. the case is that we have become very complacent with saying that you good 10x ux upgrades to ethereum uh can happen like very really lower level at the core and like with wide adoption with a with a mass amount of potential centralization attached to it. but i think like all blockchains are kind of going down that road a little bit. but you know we just have all the adoption like you know 100x more adoption than everyone else and it is quite a little bit sad um to see that path.

Nicholas: i guess while we're in this kind of neighborhood uh any hot takes on whether r1 is uh compromised.

Gregory Markou: what's r1?

Nicholas: uh sccp like the past keys curve they just.

Joseph Delong: they take k1 but they change the the. whatever the seeds are for it right but they're.

Nicholas: they were defined by the nsa.

Gregory Markou: and is that p256 or whatever?

Nicholas: yeah p256 and the nsa has supposedly lost the strings that were hashed to generalization those seeds but there's no open process about them. anyway some people are some people use that as a reason for skepticism about integrating it into blockchains for example.

Gregory Markou: wait are you serious?

Nicholas: yeah it's the same curve it's just got.

Gregory Markou: uh got these? no no but like the nsa developed p256 and allegedly lost it. that's like an action.

Matt Garnett: i mean this is why i think bitcoin originally used k1 and why we used k check to p256. yeah since they're kind of the sort of in state of the cryptographic mechanisms but before it gets the nist stamp. um personally as long as to me as long as it's not part of the core protocol in the sense that this is like how transactions are instantiated then great if people feel good using it they should be able to use it and i think we should have a pre-compile for

Nicholas: it. right makes sense for people who are interested in this. uh there's an episode of the podcast security cryptography whatever it was shared to me by uh leo lunesu. uh the episode's called jerry salinas deserves a raise with steve weiss and it describes how this uh cryptographer who passed away in the last year or two jerry salinas who was working for the nsa and is the one who came up with those seeds. um claims to have just forgotten but the the seeds came from him hashing a phrase that was something like jerry salinas deserves a raise but he could never. he could never figure out what it is. at least that's the story that he told before he passed away. so if you're interested security cryptography whatever is the podcast uh but yes i see what you mean um about. you know there could be a pre-compile. as long as it doesn't compromise the essential chain. uh security then it's just whichever smart contracts decide to rely on it. it's their problem.

Joseph Delong: isn't it a little bit crazy that there aren't any? like like blockchains and crypto people are probably the largest consumer like cryptographic devices in the world and like that there isn't a secure element. that's k1 and that like that feels like insane a little bit if you think about it.

Nicholas: from what i understand you're bringing out your tinfoil hat. from what i understand it's nothing wrong with the trusted execution environments in a hardware. it's just that the software doesn't provide k1 apis but there's nothing in the hardware that prevents them from doing so. oh interesting that's what i was told by someone who understands more. uh that person leo lunesu who previously worked on p256 incorporation or a contract for p256. he wrote a p256 smart contract uh verification contract in like three or four years ago and uh he has told me that there's nothing in the secure enclave for example that prohibits it from having a k1 signing. oh interesting for people who are interested about that. there's another episode of this show all about 7212 where you can find out more about that stuff. uh any other like. uh crazy i have some questions from the audience. i want to get to in just a second. but any uh hot takes or controversial opinions you want to provoke each before we get to those. joseph you're all out of controversial takes.

Joseph Delong: yeah i mean i mean like. yeah i just would say that the centralization around or like like not i guess not. centralization like capture right that's happening around. um different parts of our protocol are like our derivative from our own inaction to kind of like solve the core protocol problems like how many companies have raised on eip 4337 like we're you know there's probably like 30 or 40 different eip 4337 wallet providers.

Nicholas: you're saying the premise of those fundraisers is that they must be able to convince vcs that there is some possibility for capture at the other. totally yeah yeah 100 i mean i want one. i like a counter point might be that it is sort of the next generation of accounts wallets. it's the next gen wallets seem to be coming out of this 4337 movement. so maybe the next metamask is one of them. it has a certain kind of capture but it didn't prohibit things like wallet connect or 1193 from emerging. that kind of mitigated its amount of capture of the early software wallet market.

Gregory Markou: yeah but all these service providers that are bundling 4337 paymasters and doing smart contract deployments and forcing developers to go use the proprietary apis so they can discover the 4337 wallet because there's no standard way to find them is precisely the problem. and that's why in pbs flashbots runs the market because there's like no other convenient way to do it. the capture is like there just because of convenience.

Nicholas: right. and maybe maybe there's something similar with centralized sequencing and the hypothetical access to a trapdoor. but in practice? how many trapdoor? uh how many times have transactions been included via the trapdoors on these popular networks? maybe zero.

Joseph Delong: how many times have we had a fraud proof?

Matt Garnett: it's a deterrent joseph.

Nicholas: okay it's a little off topic but i want to ask you do you think that all of these optimistic roll-ups are a house of cards? and if there was ever some kind of censorship? or if the centralized sequencers go down are they? is there like a cascading problem that's going to happen across all of these uh roll-ups?

Gregory Markou: or is there a chance that optimistic or otherwise i don't know how l3 4 5 and 6 is the exit if the l2 fails? i've never gotten a good answer.

Nicholas: what if base stops producing blocks? right? does it have a consequence for the assets in hop for example like are the hop? lp is just gonna take the brunt of it and it's no problem? or will these assets that are you know on i? it just seems to me like a huge problem. i don't understand it well enough. i'm curious if you have ideas.

Matt Garnett: i mean technically if the sequencer of an optimistic roll-up goes offline to retain the safety and aliveness there should be a way to post things to l1 and have them processed on the chain by anyone permissionlessly? do they do that? does it? is it implemented? does it work? i don't know. but if it doesn't then that's not really the optimistic role design.

Gregory Markou: are you able to then recursively go down like to other like l2s threes and fours that are attached sequentially to those chains? then yeah i guess you would be able to prove those.

Matt Garnett: i think technically you could.

Gregory Markou: but what is an l3? an l2 anchored to an l2?

Joseph Delong: yeah that'll that'll. that's one that you could probably raise some money from venture on.

Gregory Markou: is a l3 any vcs here? i uh chain space raising on an l3?

Nicholas: no i think is it orbit that does that? it's supposed to be a l24 l3s to build on top of specifically closing my ears.

Gregory Markou: i i i know i mean i know of some teams that have a roll-up attached to base which would qualify as that. technically.

Nicholas: do you think there's anything substantially better about these optimistic roll-ups given the amount of centralized um sequencing etc. dependencies? that makes them substantially different than when everyone was complaining that polygon was misbranding its pos chain as an l2 when in fact it was a side chain? are they substantially better than side chains if in practice nobody on this call believes that they'd be able to keep the chain going. if those centralized parties stop participating they're way better because you have an exit scheme but only if your assets are rich. only third l1 native assets. but the premise of all this is that people will be working directly on l2s with l2 native smart contracts. so where are you exiting to?

Matt Garnett: i mean if the system is constructed correctly there should be an escape hatch that is triggered from l1. i'm not saying that's how they are implemented today but i know that optimism on the optimistic role of fund are aware of these things and have the general structure if they're not actively working right now.

Nicholas: but that that would apply to like bridged usdc for example.

Gregory Markou: okay i'll answer your question directly right now. i know exactly where you're going with this in the interoperability space. if you are performing a mint burn style bridging directly across the canonical bridge you are safe if you use a bridge that likes to mint burn their own token and then the same would apply for liquidity pools on that as long as like the assets are like coming through the canonical chain. the problem is when certain bridges designs decide that it's more efficient for them because it might be on revenue based or they want to get volume based to not use the canonical bridge natively for the best security path then you are exploiting you're you're circumventing the hatch. so when you do a bridge when you're using bridges the best thing to do is to make sure what is the safest security path to take and that's always canonical bridges. then it would be full consensus zk proving bridges then it would be like client-based ones and an npc all the way down.

Nicholas: but that's still uh depends on the premise that the assets are native l1 assets. right like if you have arbitrum or polygon native usdc there's nowhere to exit to uh polygon.

Gregory Markou: well okay usdc doesn't count though because you have ccip.

Nicholas: oh i don't know i don't know how that relates.

Gregory Markou: yeah that's their like that's the usdc. okay we'll use us we'll let you. well let's use die because like that's a better example.

Nicholas: let's do it.

Gregory Markou: usdc has its own settlement layer that's like access interoperability layer to ensure that mishaps are i see easily fixable.

Nicholas: so there's a big off-chain dependency that solves it for them. basically oh yeah huge huge i mean so. so a native asset or like i mean just. it seems to me like there's some kind of cognitive dissonance in the premise that we're going to onboard a billion people by them interacting directly with l2s or threes whatever. let's just stick to l2s for a second. but if the assets that they are interacting with let's say they're making nfts and they're interacting with friend tech and other kinds of interactive apps that live primarily on an l2 no exit for those assets.

Matt Garnett: right i mean just create a wrapper on l1 and create a proof that says i was the owner of this.

Nicholas: on l2 i don't know if the friend tech native smart contracts are compromised in the sense that their sequencer is no longer producing blocks and coinbase disappeared or something.

Gregory Markou: but it but wouldn't like through 4844 like data availability posting like wouldn't you be able to just prove some given state on the on it from that blob data to then like recover any data on the l1?

Matt Garnett: i mean you still need to prove against the state route from the l2 and that state route might be in a in a blob as part of the state update. but if it's like an optimistic world like the state update still needs to be accepted by the settlement contract and to be accepted you would go past the um the challenge period for the fraud proof because until then you know you can't really create a proof about something because you don't know if it's going to be fully accepted. yet

Joseph Delong: my my other two cents about l2s is like is like we we relied on them to scale ethereum but really did they scale ethereum like we inherit the security of l1 but like now we need all they on l1 and all they on l2 and this other l2 and this other l2 and they all need liquidity. and then like each individual l2 if it gets too busy it has the same scaling problem problems. well not not the same scaling problems but it has you know some finite upper bound for scaling. i actually don't care about the the centralized sequencer. i don't think that's. um uh you know as big a deal as as people make about it. i mean if there were fraud proofs it would be you know a lot better but you know um the uh i don't think l2s really provide scalability. they just fragment all the liquidity and then you know they fragment all the interactions to different l2s and then there's like this l1. there i i just don't i don't i don't see it.

Gregory Markou: you know what though? i'm gonna throw the burden on like wallet developers though and adapt developers for continuing to think that. uh the web3 architecture stack is still looks like a web 2.1 where there is a single client and a single server back end where the representation of server is a single. blockchain like this is not 2017. you know there's we have. you can very easily blend all these assets together and treat them as a single asset and i'll step on this further. it's like the fact that when i go on a wallet today and i look at my eth balance and i have like five different l2s connected plus ethereum mainnet and it represents all six of those networks as having a different total amount of eth and i can't see the total amount of eth is fundamentally the problem. i think this is also i think the interactions between l2s are completely solved if we just abstract away the fact that and accept the fact that like everything is just a unified asset across it. you know if you want to go make a swap from eth to like usdc the wallet and the interface should just be aggregating the whole every single chain and finding just the cheapest bundle across your entire wallet portfolio to like make that swap happen like you shouldn't. as a user.

Nicholas: the fact that we have a network switching tab still is beyond me for sure especially in metamask it only shows one letter of the name of the network. but um that all depends on the fraud proofs etc. the security of these l2s being decent enough that you can abstract it away entirely for the user. but if they are fundamentally different and not particularly great any of them in practice then it's a little bit scary to start just saying well eth anywhere is the same.

Gregory Markou: if it's not really i mean if it has a canonical bridge with the alleged escape hatch that matt described then it is.

Nicholas: um i want to.

Gregory Markou: i think also west and eth should be represented as the same asset but that's a different story.

Nicholas: yeah wrapped wrapped tokens are terrible ux for regular people. um i want to do.

Matt Garnett: 74 can get rid of the west.

Nicholas: how?

Matt Garnett: so bingo there's a sorry we can get to. no no let's do it but how does it kill west? tldr there's a really two years ago on eth magicians called getting rid of west using 3074 and it requires a specific version of 3074 which is not currently what's being proposed in the eip but it's just a small difference that allows us to transfer ether from the account that is authorized and so the way this mechanism would work is sort of like the approval mechanism for an erc20. you would send this new west contract an authorization which would just be a signature from your account and it would put in storage that authorization so that at a later point whenever some application that you're using needs to use uh west then you would do a transfer from and it would look up your old signature that you had previously submitted. pull that out of storage and then give it to the 3074. uh off op code. and because it was a signature signed by you then it will say okay this person's authorized let them do the off call and with the off call you would provide a non-zero value and so it looks like an erc20 token. but it's actually pulling the ether out of your eoa account and so no need to have ether in west just have it in your account. always simply authorize it one time.

Nicholas: that's very cool. um are there any other 3074 applications that are uh spicy tasty that we should uh mention before we get into the questions from the audience?

Matt Garnett: i think that's definitely the spiciest one. the thing that i am most excited about is the fact that with 3074 what you could do for onboarding a new user is you could have as part of the onboarding process say sign this message. that would allow some you know threshold of other wallets to perform an action on your behalf aka recover your account in case you lose your key. and so you know you can imagine a world of metamask. you start up you get your seed phrase. you know. list five people. you know three out of five of them could help you recover your account. and then all you have to do is save that message. they could save it in the cloud somewhere. it doesn't have to be posted on chain. it costs you nothing. but at some later points as long as you can get that message back from whatever medium you stored it on you could relay that on chain with the signatures from your friends who are going to help you recover your account or whatever recovery mechanism you want. and then your eoa like it sort of solves a problem of like.

Nicholas: i lost my but it doesn't solve. my ledger was like my. uh pk is compromised. my seed phrase is compromised.

Matt Garnett: right it doesn't solve. my pk was compromised.

Nicholas: that seems like the big sort of deficiency we kind of alluded to it earlier the idea that post 457 you could imagine 3074 revisited um and then enabling eoas to point to to to have off and off call to enable a kind of smart contract wallets on top of it. but if you don't get key rotation it seems a little bit deficient. right as far as the smart account uh dimension

Matt Garnett: there i mean yeah we could debate this for hours and hours but ultimately i think that if you had your private key on us on a ledger on some sort of hardware wallet and you put it in the ground six feet deep and you authorize some other accounts to do things on your behalf which 3074 allows then it starts to look a lot like a smart contract wallet. yes there's some private key that if you dig it out of the ground you could use it to bypass whatever restrictions you put up. but hardware wallets are kind of safe and most people aren't getting targeted by sophisticated attacks on their homes. so i think for like 90 of the use cases it kind of does the thing that people want.

Nicholas: uh all right let's let's flip to the audience question. so kate with a c on farcaster asks what implications do 3074 and 4337 have on state bloat?

Joseph Delong: um i would say for 3074 like it like in an ideal world 3074 and 4337 have a lot of implications for 3074 and 4337 have on state bloat or combined with eip-1153 um or 4337 combined with eip-1153 that would allow us to do ephemeral approvals. um would reduce state bloat because um there would be no approval storage anymore.

Gregory Markou: um yeah wait do you mind repeating the question? sorry i uh someone called my phone.

Nicholas: yeah it was just a 3074 and 4337. how do they uh impact state bloat?

Gregory Markou: oh absolutely terribly. 4337 is a lot of absolute disaster in its current state. absolute chit show. um i call this. i put a tweet out today and had like thanks to matt and also and some other people reviewing. uh we launched two eips today for 4337 to help with discoverability. um the gist though is like currently today you cannot detect a 4337 that's been deployed by a third-party provider so that can be like you know like by economy alchemy like capsule and you know these like third-party providers or like me just deploying you for fun over. like a 4337 it's impossible to discover that an eoa has one like not possible. and so i i've dubbed this practice because i see it a lot in the gaming side which and honestly just in like hackathons and everywhere which is called um detect or deploy where people and their apps are just like natively through like zero dev just saying didn't don't see it see a 4337 wallet. through my own specific way of looking up if you have one then make a new one. make a new one yeah oh my god you should go look at like sapolia or girly. there's probably like a bazillion implementations of them. it's absurd like absurd death by a thousand accounts. i stole that from somebody's talk at wallet on con on friday. but like literal death by a thousand accounts no no shade.

Nicholas: but uh it certainly improves your numbers if you encourage someone to deploy a new account rather than oh yeah so do you have these? are you vcs?

Gregory Markou: if you want to you know hire me for to do some due diligence for you.

Nicholas: yeah i guess true enough. but so your eips that you're presenting would essentially what um emit an event when you deploy so that they could be indexed.

Gregory Markou: no um it follows a lot of standards. so it's this idea of like. i mean like. i'm not sold on the this exact pattern like. i'm happy to debate it um but it's the. it follows oauth redirects. so like when you log into google a user is presented with like a redirect to accounts.google where then you do your like normal login process flow and then from there it redirects you back to the app you're on before you. everybody's really used to this. in like web 2 um it does the same thing but you choose your provider. so like if you know. like for example capsule is your kms provider solution and then or alchemy or become by economy or sso.chainsafe.io you know is your provider. then you can like go in the web 3 modal at least that's the idea and you know be like hey i want to like authenticate myself through their website and it would. on the provider side you're just simply saying like okay i deterministically know how to generate a public key for this user whether that's through metamask

Matt Garnett: a standard doa on

Gregory Markou: ledger or through pass keys

Nicholas: and then i

Gregory Markou: also have a provider that's like a also deterministically through that process also know how to figure out if that if i deployed a smart contract wallet for that user or not. and then you're just simply returning that data back to the application. so then they know how to handle that user.

Nicholas: right. i guess it depends on cooperation from these uh wallet providers or account providers who are often setting up completely incompatible systems for managing the relationship between the email and the smart account or whatever. the oauth is a smart account.

Gregory Markou: yeah exactly i think i think so.

Nicholas: so okay so that's so. state bloat for 457 in one way because it um 3074 reduces it because there's less approvals and managing of the approval state 457 increases it because given that there's no discoverability people are deploying multiple smart accounts even though the whole idea should probably be that you don't have to do that. um on the recent episode with dc posh and nalan from daimo they mentioned that one of the things about uh sort of the limited returns in optimizing the p256 r1 version of the p256 is that it's not going to be able to deploy multiple smart accounts for l2 deploys. is that the majority of the gas that you pay for an l2 transaction against a smart account is more about the data availability what you're storing on l1 not so much the in memory compute verifying your signature. so it's kind of like not that much benefit to uh as long as you're thinking that your users are on l2 to optimizing the hell out of your p256 smart contract in the absence of 7212 pre-compile. because at the end of the day that stuff doesn't get stored on l1 which is where the gas cost comes from. um. so i don't know if anyone else said anything before we move on. but state bloat of these two two uh two eips if not um. next question from kate was um. um regarding replay protection how do both approaches address replay protection? maybe matt you want to jump in on how 3074 thinks about this.

Joseph Delong: i'll say for 4337 4337 includes a nonce and then the outer transaction also has its nonce as well yeah and 3074 relies on an eoa submitting a transaction.

Gregory Markou: so like that exists there right?

Nicholas: um she also asked um how do they manage transaction nonces? i guess this. you kind of answered that especially in high throughput scenarios where nonce space might become a bottleneck. i don't know if that.

Matt Garnett: sorry i was away from my phone for just a second. uh i just wanted to say on 3074 the transaction submitting the 3074 messages has the nonce but there's actually no nonce in the message. that's signed by the eoa account that auth is processing and that is a very specific design because we want to allow invokers to create whatever kind of nonce mechanism that they feel is necessary for the application which they're they're utilizing. so the signature for 3074 is a nonce mechanism. that's and phpy and the type discriminator has only two important parts. one is the type discriminator which you kind of have something similar with type transactions. that way there's not an overlap. you don't sign a transaction that's 1559 transaction and accidentally have it interpreted as a 2930 transaction or a legacy transaction. 3074 has its own type byte discriminator and then you sign over the invoker which is going to process that message. that way your signature isn't taken by some other invoker and just executed. and so the thinking behind that is that you're signing a message to an invoker that you trust in some way which means that that invoker has implemented some sort of nonce mechanism and it's again up to them to decide. and so the question that she also asked is um what do you do in these high throughput situations? and i will say it's again up to the invoker it's up to them to decide if they want to have some sort of parallel nonce mechanism which allows them to better process a situation where you're trying to push through a bunch of different operations which aren't really tied to each other consecutively.

Nicholas: one final question from kate was how would 3074 handle nested execution within an invoker contract? not sure i totally understand but maybe do you know.

Matt Garnett: i think what they're. what they're trying to ask is if you submit a if you if you call a 3074 invoker and you do the off and then you do an off call and then somewhere along that

Nicholas: call graph

Matt Garnett: as you keep going deeper and deeper it comes back to the invoker and they again call off with the same eoa and then they do the off call. and i don't really see anything particularly wrong with that like yes it's a weird thing to do. uh maybe the. the question is a bit about like how do you deal with this tx origin? because you might. i mean there's like two things. because what do you do with tx origin? right now? the thing we do with tx origin is we sort of actually i'm not sure what we've decided to do right now. it's usually been between do you not change the tx? three things? do you not change the tx origin? do you set it to the account that's calling which would mimic exactly what the transaction would look like if it came from the eoa? or do you set it to some third value? that way you don't break some invariance that exists. so there's that thing. and then there's the tx origin. also a question about some contract might make the assumption that if an eoa called it then the eoa cannot again call it within the same call graph and so they might use that as this as like some sort of really naive flash loan protection mechanism or maybe some sort of um some sort of whitelist mechanism. and yeah i don't really see too much of a problem. there's a bit of nuance in the question but it's not really a major issue.

Nicholas: great. um. evm brahman asks uh given the momentum of 4337 how will the products being built on 4337 be impacted by 3074? i guess that's dependent on 3074 ever coming to fruition. uh will those products be able to benefit from 3074 at all? absolutely yeah totally so.

Joseph Delong: like the matt mentioned the toolbox earlier and i thought that's a perfect analogy of like the 3074 being a screwdriver i think that the screwdriver exists. it cuts down half the tools that you're going to need in your box like to to implement 4337.

Nicholas: greg did you want to say something on that?

Gregory Markou: no that was elegantly put very true.

Nicholas: um i think that's basically the end of the the listener questions. i had one other question. in talking about 4337 with a bunch of teams uh rhinestone conrad and other people um the and also this morning ahmed from uh by economy um the difference between the safe style safe style architecture and diamond style implementations for a account contracts has come up a few times. i'm curious if anyone has any hot takes on uh which you prefer or which makes more sense or why both maybe make sense. any ideas on this?

Gregory Markou: is the diamond pattern piece referring to eip 6900 the plug-in module system because i don't think 4337 actually does anything there.

Matt Garnett: i thought diamond sandra was older than that like 2000s.

Joseph Delong: maybe the the diamond the erc 777 is the diamond pattern token right? i don't know what we're talking about.

Nicholas: no it's a diamond. uh multi-facet proxy is 2535 and um i think it's in the implementing of a 4337 compliant account contract. you can make choices about how you handle calls between contracts either doing it the approach that safe uses which i'm not personally that familiar with or the diamond style which can open you up to a different kind of contract. i think the danger is like uh if you don't carefully manage your storage slots you could get into trouble by overriding or being exposed to vulnerabilities if you aren't managing your storage slots carefully as you have contracts interacting with one another. and this is like i think a topic in implementing implementing 4337 circles um and it's something that probably developers interacting with these things won't think too deeply about but it's it's kind of a contentious issue and unsettled. so it sounds like nobody has deep deep thoughts on this topic here.

Gregory Markou: well actually i think i know the problem. i think the problem here is the use of delicate call versus call. yes um but but safe implements that they just hide it from the ui band tag. actually somebody showcased this the other day but band tag explained it really clearly with dean where there's two types of transaction types in safe and you can actually transaction delicate call. transaction type two is call. safe ui defaults to two but you can effectively delegate call directly through a safe transaction and modify storage. so that's how you can avoid adding owners to the direct link list that's created through the safe ui and basically have like a an owner that does not show up in the ui because you can't find it through the link list. so i think safe is actually exploitable in the exact same way because you can do arbitrary delegate calls directly to the source.

Nicholas: all right that's a future research topic for me. i'm gonna have to look more into that. um as we close things out is there any like last comments or things that we didn't mention that you think are important for people to know about 3074 4337 or maybe the eip process? any uh any final remarks?

Gregory Markou: if you need an eip number associated you just tag like clients. they'll eventually do it but you have to give them a hot name.

Matt Garnett: that's it that shit better be hot matt.

Nicholas: did you have any uh any final thoughts? or uh you think we covered it?

Matt Garnett: yeah i mean maybe the last one. last closing thought uh if you if 3074 speaks to you if you think that this is something that would would benefit the protocol then we need you to share that sentiment and try and and help us build some sort of community um voice around it. because the core developers they they've just been most apathetic to ux changes and it's really going to take a big community effort a big community push to to make something like 3074 happen. and i do i honestly think it is possible. i think with 4337 it's such a large and complicated change. i don't see a world where we enshrine it but i do see a world where 3074 it makes it to main that. otherwise i wouldn't be spending my time talking on twitter spaces or unstagnating the eip every six months. so yeah if it's something that speaks to you please share with people reach out to me. um i want to make a bigger push for it for the prog hard fork which hopefully will happen sometime next year but you never know. and yeah thanks a lot for having us on here joseph.

Nicholas: any final thoughts?

Joseph Delong: yeah um the as matt touched on the user experience improvement for 3074 is huge like right now essentially. um if if you want to onboard someone onto ethereum you need to have them install a wallet. you need to have them install a wallet to onboard eth. so they have to get eth from somewhere through coinbase or through you or whatever. um and then and then they need to and then from there they can execute their first transaction. um with 3074 essentially the user experience goes from that to installing a wallet and having someone sponsor the transaction through like account abstraction and and economic abstraction. so so like i think that's it yields huge benefits. uh for for the end user and onboarding the end user awesome.

Nicholas: uh matt greg joseph this is awesome. thank you so much for coming and chatting about these interesting and deep technical topics. uh thank you everyone for coming to listen. if you've enjoyed the show web3 galaxy brain is going to be in gitcoin for the first time. uh hopefully in five days. we'll see if they approve my submission. so if you like this conversation you want to hear more stuff like this check out web3galaxybrain.com for past episodes and a new upcoming website with web3galaxybrain.com like ai transcripts that are searchable and stuff like that. uh and check out the gitcoin round that starts november 15th to november 29th. it'll be in the community communication and education uh section. i think it's called uh. so i appreciate your support a lot. it helps to make the show possible. thanks guys thanks everybody for coming to listen. see you next week cheers. hey thanks for listening to this episode of web3 galaxy brain. to keep up with everything web3 follow me on twitter at nicholas with four leading ends. you can find links to the topics discussed in today's episode in the show notes. podcast feed links are available at web3galaxybrain.com. web3 galaxy brain airs live most friday afternoons at 5 p.m eastern time 2200 utc on twitter spaces. i look forward to seeing you there.