Future of EOA and AA Breakout #2

Transcript

awesome hi everyone welcome to the future of EA and AA breakout call number two we've got a pretty big agenda and we made this call 90 minutes instead of the usual 60 Minutes for breakouts it takes a lot to get everybody here from the community and I want to be respectful of that organization I also think it's prudent for me to not moderate this call since I'm been pretty involved in discussions and my take is obviously not biased in the debate so I have found a few people to help us moderate this discussion I think there are people that you have seen in the AA community over the last few years so with that said I'd like to turn over this moderation to Nico and

Eric thanks thanks like Cent so indeed we will be moderating today we have a lot of things to go through um so I think we can get started Eric what do you think I hope 90 minutes will be enough to to put for everything but we we'll do our best all right let's go so we have the updated agenda um we will go for the first point which is account migration in the protocol AA road map so um if everyone can prepare their take

and give um give something in the chat if you have prepared uh your messages that you wanted to pass we asked people to prepare um and if not we can go straight to the account migration point I think maybe if I can add some context since I wrote this agenda and I had some things in mind as I was writing it and then people can we can have a bit of discussion about it if that's okay with you yeah sure yeah so I think one reason that I mean there's a lot of reasons to have this call to talk about 3074 and the proposals but the reason I wanted to talk about this AA road map

before we talked about the proposals is I don't think that there is full alignment on what or when this full native account of structure road map looks like for layer one and I wanted to hear from people working on Native accounts abstraction people building smart accounts and like what the expectations there are just to try and move into the next discussion about like what is there to do today with more clarity about where are we all moving towards I can share my perspective from being a client developer on layer one that it's not clear to me what or when the native accounts abstraction road map will occur based on where things are today it

doesn't feel like it is on the Forefront of client developers Minds how to ship native accounts abstraction so that is usually a good indication that we are at least one or two years away from possibly scheduling such a feature into a fork so if that is kind of the lower Bound for how soon we can have these types of features it to me feels very prudent to ship something in the Petra Fork that improves the situation for EAS that's what I have to say I'm curious what others think about this there's a oh um all right thanks Richard I see you

have raised your hand you can take the mic sure thanks I mean just to take up the microphone from M right like I think for me we all have been working especially the smart account teams have been working on wanting to have more native supports for smart accounts for a long time and it's always this I wouldn't say battle it's maybe a strong word but if there are discussions around this with some of the note teams for the client teams I like it they are very defensive outputs for good reasons not going to judge this but obviously now for for us it's always about okay we want to have native for C OB faction we've seen this in other ecosystems work to some extent we see that 4327 um set a very nice starting point

where we can iterate on and these were signs for a lot of the smart accounts that we go towards Native account OB in my opinion I would have loved to seen this even faster but I think we all agree since has been a while and now the question is okay um why I agree with you that the science because the client teams are still very defensive if you hear comments like um the guest team being very conservative about not wanting to implement 7560 my have changed but because of complexity these are obviously signs that damp a little bit like okay how can we go there even so I would really want to have some or like as one of the smart account based teams would love to have some commitments that we or like some clarity do we want to stick on we want to make

smart accounts first class citizens and that this should be um our goto solution or do we rather want to go the route of empowering youra Swit for you from the US perspective is a valid Road right like I'm not going to chish on this one but it's very different one at least right now compared to what we started with 437 personally for me I would still see that having um like in my mind um and I think you of can give this more realistic numbers actually but I would have seen that in the next one year one to two years we get rip 7560 so the basically native account OB Direction on rollups to a state that we we have

enough Insight that actually after um pectra so after the work Fork we can really start tackling this on Main net and with this then transitioning Over The Wider ecosystem um or like enabling The Wider eum based ecosystem of having native account abstraction support and then starting actually after this to migrate trans uh accounts over towards smart accounts because then if we have native smart accounts are first class citizen then the migration should also not be that painful anymore this was my understanding for the like basically what would be coming after work the mer Fork but yeah this is again being slightly challenged with 3074 timeline wise that's I think also

where some of the Contra TM comes from oh yeah sorry yeah sorry what but like I'm not meaning that after Petra we see anything native ction it was after the ver right like we have Petras and work and then I would have seen naction so right that makes sense uh I think Anar wanted to give some comments yeah I just want to to to briefly comment specifically on the the kind of the situation um specifically regarding in TR to kind obstruction and the the difference in between layer ones

anday layer one and Layer Two basically I think some of the um problem that that 437 ran into is that on the layer two side there's a lot of interest in also shortterm already in training some some some version of a account abstraction um and so that's what how kind of Ip 7560 came into being but ip76 is the very first kind of large uh IP and so we are for the first time kind of actually figuring out how could layer tws move Beyond pure ebm equivalence so this adding features that layer one does not yet have the layer one evm and in in particular one problem that um so far we still kind of looking into how to do

this is basically that L to mostly just use unmod largely unmodified lay one clients um well in practice they mostly use G um but which means that even before we want to ship this to mainnet we would basically need to have some sort of support for this native account obstruction in gu that doesn't of course have to be done by the GU team itself that could be some like the layer two teams but layer two teams are very hesitant to basically make large modifications on their own that they have to to basically maintain the guest team has been very hesitant to basically Implement and maintain large features that are not relevant for layer one so we a little bit of an impath there right now but we have to solve

this anyway because there are multiple directions in which layer twos might want to move Beyond layer one right so there so there are a lot of thoughts there but this will take some time to sort out and and and so right now kind of native C obstruction on layer tws is somewhat blocked by by basically this having to be figured out first and then on the layer one side I will say that part of the reason for why because otherwise we could just wait for layer one to to start moving in the direction but it does seem like on layer one side we are much more conservative right to to with with with these bigger changes so I think the realistic time until we are very confident that we have a good solution there might still be a bit longer there's for example now one good

