Future of EOA and AA Breakout #4

Transcript

Tim Beiko: okay I guess we probably get started um I had a few things on the agenda for today um basically some spec discussions and then following up on what best practices and I don't know if there's been a um an update on the proxy pattern um but yeah see how how things go uh and S is here so I guess uh yeah let's maybe kick this off uh with the uh revocability uh conversation so Sun deep I believe you're the one who posted on

the

Aragon uh or on Aragon's behalf on eth magicians around optional revocability um do you want to

Tim Beiko: take maybe a minute to like walk through your views and yeah concerns

there

Sudeep Kumar: yeah so uh with the um revocability question uh we have been considering the uh sort of security uh handling and concerns uh and saying that it's the same as a private key or a seed phrase um but yeah like I disagree there because uh once you delete the wallet from your browser the seed phras or the private key is supposed to be gone and

it's no more with the wallet provider but um with the signatures it's it's a different deal like once you make a 77 transaction the authorizations live um on the chain and uh so so let's say if I don't trust the wallet anymore and I want to move to a different wallet uh then I should have an option to uh do something similar to you know sign out of all accounts or sign sign out of all devices uh there there has to be like a mechanism for that and uh yeah otherwise there's always a lingering question about uh you know is it safe there was a um authorization that that was there and it wasn't really revoked so what what happens there

uh

secondly uh second point is that um you know you know like with um sorry just a minute um yeah uh so so the people who are opposed to revocability um I don't think they're opposed to um revocability as such but the constraints that it poses on the wallet providers um and and I think the nun solution the nun revocability is definitely um like too constraining for the wallet providers to create the

create a proper ux so I think we should investigate like more solutions um certainly Max nun is uh one such option the nun manager is one such options and um you know like I think we can like come together with come together with more solutions on top of this which have revocability baked in and also allow the wallet providers enough uh sort of breathing room to create the Ys that they want uh so I think that's the two points I want to put forward okay and yeah I guess so there's uh some yeah some some comments in the chat

around like uh if the wallet sent out the private key it would also be unsafe forever even if you deleted the signature um and then yeah maybe some comments from you about like if the youing your Hardware wallet then the the private key basically should not leave the hardware wallet so there's like a difference in trust assumptions there where like if you use a hardware wallet today I have the private key on there and then use you know something like metamask or rabby or whatever to like interact online um there's no way that like metamask can leak your Ledger private key um and this is like a change in ch

assumptions whereas under 7702 if metamask signs something um effectively makes every wallet like a hot wallet um I guess is that like maybe uh yeah ongar yeah is is that like how you would describe the trust model like you know any 7702 um every 7702 wallet should be thought of like as a hot wallet basically um Richard yeah I mean sure sure I mean I M Tech is basically just the moment you sign a 7702 signature that basically is like ending out like extracting your private key from one

wallet and into inputting into another wallet and in this case you're just inputting it into a um smart contract in a way um which is definitely new but it but in terms of like how the trust assumptions to your old wallet are basically the same at least that's that's my understanding right then I guess yeah the the risk that the user is like you think you're just signing something just like how you sign like a random uh signin message uh on your Ledger but then you're actually doing something that's closer to export in your private key um and and that's like not super obvious to the user well to be to be

clear of course the idea was always that this would already be a failure by the wallet like you should never make it look like signing a signature it should look like exporting your private key or something something close to it at least like it should definitely Goose closer to exporting the private key than to signing a signature um and so the question is more to what extent do we trust that wallets do will follow those those best practices and recommendations around how to how to expose this got it um Richard yeah basically also what Anka said right like for me the question was also when we had the breakout session in Berlin actually there we had people also from leer there right like and we talked with them and it was already a big benefit that there is a very distinct

way that wallets can enforce it right like you trust the wallet already to a big part if you don't trust your wallet you kind of lost in any case um and the wallets should enforce that you set a nons right like not setting the nons I mean we when in the best practices we try to outline it in what cases do you not set the nons there I think especially in the short term that's more like a like a very Advanced case that normal it's most likely will not enable at all why should let you enable this there's no good reason for this um but this I think in general for me the question which I also post on like where should we enforce it on on the wallet level which we have to we have trust assumptions towards wallet in any case

