Future of EOA and AA Breakout #5

Transcript

all right let's get started so thanks for joining today um we will be discussing the last update to 772 um so it's basically add delegation designation um You probably have already checked the files um so yeah without further introduction I can give you the mic if you have some comments around this one I've seen some comments on E magicians uh from Kevin uh so Kevin if it's you I think it's you maybe you want

to start and then we can take it from there um and Zar also if you're available um to discuss would be very nice I think I don't know if Matt will be joining but we'll see all right I see the thumbs up okay let's go Kevin uh if you if you want to take the mic and I give you the floor sure yeah uh so my proposal was not really oh for information that's that's uh lger proposal just not mine U but yeah my proposal is not really about the latest version of the EAP uh the proposal has been made when we were still discussing the previous one but it's basically

serving the same uh the same purpose I guess of trying to find revocability uh in a better way I guess than just having the nouns and and creating this Max nouns or nouns option which is Impractical for in terms of ux and everything but yeah the the the new version and Beer's proposal is basically going into the same direction I guess by trying to enforce having a single imple implementation uh at a time and and not trying to basically trying to store it somewhere uh our proposal was to store

it in a very specific storage slot mimicking what um the the proxies are doing most of the time with um the um some already known erc's and and I guess the The Proposal is just moving that directly into the contract code or or the code of the address into the gun State uh so yeah it's not really any different I guess uh except that migration later on might be more difficult or or wa yeah more difficult to handle because we will already have code so

it's not like draw said it's not temporary anymore it's it's really like permanent now uh and yeah I'm I'm curious to know if anybody is is against going into something that is more permanent I think that was one of the first thing that was actually causing issues trying to go into something that is more permanent when when we wanted to um have a more a bit more space I guess to to um to try to do that so it's not really I don't really have any question I guess specifically on the spec it's more

like I confirm that this is the kind of of direction that ledger could be able to handle way more than this multiple authorization at the time thingy that was really difficult I guess all right um thanks for your comments uh maybe I've Sam Wilson maybe if he's around he wants to answer or oh I see Matt joined or enar any one of you just raise the hand take the mic yeah sure um

hey um unfortunately I wasn't really um super super involved um over the last two weeks around 772 had a look um at this propose change though um I think directionally it's kind of the right direction to explore in um basically uh staring the delegation Target um I think conceptually it it is somewhat cleaner just because um uh it it is more reassuring for users because at any given moment in time you only have like this one um uh delegation Target so so so it is basically obvious

you can always revoke but basically um over overriding it so so I think in principle I like it the one thing that I was wondering so when when when that idea first came out um um like couple weeks ago um just as as a rough idea I was picturing more something that basically that was not in itself immediately like lasting beyond the scope of the transaction right so basically the the old version of 7702 you set the the the um the delegation Target it only for the scope of the transaction right and then at the end of the transaction that's clear with this new version you store it um and then it is valid and and inactive um um from

then on out right until until you you you change it and then I am very uncertain whether that is the right approach um and I actually be curious to to have some feedback from people here so the the one alternative I've been thinking about and it also has it own downsides but the alternative I've been thinking about is basically do the same thing store it um in the code field the the delegation Target but it is still only active during the scope of the transaction where it was set and then afterwards it's still sitting there but it is only sitting there as basically the only currently valid delegation option it doesn't mean it is active so outside of the scope of the transaction if you the the account account code you would be told that there is no code and

if you call into it indeed nothing happens um and then basically um there would be two different options how you could actually activate the delegation Target so one would always be as part of uh whenever you're in a 7702 transaction if you actually change the delegation Target right with with basically nonsense signature and everything then doing that new transaction doing that transaction it would that that it would be active but then also you could instead basically um I don't know add another field to the 772 transaction or something where you basically just list a just just give a list of addresses completely without any authentication so there's no signatures no nothing no nonis and and and for for for this list

of addresses that the transaction Center specifies basically you you just within the scope of the transaction you you activate the delegation Target if if set again so basically it it would basically make this delegation not not not not permanently active but only active manually to to be activated by the transaction by every individual transaction cender I personally think I like this a bit more although of course it comes with the sound on downsides and I'd be curious how people think about this kind of so yeah so with with that approach doesn't that mean the transaction originator gets to decide whether your account has coding it or not and not the actual owner of the account this was already true in 7702