step in that direction is there's this been this recent EIP to basically take take the IP 7560 but remove the the the the inin um solidity interface but instead using UF um which is a good direction but it will still take some time so I don't think even after ver I think it's very optimistic I would say there's probably at least three four five years before main moves to Native account obstruction and we still in the Pro process of figuring out how can L do this faster thanks very interesting point uh I guess we will need to talk about it more during the roll call and dedicated layer two calls

um anyone else with a a take right now all right I guess we can jump uh into to the the agenda then if that sounds good for you guys um so should we directly go to EIP c74 uh as I think a lot of um questions will revolve around this and we have some news some new proposal from vitalic so I guess a lot of people would want to

talk about this so maybe we can uh directly go to this and or maybe Matt do you want to give us Insight on the different uh previous points yeah I was just I mean I'm trying to make a platform for people who disagree with some of the decisions that were made with all core devs because you know we've sort of accepted 3074 to go into the next fork and like what does that mean that just means that the core devs are putting these into the dev Nets that they're working on right now like we have the opportunity to change 3074 some we have the opportunity potentially send a different proposal through and accept it and remove 3074 like these aren't necessarily set and Zone it's just moving a step of

confidence higher that this is the direction that we're trying to go and the feedback was a lot of people felt that that was not the right decision it didn't work with what they were believed accounts abstraction was supposed to look on like on ethereum and I wanted to give people the opportunity to discuss how how ethereum should be changing over the next you know one year year to improve the situation currently with EAS but also support the accounts abstraction road map and like there's some points here like you know is account migration the thing that we should be prioritizing over something like 3074 like that was a discussion that we had in February and it seemed like 30741 but I understand that there are people who weren't part

of that discussion back in February so I wanted to maybe give them a chance to talk about that and then the smart contract originated transactions we sort of just talked about it seems that we're years away minimum from having that on L1 so maybe we can skip over that and then yeah maybe dive into 3074 all right um so I think we've had many many different takes on on what was wrong with 3074 uh in the AA group so like if someone that was supporting one of those Stakes want to speak now I think it's it's a good time obviously we can nothing is setting Stone so we can be chill and uh it's the moment to speak

guys hey maybe we can chat briefly about some of the comments going on in the nav bar but um my biggest question right now is around inclusion of 3074 and L1 today um especially given that it comes at the cost of some features that better support rollups like s resistance Fe inclusion lists um and is generally in congruent with the overall role of centric road map um I think there's like a great opportunity for us to Define what is an ethereum score Charter right now and how to best support that versus what are in role of score Charters and even as an rip I think this would have been less controversial but even then I think it fits a little bit less cleanly in what has been like the well- defined

long-term AA road map so I still struggle to see how this fits into the long-term system in a way that like promotes the right incentives for users on using the right systems and and how to grow these things in the long term I can I can quickly talk about inclusion list I don't think that inclusion of 3074 has anything to do with excluding inclusion list from prag um basically we worked on inclusion lists quite a bit and kind of found several issues with inclusion lists that weren't great and it felt like we were just patching

up bugs that um that we found and the spec was never really finished it it kept evolving and um yes one of the arguments for not including inclusion list is that it doesn't play well with 3074 but there wasn't the only argument to not include inclusion list so I don't think that uh it's either inclusion lists or or 3074 inclusion lists were not included because they were not done as a feature on their own but doesn't this kind of shut the door on adding them in future hard Forge 2o at Le any kind of any kind any kind

of account abstraction where one one account can spend the funds of another account or can modify anything uh of another account is something that doesn't play well with the with inclusion lists um yeah basically but and so like we can yeah we can uh we can make we can find a way to make inclusion lists work uh with any of with all of the features or we can just say yeah we're not going to ship any

feature that is looking like um account obstruction yeah but then it becomes a question of like sequencing and priorities right and like what is the core focus of L1 e theum and like on what ADV variance should it best support its customers and from my perspective its customers are increasingly rollups more than Ed users and that's why I'm flagging this is something that I see as in congruent I just don't see 3074 or something similar to 3074 being a big detractor from L1 moving in the direction that we're talking about like if we were saying okay 3074 is going to be this 2-year project it's going to take all of the

the teams the same level of work that it's taken to merge the veral then that would be a big question about like what is our Direction but we're talking about like an EIP that takes 2 hours for a client to implement it feels like a big win for the users on ethereum today and it seems like something that we can just do without significantly detracting from the direction that we're moving I think um yeah sorry yeah go ahead you were muted um yeah um I generally agree that I think on the Note side this is not uh like there implementation of Ford it's probably not the biggest blocker I

think also when I was primarily voicing my skepticism here was less about actually the not teams and more on the level of the accounts the wallets and the depths right like why there are definitely synergies where 3074 will in general break some of the statement with depths most likely when it comes to that we should not just assume certain execution flows as we have them right now which is a big item that we need to work on I think also on some other fronts that we create some Duality again between two standards which might or might not be to be honest create a delay or not I don't know might also speed up things who knows um this is where my personal skepticism came

from when it came to okay should we now go for second option or should we try to stick to 437 for the time being I get all the reasons um and I my point that I wanted to make is we should not only think what does it mean an overhead towards the not teams it also means for towards deps wallets alignment on the wallet side and there are different reasons it's not as black and white as I think we have had a lot of discussions but this is where my personal skip came from I'm still would not be I mean there different views on this yeah I I don't know for me I just I don't see it as a separate track I feel like it's something that we can put into 4337 and help supercharge the adoption

of 4237 because there are still a lot of EAS out there and integrating like allowing EAS to use 4237 increasing the base functionality of the account that daps can expect I think it will proliferate the the adoption of a lot of these standards much faster than if we're just waiting for everyone to migrate or upgrade to Smart contract wallets all right I see some hands raised enar and Rafi you can take the mic and then we can move forward briefly yeah just just briefly on the point of um of basically 437