already and where should we enforce it on the protocol level and where is it just that we provide a means to enforce it right like so this is it would be interesting to understand a little bit better this this shift because this is for me in general I think everybody agrees we want to provide or we are fine with providing a way to for revocations it's not the discussion anymore right thanks and yeah I guess um yeah I guess one also uh yeah question around like unrevoke uh transactions is you know if you do like

you always saying if you do change your wallet um you know you realize your old wallet was a bad wallet um yeah effectively the the if it's not a revocable signature then uh you sort of have to assume let see that it's as bad as if the private key had been compromising that wallet um yeah and I guess uh step like what what would you feel comfort with uh in terms of like yeah design um um yeah definitely revocability

should be there and then um like some way somewhere to have uh where the world provider also have theity design the ux that they want so you know it's it's not um not like maybe nuns where you just make an year transaction it invalidates all the authorizations uh so definitely not as restrictive as that but uh yeah there should be enough breathing room for the work ERS as well but yeah revocability should be mandatory um I think another point is that if we allow the work providers the option to have revokable or non-revocable signatures or authorization then um I don't know maybe

we allow the users we let the users also we sort of leak that information to the user as well where they have where the user has to know if they're signing a nonre revocable or revocable um authorization and and that's that's not exactly user friendly for me and uh secondly what's stopping the wallet providers from just having uh non-revocable authorization in in their ux and and the user later on realizes oh it was non-revocable and now I can't do anything thanks uh Oar yeah I just wanted to say that um I

think if I remember correctly on like last call there's definitely um some openness even by people who are skeptical towards the mandatory revability to at least explore that direction further because um if it was to be done in a seamless way where it wouldn't come with a lot of tradeoffs I think people would definitely be open to that um I just think so far the only proposals that we have had in that direction have just not been good enough like I think Max n specifically for example um the the general feeling was that kind of then requires some sort of in inm mechanism to bump your non spend more than one at a time which just is is a kind of like then a kind of worm in it on its own you can't really get that to

to have to have kind of nice minimum in protocol footprint so so that just seem to be non sta um non manager is like basically way too heavy as an overhead because you know you have to load an entire separate account every time you use this which would massively increase the cost so that's a nonstarter um there are ideas like for example retalic had this idea potentially saying say to just actually store the delegated address um associated with your own um account before work that's a little bit hard to do so we could do some sort of trick where we basically store it just add your address plus one basically and then put it into the code field which is a bit hacky and the question is how would that the veral transition but ideas like that could could potentially be done

where you basically then get revocability because you basically have to manually set that address and then manually change it again I think in that setting we would probably have to rework 7702 a bit more fundamentally um because then you basically just want us want basically some sort of set transaction or or something and then a revoke transaction or something so so that would definitely look like you wouldn't just basically you would have to to to make some more fundamental changes my feeling is given the pectra timeline that if there are people who are still uncomfortable with um the current optional revocability that it was be basically on them to keep pushing for and for helping finding a solution that actually is good enough that would have a full revocability um and do so reasonably soon I think if say within

the next month or so we don't have a fully speced out alternative Proposal with full revocability that is good enough and it's broadly accepted then my feeling is we will just this will not happen so just for people who kind of very much want this I think basically the owners is on them to to to find find such a solution any comments so I guess yeah when one

question I had was um you know on on the account abstraction or wallet side like if we shipped with default revocability using the nons um you know in pectra how and and potentially like find a a a an optional approach that's like maybe more complicated that people like but that that will take longer and and have that in the fork after like how bad is it or like how much of a redu reduction and and like value is it um yeah how how much of a reduction in value is it to like Shi the V1 with like mandatory revocability and then

potentially soften that in the future uh so I I I join the call kind of late so like apologize if I like apologies if I you know you know if if I miss something but like um so when you say mandatory revocability are you talking about like going back to 3074 like it was before where it's like whichard onard saying is useless right now I guess so so so so so so you're asking like how much of like a usability hit will be if like every single EA transaction revokes everything yes oh yeah yeah so so so so the the the point I've been making and you know you know you you know really it's not just me you

know I'm I'm I'm pretty sure it's like every every AA Builder every AA builder in in this uh code right you know that like like most of the most valuable AA use cases requires long-standing authorizations right so the like if every single EA transaction will invalidate everything then this will vastly reduce the usability and usefulness of this EIP yeah got thanks yeah so so so so so personally I want to maybe just say that's like personally I think I think that's the uh the changes that's I think um it was um met that proposed uh in the latest uh PR updates which is to make

