Future of EOA and AA Breakout #1

Transcript

[Music] J um okay let's kick this off we should be live welcome everyone to um this future of eoas SL account abstraction breakout

rumor and to give some context uh we we are currently planning the next hard fork for ethereum and uh there's been a lot of proposals to do something around the count abstraction and depending on the scope and size of it uh potentially some bandwidth to include that in this next fork and the biggest uh challenge when it comes to doing AA stuff on L1 seems to be the getting everybody to agree on what the right thing is to do uh more than the technical complexity of actually doing the thing and one area where uh we we struggle to to get like

the the input that we need is uh from like wallet devs application developers um who are going to be the ones that end up uh using new uh account capabilities and who are the ones sort of in touch with uh folks who send transactions um so the idea for this call was to try and um ideally align people on like okay what's a high level road map and direction that we'd want AA to go in what are some things that are like mus haves both in the short and medium term um and then if we can get through that and and sort of have a rough uh rough consensus around that um looking into the existing proposals or potentially

some new proposals that would meet that um both potentially as something to go into the next hard fork and also something that that might be longer term more ambitious um but making sure that if we if we do something short term it doesn't sort of compromise whatever longer term effort we'd want to do um I talked to a few of you this week uh or in the past week offline um I think uh light client you have a pretty good feeling for where the conversation is at so I think it might help us like start uh might help us to kick things off with just your perspective on the whole thing and then uh go from there as you've been involved in some of the AA proposals

you're obviously on the guest team and you've been talking to a lot of the folks uh on this call as well cool yeah thanks I can definitely give an overview on how I sort of see the conversation where it's at right now basically we all want account abstraction and we're trying to find the ways that we can get to that end goal and the place that we're at now is that we're thinking about how to have quote unquote true account abstraction native protocol account abstraction and there's this proposal you know we have 4337 and then we have a enshrinement proposal

7560 and I don't feel like that is in a place where it's really something that is going to be considered by all core devs to be enshrined in the near future namely because it it substantially modifies the flow of transactions it adds many many different frames of execution to the transaction flow and a lot of that stuff to me feels like it's you know it's clear from the way that the changes of transactions are coming that it should probably be within the transaction and so it doesn't to me make a lot of sense for it to be in the protocol at this point so we're trying to think

about how to to maybe do something different how to modify maybe modify 7560 so it's a bit simpler something like 2938 but unfortunately 2938 doesn't really address the desires that people have for account abstraction it doesn't allow pay masters easily it doesn't allow reoccurring payments it's a lot more limited than than what 7560 is offering um so for True account obstruction it doesn't feel like there's a clear path to enshrining that and that we need to do support work and thinking about how to provide that um that primitive to users and we might need to ask if that's

something that we should provide to users for me given the desires that people have for account substraction specifically with pay masters I don't know if we should be enshrining that type of logic into the protocol and so to support a pay Master you need to have different frames of execution validating the messages from the pay master and then after the transaction sending payments to pay masters these things start to feel like we're losing a lot of the generality of what we want the protocol to be and so 4337 as it is today feels like much more clearly the right path forward for that so there's a lot of discussion that

still needs to happen around there the other big part of the discussion is how can we improve what we have today because we haven't been able to figure out how to do account substraction in the protocol yet and there are proposals to improve EAS but there's also this big question of should we do this at all and I don't have an answer I don't think anybody necessarily has a specific answer for this there's the two proposals I think that is listed on the PM in the PM repo on the agenda for this call is mostly 3074 and 586 so on the axis of improving EAS 3074 makes EAS much better it's something

that could make EAS compatible with 4337 and in terms of getting users to using smart contract like functionality you'll have a good had a good post where he was comparing 4 through3 37 and 3074 and he was saying that 3074 gives you execution abstraction so 3074 gives you a lot of the ux benefits that users want what it doesn't give you is it doesn't let you change how you validate transactions so you don't have this true mechanism for recovering Keys change you know rotating keys out of the account and a bit of the concern here is you know outside of some of the security concerns it's 374 is also if we make EAS this much better are people going to