before this change yeah I suppose Yeah so basically it would recreate this this behavior of non-revocable um 7702 signatures that basically would have been floating around uh forever and anyone could have ever just decided to pick it up and use it for that transaction to temporarily give you code the only difference now is that you can prevent anyone from doing this in the future by just physically unsetting uh or or overwriting with a different one uh the field in your transaction so it's not basically the change would only be in behavior that now for User it's not unpredictable whether that can happen but you can always just look do I have the delegation Target set currently and if so that can happen to me and if I don't

want this I can always just unset it but but yeah yeah interesting uh maybe Matt you want to say something about it um this was your call yep go ahead sorry I'm I'm running late this morning I didn't see what the first I kind of only came in as suncar was talking there no is you didn't miss much um so the the first uh question well comment came from kin from Ledger um he

explained that he they didn't really like the permanent approach uh that was um made during this uh update and enar explained another alternative uh to this so maybe enar if you can re explain quickly for Matt yeah sure and this is just basically a question a question that I was having for for people here is um I'm a bit uncertain this this proposed change by has this new property that once you set the delegation Target it is active even beyond the scope of the transaction where it was set so basically you set it and then it is you

know in in in the account and then from that on moment onwards basically your account just has that code basically for all intents and purposes until you change the delegation Target with another 7702 transaction um and this might be fine it might be that we decide that this is actually Behavior we want um I I was thinking about whether there's any value in the alternative where whether delegation still ends at the end of this the transaction where it was initially set you you still store the information though so basically from that moment on basically it is in the account code just as a if it is ever if delegation is ever activated for this account this is the only allowed delegation Target basically and you can change it you can change it with another

7702 signature that that basically has comes with a nons and is basically revocable in that sense and everything but as long as it's not change as long as it's sitting in the account it is not active by default within normal transactions but any 7702 sender can basically add just in an extra field or so just the the just the address itself doesn't have to have any signature or anything attached to it and if they do so basically if they specify hey please add this account to the list of accounts that are active within the scope of my transaction you you basically activate delegation again temporarily and I'm just wondering people think there would be any value in that alternative approach yeah I mean let me I guess I

can just say something quickly about the proposal to me what we're doing is we're sort of Leaning into what actually happens when you make a permanent delegation under 3074 under 7702 something without revocation and yes the way that these things are manifesting in the new 7702 proposal is very different because before you had to bring the authorization on chain every single time that you wanted something to happen but if there wasn't revocation which again is like an important thing to have some of the use cases that we want like you know social recovery or um delegating to more hot wallets then you have kind of given this

permanent delegation and it's really just an implementation detail whether the user needs to send that authorization on chain that can't be revoked or if something is stored in the account that says at some point in the past this was authorized and it will continue to be authorized into the future until the user revokes it the nice thing about the new 772 proposal is that it finally addresses and what I think is a much nicer way how to deal with the revocation story and what I mean by that is that now the authorization is only valid one time for the specific kns the nons is required and that's okay because you are setting the author authorization the account so so you consume an

authorization it's no longer valid the account is delegated to a Smart contract wallet for the you know in perpetuity until they change it and this is really achieving the things that we were hoping to achieve with 772 which is creating an experience that is like using a smart contract wallet and I think that like what you're proposing onar and what 772 sort of used to do 3074 used to do always had this difference between what smart contract wallets are today and what they were under 7702 where you sort of have these like kind of ephemeral authorizations and we had a way of them being irrevocable by just signing something without an Nots and

then we had some optional revocation but now that we can write it into the account this feels like the best thing to do and now it's kind of like I deploy a smart contract wall to my account but I haven't given up on the ability to originate TR transactions from my EA this sort of gives us like The Best of Both Worlds and sense and it sort of lets people slowly try and migrate not just people let people and developers slowly try and migrate to Smart accounts that's the summary I guess thanks Eric you have your hand raised yeah so just to I I think actually connecting to what Matt said