compatibility with with with 3074 I do think that that a lot of the concerns here or like third concern 3074 do come from from this question of will we end up with two two competing Tech stacks and and and and the thing is that that yes 374 can be made fully compatible and like if all the invokers that end up being used are invokers that actually um allow for 437 style decentralized mle flow then I think a lot of people's concerns would be ease the question is it's not clear that we can basically ensure this from the outset like it's not clear that we can put guard rails um in advance to make sure that the invokers that end up mostly he most heavily used do do do

these things there have been some ideas like for example we could even initially launch 3074 on mainnet with a list in protocol white list of invokers we Bic pick some safe invokers initially and we say we might remove that white list or expand it in future Forks um but but basically this this general question remains how can we in advance make sure that only invokers that follow patterns we we think actually are good forward compatible for C obstruction are adopted and and and yeah it's not obvious thanks uh Rafi you were the next one

then we can yeah I was about to ask almost the same exact question so like um I think instead of like discussing like first instead of discussing the censorship and the others we do need to understand the actual motivation here because um if you're just throwing the 3074 without the actual plan to then migrate to 43 37 then we are just basically creating two Divergent Stacks that are competing as said yeah okay all right um yes yeah so the I'm sorry I just thought that I heard something so the biggest question here is actually I think like instead of thinking how um 3074 can basically bring um can bring how the apps are like going

to be more willing to support account abstraction features um I think first instead um the discussion should be made around the motivation and also the the the situation that how 3074 will be migrating to 4337 in the future at least in the forceable feature all right uh Ahmed last last one and then we we move to the Alternatives right um so first of all I would want to point out that um I'm a a uh like I was one of the supporters of 3074 Stam um and the fact

is uh account abstraction is uh the end game here and we want account abstraction to be like a smart accounts to be uh this the de facto account for everyone on the blockchain but the road to that seems to take a very long time and for us to just wait until uh that is sorted uh in in in in in in years to come uh does not look like the ux and we're like the users of of the block of L1 are always saying that they feel that uh the core devs and the developers of the blockchain are not putting the user as the first class Citizen and not

thinking about the user experience that the user has to put up with to uh Contra uh to um transact on uh whether it's ethereum L1 or l2s and um with that in mind uh um I don't think just hindering EAS is the correct approach to uh resolving uh like force migrating users into account smart accounts because if they H if if if we just say Okay um let's not allow EAS to uh feel a little bit better to the users uh just so uh smart accounts can flourish well then

why did didn't smart accounts already flourish by now they had they had all of these years of uh of Advantage supposedly in in the ux department um but adoption is still stagnant as we can see um uh the other thing is restricting the invoker contract to a predefined list like since when do uh protocol research and uh cives uh decide on uh uh like like like why are we trying to block innovation in this area um like the same the same thing that applies to the invokers applies to uh smart accounts to

to to interface with a smart account you need to have an inter you like to to work with a smart account and publish your transactions through a smart account you need to have a lot currently you need to have a lot of infrastructure built you need to have a UI built to support the smart account etc etc if you're not following a standard smart account you will have uh a really really hard uh uh uh time getting your transactions in um so it's normal that a certain invoker implementation would be would have a certain interface let's say every wallet uh needs to support a certain invoker uh they can develop the invoker that supports their UI Etc and

this is the same thing that already smart contracts already have so like this is not different than smart accounts it's exactly the same and uh saying that invoker contracts and the wallets blocking like having some kind of control over which invoker contracts uh they would allow or disallow uh does not make any sense because that's exactly the same for smart accounts as well my opinion all right um we will let you have responded then we really need to move forward else this else the call is going to be very long so you have you have your response yeah so I'll keep it short so I so we can move on just wanted to make a

comment that uh we also think I me and the counstruction team we also uh see we also see EA improvements as important and I think we should have uh we should have something the difference here is that uh Within workers I mean we want to allow any form of innovation but we also want to be able to uh to decentralize and to have H to have censorship resistance if not now then at least in the future and uh this requires having this requires separate invalidation and execution that's a key part of of anything that would use a permissionless mol because otherwise denial of service attacks become too powerful so with invokers the way 3074 does them it is

much harder because this separation does not exist so yes it allows you to innovate it allows you to innovate on the eoa improvements but unless you do them in a very specific way such as implementing the invoker as a 4337 account then you will not be able you you we will not be able to H to have sensorship resistance later because it's not something that you can fix later whereas if we if it's a transaction type and I don't mind which one like for example the one that vitalic just proposed seems like a good alternative if you have the functionality of 3074 but implemented the transaction type with separation between validation execution then you can have all of the

same Innovation at 3074 but also be able to uh to have a permissionless m pool and I think that's the that's the key point I would make about that perfect perfect thanks that's my that makes a great transition uh so we have a new proposal it's uh 77702 very new uh so maybe vitalic if you want to give us a quick explanation here um yeah um so I just uh pasted the link into the chat in case anyone wants to follow along so the idea of 4 through

three of of 72 is basically to have something that you could think of it as having the form factor of 586 but the user and Dev experience that's very similar to 3074 and the basic idea is that um what we do is we create a new transaction type where that transaction type allows a user to provide a contract code and then sign over that cont contct code and then that signature gets included into the transaction you can even have multiple included into a transaction and then for the scope of that transaction the user's code gets replaced with that piece of

contract code and the way that this would uh work in order to mirror three 3074 use cases is basically that you would have a transaction and then the cender of that transaction could or the origin could possibly be some accounts other than the user and the user would just sign over their code and then for Ela code will be replaced with contract code and then instead of having calls or instead of doing an off to authenticate the g account and then an off call to call on the G account's behalf you would basically just literally do call like two calls into the user's wallet that

would uh verify like perform some other form of verification and immediately after that just call into the wallet and then do whatever execution that they wanted to do so basically there so this approach is nice because it's uh both uh like very clear how an existing 3074 use cases can be translated to it and at the same time it has this really nice property of forward compatibility with the smart contract well it's ecosystem because essentially the code that a user would sign over would just need to be a spart qu wet code and it would even work