migrate to walls at some point in the future or are people just going to stay on EAS are we further enshrining the EA are we further enshrining ecdsa and that's uh kind of some questions that are revolving around uh 3074 806 is something that has also been proposed and has um been picked up with a little bit more steam in the last month or so but basically 506 just makes EAS a bit better it's not necessarily compatible with 4237 it um really just addresses this the loud squeaky wheel of users wanting to do some operations together and I think there is a concern that maybe 5806

turns into the next 2930 the access lless transaction maybe not to this degree but I do worry that we could come up with some sort of solution some sort of account substraction solution that gets people to move off of E and then we forever have this EA transaction sitting around that's not terribly useful and maybe we should go that direction in the the near term because it does provide enough value in the near term to me this is where I think 3074 shrines a little bit more I think maintaining a transaction Ty is a bit more effort long term uh sorry maintaining the op codes for 3074 is a bit easier long term but 5806 is very safe and very simple it

doesn't really change how you think about the intuition of transactions or anything so there's a lot of trade-offs between those two proposals I think there's a couple other ones we still have to answer the question though should we be improving EAS and maybe we can talk about that on this call if we split the difference between native account account substraction and approving EAS right now we H since we haven't really found this path to whatever in in state that we want I think a reasonable compromise might be to uh to support 7377 which allows EAS to upgrade to Smart contract wallets I

think if we have native accounts abstraction in the future or if we don't have it this is still useful people are going to have Smart contract wallets in the future uh so that aligns in that sense it also sort of improves this EA experience because at least users today who are using EAS have the ability to migrate without going through the painful process of sing every single asset so in terms of minimizing the risk of doing something that's not super useful in 5 to 10 years I think 7377 is probably probably minimizes that risk most um yeah lots of questions still to answer that's kind of my perspective from talking to some people some other

people on the GU team and other court devs thank you uh that was a really good context setting um so okay so Danny and vtic have their hands up and I think after that it also be good to hear from some wallet or uh contract devs because those are the folks who we don't hear from as often um but yeah Danny yeah so from your perspective um does 4337 plus 733 7377 get us where we want to go but maybe has additional features and too much complexity like does that feature set is that it features that at least like a subset of like full account of traction review or is it missing something I think that 7377 plus

4337 gets us pretty much where we're wanting to go um the big problem with 4337 as I understand it on layer one and again like everything I'm saying is in the perspective of layer one there's totally different perspectives on Layer Two and how layer twos might go about this but on layer one I think real quick when I say 437 I meant I meant like a native version of it but you can also between those two those two yeah so for me I don't see a lot of reason to I mean a I don't see that 7560 the native enshrined version of 4237 I think that it changes too many parts of the transaction flow I don't think the cordev support changing having

that level of change on the transaction flow um and it it there it doesn't does it seem clear that you have to do uh 7 7560 in the protocol 4337 should work just as well as 7560 there's some problems with how expensive it costs to transact with 4337 I think that we should be looking at like how can we improve the standard and how can we improve the VM so that the cost of using that standard might might be a bit less uh the main argument that I've heard for inity 4237 is being able to use you know in protocol inclusion lists stuff like this but these don't exist in the protocol yet so until that exists into the protocol I don't necessarily think

that we should be I don't think that we should front run enshrining 4327 before we have the protocol feature it's uh claiming that is going to be very useful for it thanks uh vitalic yeah well no thank you uh so so much to both both of you um and Danny and I think the way that I've been coming at this is basically that uh like in every other branch of ethereum protocol research and development like there's been this really big change over the last five

years right where five years ago things felt very blue sky and there was a lot of kind of holding out for the possibility of future discoveries and a a lot of similar sentiments like that um but now like basically like every part of the every part of the the road map like there's a mindset that you know we actually have at this point spent quite a lot of time exploring the idea space and like we actually need to settle on something and uh we need to start building toward it right so in the case of the state tree for example right like I think there

clear agreement around veral trees and a possibility of a stark friendly upgrade to that some point in the future in the case of proof of stake there's the single swad finality road map in the case of data uh scaling there is the data availability sharting road map and at the same time other forms of laor 2 scaling and I think that in the wallet space as well we're at the point um where we really are in the position where we can make that uh mentality shift but it feels like we haven't quite yet made made the the mentality shift