nons optional um that's might be the best approach uh for now I think personally yeah in the world with um optional nons would we still be doing same nons or less than equal to nons revocability my my feeling is basically that um basically Maxim mon mechanisms so that theil would be that your count your count countly has to have a on smaller

or equal to the one that you signed over um that can still be useful in a pattern where you basically say sign over the nons you the count nons plus 5 or something but if you the problem is what if your wallet made you sign count on plus a th then basically now you the facto don't have revocability anymore so now you would have to have a mechanism in protocol to bump your nons by a thousand um but then basically you have you have to solve all these other questions of like but can you basically is there some sort of Maximum bounce level at once but then if you if you do this again then basically now you the question answer becomes now the signature should only be valid if it is at most this amount above the countr ons which means like it's basically it this

this entire kind of um flavor of Max nons signing just I I have not seen a proposal there that seems sensible okay so you would say same nons in that case yeah which that's that's why I specifically think that basically mandatory revocability using nons at all to me is just non sta because I think you you can't really do Max NS you would have to do same nons and if you do same then you have to make it optional because if you make it mandatory I think the thep is relatively useless for for the main use cases we were trying to aim yeah hard

age is is a non-starter basically the best solution sorry I missed the question could you repeat that Anna I was essentially asking whether you know regardless of whether we were shipping mandatory uh you know mandatory non spased revocability whether the non spaced revocability would be same nons like require that the account nons is the exact same as what's signed over or like maxn um so like you know uh can't be above this

nons is your him oh yeah please Anna oh I was just gonna summarize what what Anar said but but yeah Asar was saying that the max non's mechanism was like too complicated had too many gotas basically like um in terms of how we would establish best practices around it so he was saying that same Nots is the better option but that it's important to um have it be optional in that case or else the EIP is essentially useless uh s s sorry yeah so yeah agreed the same L is then nonstarter and the best solution we have for revocability is to have Max NS

with in protocol mechanism to bump the NS it's uh enor yeah I was just going to comment on a few issues that I see with having the same L revocability even in optional scenario is that as D mentioned one of the major use cases of account abstraction is session like Behavior right where you sign a transaction once and or you sign a approval once and you expect it to be available for a long time uh in if this assumption is correct then most accounts would be signing the authorization with the nuns and the

chain ID set to null in most cases and in this case once it sign then it just becomes then this particular signature becomes non-revocable right so if for whatever reason in future a bug is found in the implementation to which the authorization is signed then it still becomes non-revocable with the Max L approach you still kind of get the option to revoke it even if you feel that even if the earlier approval was given with the intent of being uh longstanding so I I feel that you know for in the worst case scenario where most of these session sessions being signed are actually longstanding the maxim approach might be might have better security guarantees yeah thanks um

Amad yeah I just wanted to bring attention towards like the hardware wallet kind of conversation because like uh we were discussing revocability and irrevocability and let's assume that Hardware wallet is account a and uh you have U smart contract Wallet account B and in account B you have account a as the authority that can control account B now would it uh wouldn't it be the same if um for example account a um had all its funds in account B already and then account B had a had a had a bug and

you then as if it is was account a who delegated to account to to a Smart contract that is similar to account B and that smart contract had a bug so it's kind of like when you do this authorization you are saying this is my smart contract wallet this is the implementation for my smart contract wallet so the same trust assumption that you're putting into a smart contract wallet should be here and if this bug exists then uh like it it will exist also uh for all the smart contract wallets that will implement the same

Implement that will have the same implementation and this this is like I think given that we already have this stress assumption for smart contract wallet I'm not sure why we're trying to impose a higher level of security for EAS that are trying to implement like follow this uh s uh yeah so so when I'm interacting with a smart contract wallet then definitely there there are there is trust placed on that and uh you know I'm doing

authorization so definitely a lot of trust is placed on that but as a user I should be able to decide the lifetime of that trust and uh like once I decide okay I want to move away from the wallet to another wallet then I I should have like a final call to be able to revoke all the previous authorizations and with revocability that is not possible but but we have a proxy for this like if you have a proxy that can do like if if you sign a proxy then you can actually assign which wallet you want as your implementation or assign none so no wallet is your implementation and you basically revoke the whole authorization if you have a proper proxy the problem is if you don't sign a proxy or a proxy