as is if a user signs over their existing 4337 wallets and so it basically accomplishes the same functionality as 3074 in in the sense of allowing a wallet to temporarily turn into a smart contract for the scope of one transaction and at the same time um it would it would also enable all of the standard use cases including batching including more complicated forms of batching including sponsorship um including privilege deescalation and uh potentially know you could even uh just have it like or have the

transaction just be an ERC 4337 bundle that directly calls into an entry point and so it's uh like it's very compatible with the with the existing 4 3074 ecosystem and at the same time it's uh very forward compatible with both the 4337 ecosystem but also like theoretically pretty much any kind of pathway towards SM wallet right so there is nothing like 4337 opinionated about this proposal in the sense that the only opinion that it has is the idea that that you have some kind of smart contract wallet that you're activating for one transaction right and so if some smart contract wallet proposal of that

looks very different from 4337 and up winning then this would also be forward compatible with that as well so that's the right so that's the core idea basically yeah becoming the a smart contract wallet for one transaction and doing that as a as a transaction type um I guess uh right and I mean the basic goal of this I think is that like there have been multiple efforts at uh coming up with like things that provide some of the use cases of 3074 but without the uh the properties of 374 that like people

have the most issue with but this one I think like goes much further in terms of uh providing pretty much uh like I believe basically all of the 3074 use cases because there's just a like such a nice way to translate existing off and off call workflows um let's see going through some questions can 7702 be used together with 4337 and bundle user offs for multiple accounts um the answer is yes um so you can yeah you can authorize mult you can have multiple contract codes for multiple accounts that get authorized and so you can basically literally have a single

transaction that just is a 4337 bundle where the code is all exactly the same as it is today except if you wants to make it work with some EAS you would just uh like do it inside this new transaction type and you would put their uh the signed contract codes in and it would basically just work as is um then there's questions around like should you sign over a non should you sign over a chain ID like how reusable to be want this and I mean I personally am agnostic to this and I think we can probably borrow a lot of the re discussion that we've had around 3074 and 5806 and like pretty strongly the um or a lot of the reasoning should be pretty similar

um why right signing the code versus signing the code address is uh one of those uh interesting points I think think yeah I mean I'm this is one of those things that like I personally think doesn't really matter much in either direction um basically because uh if you sign a code address then uh or like you can sign any code by just publishing it first and then if you don't have code addresses then with I think it's EIP 1167 orc 1167 proxy is like a a proxy that wraps around a piece an existing pie code is only a few extra bites

sorry in 7702 how is the code getting on chain if you sign over the code do you have to propagate it every time uh yes you do so in the code proposal you do have to propagate the code every time and the argument for why this is like not incredibly inefficient and fatal is basically because we expect users in practice to just use proxies for this and proxies we can be extremely small like there are the like the one I mentioned is only 44 by makes sense uh we have a yes Daniel you can

yeah just just one question how do you prevent that the users are signing some malicious contract uh with this type of transactions because wouldn't you end up that the wallets have to have sort of a white list again but in this case just for contract code um yes good question um so I think uh the set of concerns around uh like that people raised with 3074 of like complaining about having the trust invokers um like a lot this does not um solve a lot of the concerns and like the need to trust code does remain but that's something that exists in any smart contract quity ecosystem right

like that also exists in or like a version of it exists in 4337 or because like ultimately a user has to trust whatever wallet implementation they use and so I think the recommended way to interface with this would basically be that your wallet would have e canonical smart contract implementation that uh follows some particular API and that's pretty much the only thing that you would trust yeah but then but then in the end I mean this would be the same concerns as with 3074 no I mean this there would not be any Improvement it would just be instead of 10 vocus you trust the smart

contract that the wallet allows right Ian maybe the one thing you can say is that it's uh it's more plausible that a user would be able to have only one and be done with it uh but uh okay all right next question Derek um so I do have like a lot of questions um I guess I'll just like ask three ask three questions right now so uh so one is um it's not clear to me from the EIP and I really only had like you know maybe five minutes to read like before the call um so so so it's not clear to me from the EIP like how how does storage work right you know cuz

like because like most of like the most important use cases of of AA depends on storage right you know so so so so I would like to learn more about how storage Works in this case uh the second question is um it's not super clear to me why vital decided that um that's better to sign over the codes of the contract instead of just signing the address of an existing contract right you know so that's the second question and then the third question is um it's also not clear to me why um uh just like how does this proposal handle expiration right you know so like like what is like the lifetime of the authorization yeah so so so those would be my three questions thank you um yeah so I think on the first one and one appro there's basically two

approaches what right one is to just allow storage and the other is to um either like force storage to be temporary or even just disallow s storing completely in the way that 5806 does and the trade-off is basically that uh you know if you uh allow adding storage then there's a you know po like well I think in 586 it might have been actually a bigger risk because uh the the application in 5806 would be that users would be more often in the habit of constantly newly signing signing over pieces of code uh whereas here like a realistic user might have one but like

there's the risk that if you sign the wrong things and your storage gets screwed up and then if you want to like actually deploy a contract safely then like you'd have to like do some like sign over some other piece of code that clears all clears over all your storage or something like that and then the other option is you just disallow a store and if you disallow a store then realistically yeah like you'd have to rely on storage that's uh store it somewhere else or you'd possibly have to just make do without storage and rely exclusively on like vertical level nonsense for replay protection so those

are the two paths that I see for the like signing over contract code instead of side over addresses thing I mean I think as I've said before like I'm personally not too opinionated I'm okay with either approach and like I actually don't think that the two approaches are that different from each other in terms of their consequence and what was sorry what was the third question again yeah oh expiration yes so I think I mean the the most natural expiration strategy is basically to stick the nons into the thing that gets signed right or at least make it an option and so that's like if we want the ability to expire that's probably the easiest way to do

it um yeah um then uh I saw another question like would it did increase gas usage because EA users would provide code in every transaction and right I think the answer there is basically that either if you use a an ERC 1167 proxy your code then your code is just 44 bytes and 44 bytes is like very trivial call data call data cost wise or if we do it as by providing code addresses that of code that NE also soles usage in a different way all right Eric next thank you um so I wanted to ask about the practicality of implementing