and I think like now is exactly the right time when we when we should make that shift right like I think there actually are quite a lot a few properties of accounts um in the in the ethereum like long-term game that we've generally understand are just security properties that are pretty necessary right uh so like the ability to CH make key changes or and including like revoking old keys from an account right this is uh you know something that in traditional cyber security is like considered a pretty basic thing like you should be able to expire a key take take permissions away from a key this

something that AAS don't support it's accepted that eventually quantum computers are going to come and so there is a flood like a tsunami and unknown number of kilometers in the distance that will eventually wash ecdsa away and like basically it's our choice of you know whether the whether ecds is or something that we move fast on our terms or on the terms of that tsunami whenever quantum computers end up coming there is uh some more ux side things like batching sponsorship signature aggregation um and like we know what's what proposals that satisfi all of these goals look

like and and like basically the thing that is even more like like basically figuring out the the next step is very difficult if we don't understand what is the long-term goal that the ne that the next step is trying to get us Clos to to right and so I think actually getting to a stronger agreement on those long-term goals like what is the a long-term future for accounts that satisfies all of the desires that all the important goals that that people have and if we can get to that consensus then it

gets much easier to actually figure out like both figure out what some of the initial steps are um and at the same time figure basically yeah figure out like for example if uh in the short term we both have the existing 4237 ecosystem and the existing AE ecosystem know can we try to improve those in walk step rather than you know creating like basically two branches of technology so that we have to deprecate one of them um so the like that's basically for me the rationale of kind of thinking um or spending some time to kind of think back to front and I know that you know like these sort of all X death calls tends to

be kind of all about um you know like front to back and it's usually sort of quote ethereum research that does the back to front but I think you look this is a a group where we need some consensus on the back to front another big thing that I that is important I think to like really get consensus on is just like basically have a clear answer to the question of like is the ethereum L1 meant to be in principle a chain that is friendly to users right the other vision is basically that like L1 is a a B2B chain for l2s and I know that like some people have that vision and it's a valid Vision but like if we choose that Vision that it has other consequences

right like for example you know like it's worth canceling EOS it's worth canceling 3074 it's possibly even worth making an mergency push and canceling T store right so like basically L1 being L2 exclusive is also something that has uh that has consequences and you know like my personal impression is that generally we do want L1 to be a thing a thing that's uh that that continues to be friendly to users going into the future even if the the bulk of transaction counts ends up happening on L2 um and then if that's the case then like that's something that we need to like actually accept and like

basically internalize that know whatever the longterm account solution is that's something that L1 is ultimately going going to have to be a part of and like it's not something that we can sort of points to some future decision point so that's um I think kind of the basically the context for the like where I perceive the the need to like really know get get this get ourselves align around some of the long some of these goals um I think on all client got an exell question which is uh basically

what of all of this stuff does ERC 4337 by itself not satisfy um I think uh well there's three answers um so and I think you already mentioned two of them right well there's like a longer tale of answers but one of them is uh of course inclusion lists in the future um but uh in this case I think the argument basically is that you know it is true that changing the protocol to be inclusionist friendly is pointless until we actually have inclusion lists but even like while we're talking about the end game I think it's still worth like in the end game inclusion

lists are presumably going to exist and So within that conversation it's still um worth thinking about them um another issue is the gas cost stuff which is definitely super important the um gas test and I think like actually the veral tree gas cost redesign is probably going to end up solving a lot of that which is good um I oh I saw one great reply from a vid cich which is the bundler and relayer is not Quantum resistance which doesn't make 4337 like impossible because you can still do stuff like putting the it right into block at the end but it makes it much more annoying another really subtle

one that I actually got told about only a couple of days a days ago and I wanted credit um I think it's um Aus uh 1211 for this is uh basically that uh ke store behaves differently for um calls and transactions uh basically in between transactions t storage gets cleared in between 4337 calls D Storage does not get cleared and so that might lead to different application behavior and like in the short term I guess we just have to like yell loudly and make sure applications don't like assume that the store starts off zeroed but like that's also one small thing where if user