that is audited and wallets should not let you do that in the first place uh but if you're signing an audited proxy an approved proxy then this problem disappears okay but if I move to a different smart wallet then wouldn't the previous authorization still be sort of valid and it can still be used no like if you if you change the uh mation Target in your proxy contract in your proxy storage where it is storing the target whether it's outside uh

storage or uh in the in your eoa storage then that the the previous smart account implementation will not be valid anymore only the proxy is the thing that is permanent for you which can also be uh revocable by setting the target to nothing to to to the zero address or something like that okay so if I'm signing over the proxy address then it has the implementation address in the code so I'm effectively signing over that as

well is sorry no when you when you sign a proxy address you're just signing the delegation and then in the call data of the actual uh transaction you specify the target okay I see yeah David um yeah I also wanted to add my thoughts regarding the um in protocol level revocability I think for smart contract wallet in general um the 4337 itself was developed on top of the

protocol layer so um it was mostly like the account's uh obligation to have a non-repayable and a revocable approach but I think for EA it's quite different because right now protocols can make a choice to make it fully revocable at the Smart contract at the protocol level or not so I think like uh we we should somehow this in a different way because for the smart contract wallet right now like it wasn't able to have like a in protocol revocation mechanism and other than that um I actually agree that protocol level revocation is needed but the nons is not

a good approach because there are a lot of times where the AA wallets used case relies on the user for a relatively long period of time that if we assume that a a single eoa transaction revoke it it will be like um practically useless um so I it might be quite dumb but like I was thinking whether if we just add a new transaction type to just revoke all the existing um like access control that we granted to um the implementation like what would be like the approach or if that would be feasible or things like

that me responses otherwise uh and lordel sorry it's Nick it's just my GitHub handle um no I just also wanted to say that I think Echo the sentiment of protocol revocability is super important I think there's a very specific case where it can actually cause issues if you rely purely on some onchain revocation method is things like token callbacks where U something that as code behaves differently than than an EA and some implementations and you can actually you know you know you can think of scenarios where uh these these

7702 uh uh authorizations can be used as sort of Dos transactions if you have depending on you know how it's implement but you can cause certain token transfers to fail just by including these and if yeah so I do think it's super important to have protocol level revocability I also brought something up in the chat I don't know someone said we should maybe discuss it more explicitly so I can bring it up now but it was at least my understanding with 7702 is that it was meant not necessarily as sort of this end goal thing so my personal stance is I like this I I actually like nuns the nut system for revocations I liked it also for the 3074 it does sort of restrict Your Design space for

wallets but at least in my view it's not super obvious this assumption that we're making that um accounts will work as hybrid eoas and you know 7702 based smart accounts I know that this is if you have this assumption then yes obviously though this way with the nuns is is sort of really bad and really breaks a lot of things and makes it kind of useless but I would like to challenge that assumption because it isn't obvious to me and I think it's a an okay compromise given that it's sort of like a temporary solution to say that um you know for this to work for eoas then you really should use your eoa as as a sort of smart account always that's just my

opinion um Derek oh yeah you know I uh I kind of reply to that on uh on the chat as well you know but I think I think I think there are like there are a few reasons why I think it's probably like more reasonable to assume that people will be using their what like their accounts as hybrid accounts rather than using it as pure smart accounts um and the reasons are so so one right you know um um first of all like like um I think there will be a lot of users will only use 7702 for to for things like batching for example right right right you know you

know you know it's it's it's not actually like a given that like all users would be using like a fully featured smart account um and and and this is especially important because right now there are there are there are a lot of applications that are not very compatible with smart accounts right so if a user only uses their OS as smart accounts today they will find that their account will stop working on a lot on a lot of applications because like the reality is there's a lot of a lot of applications they don't they don't work very well against Smart Ones right now right so for Pure usability reasons I expect a lot of users if not most users to be using their what is still primarily as EAS but then like turn the U into smart accounts for specific

applications that explicitly support smart accounts right um and then there are also like reasons like for example um like if you if you are going to use your EA as a 437 accounts then this will only really work on networks that actually support 4227 right so keep in mind that like 427 is a ERC right right right you know so it's not implementing into the protocol so not or networks will support 427 by default right so if you turn your EA into a 427 account it will really only work on the networks that support 4227 and on the other networks it will still be used as a ea right so I think like given all these reasons I think it's more reasonable it's way more likely to uh you know just like it's more more reasonable for us to