this in uh pectra uh I think given the from what I understand given the similarity to 3074 I kind of get the sense from people that it should be possible but uh at least from my end this is kind of a core uh question because of the importance of including including those capabilities before we go into the veral tree uh um basically pause in things that could improve user experience sure um I think it makes sense for corev to reply to that question so that would have to be discussed on the call I don't think a

single cord de could give a yes or no to it all right the next question Ahmed yeah um so my question is that uh so I have kind of a couple uh one question is like if you have to sign uh contract uh uh code or address with every transaction how would you be able so like 3074 allows you to off uh a contract and this or is valid on on uh you can you can you can put certain permissions on this off that uh it would

execute in at any time uh so does 7 how would uh 7702 do the same thing that's one thing and the second question is um from the core core development perspective um like one of the motivations behind 7702 is that we don't want to introduce two new OP codes into the evm uh the oath and oath call but instead we're introducing a new transaction type that could possibly be deprecated um so from a core development perspective uh is a trans a new transaction type really less of a big deal than just adding the two op codes um the third and last uh would

be uh how would uh 77 O2 be different than that proposal that light client uh created where um uh he said that we can modify 3074 to uh uh make the uh like the frame of execution is the eoa itself and point to the invoker contract that way the invoker contract can kind of act like a smart account uh inside the exe like the execution frame will be the eoa address but uh that it will act exactly like a smart contract account um for the op code versus uh op code

versus transaction type uh maybe a CV can answer or I mean someone with the knowledge about this I was asking theic about this because iord yeah I mean I think my case for why transaction types are like lighter than um or more like less of a technical dead problem I guess than op codes is that like in principle if you remove a transaction type eventually then or the only infrastructure that would have to change in response to that is offchain infrastructure whereas if you remove an off code eventually then that would require onchain infrastructure including

smart contracts that people were counting on to be at the same place and have the same functionality forever uh to uh change how they work and so like this this second is just strictly harder than the first and like we've seen how challenging it is even with self-destruct which is an upod that that barely anyone uses at all and this is an up code that's uh or transaction type that's likely to become part of very mainstream user workflows so that would be my probably my case for why up for why transaction type makes more sense in this case um and then I mean I guess there's also the uh philosophical point that like op codes feel like something

that uh should focus more on comput on computational things and like like basically there's value in this like very high level user authorization stuff being something that's a a like being something that's at the transaction Ty level because it's uh more legible to the protocol and might be more forward compatible with various things right and around the question of um how would 770 uh 7702 support use cases like um an O an o that has other use cases than the immediate transaction

like where you o um a contract and this contract would be then called under certain permissions at any time I mean in principle you should be able to do it right because basically yeah you would just send out that o and uh that o would just be a piece of contract code and then you'd be able to call into it from um like whatever from some other contract and like basically a very parallel way to how an implementation through that uses 3074 would be able to call the aop code right because like what you're basically doing is you're

basically saying you replace the uh you replace the o with a call to the contract you you can replace the off call with another call of the contract or maybe you can replace both with one so in principle they like any use case should be able to just like be translated at the very least pun they get na yeah I think so but it does feel a little bit more restrictive than how or and or go operate I'm not entirely sure all right I mean one other yeah one

other way just I think to finish that thought one other way to address that type of question might be to explore how the 4337 ecosystem has approached that particular use case because there's some chance that it has and uh you know you'd be able to convert the 4337 approach into working with with the CIP as well so so so like the question is because like the the the smart contract code is only valid for the duration of transaction um so what what 4337 has is that they have the smart contract code always liveable men

whereas right so yeah right so in this case yeah the solution would be that like it could be reusable right like basically yeah I think this all has to do with like do you sign over the nons or do you not sign over the nons and actually even if you do sign over the nons if uh like if if you sign over the NS but you don't update the nons then it's still something that becomes reusable yeah makes sense Derek go ahead oh yeah so so personally like after thinking about the proposal more I definitely um think that is a more

elegant and more clean way to do you know to kind of like bring the benefits of AA to EA right right you know and like I also like how it's more forward compatible with the the overall a map um but I think like um from a practical spe from a PR a practical standpoint of adopting 7702 in Petra I think it does have a few more dependencies comparing to 3074 right you know so so right now 3074 is already implemented by the Cent teams um so in order for so if we want to ship 7702 within roughly the same time frame as as you know the original time for 3074 then I think there are two main

dependencies right so one is that um I'd like to hear from the ceps like whether they think that implementing this new transaction type is doable within the time frame of s you know you know within temp of pure and secondly since this proposal we require I think like if we want to use 772 with the 437 Meo which I think is like how most people want want to use it then it will also require an update in the spec of 437 itself as well as like the updates of you know of of all the bundle infrastructure right so I think I would like to also Al hear from The A Team whether they are roughly on board with with this proposal and whether they

think that they like kind of like you know like the bundlers can also um you know Implement support for this proposal within a you know within a reasonable time frame yeah um great question I think like client gave a reply in the chat which is yes for the first part uh and for the second part I would invite uh AA teams to discuss it soorry so what you what specifically

uh uh what part do you want to discuss oh so so so the so the question is basically just because it's like to use 307 so like 3074 comparing to this new proposal has the advantage that like it can basically Leverage The 437 men pool in a way that doesn't require any modification to 2437 right you know you know like through a multitenant invocal account so you know I like this new proposal but it does require updates to 47 itself as well as obviously updates to bundlers so I guess like like my question is just like y like just like have you guys had the time to review this proposal and are you guys R are you guys roughly aligned with this proposal and like would you get behind this

proposal and up and update 437 if this proposal was adopted uh I think it's I mean in general The Proposal looks good but since it was written like an hour before an hour before this call I think we need to think about it a bit see how it fits in the 437 uh ER how it fits in the framework in a way that doesn't create new attack vectors but yeah if it's um so if this proposal does not introduce any problems I mean if we have a good way of integrating it then I don't see um then I don't see why we wouldn't but uh that's but again I we can't commit to it before spending some time thinking