operations actually correspond to transactions it becomes easier and so yeah I think those are yeah those are basically the main ones um and then yeah extra complexity to uh developers is uh yeah I mean I think complexity is definitely something that's really important to think about and like this is also one of those one of those places where it's uh I think important to kind of like think about it in end game that that reifies some of these structures that we've been creating in the short term right um but

that's definitely also longer of discussion Patricia asks what is I inclusion lists basically inclusion list sorry technology that allows the protocol to like or use user is to specify a list of transactions and then essentially forces those transactions to be included within one block and for inclusionist to like actually work in to be economically sound like you actually basically the protocol needs to be directly aware of like the concept of a user created object like the type like the the specific like container that needs to be made censorship resistance um I I talked about this quite a bit in my post on uh like I think it's on hackd

like year or two ago about like the end game of PBF censorship resistance um so yeah that's that that's what I wanted to go through thanks um yeah a lot to digest um okay let's move on to Andrew then we'll do a Siri um yeah so I agree with uh vitalic Vision that L1 should agree should um be some remain somewhat friendly to like normal users um and in in the in that light I think uh 3074 is uh very dangerous because uh it it poses a

security risk uh that uh of signing a blank check so I I I I'm really worried about 3074 um and uh I think in terms of like PR practical steps uh we it's it's absolutely worth doing trying to figure out the end game but it's highly unlikely that we will arrive at something at a consensus for for Prague for the next hard for so to my mind we we should Implement uh 586 because it it it brings uh real ux benefits uh I don't see like like in for

instance you need to you won't need to do two transactions first to approve a a Unis swap exchange and then to actually um do the exchange itself so it will help with batch transactions it has real benefits it's quite simple I don't see any drawbacks it does not prevent us from going into from implementing a fully blown uh account obstruction so yeah I would do that in frog thanks uh Siri yes um my question is whether there is a proposal right now to inine

4337 um or 7560 in the next uh hard work in brag and um if not then um maybe it would be best discuss these proposals when the authors are present um right now aav cannot join the call because uh he's uh in the um midf fight so yeah yeah um and there's a bunch of comments around uh enshrining 4337 as well I don't know is there anyone on the call who can give a quick overview of what this actually means because there

seems to be confusion as well in the chat of like what would get enshrined and what would still rely on offchain infrastructure um I'm not sure if there's been a specific EIP or something written up for it but I don't know if anyone even has like just a vague design uh overview they can share uh okay so there is a rip 65 uh sorry 7 7560 um okay um so yeah I guess in terms of of

uh having someone sort of make the case for that uh I talked with yav we can discuss this on the alord dev's call tomorrow and I think yoav should be able to join there I I my I'd be curious to to hear from all the client teams but there is probably a a degree of like complexity that we're Bound by as well for the next Fork so um I haven't like reviewed this yet but there's uh yeah that's probably the other thing that uh we should we should discuss tomorrow where like you know even if we wanted to move forward with something like this uh do we have like the bandwidth to uh to include it

in the next Fort um yeah uh sh hi yes um I'm sh I'm working with yav and Alex Andro for the 427 and 7560 and regarding the question about um in shining 457 this is exactly what 7560 is supposed to be supposed to be doing and but the way we saw it we saw from 47 as an ERC and not an AP in order to implement right now a solution for count

obstruction and only discuss the for the for the very like the other future of of account obstruction to discuss and shining it in in the protocol as inside as in 7560 without changing the protocol right now so I saw some people asking in the chat questions about shining 437 and talking about 7560 without connecting each other so I just wanted to to say that and also uh when we when we had 437 and 7560 it was supposed to be our uh our goal was to first introduce it to l2s uh in

order to in order to see the the the adoption over there for uh uh for wallets and other and other developers and other other projects and only only after that we wanted to uh to suggest that uh uh to to have a native solution for it in uh in L1 so that's why I'm connecting it to what uh to what Siri said before that I think that the best time to uh to speak uh about 75 60 would be farther down the line especially when you and will be able to join the call got it and I guess realistically