assume that uh accounts would be used as both EAS and smart accounts rather than just like only smart accounts yeah yeah I just add like if we're designing with the assumption that people will only use this as a smart account then why wouldn't we be laser focused on just shipping like a migration style EIP um which we're not not I think for good reasons and yeah I agree that users want to use this as a hybrid so I guess yeah we spent about

half an hour on this it doesn't seem like there's a like Silver Bullet solution um it does feel like they be value like Anar was saying in the chat to like explore the design space a bit more um is there someone you know that wants to take this on in like the next week or two um because it does feel like yeah we we need something that client teams are are comfortable shipping that um you know is provides functionality to or provides enough flexibility for smart wallets um but that uh yeah we we we don't feel compromis in

security too much um and so yeah I don't know if anyone has the bandwidth picks on in the next week or two but it it does feel like a pretty critical thing to get this shipped wait team sorry so so are you just to be clear like like I I was suggesting that we just like by default we just go with the latest PR updates which is to make turn on optional I guess based on s's comments like my concern is that the current state like we can move forward with the current state and Implement that but I think there might be some push back from

L1 CLI teams that uh yeah this is like not enough on the revocability front and we should ideally have like Alternatives that um yeah I think and and and I think like yeah basically uh yeah too deep I don't know if like on the Aragon side you have some some some band withd to spend on that yeah I can I can take a shot at it yeah I think if yeah like in and and I think yeah like figuring out what's like the right balance between flexibility for like contract developers um security

and like preventing users shooting themselves in the foot and then like complexity in terms of just protocol level changes um yeah I think if if you can like try to think through this a bit and look through the other proposals that that'd be really helpful um the other thing I know there was a comment in the chat around uh storage uh management um is there anyone sorry I lost the agenda uh is there anyone who had an update on that that we discussed it a lot last week okay so no update on the S store

issue I think yeah you have had a comment saying that c was starting to address to work on um uh yeah storage name space um but I guess nothing else on that front um and then uh siging over the address versus the code uh there was uh yeah a comment on that on the agenda um Nick do you want to give a bit of context here I didn't put that on the agenda I put it on the agenda I think it was your comment around signing on the on the form you oh yeah sorry sorry yeah

yeah you put it on each magicians um yeah yeah sure I can give a little bit more context I just argued for signing code because you it it gives you some of the I mean it is a little bit bigger right which is the the downside of using Code vers address but it gives you this uh ability to sign additional context or add additional context into what the what the EA is signing and like the main use case that I had for this is you can basically um you can encode the configuration of the of the account directly into um yeah into the code similar to what the commit would do so you yeah I gave a short example on on

The ethereum Magicians but it basically it it makes the proxy sort of simpler where you can make the uh the initial set of storage and and configuration be sort of permissionless where you don't have to um set the you know have the owner sign two messages but have the owner instead sign the code plus sign and have the code appended with some hash which represents the initialization and then have the initialization be done by anyone because the initialization is checked that it matches the the parameters for the initialization is checked against the the hash that's appended to code it was just an argument for code I I don't feel super strongly either way it's just uh it was it was a nice thing and you can one nice feature

is you can kind of use Nick's method to generate these sort of disposable accounts with 772 that use some code um because you can you can add this extra context in there for configuration but it's not something I feel super strugly about any comments or reactions one more thing I also wanted to mention this was something that was possible with 3074 because of this commit that was included in in the bites and sort of was was lost when we went to signing address over instead of code thoughts if not uh yeah I guess people

can oh yeah please I mean I can answer if nobody else is answering I think like the proxy contract supposed to basically even if you have an authorization to a proxy contract implementation somewhere the idea is that this proxy contract implementation should have like if it's not initialized by this account then it should revert any call that comes into it basically and this should be like the standard proxy contract implementation uh that Wallace will whitel list um that's the idea and when you sign this uh uh authorization then you also need to sign a a transaction that

basically initializes this uh proxy contract on the chain that you want to enable this uh on unless you um want to use some cross chain uh thing then uh this is this is different but like I think you need to push a 7702 a transaction to initialize the the the proxy to choose the target implementation that you want uh this is the I think the main idea that is being pushed right now yeah that's that's my point was then we need two signatures right you need the 772 authorization signature and you need