just in his last sentence I think in order to actually let people try it out uh and slowly get into this process you don't do that by giving them permanent and only permanent uh uh delegation scheme because like it isn't permanent it's permanent so I'll I'll put it differently it delegates for as long as the account as long as you don't do another action right so basically from that point forward let's say you have a million dollars in your account from that point those million dollars are dependent on the safety of the contract if there's a new hack found two

years from now if you didn't do something there change something that money is gone versus in a different situation uh where you do have the option I'm not against the option of permanent approval I think it's useful uh but it's useful in a process where in some situ situations people will uh prefer to initially have one off delegations and at some point emulate this behavior all you have to do is have a revocation piece of logic at the very beginning so you set the flag for the first time that this code has been called it can never be called again yes it still exists in your account but now

none of the rest of the logic is going execute and if you want to update and using new piece of code in that account you would have to sign a new delegation right but that's like so that's good as long as that code is not broken I mean if we can't write a revocation flag that's not broken then we need to like revisit what are we doing here no but like you know there's a lot of different ways that things get get broken so like what I think makes sense in that like again in the approach towards and I'm just thinking about this from just do to explain the angle like we clients we make the decision to opt end users into this

situation so if you're suddenly with the decision do I opt a 100,000 users into this experience your risk management is very harsh you you really have to think about anything you enable and it's much easier to enable something for the duration of a transaction than enabling something until otherwise uh uh and by the way this the I I think a good similarity to think about is bridging so there's a lot of people that are willing to use a bridge to go between chains but they will not stay on synthetic assets that have pernament uh Bridge risk associated to them and I think this is similar but instead of bridge risk with

smart contract risk so as a user you can decide and here we're kind of taking that decision away unless if you do another transaction and I actually think that like there should be a pretty simple solution where we say you can decide when you do 7702 do you want this to be a one-time thing and not have Smart contract risk regarding how simple it is or you're you want to opt in for a Slicker experience over time where you delegate until otherwise said it should be quite similar and I I don't see the side uh I don't see the downsides to to have this SP I mean I I agree with you I see what you're saying thing but

ultimately we haven't come up with a mechanism that gives us the best of having permanent delegations which is very important and aligns us more with what smart contract wallets look like today and will look like in the future and having this temporary execution and like ultimately this temporary delegation mechanism is something that does not bring us closer to Smart contract wallets so I just don't really see much of a reason to have it like yes we might get some users and we might have some organizations who feel that the risk profile out is better but I don't think that this like moves as closer to the end goal that we're trying to get which is getting everyone to Smart contract

wallet one day so so I I I actually think it is the most important thing in getting us closer to that and I'll explain um right now um there's separate proes between like EA wallets and smart contract wallets as to how you interact with user in a Dap and just having the ability with a low amount of risk for an EA account to support the you know the I don't remember all of the the eips and ercs that are happening right now for batching for gas list so the fact that both ecosystems will be able to play in this playground and do this together and push the DAP ecosystem in the same

direction without having to do a big risk change uh I mean preached into the choir here very meaningful I have been saying this for like four three or four years I agree but I don't think that the risk profile is that different between delegating to a Smart contract wallet especially something like safe which has tens of billions hundreds of billions of assets locked like are you're basically saying that you don't trust a safe so with so for example for me it would be very different and this is even on the personal level between safe and safe plus model like any module that you have on safe because most of them have not been widely used have not had traction

there's very little modularity built on safe that has any of the same kind of Lindy effects as safe itself has right but then I'm also thinking about other smart contracts that don't have that so you know it's like the this risk difference is actually very big and I think like this is kind of like I I think the main point it is very big so having this for a single transaction puts you in so much less risk than anything else for a person that is concerned about that risk I'm sure not everybody is so doing this having this option is actually going to be a huge driver in adoption and in collaboration uh in making those things happen I think it's a huge unlock that's why I'm

actually like I'm very vocal about it because I think it's huge for the ecosystem to be able to do this um and as far I think the solution that you already brought just misses one flag of saying at the end I'm not sure what's the best approach either delete the code or just have one bit that says I know I have the address here but actually it's not delegated anymore uh or something like that you know like you guys have a lot of options for for solving this but I think it's going to be very important and with that change this new suggestion is actually gives you kind of both the first step which is temporary delegation and the Second Step which is long-term