then if if the plan would be to deploy it on l2s before it's on L1 then it seems extremely unlikely this would land in the next fork and might go into the fork after that um if we'd want to see it used on l2s with like some scale before um yeah before it's it's on L1 um ongar yeah maybe on that point I just want to briefly mention and because this is in principle relevant for of course for multiple eips that could that could all be brought to l2s separately or first before instead of L1 uh one problem that has or like one question that has emerged on that side more and more is that whether we

will be able though to actually introduce eaps that require meaningful changes on on the L2 side if they are not supported by layer one and specifically not supported by any of the layer one clients so for example um G has already signaled that they would not support an in shrined version of 437 unless it would at some point come to main net and so then layer twos would be very hesitant to ship that um either of course the solution can be found there but I'm just basically saying that right now the path for eips to be tested and or like to be introduced in Lay to first um is a somewhat restricted path unfor fortunately got it yeah you obviously

need some clients or some Fork of them that's maintained by L2 teams to uh actually implement it and test it um oh uh Eric I hope I said your name right thank you uh yeah so I wanted to add a few things to the discussion um so this actually goes to the the point that asgar also mentioned uh a second ago um coming from the wallet side I know that uh l2s have a pretty big incentive to remain evm compatible because of all of the tooling that eventually kind of go by the evm and when I say evm eventually it's like the ethereum standard so

indeed I think that any process right now without having a new Norm any process that basically pushes l2s to adopt a technology that is not supported uh by Ether is going to be possibly slower or meaningfully slower um so there is this connection right now of like uh the that eventually all of the tooling goes by the standard set by E theorum at this point um so I think that's that's something to consider um and I think it's especially important given that uh when we talk about the the things that are needed in order to kind of uh maybe the cliche of bringing the next billion users to uh

ethereum um I think guest sponsorship like transaction sponsorship is really really important and the l2s are actually possibly suffering this from this even more uh because they're trying to be facilitating for use cases that um are G the Gateway for a lot of the new users things around payments things around nfts that are not by themselves like digital assets of values but like nfts that are part of some other product so in those situations getting hold of eth or madic has a lot of complications sometimes the complications are um just tactical and sometimes they're regulatory so this is quite preventive

from a lot of use cases of adopting uh evm l2s to solve this um so I think really sponsorship is really an important issue um in the near to medium future uh not just longterm so at least from our side I think it's important to to try and solve this um as quickly as possible and understanding that veral trees are coming so anything that's not introduced in the next one might be another year year and a half to introduce I think that's just an important consideration um to make and I do think that EAS do need an improvement again and kind of for the the things that I

mentioned so I do think it's important for us even though there's a lot of uh um different opinions on what to introduce and how uh I would say that it's very important we we solve some of the things that vitalik mentioned and he kind of went through all of the use cases uh of the features that need to be solved so I think it's really important to address as much of it as possible thank you thanks um okay yeah there's a good question in the chat so um on like a more incremental step is there a counterargument to not doing uh 7377 which is the one-time um upgrade from uh an eoa to uh a smart contract

wallet um which can be an which can be a 433 71 or or any other types um and there's a comment saying that uh some cross chain interactions um yeah I think yo has written about this in one of his posts but it is it could be confusing for a user if they have an EA they have this private key uh and they deploy a spar contract on some chain with that private key it's like how do you communicate to that user that that private key is still useful I mean one on that chain already we we need to think about how to deal with the EC recover situation that is

being used for permits and other types of erc's that allow transfers of tokens with signatures and then on other chains you need to be able to communicate to the user hey don't throw away your private key you might in the future want to deploy your smart contract wallet to another chain so there's some issu some small issues around um the experience of of using that got it sure hi uh Al I asked that question in chat so just coming to the user point of view though could we solve that on the wallet side and potentially reduce the burden on um a larger hard Fork here with

7377 uh meaning like yeah like meaning make it the responsibility of the wallet to um like move all of a user assets over to a different address or uh yes potentially on the ux side yeah right um yeah I mean my impression is that this gets talked about from time to time but like in practice it ends up being even harder just because there are so many applications that people like forget that they've even participated in but I think I know other have this even more than I have and I assume the cost can end up being your barrier right like the whole point is uh if I have I don't know 50 $50 of 20 different tokens maybe the gas