the the signature for for the sort of configuration for the upgrade of the account yeah so the assumption is that the wallet will will will have a built-in feature to sign both of these at the same time but you will not need to Signature to to like press sign twice I understand the this is but my point was more that you still do need two signatures and this kind of breaks um like I said I don't feel super strongly about it but it is sort of a difference with 3074 where you don't and um if you were to sort of randomly generate addresses or accounts for doing things then you

always have to have these two signatures instead of just one again it's not like a really strong use case it's just that they want to bring up that it is a little bit different from 374 and yeah but just this is this is only for authorization and not for just just to be clear this is only for sorry the initialization and not for every uh transaction no I I totally understand I understand it just lose the ability to make a permissionless initialize initialization yeah my point that's true elim yeah um so I just wanted to kind of

um talk about like the like reasoning for like the proxy because I think one thing that stands out to me is that the proxy doesn't actually solve like security issues um like yes wallet providers don't have to like sign over any like other implementations but then this just just kind of delegates like the actual security work to like whoever is in charge of like setting the implementations or whoever is in charge of like um kind of implementing like the upgrade patterns to different implementations um so what this basically just boils down to is like a verifiable way to track which implementation is currently being um

delegated to like in like the ethereum state so I think there isn't actually any need for a proxy like we just could just choose like a magic slot in the account and then um like verified implementations well like promise to kind of check the slot to see if their implementation has been like set like maybe they can all um like record their template addresses into that slot or maybe some magic value um so like they can just kind of verify to see if this slot has been set to their magic value before the implementation runs yeah that's kind of what I wanted to say right so I

guess yeah again it's not clear to me what the like or that we have like a a final Iz like design here um anyone have thoughts or strong opinions about like what the next step should be okay I guess yeah uh Ansgar has a

question around Petra timeline like I think we are pretty far along like I would have loved if we would have had this conversation in March rather than June so like I guess one yeah one concern I see is like if this takes two months to get finalized and it requires like significant changes were sort of too far along in the development process that the default half as we just Bumm this to the Vex Fork um so I think like unless there's people like actively working on this and um and and one challenge is like the amount that can be done by just like client themes alone is kind of limited

because um of the like needed context to uh like to understand like the best design for for smart accounts and and wallet providers and all of that um but yeah like we should get to a final spec in like weeks or you know if we're lucky it's like oh you know it takes us uh it takes us a lot of time but then the end State Design is actually super simple and and like maybe we can implement it later but like it yeah um yeah so I guess yeah Derek to your point like

you know uh clearly the arogant team has some issues with like the uh the optional non certification so um I would feel better if we had like an alternative or or something that was um you know that was uh yeah that that we could consider in in or that we thought were just straight up better um and we'll probably discuss this on tomorrow's call so we can get a sense of like how you know how many people like aren't happy with the option on odds but it's like I would not rely on that exclusively as the yeah Cal design

um um Tim can't we uh like because like I see that there is mostly the objection is coming from the Argon team for the null nons like if if they if if the people who are arguing for the null nons can't find a solution in a certain period of time then we include it as is is if everyone else is in agreement of on on including it how it is right now sure like look if everyone else agrees it would probably be included as is um but I think the fact that like at least one is like uncomfortable um means it's it's probably worthwhile to spend time

re yeah yes as is I mean optional amounts um yeah it like yeah I would try to spend time to see what the alternatives are um and I think yeah and the thing like yeah I would not want us to like get through like testing and whatnot and end up like removing this later on because we find some weird issue with this revocation scheme that like we didn't like yeah um and then okay and then Justin on the Bas side has uh uh handling storage as being

the yeah handling storage as being the more complicated thing um yeah I don't know Justin you want to share any more from B's perspective on that yeah I was only bringing that up because it's a potential angle that we could parallelize on and maybe accelerate things so if the revocation con uh conversations could happen in parallel with the storage conversations I think there's two different audiences um you know wallet folks may be more interested in the former and evm folks may be more interested in the latter so um at the end of the day if we could sort out the storage stuff first I think circling back to whatever we decided revocation is actually fairly trivial for us as an execution client so for for the storage part I

think one thing like there there are two challenges there are the challenge of compatibility with uh the EIP that we included that uh about empty accounts and how we to deal with empty accounts uh the one with retroactive effect and the second part is storage conflict and for storage conflict uh we don't see it as a problem uh light client doesn't see it as a problem asard doesn't see it at the problem uh because as much of a problem right because we the assumption is that you're going to sign over one client implementation or like like one implementation sorry um but but also with the solidity updates uh for uh that