delegation and then the third step is going to be possibly a forever delegation but that's like you actually get three steps instead of two and the difference is uh uh very big interesting uh I see a lot of chat going on Ansgar uh you want to take the mic for a minute yeah yeah I just wanted to briefly point out one point because in principle I actually like the idea of adding actually in directly in the protocol adding a one time use flag of sorts that basically says hey do the thing but at the end of the transaction just don't write it at all to the to the boat right you basically just it's it's just emal like that the the the one

problem that I think is actually hard to solve with this is the the the the problem of extracting and and front running that that signature so so so if you send that VI the public M Pool anyone can just basically see that just extract that has sent their own 7702 transaction that that basically uses your in and then um because it's not it doesn't actually commit to um to what transaction it would have to be used within right that that's kind of one of those those fundamental 702 um properties and so then by the time that that actual transaction is run it's it's no longer valid and can't be used anymore right and and that that I assume in most use cas that wouldn't actually necessarily like be a

vulnerability um because just because it's active doing that other transaction it's not like you can do anything with it um but you can basically just grieve the user because it they can't actually make make use of it so so I'm I am wondering if there's good ways to Rally mitigate this because otherwise I I I just I I I don't don't don't really see how basically in protocol like this in protocol one time um one time use could work and of course where Matt Matt's Matt's proposed idea of like basically just leaving it up to contract logic um at least that would have the upside that it could be conditional so basically you you could see that that you don't actually like consume it um

within an authorized context um so so I don't know like I'm I'm I'm I'm I'm I'm just wondering whether there's any any good way to make the in protocol one time use um work in in an unable way I'm not sure ultimately we just need to buckle down and Implement smart contract wallets or have a way of inter integrating with existing smart contract alts in ways that are safe or that people consider not to be risky because really the whole argument is hinging on the fact that there's a different risk profile between using this permanent delegation and using you know some temporary delegation

but like in theory we could Implement a piece of code that is provably secure that we could Perman permanently delegate to of course this doing this is hard and one might say that safe has already done this but if we have this piece of code that doesn't have risk then there is no point in having the temporary delegation the only point of having a temporary delegation is to develop some flows which are not easily replicatable within the smart contract wallet ecosystem interesting take um maybe we can have some words from safe or I

mean I think in general I for us mean we are biased right like first of all because we are a smart contract wallet and I think as we all Realize by now that this new version is going a little bit more in the direction of the full migration par which I think for existing smart contract buets is um quite nice to have I still understand uh some of the reasons also from from aric around having it as a one-time use only it's the interesting for me the biggest question would you considering the time considering the state that we are in what is the most realistic version to push into a hard Fork right like I think we will never get to this version where

all of us really say awesome that is exactly what we wanted all of us right like so this is um and then whatever we add and whatever tradeoff we make we have to think okay what is the complexity here we want to ship it in defet 2 by now I think defet one is not even on the list anymore right now so for for me personally and also for safe right like this is um I think this is the biggest question right like okay do we like as also like Cent said in the shat right like is it enough that we can Implement most of one time usage in the contract and we have to then trust it and then we in the beginning potentially have to have stronger white list yeah white listing or similar to make sure

that only contracts where we know that this revocation Works uh is in there um or do we want to go back completely to the initial version where we like before this proposal right like because we said okay this one is the one that was accept indefinite one but the other challenge was I think that actually there were a lot more questions around this revoc revocability than we have right now I think the re on a from a security standpoint the new proposal is I think has a wi way wider adop like a support and I would yeah so since we you know from we care about security and the revocation is important there seems a

good way to go from us but ultimately I think both of them are fine for us both verions yes and I agree with what Ana is writing in the sh like so really have to keep the time in the back of our head right like it's not that we can take another month to really iterate over the specs we basically should within the next week align on the specs so that we can in the next all C of meetings say okay this is a spec that we want to um align on and what that we want to finalize absolutely um good point indeed it has been a discussion topic for the last month or so and um hot Fork is