costs on L1 are like prohibitive to individually making those transfers but um a onetime call to change everything to a Smart account isn't um Richard yes just wanted to add also to this question that when it comes to the signature validation cross chain right like if we migrate towards the smart account this requires that the signature or this IP 1271 right like is widely supported to and adopted I think this is currently still a challenge which needs to be considered because if most and I mean it was mentioned with permit which is the onchain part of this but even a lot of offchain apps first validate your

ecdsa signature and then if at all fall back to validating signatures uh against the smart account and this obviously if you suddenly can generate two pairs which is theoretically you have a private key that is can generate a valid signature but it is actually not the real owner anymore this creates some indeterministic behavior for a lot of depths which either do not get updated or just due to Simplicity favor EAS and this is something where from the developer side which is more off Shain so not sure how important this in this round but there it creates some ambiguity which should be considered and which needs to be somehow addressed

so I guess uh summarizing sort of what we've gone so far it seems like there's a rough alignment on like what we want out of aa's long term um so you know the things T pointed out um I think it's unclear like which of the larger proposals uh get us there the best um but I guess yeah I'd be curious to hear a bit more from like some of the wallet devs or client devs here like um given that we probably have some bandwidth to make some progress on this now across client teams like what's the most useful

thing we can be spending your time on um in the next you know weeks and months um and potentially that thing is not like something that goes in the next hard Fork maybe it's something that goes in the next in the one after if it's like figuring out a path forward for say 7560 or something like that but um yeah I guess I this this comes up all the time where um yeah it's it's like uh there's this demand to do something to improve the ux to make things easier for users and whatnot um and we we do have some capacity now so like yeah what the wallets what the contract devs think would be highest impact or most valuable to to prioritize

oh yeah Eric um yeah so um slightly repeating but not fully uh I think in terms of the improvements that would be useful on our side I think again like I would say that probably the first priority is sponsored transactions um um because it unlocks a lot of use cases again on l1's and l2s um I think following after that I wouldn't say batching but more like evm execution in general uh uh from from an EA account um now I'm not sure that an upgrade is as useful because it introduces a lot of complexity if I'm

somebody who manages a million clients of mine then starting to upgrade some of them to Smart contracts versus others are still regular eoas creates a bit of a complex ecosystem to manage um so again maybe it's a path forward but I'm not sure it's very Progressive slowly right like it's more like a big change uh to make as somebody who has a product in the space um but definitely executing evm code from the eoa is useful and especially it's useful if I can do this in a sponsor transaction so the combination of those two use cases is is very useful uh um this is why kind of like the

3074 suggestion is appealing I understand there are some concerns about the security I know that there's suggestions to do this a single transaction instead of like supporting for uh indefinite approval um I'm not sure how many of the concerns this alleviates uh in terms of the security because then it's much closer to 5806 if I remember the number correctly but just generally speaking I think those two things uh would be the top priorities uh from our side not as just a wallet that is end user wallet but actually more as like enabling other companies that are building their enduser uh products um yeah thanks that's pretty valuable

um other thoughts comments okay I guess so sponsored transactions the ability to have more complex execution flowing out of an EA and and figuring out um um the best migration path to do that in the tradeoffs of like converting existing accounts versus not um if we did either of those things do they like block us in any future end games um you know if we if we went ahead

and did something like 3074 or something like 7377 or both of them um and then we deploy say ens Shrine for 337 on l2s I've realized this is great and then uh in two years want to move it to L1 have we like painted ourselves in the corner um is this basically vitalic you mentioned at the start of the call you know the idea of like there's these two branches of uh of development um does this mean we just sort of um yeah have to live with that and and and deprecate one or have wallets support both forever yeah because it does seem like yeah the

the sort of types of proposals we can consider for L1 right now are like different than what's being proposed in something like the enshrine 4337 um and how bad is it to do both those things yeah I mean on the yeah like in convert smart contract side it feels like the sort of thing that's not forward incompatible with anything because or at least it's thought forward Getti with other proposals because it's uh like once you have a uh a a smart contract wet like if it's written sanely it has a self- upgrade functionality and