about it because it's very new thank you yeah because to me like you know if both the Cent the core Dev team and the 43 to7 team can get behind this proposal then I really think that this is the you know you know you know that this is like the best way forward yeah I yeah I tend to agree it's uh I tend to agree I think it could be a it could be a good way forward but I think we just we just need probably need at least a few days to think about this proposal because it's so new and uh see if it's uh same I mean if we can't see any new problems it creates which on the face with it they don't see then uh yeah then it would

be yeah but you know I I also do want to say that's like I think it's I think it's important for us to commit to get this into pack sh just because like I think like um you know since like through 74 itself has already been delayed for years I think we should you know we really shouldn't just like keep keep kicking the can down the roads so it's like you know if if we want to if we want to replace 3074 with this proposal then I think like you know we really have we should have like a strong commitment from both the CFS and both the7 te to uh to you know to ship this within the P temp soen we haven't had time to even to even discuss it so I'm only speaking for

myself here I think uh we'll need toh I think the team will need to discuss it and we prob need to discuss it on the uh on the mafia group but uh yeah let's I think we should do it as and the sooner the better so it can be included in Petra perfect thanks for the reply uh elim you had your hands up yeah hello um so I think remember from one of the previous allore devs I think balic mentioned that um like a reasoning for not including like a ANP such as I think 503 or 7377 was that it breaks an invariant that um EAS don't have a

contract or don't have code um so I guess if that still holds then like does 7702 kind of also touch on breaking this invariant and if so then um what's the reasoning for having this kind of temporary code um solution rather than just outright like including something like B3 or 7377 that permanently migrates the um account yeah um so I think so in terms of my previous comments on like the breaking the coded variant like just one thing to be clear is like I am in favor of breaking that in variance right I'm just uh in favor of us being super explicit about it so that applications um such as I you know nfds that depend

on non transferability and things like that are aware that the changes are going to happen well ahead of time and people don't make new applications that depend on it then get hit by a surprise waiter um one other interesting um really nice thing about 772 that I didn't mention yet is that like actually 53 is like literally just one line of code on top right basically yeah like you could imagine a flag being added where if the flag is set at the end of the transaction you just don't revert the code back to zero right and if we do that then 5003 basically yeah exists immediately and from a code complexity perspective it feels like the Delta

between doing that and not doing that is like fairly small I think the only reason why it didn't wants to just includeed into the EIP by default is just because like I didn't want to introduce this as something that like changes like 10 different potentially controversial things all at once but that like if we decide that we want a 5003 to happen fast then you know we do have a very easy way to do that either in Petra or in a future for um I guess like uh kind of uh maybe I

just wasn't that clear or maybe I just didn't understand quite but like what is the reasoning for um not just uh doing that end game like endgame migration um oh so for like not just like adding the the adding the flag to set the code permanently in the additional version um I me I personally am not personally I'm not against it I just like like procedurally I just uh wanteded to present this as an alternative way of satisfying 3074 use cases without also simultaneously doing the discussion of you know like let's do 5003 and Petra but if people decide that they want them simultaneously then like I have zero

opposition to that personally thanks uh like client maybe you have uh something to to add because we we had some points uh on the agenda that were related to um to to some of the things we just said but maybe you want to take them in the in the 3074 context uh yeah sorry go ahead Ben just just regarding uh permanently writing code to the EA wouldn't that mean you can essentially

brick your wallet which should be a bad very bad outcome by writing the the wrong code there's no there's no walking back from it I mean yes it does yeah and like that's the reason why things like 53 have any controversy at all right I mean it's the same problem with smart contract wallets too so if we're moving to a world where everyone's going to have a smart contract wallet then we're going to have the possibility of them setting the proxy of their smart contract wall to the zero address and never getting their funds back out so it's something that we need to design

for uh yeah I mean in terms of 3074 I think we're sort of up in the air at this point like I'm happy to discuss some of these things but but given that there seems to be pretty good support for 7702 um you know we're still working on 3074 it is going to go into this initial devet for pectra but we're I am personally open to removing it and swapping something different in 7 702 seems like a good alternative I want to spend some more time looking at it maybe iterating a little bit on the design but in general I'm happy with it we need to wait to see if it's acceptable by the 4337 team because if it doesn't support the the

decentralized permissionless relaying use case then I think that it doesn't really give us what we're looking for in this upgrade does anyone have any 3074 specific things that they were hoping to discuss uh am I audible yes uh this is a little skeptical point of view regarding EIP 7702 is that it could be a threat to e EIP 4 ERC 4337 account exception because EA have options to update their code why

would they shift to a Smart account later on am I making sense no I think uh that uh it makes sense um so the the thing that I would say is basically that like as a if 7702 gets introduced then you as a user would absolutely be able to just like keep on using EIP 772 transaction types either forever or until the trans if the transaction type gets removed 10 years in the future then I know you would actually have to upgrade um but the main

reason you would have to like actually finalize the upgrading eventually would basically be if you want to switch keys and if you want your original EA key to no longer have full Powers over the account anymore um so I think the case for it being a bridge is basically that if you like any user who is in that halfway house state of being a frequent 7702 user would actually be part of the 4337 ecosystem and they would share networks with the 4237 ecosystem and once um the ability to permanently set code is introduced then they would have the ability to just switch over to being a full member of that ecosystem anytime

and they would not have to so I I think in practice it's not a competitor to with the 4237 world I think it would it ends up serving as a bridge but Alexander you want to say something nope all right I guess one thing on the agenda under the 3074 category but that's also

relevant to this discussion on 7702 is there has been a lot of debate about like what should how flexible should this signature be and we've discussed it a bit in passing in this call but I maybe can just ask if people want to make Arguments for against the signature having certain fields that limit its flexibility for instance the chain ID or the nons that exists in signature right now as it's written 7702 does not have the chain ID or nots it's a question of should we add those things to it I have personally felt that they're