coming the dev Nets are already uh ongoing so yeah this is going to be very important to solve in the next uh days or so uh Ahmed I think you raised your hand first y um so I have one one suggestion here is that to preserve the old 7702 uh Behavior we can simply add a flag bullion it's one bit false or true if uh this authorization is temporary meaning it will be reverted at the end

of or delegation sorry it's going to be um uh uh like reverted at the end of the transaction or not um the nice thing about this is that once it consumes the nons it's it's as if we had used the older 7702 uh Implement uh implementation which is currently uh the EIP the current EIP before light clein PR but we gain the implementation Simplicity and from from the client perspective from the court Dev team perspective the light client PR is way better in in

in the in the implementation perspective whereas this would preserve the same kind of behavior you have the temporary only for one transaction kind of authorization it's still there uh you have the non-temporary uh and then you can even the non-temporary you can still revoke it uh by pushing another transaction to change the designation so like this satisfies all uh uh like uh concerns whoever wants to designate once and for all can do it whoever wants to do it for a single transaction can do it whoever wants the option to even change his designation at a later time can also

do it so we have a path forward for all three with the better implementation of thep also uh as I see this designation approach is from the Corp they have an execution client perspective as a way better approach than the what the EIP currently is right that sounds ideal indeed uh but there seems to be a debate around a Dos issue and Scar can you extend on this uh ah sure yeah I mean just summ again

so basically the problem I see is just that um if you if you send such a one-time uh youth uh signature uh basically as part of I don't know user op or so in the 437 men poool and then some band wants to pick it up or something it it while it is in the public men pool anyone could basically just pick it up um uh without your user op so basically just just send a 77 or2 transaction that uses the sign and then in in within that transaction doesn't actually make use of your account being there it just basically consumes the sign inure up um and that way basically not actually hurting you but just griefing you so so that then by the time the bundler tries to to add it or so it's no longer

valid was my concern that that's not why I had my hand raised but yeah yeah sure go ahead for or yeah maybe have you want to reply to this no I I just want uh a better understanding like it would just invalidate the transaction that's it well it it would basically just invalid like so so so by the time I don't know the bander tries to to include it it basically it would be like hey you know that signature the non is no longer valid because it was already used so it would just with it like it would just be be no op in that sense like it would it would just not activate and that user op would be skipped in the bundle so so so basically the user could not actually make use of the the one time um

and you had another point or yeah right I mean so if someone if someone uses the authorization for one time yeah then then then yeah that would invalidate that that transaction I got you okay thank you thank you I will I will think about it thank you good yeah yeah but otherwise I I agree I think otherwise it would be really desirable so maybe we can find a way um the other point I just wanted to make is yes in terms of timing um as I was saying in chat um I do think there really is um um time pessure to some extent at the same time I just just for context setting like the upcoming Petra f it is very unusual um and that's important to be aware of in in terms of

just this its size it's very unprecedented we usually have like small three four five six e forks I think this one has like I don't know well above 10 10 to 20 I don't know eips um and and and several really really big ones so I think realistically of course it can things can always go perfectly and actually you know we are rolling it out in a couple of months and then really basically the the 772 spec should should be final like very soon otherwise it wouldn't be make it but like realistically most likely it'll have several months of delay so there's still a a little bit of room to to figure out details of 7702 what could happen though is that it ends up being split into two with the the the eips that are basically already done and also implemented being shipped out relatively

soon um and so they are really then and then the rest basically in a follow-up for a couple months later um and and if that if that were to happen then then basically there's you know we have to just basically decide do we want to like really rush to finalization of of the AP and then try to make it into that first um first part if if if it exists um or take the extra few months to to make make sure that this this has the best TR possible I would personally into the second but you know up for us um this like over the next few orod devs I think this will shape up a bit more clearly um in the meantime I do think there's a few decisions we have to make very soon um people already mentioned the dev Nets I think we should ideally on this call H

decide what recommendation to give for aods in terms of um what to ship on on on on on on the next upcoming Dev Nets so like uh uh so basically should do we want this proposed change byat to to to be the one that is is is the next one implemented yes or no um and if so I think there's still some details to be figured out I think some people had concerns like I think the the cost of the of the 7702 signature should be increased to to account for this this permanent storage change um and then also um I I personally for example wonder whether we actually want to make the existence of that delegation transparent or not so basically whether the reading the code should actually