so you'll be able to convert it to some different type of smart contract wallet in the in the future anyway and I'll I'll let others speak on like forward comp compatibility of 3 74 and and uh like a long-term conversion to Smart contract wallets so I guess yeah there are a couple comments and and on this based around you know like fully deprecating EAS but is this something we can ever actually do um so if I if I just like log out of ethereum you know stop paying

attention today and come back in like four years is it likely is it is it possible that we can um that we can um like fully deprecate EAS ever right um right I mean the thing that we'd have to do is we'd have to basically make a create five op code that uh initializes an account at an address uh that is uh just based on the hash a public key whose code is just then like some standardized thing that is that accepts cdsa signatures from that public C got it yeah like the big thing to keep in

mind is like there is always going to be a smart contract while like a design that is able to create equivalent functionality what EAS do so and we can arguably um yeah just yeah exactly we can arguably Force canver e into smart contracts with equivalent functionality yeah yeah um yeah I think the concern like with some of the EA empowering designs might be that like if you start like putting the idea of an EA into an OP code then

like that starts be becoming more dicey because like sure you know like you could support like support smart contract wallets but then you'd be supporting a very specific kind of smart wallet that like um yeah Anar you have a comment about uh the L1 versus L2 perspective do you want to share a bit more about that sure yeah I was I was just thinking that it's it's it's only basically for for further informing the context for our decisions but but I I do think that it makes a difference whether you think about this as like we want to improve the situation for users on layer one or we just want to change layer one because For Better or Worse right now most layer

twos follow the standards at layer one sets and layer twos is where most of the users are I personally really think that we should be okay with embracing that layer one will be more more the settlement layer especially as we hopefully get more white on white adoption most users will be most of the time priced out from layer one anyway so I think focusing on the just the power users on layer one doesn't really make much sense so I personally really think that the reason to even think about any of this is mostly for for kind of guiding layer twos um and again I'm not saying that next makes an actionable difference but I do think in terms of mindset it it's important to

yeah yeah I agree with that and I think in parallel you you sort of want to think about the the handoff or the like uh you know l2's ability to incorporate new standards so you know like you were saying earlier if like clients currently don't support like L2 specific features um you'd hope over time this changes it doesn't seem like an unsolvable problem but it means you know I in the next year or so it's it's it's more likely that like L1 is the one sort of setting the direction more heavily and uh L2 sort of starts ramping up in like you know if and how they can adopt independent features um but then maybe three years from now this has um this has like shifted um so yeah so I think it's it's

like worth considering that like L1 probably can have like a heavier hand now but um over time uh you know that may stop being true and and if that's the case other specific things we'd want to do now while everybody sort of follows what L1 does and yeah balic you have your hand up um yeah I mean I think like the challenge that that I see with L1 sort of being almost compatible but not quite right is basically that I expect wet will once to try to provide equivalent functionality on as many chains as possible and uh L1 is just realistically going to be one of them for a pretty a

pretty long time and and so if like well let like just all have to write custom code for L1 that uh just to like serve the particular people groups of people that do use it um then like that is a significant burden on the ecosystem even if only like 0.5% of people five years from now actually have a one accounts uh so that's uh I think a big part of of my reason for um like basically saying that know like either we're supporting L1 or if we're deciding that1 is not for users then like actually more fully embracing that

okay so um it does seem I guess you know coming back to like Matt's first comment like we're in this sort of uh impass almost where um either we sort of lean into these larger uh sort of account obstruction overhauls whether this is something like enshrine 4337 whether this is something like 2938 and whatnot and we could have like a separate conversation about all those in more Deb um and I think if we if we only focus on that uh this means that the status quo Remains the Same on L1 for the next year

or so um which might be fine uh people will complain about it on Twitter and then say that we do nothing for uh users but alter it like alternatively the we go with like what are the smallest incremental improvements we can make on L1 um do those now while the while the sort of broader road map gets fleshed out um and be mindful of like their forward compatibility with that and it's not clear what the set of like L1 net improvements that don't potentially conflict with the larger AA Solutions is