that that is being discussed maybe this also can be mitigated right so that's that's that's one thing and we can we can probably discuss uh some other mechanisms but yeah and the for the other thing what I was thinking about is if the nouns of the account that is we are using the eoa like if the eoa is nounce is uh zero and it's empty and there is an authorization on it then what we can do is we can do maybe increase the anounce by one just so we can uh um we can utilize the storage and the account wouldn't be empty and then in this case it

wouldn't uh uh like like just just in the case that it is zero and we w we put something in storage then we increase the L with one that's that's one of the suggestions that I have to resolve that issue I guess do you think it's worth looking like what do you think is the best way to like resolve this should we spend more time looking at the spec or do should we actually get it like implemented in clients and you know prototype there and see what's what's a

better actually one thing that I wanted to discuss in this call is that maybe we should merge the pr um just so we can get like the clients to see the that the final state of the EIP because like not everyone is looking at the final state in the EIP from the pr some people are getting confused and probably like merging the pr would make this a lot easier for client teams and a lot of people that are looking into this to um to to to find the resource that they need to look at and then we can uh discuss change like we can always push another PR with any changes that the

community is trying to we we we we end up deciding on yeah any objections with that like I I agree that it's been uh it's been pending for like uh several weeks now and it yeah it'd be nice to have a single current View okay no objection so okay let's get that uh merged um Julian you have your hand up yeah I'm I'm in favor of having the um the current PR merged in but also

like you know we're we started talking about client implementations we've been the otm team has been focused on making an implementation on W um over the past like two two-ish weeks given the moving Target of this new PR so we've been focused on building there we're having to like continue experimenting and uh you know working alongside folks to like Implement different ideas and and and test things out um and we we'll also be working on some re you know potential revocability implementations that might be um useful in terms of Discovery or you know we we just end up deter actually making a a hard choice that

we're absolutely down for optional revocability so we're happy to share our findings over the next week or so week or two thanks um I don't know yeah we just have five minutes we didn't really have time to go into the best practice talk uh but I don't know um Richard do you want to give a quick overview uh or at least yeah highlight like where people's feedback or attention would be valuable uh outside of this call I mean in general um I would and just ask for feedback in

general because currently there is not much um I think there this will have to be updated with ever we do also rounds or nons considerations because currently there are like I put it at the top of the section some um open discussions around like should we allow null nons what our recommendations for wallets to go for because it's related to the discussion that we had what should wallets enforce and where does it protocol enforce and considering that the wallets have to make some considerations here and it as Anka said it's like a feature where users need to be aware you are handing over control over your account to a Smart account which is similar to extracting your private key the idea is like we want to provide some um concrete guidance here like currently it's separated into some

security considerations which are around like what happens like what needs to be considered if you have multiple 772 authorizations um considering that also 7702 signatures or authorizations are public and and also some guidelines when it um like polymorphic accounts can be or like accounts the address that you send can be polymorphic um we want to extend this also to like some contract guidelines I think light client provided their nice example with the um proxy and also you have kickstarted quite nicely the whole discussion around the stop pattern which are kind of best practices that we should um document because this is what wallets should check for and then in general there's a short summary right

like what should you sign and what should you allow um currently I think in the code address one there was a whole discussion right like how do you actually enforce that you know what address you're assigning I think there were fun discussions and a Ser magicians around the keyword wh listing I'm not sure if I want to go there again but this is something where we have to find a good formulation for so there it would be very helpful very nice to have some um proposals and then again nons and Shain ID we just have to align on okay what do we actually want to allow here and maybe give some examples where what makes sense in general there's some text written it's not everywhere complete but yeah it would be nice to have something um because it also helps like if we can

give this other implementers as a reference maybe it helps us have a common understanding on how 7702 is being used and what are the possibilities here I can drop the link for this shat also if that was not done already thank you um okay anything else before uh yeah before we wrap up um we only have two minutes do we want to schedule another of these calls um okay if there's no strong interest I'm

happy to move this async and you know once we've gone on aore devs and uh discussed this more and uh see like sort of the next step we can we can decide if we want the another call um but yeah anything else before we wrap up are my hopes and dreams of signing code dead I'm just kidding I guess yeah we will find out um sweet well thanks everyone then um I'll share the recording as soon as I get it from Zoom um and yeah I talk to you all uh soon all right thank you thanks everyone

thank you thank you Tim

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.