show you that there's some UF code in there I think UF has restrictions anywhere where you can't actually see the specific UF code so you wouldn't be able to see the delegation Target you just see that there is UF code in there um so I think basically we yeah so I think for now we should focus on on maybe on that decision like like what should be the spec that that we want people to use for the upcoming Dev Nets yep good point uh ahed you have something to raise about this yeah so I have what two points uh I'll first address one of ansgar's concerns about introspection um so code introspection is very very like youf

tries as much as it can to disable code introspection and like uh remove the ability to know if this account is uh is uh what or gas introspection for that matter um and that's one of the goals for eof to remove this uh for for for various reasons right but uh so yeah that that one thing is I would I would try to avoid uh introspection uh uh of the code or of what the account that is there I would try to follow whatever e is doing and apply it here in this case as well so that's one thing the second thing is

that I wanted to ask like um if if uh if we have the uh the the the the knowledge that a one-time uh designation or a temporary designation will be consumed by a certain account for example the sender's account then we can attach to the authorization the account that can consume it and if that address does not align with the with the address that sent the initial transaction uh then then we do not count that as a valid authorization and thus we do not increase the non uh um of course uh if this does not

work I'm not I'm not sure if this will will work well with uh pay masters because like you not necessarily know who your pay Master is uh when you're submitting a transaction but um I'm not entirely sure if this is uh like a requirement that we need to allow anyone to consume the authorization the temporary author ization or not all right um like client maybe you have something to add

on the discussions that are going on in the chat uh I think it's not very clear if everyone wants uh to go for the devet with Matt's proposal or not uh from what I read I see people seem to be okay with it um the problem with this format in general is that we have a lot of people with a lot of different things that they would like to do with this proposal and we end up needing to like agree on one specific thing and it's hard to do that and so we instead we say like we can do both things we can do temporary and we

can do to permanent and then the EIP and implementation grows and grows so I just I don't support the temporary delegation I don't think that that it's needed I think that you can emulate the exact same thing with the permanent delegation that is in the proposal and it's a lot simpler to implement this than it is to add Flags or to interpret the delegations differently I see uh good points you have you have you have your hand raised uh yeah so I first I also agree that I don't think temporary delegation is really needed since it can be

emulated but if uh but if we want it and we still want to mitigate uh I mean still need to mitigate the issue that Anar raised maybe it could be related to a revert like you could have a I mean if you if you associate it with a rever then instead of a particular sender then it would become possible to to use it with 437 because just if you have a contract that otherwise fails fails validation and causes a revert then you get a different Behavior so I'm just thinking whether we could I mean if we do need to do temporary delegation whether we could use uh whether we could associate it

with re with reverts anything to to reply to this Matt or Nar yeah go ahead yeah I'm just wondering um because I was also briefly thinking about this so basically um how would you handle the following cases I mean a a 7702 transaction that you has a one time signature in it but then within the transaction um that account is just never called um so there's no revert or no passing um or B um I mean of course

many smart accounts basically also just have code paths that don't revert that are very trivial like you just send something some some eth to it and it just accepts the eth you know doesn't revert so so you can basically it's a bit more expensive to grief then but you can still basically just have it be used in a way that doesn't revert um or see you know like some sort of multiflow way within the same transaction it is called into multiple times and revert sometimes and doesn't revert the other times like it seems tricky to to I think I think you are right since it can be included in a transaction that actually doesn't call the contract so it has no opportunity to revert then your solution will not work so so I go back to the original to what I said

originally that uh maybe we don't need the temporary delegation yeah yeah you you could try to make it work right but just basically saying that the the the nons is just only increased the time the first time in the transaction that it that the the account is actually used or something I'm I'm not sure it's a good idea but like it maybe what exploring I think yeah so I see Sam wrote about a self-destruct which could also be a case you could say that uh I mean if you could if you could use a self-destruct or something similar uh during uh during validation of such a transaction say that like during this transaction you say this is now becoming invalid you