but we can we can think through that a bit better but yeah do people generally agree this is like where we're at or does anyone see another sort of path uh yeah Andrew um yeah I agree I think that's the alternative uh but to my mind like the the one of this like the smaller e like 5806 it doesn't conflict with with any bigger account obstruction proposal yes there will be a new Legacy transaction type but so what it's like it doesn't matter we will have some some Legacy stuff anyway so it doesn't introduce any new incompatibility in

principle I mean it specifically doesn't support account abstraction it's going off at a completely different branch and not only that it doesn't support two of the number like most important features to people which is key rotation pay masters so it's just addressing like the third most useful thing for for users I I don't think it's worth in shining that into the protocol forever well it's uh I think okay maybe not not necessarily that one but we we can maybe consider a small e to address the the first like the the sponsor transactions or whatnot but why I'm talking about 5806 because I think it's

simple to implement it doesn't introduce an incompatibility and it does bring a benefit I mean I I would just rather enshrine 3074 with the requirement that the message is only valid for the account uh for the current nons to the account so you have you're not writing this blank check forever that to me is a much more useful feature that provides a lot more flexibility to improve the EA way than a very specific uh Improvement around transaction batching that 806 provides U okay if 3074 is amended to prevent this signing of blank

check forever then yeah I guess we should yeah I haven't looked into it in detail because my biggest worri is was that we just signing a blank check but it's if it's not the issue then yeah like I personally need to think about it but what you're saying makes sense uh Shah andalex yeah I just wanted to ask Matt because he mentioned before that uh in the G team they are reluctant to to change the way transactions are being validated I think for for the 75 60 proposal so I just wanted if you

could just elaborate a bit on why is that the case I mean I think we're generally trying to avoid changing the protocol in substantial ways and this is a pretty substantial change on how to think about transactions and how to build blocks it's not something that you know we're necessarily 100% against but my biggest argument against inin 437 is that there isn't really a clear reason to do it things like veral you know you have you can't not enshrine veral you can't have veral live at the application layer where 4 through 37 seems to be used in production there are some rough edges

around the cost of using it on L1 but these are things that I think that could just be improved over time whereas you know in shrining and doing these changes to the the protocol we should only be making these like large changes to protocol if they are absolute necessities and I don't see that as the case yet for uh 4337 enshrinement but like moreover on H Scar's point which I don't know if that's what you're referring to where he was saying that the G team is signaled to not support things on L2 before it goes to L1 um this is just generally a um a decision that we don't feel like it's our role to maintain the code that l2s

only are running you know it's already a lot of work just to maintain and make sure that the L1 protocol is staying up and everything is correct and if we need to do like large code refactors and you know this is the big thing with 7560 I don't think the GU is going to support it before it is having L1 support because it is a very large change to the behavior of our transaction pool our uh block Builder and our block validation so we would change many different modules just to support l2s and that's yeah that's probably not something that we're going to go be going down in the near future okay so we're about at time for

the hour um I think what probably makes sense from here is uh on tomorrow's aev's call we can one have yav uh give kind of a a deeper overview in 4237 unfortunately him and his team couldn't make it today so I'm giving them the space to do that two I think uh it would be great if we can dive into the specific uh eips for the next Fork a bit more and their trade-offs um so it seems like 3074 5806 uh in terms of like enabling new functionality um are are like the two main contenders and then ongar uh also you had to draft thep uh I forget what the number is that was just

like a new transaction type with a sponsor and then we have 5806 and 7377 with regards to like converting EAS to Smart accounts or or smart contracts um yeah I does this seem reasonable to people to um get a bit more of the high level around 4337 and then look at the smaller potential changes for the next Fork tomorrow and uh take it from there and in the meantime there's also the R&D Discord people want to continue discussing this so we have the future eoas uh channel uh so I'll post the link here um but yeah I think this gives us a

decent uh yeah a decent overview to keep uh to keep working on anything else before we wrap up okay well thanks everyone for coming on appreciate you all spending the time and uh we'll talk to you tomorrow about this stuff some more thank you thanks Jim thanks everyone thanks

h [Applause]