not necessary because the contract should enforce that functionality but I'm open to feedback from others uh yes firstand raised was ncar I think yeah um so so I will say because I'm also I I I otherwise I would have also argued on this call for removing those restrictions from 3074 I think given that all of these proposals come with a requirement for manual wallet white listing anyway basically like all of these restrictions can be enforced to an equivalent level

through that process so you can you can have the exact same restrictions around um revocability around expir around chain ID binding um just basically buy only wallets only white listing invokers or in this case code that actually has brings those those restrictions but the nice thing is now it's up to that ESC layer and so if at some point some pattern emerges that requires those not to be present we can just upgrade to them and so I would always argue that we should do this this security model is already that we trust that the wallet does not do anything stupid with the white wi listing so there really is no downside to this other that maybe it would set the wrong standard in the ecosystem but to me basically the added flexibility always outweighs those

concerns um Ahmed yeah I actually agree with as on this front uh um the protocol does not need to really restrict uh the to enforce these restrictions usually we we uh as as pointed previously in one of the previous calls by light client we usually let this these type of restrictions happen on the smart contract kind of side uh of things and we don't have enforcement on the protocal side of thing and because this is a a new transaction type like um wallets will not have will not as soon

as but picta uh lands wallets are going to become vulnerable to this attack no they have to like support and Whit list or do the work needed to support this transaction type um and as such the risk of oh suddenly after the fork all the users are vulnerable to some kind of scam is this does not really apply in this case because again like uh support from the wallet side of things need to be added because of the new transaction Fair Point uh Richard uh I'm also more on the side of not enforcing nons and chain ID why I do

see many points made about security um there's for me also the distinction do we need to make them required or can they be optional right like can we leave it up to deps users the wallets to um like give this op option um because if we also make it optional we see that there's a landscape of more and more networks coming in and if we say we make them optional actually you there are certain use cases where having replayability across chains is super powerful right like it's like they're two sides of the same coin right like so replayability can be bad and good and generally just excluding it um will limit our design space which I think

currently we are in the need for better U we need to have a bigger design space not a smaller one and I mean the only point where that comes to my mind why we should enforce them is because apparently it's easier to get this through with certain stakeholders in theum ecosystem I'm not sure if this is the best reason yep dra you can go ahead uh yes uh okay I'm trying to think about what Richard said because my first inclination was just like with 3074 these are required to avoid long lived signatures and network

malleability ER whether they can be optional I'm not sure so I not think about it try not to speculate it right now and earlier it was say how is it fit with the 4327 again we've seen it only for one hour when we live really look deep but it looks like it's promising it's make it might allow EAS to become first class citizen in a transaction and in 4337 transaction and looking forward like counter structured counter structed transactions so it looks promising but

again we didn't really look the code how it will change anything either the entry point maybe the ENT point doesn't change at all what the bu need to check sure um we might want to plan out another breakout room given the the the fact that 7702 is so young uh but we will discuss this later Ben you can go ahead um if the uh if the things like chain ID and so forth aren't included in the um signature then that would lean more towards it being contracted than um a

contract address in the in the pH uh because then you could include the chain ID in that optionally if that makes sense whereas if it was just a contract address you you wouldn't be able to include that you'd have to include it in the data which would be a different signature yep good point Rick you want to go um so I just want to jump in quickly so I mean first of all I feel like one thing we could always do is make it so a chanity zero is the Omni chain if you wanted to disable um like you're done talking okay sorry um yeah so if you want to disable like

the ability to to work on just a specific chain but for me personally like when I'm signing my ledger if it's on a network that I don't really care about um then when it pops up saying you're signing this for arbitrum I'm far more willing to click a button like recently I've noticed a lot more things uh are signing weird type messages that don't specify the chain ID it's kind of scary because you don't know are you like authorizing like die on whatever Network so tying it down to one network definitely like reduces the the threat profile of what I'm worried about so it could be a wallet limitation currently but that's kind of my my quick uh reasons for wanting chanity kind of embedded in it again with the option to

disable that by setting the chanity to zero yep interesting point I do agree I do tend to sign things much faster when it's when it's on a on a layer to network um who's next we have a lot of hands raised uh David maybe yeah um this is not directly tied with like like the chain ID and the nons within the signature but um I see one of the things that the community discussed regarding 3074 um is like the original key still being used so like there isn't that validation execution but rather execu um

um execution abstraction and I also see correct me if I'm wrong on the 7702 that the account is still bound to the original keyn um I wanted to discuss with the community like what if we could the current architecture uses the E recover from the protocol but will there be a chance where we can um create like a add another parameter where we add the input or the address of the validator contract which um is similar to having like a so basically to support like um custom signature schem

with 7702 so we delegate the validation to another parameter which a custom Smart contract will handle rather than like being bound to um like the default protocol although I understand the point I just wanted to bring this up and see like what the community thinks about this yeah I think that uh I mean it depends on this philosophical question question of uh whether you're looking at the 772 workflow as being um this kind of like temporary thing that like you know the equivalent of like a Linux live USB install where you can just like plug

the USB stick in your laptop and then it like loads up a bun to without ever installing it and that just gives a a nice way for users to like quickly try the functionality versus if you're looking at like swapping the code for the scope of one transaction as being a workflow that around long term even um after users switch to Smart contract wallets and I think when writing this my thinking was much more the first but uh and then like basically because I think the second could be covered by smart contracts themselves having the functionality to authorize like new pieces of code for temporary Scopes but I mean definitely open to thinking about

it the other way Derek you have your hand raised oh yeah so so personally like I don't I don't have like a very strong opinion on Chen IDs but I do want to say that like about nons I think like whether it's with 772 or 3074 I think it's like if our benef like if our goal is to bring the benefits of of a account abstraction to users then I think is is very very important that we avoid including nons in the signature um the reason is because like so it's like you know like our company Zer death like