know that's we I'm now invalidating and otherwise it doesn't get invalidated maybe it could be made safe but I think we need to think more about it it's hard to like to think about all the all the cases here uh so then we would go back to Matt's proposal right for the time being yeah I think so all right okay sounds good uh kin you have your hand raised yeah just wanted to mention that that the basically the the thing that we're mentioning here being able to remove the the delegation into a same the same transaction or or or directly from the

implementation itself is part of why lger proposed to use a start slot instead of um directly changing the account code that way it's it's basically uh as easy as just having a simple method in your in your contract capable of removing that that Sor slot value from whatever implementation you had and going back to zero and that could be inside of the same um inside of the same transaction yeah Matt is bringing the point that the protocol should not touch the user storage oh so we're back at not doing asore right that that's I think

that was kind of um we kind of changed opinion on that but maybe I misunderstood I don't know if I understand the proposal but I don't think that we should have a protocol mechanism that reads from the storage of a user account and then allows the user to like you know modify that storage to change like the behavior that account that is sort of conflating the like protocol the the kernel space of the protocol and then the user space that applications have access okay right um all right

so let's get um a last round of uh for or against the new proposal and um and see if we can move forward for devet to and say that we think it's it's a good thing to to go forward with it um I think so far from the client team and from the researcher um people seem to agree around this new updates um so maybe I I we'll let the floor for a few more minutes and then we will try to to make a decision around

this if anyone has more points to bring now it's the time Evo you have something nope we're just muted yeah because I feel like we talked about a couple options now and you mentioned there's I I do think there's one that most people align on at least feeling wise but I'm not sure if we all are really on the same line and that's why I think it might be helpful to just one time go through it so right like we do not allow temporary revocation as far as I understood it is persisted with inside

the code storage using um EF format so it's a EF bite code starting um so that it's in this uh and it is dependent on the nons and can only be be used like once and then it's persisted right like that is a very simple I just want to make sure if this is really the version just to avoid that people misunderstood Anar happy if you want to add this or have a different question yeah I think right now sorry go no I just wonder say yeah so so I think indeed basically right now we seem to mostly all align that Matt's proposal is a sensible next step to take basically in terms for the spec I still would want to

explore my idea a bit more to basically make it so that it doesn't it it's still stored um persistently but it's not active by default in future transactions you have to manually basically activate it in future transactions but given that that's conceptually more an extension of Met's idea because it would still use this persistence mechanism I think it it it would not basically we wouldn't have to decide on it now it's more like we would go with Mets update to the spec and then at some point potentially later add that extension which we might or might not want to um so in terms of future defs and whatnot that would still be useful to Bally change to Mets version so my question here would be more do we have people on the call that pref that basically strongly oppose that

direction in general like like basically either Mets or my my variant of it and and um and would just really strongly prefer the old version of 7702 um because if we otherwise if we have broad agreement to make that step then we could already basically over the next few days work towards figuring out the details of Met's proposal and then merging it so that you know at least we move in that direction absolutely Evo you want to add something yes um I'm actually opposing temporary delegations and the reason for this is that I think the ux in practice of temporary delegations doesn't really make sense because there's very little account obstruction features that you

can actually experience in a proper way using temporary delegations like one simple example would be batching in the majority of cases batching would be valuable with erc20 approvals um and in this case you only need to batch two calls uh so in this case you would have uh like one signature for the user op and one signature for the delegation so it cancels uh it cancels the benefit from batching uh and then it also cancels the benefit from sponsorships right because you need to do the delegation before you actually benefit from the sponsorship so I think there's very little account obstruction use cases where temporary delegation would make sense uh and I think emulating it on chain uh in some sort of

a minimal way where you can for example emulate it for let's say a week or a day or whatever makes a lot more sense and this emulation code can be argued that can be absolutely safe enough um to be as safe as um the current the current security model all right so compared to like the current uh proposal that we were're discussing you you meant the so you

strongly oppose a temporary revocation temporary uh authorizations so I oppose the ability to like set an authorization in a way that it would get automatically revoked in one in one interaction in one 7702 interaction right not that uh Sam could you expand on the uh mutating account codes uh what did you meant did you mean oh uh like if you can change your delegate call Target like with another 7702 transaction and that Target is starting stored in the