we like we have been working very closely with like many many of the early adopters of account direction right so like all the most popular used cases of AA besides maybe like guest sponsoring depends on longstanding Long lived authorizations right you know so so for example like two of like the most powerful used cases of of AA like one is like a attaching alternative signing methods to your SM accounts such as like pass keys right so like imagining attaching a pass key to your EA through either 3074 or 7702 right so in that case because you want to keep using that signer the fact that like every single transaction from your UA will invalidate that signer will make that use case basically impossible right and then like

another use case is like session Keys like the idea of essentially delegating transactions for transactions for other deps to execute like that's Al like a really really powerful and popular use case and again like that wouldn't be possible if like the authorizations can just be invalidated like all the time right so I think it's like very very important that we avoid the pitfall of including nons into the signature which will essentially make some of like the most popular a use cases we have seen uh impossible yeah so so so that's my take thanks for the contribution PARTA you want to add something yeah sorry

this may sound a bit naive I just I'm trying to understand a bit more on 772 uh would um I mean for the execution context uh the the account in this case would function as a smart account right so it doesn't mean uh you would need support for 1271 or uh a variant 6492 or uh would it uh would dabs continue to support uh or treat these requests emanating from the eua as a regular EA based transaction did that make sense that does and that's an interesting point I there's basically two ways to handle that right one is

basically that you just say well for 1271 it keeps on being an EA the other way to do it is you basically do do a 6492 extension that basically says that know if the user provides an authorized piece of code then like that gets treated as a 1271 signature exactly the same like in a way that's very parallel to what happens in 6492 so I guess either of those make sense I mean the second obviously takes more work because it's in ERC but the second is more powerful because off Chade signatures are often precisely one of the things that you care about that like creating lower sec higher accessibility a deeper

thanks uh dra if you want to go ahead yes D mentioned that the the reasons why I don't like the nons in the signature because it limits the signature and we have exactly the same issue as with 3074 I'm all for it as long as you keep some mechanism to allow the user to revoke a signature that was already published on chain otherwise you sign for life for a specific implementation which I don't think it's a good idea yeah good point you have yeah so regarding the regarding the

nons I mean first of all I do think that being able to revoke fix your past mistakes so to speak is important but it's a but it doesn't have to limit any use case so I would propose instead of including nons include a Max nons just you know you can so you can include them on Max nons say say this is valid for the next maybe 1 million nons say or whatever which gives you like infinite uh gives you a like since you are not going to have a million transactions it gives you a infinite approval but but Comm but also have a way to bump the nons by a 32bit value so and the the the

rationale for that is that uh if you if you realize that you need to revoke your past uh your past signatures now you can bump the nons by let's say 1 million and one and be sure that your past authorizations are are no longer valid and on the other hand it doesn't put the non the non repl protection at risk because the 32bit value where the nons is 64 still gives you a more than enough more than enough room not to ever overlap so I think that using a Max nons and a way to bump the nons uh would would would give us like both uh both things infinite uh like both infinite

authorization and uh being able to to revoke would that make sense yeah it's a fascinating idea I think one weakness that's worth pointing out is that it does weaken the me pool's ability to safely queue up multiple transactions for a user because right now if a user cues up 50 transactions you know all 50 would have to be included but with non-pumping you lose that guarantee but then at the same time like we realistically lose that guarantee for account abstraction anyway and you can argue that once you have badging there's not actually as much of a point in having that guarantee anymore so like I personally yeah don't see that

as fatal just want to flag that that regression does exist I think it doesn't this doesn't create a regression because this is already possible today I mean we can have a currently the mol allows it to have a if I recall correctly a 63 I me the default configuration in gu is a 63 pending transactions but the current transaction actually can uh it can invalidate the other transactions by draining the by draining the account sending it elsewhere so right no but what you can do what you can do though is that you can do a check that checks if uh the user's balance is greater or equal or equal to the sum of the values of all the transactions and

then you can forward conditional on that yeah you can do that so it it does so bumping what I would do is H since bumping the non is an is an extreme case it's not something that you do all the time you're going to do it if you think you need to invalidate all your past authorizations so I would say that this should cost a lot of gas which means that it cannot be used for Deni of service I think it's fine it's fine if you pay like if you pay some really high amount of gas for this one time inv validation of P authorizations yeah that's a cool idea uh Conrad you want to

go um yes kind of just wanted to weigh in on the non debate I think like um my two sents here are um obviously there's some some good points on on both sides like I would probably ER on the side of kind of not enforcing kind of non so chain ID checks like on the protocol like unless we actually have to and kind of like I think from the points made before I think it it would be a nice to have but it would be something that could be equally solved kind of using an ERC or kind of like just in general kind of application Level like standards or just like implementations and I think like one argument there that I don't think has me has been mentioned before is if we assume that wallets will to some extent Whit list these kind of like

either incus on 3074 or kind of like smart accounts then wallets might as well kind of check that there's some way of of revoking um kind of like um yeah outstanding signatures so I think that's another argument for being able to rely on like application of like standards or just like the implementations to have like revocability or like cross chain kind of like um preventing cross chain replayability if that's like required in certain use cases um just on the nons um invalidating transactions that door has already been opened be by by being able

to run code in your account because it could move all the e out so um the first transaction could invalidate the Rest by uh not having any more gas all right uh I think we have covered um a lot of the topics that were plan for today even though we we spent a lot of time on the New Alternatives um I think it could probably be good to plan another breakout uh considering the fact uh that

7702 is so young and many teams will need to um to look at it um so let me know what you think guys but I think we are signing up for another round great thanks so much Nico for helping moderate this discussion I think we'll discuss this further on allore devs also which is Thursday at the same time as this call I can add 7702 to the agenda if anybody body wants to come and hear what

the client teams have to say or maybe like share your perspective you're welcome to but otherwise we'll see everybody in the AA Mafia telegram yeah absolutely and um last Point uh I think exactly as Ansgar said um it's it's quite good to see all this energy around the AA road map so um let's continue with this energy moving uh thank you everyone see you soon bye bye everyone bye