account's code field then doesn't that mean you can mutate your account's code field oh okay yeah and go ahead yeah on that point um I I also I was thinking about this as well it does seem to be concerned but of course the thing is that with original 7702 that also is already the case right so basically that within different transactions you have different code um and I think the idea was also already to make it introspect so that you you actually see as if that that code was permanent and then all of a sudden at the end of the transaction that's no longer the case and then you have a different different code and the next transaction and so on so that is already a

concern um part of the reason why I was proposing my my extension of this that b would not by default be active with beyond the scope of the transaction is that I think it is somewhat problematic that now basically you can over multiple times basically over the course of a week you can check and recheck and recheck and recheck and you always see the same code and then it later on changes so it becomes conceptually I guess even a bit more of a it looks permanent and then it vanishes or gets changed but I feel like it basically it this this is a problem that's in general inh in some ways inherent to 7702 right because either you make it immediately per permanent or or or you basically have will have this problem in some variant I I I think it's basically

unavoidable uh Evo do you still have your hand raised or is this from the previous points no that the previous Point okay okay yep Richard go ahead also with the introspection right like why I get the point that this changes the behavior of how you interact with a blockchain or like how onchain contracts behave because offchain you could just check that it is really this special case with that starts with thef I think with proxies we're already in a state where you have to differentiate or like separate like what is the bite code and what is the behavior so I know that it changes an invariant but I don't think

it's the worst development that people start separating these two more clearly so yeah yep I would have another point um if there's no question towards this mutability of code also brought up by sen um I found idea interesting because it would allow potentially to make it easier to emulate this onetime transaction part or this limited time transaction part is to allow somehow for example Sam mentioned self-destruct to reset like the authorization why I find this interesting is because if you just revert that basically means that if you set your code to an address that after a

certain point of time reverts you would have to create a new authorization to activate your account again to make it usable again because if it just by default reverts at the first op code after a certain point of time that means you cannot receive ether ether you could not re receive any token that does a um call back into your account so rather having a way that after a certain time it would just self-destruct really itself would be interesting but I'm not sure if this is basically going a little bit against idea of um this we want to deprecate se struct um that's a little bit the question but here again we have mutating code already so so I think the the really interesting

thing with self-destruct is you could do it as the absolute first thing in your contract um and then guarantee that your code will only be temporary um yeah yeah interesting but then it reopens the self-destruct defecation Pender box again but uh yeah but it would be limited towards these these two account types which we can check right like we can very clearly differentiate these accounts that are allowed to do self-destruct because they are are kind of mutable accounts in a in any case basically and for them self-destruct is

just resetting their state to the original state where this other but again right like I know that it adds existing complexity and maybe this should rather be an extension that is more optional that we can evaluate but it would make it easier to emulate a couple of these temporary use cases is um are we still planning on removing self-destruct even in the same transaction I don't think so yeah so that be fine for this I think vitalic still wants to remove self-destruct even within the same transaction for my understanding not sure if this will ever happen but I think the intention is still there we could make it harder uh yeah to be discussed I guess

uh probably good to to bring that point uh to the next ACD or so um we are soon uh reaching the end of this call um I think we can go back maybe to enar uh question about defit 2 and do we want to have uh this uh new proposal from like client in the in the nextnet I think so far uh people are pretty aligned on this uh in in the call um so I I think I think we could move forward with this and and obviously it's

a it's a devet so we will take it from there and and see how it goes for the final version but uh I think it wouldn't hurt uh to go forward with this in order to be able to explore more um in the in the next stages so if that sounds good for you guys I think we can we can wrap this up maybe Matt you have some final thoughts that you want to share uh no final thoughts thanks everybody for the feedback on the pr and

in this call I think we'll let things sit for another couple days probably early next week try to merge there's some things I need to update in the EIP like the title and some of the um more like accessory paragraphs in in the EAP so keep an eye out those updates but yeah you know unless someone comes with a different idea then I would expect this to be merged before the all cord call next week and we can discuss having it for devet 2 with all the client teams all right sounds great uh thanks everyone for joining and see you in the

next goals thank you thanks everyone thanks everyone e

e e