AllWalletDevs #37

Transcript

All right, that's probably long enough. Um, so thanks everybody for coming out to the 37th apparently all wallet devs call. Um, first one of the year. Uh, reminder to everybody that we've moved to an ondemand style. So we're not doing monthly calls anymore. We are just doing um whenever somebody wants to put something on the agenda, we'll have a call. And uh today we have three items. Uh the first one being associated accounts ERC892. Uh so with that I think I will hand it off.

Um and we can uh learn a little bit about this. >> Great. [clears throat and cough] Thanks Sam. Hey everybody. Uh it's first time presenting here so uh it's good to meet everybody. I think mostly new faces in the room. I'm Steve Katsman. I work as a smart contract engineer at Bass. Um my most notable contribution to the space since I joined base was the base names protocol and the base names everything that we do with base names has pretty much been in my purview. Generally I work on the base account team which is the team that owns the smart wallet and um is very interested in um account abstraction generally. Um what I'm presenting today will be um associated

accounts um which I'm going to share a couple links here and then I'm just going to share the spec itself and kind of talk to it um as I work through the spec. Please stop me and ask questions if you have them. Um I think an open conversation is the best way. If you have a question, other people probably do too. Um, and let's jump into it. Um, so at a high level, uh, associated accounts are, uh, what they sound like, a way to associate to blockchain accounts. Um, the spec is specifically chain agnostic and leveraging ERC 7930, which is the

interop address specification that was recently moved to draft. Uh the general concept here is that two blockchain accounts agree on a shared payload and uh and sign over it and in doing so they create an object that both accounts um agree describes the relationship between the two of them. Um, and so I think you know the easiest way to understand that is to look at the actual association strct which is the underlying data that the two accounts sign over. And so included in an association record is the two accounts designated by their 7930

addresses, an initiator and an approver. Though as we'll find the ordering doesn't really matter too much. uh the time stamp that the association is valid at the one it's valid till and then two fields that describe the arbitrary data and so these are optional um one of them is just a four byte interface ID and the second is an arbitrary linked data field so both accounts would see this data um I think handwavy see this data in an app context generally they would uh get to look at the encoded data and also who

they're associating with um given the app context. They would also know why this association matters probably. Um and then they would get a chance to like sign over it. Hopefully the app helps them sign over the contents. And so the second uh type that's defined by the by the spec is the signed association record. And this is a wrapper strct that contains all of the validation data that's necessary for this to be a canonical source of data for the two accounts as opposed to just arbitrary data. Um so the signed association record contains a timestamp uh for if the uh field has been or if the association has been revoked. Um a key type describing how the initiator and a

key type for the approver as well how they're going to sign the um the association record and then the actual signature bytes from their signature and the record itself. Um, and so this struck contains everything that's necessary to validate that both parties have signed over the contents of the associated account record. Um, I think I'll I'll jump in a little bit to this key type, but we don't need to spend too much time on it. It's effectively an enumeration of u what curve was used. Since this is a cross-chain specification, it could uh touch accounts that exist on chains that don't use um sect 256 K1 um or have access to uh contract validation like

1271. Um, so this is an attempt to try and reconcile that like all blockchain uh cryptographies are valid for association and you just need to tell the um association record um which one you're using when you sign. Um and so included in here is kind of two classes of key types uh cryptographic curves and then kind of integration uh key signature types like web authen or 1271.

Um cool. So that's the that's the like structure of the data. And I think that I kind of glossed this over very quickly at the beginning and I can kind of backpedal a bit. The the reason that you'd want to do this is very appsp specific and we think it's a really interesting uh mechanism for associating accounts that have a hierarchal relationship. Um on the base account team, we're building a um an account model that leverages what we call sub accounts. And a sub account is an uh smart contract wallet that is owned by like a kind of a top level universal

account. If the top level universal account has something like an ENS domain, we want the sub account to kind of inherit that identity. And so this is the mechanism that we think we can build a trustless and secure mechanism for sub accounts to like inherit the identity of their universal account. Um we also think it's a mechanism that could be used for uh delegating authorization uh to other accounts. Um uh depending on like the protocol context um or um if you wanted to say collate all of your assets on a dashboard, you could do so by

associating all your accounts and then the dashboard could see all the accounts that are associated with your um with your account. so storage is maybe the mo the last most interesting piece of the spec. Um because of the size of the data and the types of validations that could be required for validating an association. Um we think that both onchain and off-chain storage is applicable. Um, if you do decide to store associations on chain, um, we're specifying some events about creation and revocation that must be complied with. And if you're storing stuff

offchain, we're much less prescriptive, although we do uh, try and control the off-chain storage to say that access to the data must be made available to expected consumers. Um, I'd say the validation flow is relatively self-explanatory. check all the time stamps to be valid. Uh make sure that the signatures uh recover or return true to the um their respective accounts. And um and that's and that's pretty much it. Um for revoking depending on where the account uh the association is stored, revocation uh kind of changes a little bit. If it's

onchain then the revoked that field would be chained changed onchain to block timestamp and uh this specific event would be emitted. Um that's like the that's the whole spec in a nutshell. Um, included in the comments um of this call is a link to this demo site which allows you to connect your wallet and sign an association record and then connect a second wallet and sign a second one. It kind of shows you the um it shows you the underlying fields and u maybe most interestingly it has a graph view that can show you your account. Um I am um on

my wife's computer and uh because we can't have Zoom on uh work computers and so I haven't like set this up uh or done this um on this computer before and so this is all empty and it's a little uh a little sparse but it should be pretty straightforward for you to connect your wallet and um associate two accounts that you control. Um, I'm going to pause there and see if there's anything that we should like jump back up to in the spec or um anywhere. >> Sorry. Uh, I I do have a question. I can't figure out how to raise hands.

>> Like [laughter] that's a Zoom feature, but thanks so much. Um, I'm uh Hester. work with Ethereum Foundation on a um somewhat un unrelated to this uh initiative, $1 trillion initiative. The question I have is a little bit of a new question, but can you uh clarify for me the difference you're uh in how you're defining associated account with delegated account uh in this context because there's there's quite a few standard proposals on uh how to handle delegated accounts. Um, seems like there's a nuance difference here, but I'm I'm uh wondering how you define it.

>> Can you um help me understand like what the other context is for delegation or delegated account? >> So, I'm looking for example at uh this EIP779. yeah re redelegation between wallets which uh like to me rings diff rings similar to associating uh two accounts. So associating seems to be kind of a container uh in this case of different uh different ways you might associate including uh delegation. Um but this is essentially what I'm trying to understand how do they fit together?

I see. Um I am 7779. Let me take a look at that real quick uh to refresh my memory. Um, I'm not familiar with this uh 7779 specification and so I can't really talk to the difference between it and um mine off the cuff here. I'd be happy to take a deeper look and uh provide comments in the Ethereum uh magicians forum or in the Telegram chat. At um a high level, it sounds like it's a way it looks like

7779 is attempting to delegate EOAS kind of as an extension to 7702. Again, I'm like reading the abstract and responding for the first time, so I could be I could be off the mark here. This this spec is meant to be uh significantly more broad in that it encapsulates all um a blockchain account not just EOAs. So it applies to smart contract wallets, EOAs and wallets that exist on other chains that are not EBM uh like Solana or Bitcoin >> and so [clears throat] yeah fundamentally that's >> standard benefit. Yeah. Okay.

Understood. Thank you. >> Cool. Um, in looking for your link, I saw that there were some questions in the uh time in the comments that I didn't see while I was talking. [clears throat] Sam, you suggested instead of using a key ID, could we use an address for a contract that implements validation logic? I I actually I um I think that that's an interesting pattern. In general, I'm not very happy with the key ID uh schema right now. For one, you pointed out in the PR that it needs to be extended with additional ERC's in the future. I don't think that that's very ergonomic. And also I think what's missing and someone recently pointed out in the uh ERC892 telegram chat recently

uh that we could include the like validator or the like storage location in the association record and then metadata like how these accounts signed could be returned by that um implementation and basically both initiator and approver would be agreeing to where to put these associations. I'm like pretty excited about that pattern and I'm like looking for comment on that in the chat right now. But I think it also would address your um it addresses the other thing that you're pointing out here that we don't have like a canonical uh contract that implements validation logic.

I was actually thinking a little bit more about this while you were talking and I think it would make a lot of sense to kind of have the uh so kind of in the style of 712 and what is it 1271 uh the um type sign messages and uh contract sign messages. Um, so if the contract had a validate associated account record function and you just passed a uh a strct with a blob of signature on it to the contract um and then it could just check it itself. Uh you'd still need a key ID to handle um like what chain the ad the the the account is on. So you need like you know

three is Bitcoin with a particular validation like uh scheme. Um one would be an Ethereum contract address. Two might be EC recover. But that would that would definitely make it a lot easier to to have a list. You wouldn't need to have a very long one. So >> yeah. Yeah. I think that also helps kind of solve the problem where like this is maybe too specific and so it have it would have to be extended in the future. um kind of precipitating in more ERC's. >> Yeah. And by by bucketing them in more generic classes kind of avoid that pitfall.

>> Um yeah, that's a good suggestion. >> Unrelated question. Um is there a difference between initiator and what was the other one? The >> approver. >> Approver. >> I um not functionally. The only reason they needed to be named and I think that generally speaking it's >> it's reasonable to expect that one would sign first and somehow through the app notify the other or that when the other connects the other the like association is waiting for them and so there is kind of an ordering. That being said, the there is nothing about the signing process that requires like them to be sequential. And so

>> so instead of initiator and approver, I would suggest something like um you put the address that sorts lexographically lower first and then uh the second one second. That way for any pair of accounts uh there's one canonical um encoding of that uh record. >> Yeah, that's funny that you bring that up. I actually had that um in the spec originally and in an early early draft before we moved to the PR and I will need to find my notes and conversation for why we decided to move away from that. But um I have the language for including lexographical sorting if if that makes sense. What

>> it might just be simple like it might be that it's directional if these are directional records. Um if they're not then yeah >> um yeah directionality is um kind of dependent on the app that's consuming it. Um but I think that if directionality needs to be encoded strictly, it should be encoded in the data field. >> Yeah, it makes sense. And um the 712 strruct signing needs ordering in order to for everyone to be able to agree on like what the what the strct is. And I think that there's I'll need to revisit lexographical

sorting, but um I I will take another look at that. Um we had it and removed it and I can't remember the justification for why we removed it. So I uh I'll need to take another look there. Cool. Thank you. Good content for rationale. >> Yeah, right. That's a good quote. Um, Victor, thanks. Good call out. You're saying that there's a typo maybe on Validat. I would not be surprised if there is.

>> Yeah, I I I I realized that it was that these two lines were too close. I was reading the one below. I think you said from which >> yeah but there there indeed has some implication when you said valid at um yeah it's all good now all >> okay cool yeah this line describes this line yeah >> oh I see you you clarified your comment and zoom has threads in their comments so fancy okay um are there any other questions uh how do you envision the crosschain

situation? >> I think that off-chain storage is almost uh a requirement at that point especially once you start looking at some of the more um the less EVM friendly curve types like Adwords uh where doing onchain validation of those signatures becomes really gas expensive. Um but with off-chain storage I think um the mechanism is some app can collect signatures from the EVM account and then maybe the Salana account and store them offchain um and but the association would be like available to that app and consumers of

that app's database. Great. Thank >> just skimming it now. So maybe it's addressed. Um but it it doesn't seem like it just my my first glance at this that there's like a defined maybe I'm wrong a parent child relationship. It seems like bilateral. So when you talk about things like association with an ENS address, what happens if it's doesn't have that hierarchical relationship and then you have conflicting addresses resolving there or is that more of a like a wallet

level implementation detail for for handling? >> Yeah, that's a really good call out, Sam. Um I think that that is actually more of like an ENS spec level and client integration spec. Um, and we could encode that hierarchal relationship into the data field like we like we just talked about. Um, but I also in the in the like idea that we have with like sub accounts, I most of the sub accounts are like spun up. They're app specific and they really only execute in like an apps context and so they almost certainly won't have ENS names. Uh but it's a good call out that like we need to establish what the relationship

between the two is in order for the um like inheritance to work in the right direction. >> Awesome. Sounds like uh everything >> right. Well, thank you guys so much for uh for your time and for paying attention to the great questions and uh suggestions. >> Thanks for the presentation. We appreciate it.

>> Uh with that, I'm going to hand it off to Victor who has uh two topics to discuss. >> Yeah, thanks. Um, I hope that I can present, but I'm not sure how reliable it is because I'm uh I'm on my way and uh so let me see if I can actually load it. If not, would it be possible for uh Sam to present this EIP so that I can just like talk through it? >> Absolutely. >> Yeah. Sam, I realize my connection is not good enough though. It doesn't load on my site.

I'm surprised my camera can still load. >> There's that. >> That's great. So, hi uh all wallet dev working group. Um appreciate the time. >> [snorts] >> Um recently I uh issu uh authored this new ERC's basically says if you have um multiple consecutive uh letters uh sorry uh digits you can um find a way to compress format it. Uh the use case would be for example uh open C contracts and unis swap contracts and um um and other contracts. They started to use uh

general multiple zeros leading zeros. Um the the benefit of mining these uh long zeros is to reduce chance of booth being the user being spoofed. Right? It's you have started we recently have started to see uh many attempt at where when users trying to interact with one legitimate contract uh the spammers fishers will try to send them transactions or simulate transactions from a illegit uh contracts and [snorts] then the user would be um will be uh uh uh will be will be misled to use the contract instead. So to prevent that if ENS,

OpenC, Unis swap and many um contract developers started to mine zeros or mine uh specific meaning uh uh digits uh so that it reduces the chance for spoofvers to to to do that. Uh one way to make it easier from a user experience uh is actually trying to uh to present it in a way that user can understand. So, can you scroll down um scroll down to the spec? Yeah, for example, there's when there's a lot of zeros, it's very hard for user to count. It's also very hard for a wallet to display because you wallet will result to um just display multiple

zeros, right? But having 18 zeros or have having 14 zeros is quite a difference. So a way of it is to um display it with a zero with like small digits on top if you if UTF is uh special characters allowed or if it's ASIC uh ASKI only then uh you can use brackets in this case making it much easier for user to understand this is um this has multiple repeated u digits. So this is the standard and just to demonstrate the use use of that I also created a hypnosis safe deployer which is uh you can visit 3Tsafe.xyz XYZ I

also share that URL and Sam can you present that one? Yes. So this is a public good open source project and then where it basically oh you you use a browser that doesn't have a web uh GPU. So um if you have if someone has a um any browsers uh Chrome works and uh I think fire that are you using Firefox? I am >> okay. Yeah. So, probably Firefox has not supported that. Uh Chrome and Safari uh all supported it. And then on Android and iPhone, I think that a lot of browsers supported that. So, basically, it uses your GPU to mine um create to um

addresses for uh GNO to save um uh deployments. And then it gives you a lot of zeros in front which can be uh mute yourself. >> Yeah, sorry, I missed mistyped. So, if you if you use if you mind it, I I I don't know if you have other browsers to see to show it. uh within a few seconds you can mine like seven zeros and then that already makes it very hard for any fisher to mine additional six to to eight digits to so

that they will be able to mislead users on a wallet. So this is the purpose to improve what it user experience and reduce fishing uh with a standard and with one um open sourced um reference implementation uh just so that I want to flat bit for the wlet working group and feedback's appreciated uh collaboration implementation is recommended um thank you >> cool thanks for uh demoing this. It's pretty pretty cool. Um yeah, I think this will probably end up

being useful. I guess my my concern would be does this incentivize, you know, going back to a proofof work world where uh we end up just wasting a whole bunch of resources mining good addresses. Um is and is that something we want to do? So I think it's much limited uh in in a scope compared to um compared to traditional proof of work chain generation uh because um the mo most modern wallets has or will display meaningful digits usually six to eight which means if someone want to spoof users with this mechanisms they can they need to have uh 8 to 10 order of

magnitude more computation than a genuine uh authenticate uh than a genu contract uh creator or wallet creator. So it just make people who are doing bad extremely expensive which reduce the chance they success like they succeed but also dis incentivize the day to do for any people who just want to u be good people. They don't care about all these other random uh digits. they can just run a few seconds of of mining which will much much reduce the uh I think the the waste and and the en environmental uh uh implication is much

much limited as long as they don't care about all other digits. >> And how does this compare to things like like um ENS reverse records and and stuff like that? Is it would that be another solution to the same problem? uh kind of right like if you if [snorts] you have ENS like that multiple layer of security is great right for example if you use ENS uh reverse resolution that's one level of security right but sometimes you're just you you you could also like for very important usage you'll still want to compare the wallet address right because you don't want to you want to make sure

what you see is what you can trust Right. If if someone hijacked there's other attack surfaces like if someone hijacked your uh your DNS, right? If someone who hijacked the the trust chains of DNS or the trust chain of the whoever you make query to get the resolution. This gives you another layer of of security. Okay, that makes sense. Cool. Does anybody else have any questions? Is this something that wallets might be interested in implementing? I guess that's an important thing uh to ask the people here.

>> Um >> I can show I might be able to demonstrate from my phone because I you can actually m and then you will see what it will look like as when people um display these wallets. Is that okay? Can I try to present from my phone? I think now it loads. >> Yeah. Okay. So, let me present from my phone. Start broadcasting. Can you see my screen?

>> Yep. >> Yeah. Okay. So, this is when uh you use you use an iPhone and then it has a web GPU ready and then you just click mine. If you didn't connect your wallet or if you didn't paste any owner owner address, it will let you mine with like demo address demo address just it doesn't let you deploy it. But then as it scroll down it will start to um to mine and then within a few seconds you can get easily six zeros. And then it what it what it does is it display in this way which make it much much easier for user to tell that uh if someone want to do this they have to do seven uh eight to 10

order of magnitude more expensive thing just to smooth you uh so that it shows up with similar ending digit four digits similar. Yeah, it's this is the way just to tell like this make extremely hard to fish people now with with with these wallet address and if you already have seven digits or if you for serious project like unis swap or openc if they already have like 10 or 11 digits like you can pretty much trust all the rest four digits if they matches they are the legitimate project.

So I would recommend wallet teams to consider this proposal and I will also look forward to your feedback. >> See we'll flip that back to wallets. Um what do you guys think? Something you could see yourselves implementing? Um, just speaking from the perception of a like a hardware wallet, it it seems like it can make user verification easier to prevent address poisoning attacks. I have to think through it more. I mean, in general, people don't

read through this anyways and um, it's certainly a lot better than having the truncated addresses with the ellipses in the middle um because the the best address poisoning attacks basically match beginning and end anyways. Um I guess uh one thing that comes to mind you mentioned like uh in increasing the cost of address poisoning attacks 7 to 8x. Um is there anything on like the the incentive modeling pertaining to cost? Like it's hard for me to judge you know what would [clears throat] adequately be a deterrent or just a little extra friction. Um and I know that's a really nebulous thing but o overall the idea sounds good. the more we can diminish the signing complexity and make it easier for users to verify these things

visually um seems positive but I'm curious maybe a little bit more about the the detail on the incentive side. >> Yeah, thank you. Great feedback. Um incentive would be like user do like ignore them a lot of times but for most highstake transactions that's when they really need it and then that's when it really matters. That's also when it exposes the highest incentives for bad people to actually spoof them. So I think these are not for everyday transactions. These were are not for like every random wallet addresses.

These were for like people who don't want to lose significant or meaningful amount of of of money as they go on make a purchase as they go on to make a make a trade or when they have like companies or serious institutions want to rely on treasuries uh and these transactions are the ones we we really want to spend resources protecting. So I think the incentive would partly come from the end user, the actual user who wants safeties and the other incentive would be like um like our ecosystem trying to advocate that it just not only make you safe but

whoever try to transact you with you also safe right like OpenC doesn't get spoofed themselves but they want to make sure anyone who transact with them has less chance of being spoofed, right? UniS swap, they don't get they don't get swapped or they they don't get address poisoned themselves. But as a service provider, they don't want any they want to reduce chances when anyone else will want to transact with them to reduce their chance being point uh poinsent and and these are sometimes people who are less taxsavvy.

Sometimes are people who are working on other industry doesn't have enough time to learn about these practices. We just want to have some intuitive way to show things that um make less chance to to one additional layer to reduce the fishing. um one one follow >> and as you can see as you can see within we as we we were talk just on my phone we already generating a a leading zeros with a very low power regular phone right and then but it just make it extremely hard for for attackers to generate one additional seven digits or six digits.

>> Um just sort of an implementation question for for wallets too. So if you have to um go through this process to generate the condensed address um using your [clears throat] GPU, >> what about verification like so for example if a user has met MetaMask and to avoid address poisoning attacks they use account labels and they would expect an account label to match would a software wallet be able to say without having to go through that that process of generating the truncated version itself but do a a cryptographic verification that like hey this matches is the address that's already in the address book, but this is the truncated version. Um, just so like how how is that maybe verified at that level or

maybe that's an open thing. >> Oh yeah, I I let me just clarify mining this these address were like only one of the implementations and then it was not the the standard itself is about display how to display these addresses. It's not about how you get those addresses just to clarify that. and then once it's it's mined or once it's generated it would be used. So I think it's up for the wallet creator or contract creators um to decide how they will get those addresses right on the and then when it comes to verification machine verification is easier as you as you mentioned if you already have in your uh address book you

want to make sure your address has never been temp your address book has never been tempered with and then you can compare it right and then if you already have ENS resolve set up and then You want to make sure that your ENS is the the data storage is safe like you didn't get the attack surface would be like you have not your wallet have not been compromised to sign transactions that change these pointers and also your DNS record has not your DNS server has not been been uh compromised to give you the wrong answer and verification but in this particular A11 7 is all about

displaying. You can think of it as a different kind of ERC 55 checks on display is about displaying it for easier human reading. >> Makes sense. Thank you. >> Yeah, thank you for the feedback. >> Yeah, back to Sam. >> Cool. If we um don't have any other questions on this one, um I will hand it off to Chris who has a proposal to talk about. I think it was Chris.

Yeah, I assume I'm the only Chris on the call, so I just wanted to double check there. Um yeah, so yeah, I work at base uh mainly on account abstraction work with Steve as well. Um so yeah I just wanted to share a new EIP proposal for uh new account abstraction uh proposal. I'll share uh this GitHub here and I'll share my screen kind of talk through uh it's still you know early something we're kind of uh exploring but uh early feedback is good.

Uh so yeah basically at at a high level uh what this proposal is um is basically trying to remove the uh kind of uglier parts of uh you know native account of traction based off of 437. So that's uh 7560 and 7701. 7560 is the um our rollup standard that's equivalent to 7701. Uh and it's basically just native 437 if you're not that familiar with it. Um and yeah, please interrupt me anytime if anything you need more have questions or whatever. But uh yeah, so this this proposal uh tries to get rid of that and basically just um has some onchain

account configurations that the wallet can control to basically rotate uh keys, add keys for validation and it adds a new transaction type to you know uh enable those configurations to actually be used. um to go through like yeah motivation for this uh we're really looking at trying to you know optimize uh base in terms of scaling um and that comes down to like both you know operating safe me pools uh denial of service prevention um and then also like the kind of uh yeah the kind reputation systems of like 7562 which is layered on top of 437 like protocols uh in order to have denial of

service prevention trying to get rid of all that and like yeah basically make uh a s a account abstraction system that's highly optimizable uh and having these kind of static state checks uh where the node basically you know for a standard transaction obviously just checks like you know does the sender is this signature valid does is the nons valid does the sign uh does the uh sender have a balance and like you know that that's a a valid transaction. This tries to replicate that simplicity by basically just saying like I'll scroll down to like this new transaction type uh shape that might help a bit. Um and I'll share this of course in Discord for a little closer inspection from

anyone. But uh basically yeah we're trying to get it so uh the chain can basically just look uh you know does the uh payer uh have a balance? Is the payer signature valid? Is the sender signature valid? Is the nons correct? Um, and it'll be able to just uh basically keep the the uh configuration system which is will be a a pre-ompile uh and it'll just have a bunch of uh configurations for each wallet.

basically just keeping it simple in it's uh you know I accept these keys to sign for this account um at a high level and therefore we can you know if we keep that uh state warm in in the node we can just do again simple state checks and upcoming proposals like uh block access lists and flashblock access lists for base uh basically allow us to like clear out invalid transactions in the memp pool extremely quickly uh because we have you know some small set set of uh slots we care about the data in and if they get updated then we can just invalidate the transaction instantly. Um so yeah that's kind of like the high

level you know what's going on. I think there's you know there's more details obviously in here. I think the kind of uh there's kind of like two uh you know more complex pieces. one is just like the account uh the configuration pre-ompile which is I think uh I'm pretty happy with like the the design of that of course happy to hear any feedback otherwise um and the other piece is like how to do uh native uh token payments um which starts to introduce more complexity so like outright sponsorship for transactions is uh relatively straightforward like you know we could just have a another account sign for a transaction and and

debit its ETH balance for uh that transaction. Um there's a world, you know, a world where uh users just want to have a stable coin like that's their wallet and you know they don't want to have to think about ETH. So we need to kind of enable uh some way for them to transact. Um but of course ETH has to be you know is the end um token that needs to be uh used to pay for gas. So the mechanism here uh at least on base and you know of course uh Ethereum L1 and other chains uh a lot there's no like although there's ERC20 there's no standardized um like implementation under the hood so there's

like uh balance slots are like in different places and whatnot um and coming back to the principle of like we want this to be highly optimizable Basically, we we need to know, you know, what slots our balance because if we want to do a native uh token transfer for gas payment, again, a payer would pay some balance but receive some ERC20, then we need to have an additional like uh token configuration system where there's there's kind of two options here. It's either like tokens conform to a new uh ERC, you know, 20 implementation standard and they would have to migrate to, which sounds kind of too ugly or too painful, not too ugly

that it would be ideal, but um the configuration system actually just allows kind of any token to just say, hey, these are the the slots that would make this work. Uh I'll just kind of scroll down. I don't know where exactly that definition is. just scrolling around. Um, but yeah, that's that's it at a high level like please read through uh when when you have some time and and we can chat in the discord. But yeah, uh any early kind of thinkings or questions?

>> Oh, I wasn't sharing my screen for that. Eh, >> yeah, you were. Sorry. Oh, I was okay token. Uh yeah, in terms of I'll just add like in terms of uh you know where this is at. Yeah, still early days. still kind of examining like if we could um you know like I guess like yeah I mean feedback like on the whole EIP would be great and then like in in general um I guess like the trade-offs just to be

like I'll just I'll just add a little more uh nuance to like the proposal so you understand a bit more uh of why we're doing this like the trade-off is really like you know 437701 it's it's like arbitrary code execution can define validation of the transaction and that's what we're giving up here to try to be able to optimize uh and and you know run uh better mem pools or safer me pools and ultimately that like that uh arbitrary validation code um the wallets we've seen you know everyone just uses a key uh anyway so it's like at least for this path uh this seems to be like you know a fair tradeoff that we

just have some set of key types that we accept uh and that you know accounts can use this new approach which will be a lot less gas and more optimizable. Um and then there's also like any sort of you know custom logic is still possible. Uh the call goes to the wallet address anyway. So you could add any additional um validation you want and the the pre-ompile is accessible within the EVM EVM to be so you can update it. You could have like you know social recovery mechanisms that don't conform to these key types that are on chain. You just need to like you know call your call the wallet address and then it can perform any kind of uh recovery against the

onchain pre uh pre-ompile as well. Um yeah, I understand like you know it was a lot to just kind of drop at the end here. So uh probably best if we uh just continue conversation in like a thread. So I'll post but uh yeah uh if there's any questions happy to go over anything now. >> Yeah, I I see a question. >> Oh yeah. Hi. Hi Chris. I think this is a very interesting uh proposal. I I love the directions. It's I can see a lot of different uh use cases like especially like accepting R1 it's going to massively reduce the uh frictions of usage. My question about delegates

uh is that if we let's say have delegation how how do you envision the uh attack surface of DOS uh or um or how do do you think we need any like mitigations in those right if someone tried to send delegated uh transactions but um make it costy to validate them. Um and then how how efficient would the uh client knows to uh to be able to validate them without causing a lot of computation and memory read.

>> So yeah, so uh delegate I think yeah is uh you know the most interesting transaction uh sorry uh key type here. Uh basically what it's trying to enable is um so you could have you know sub accounts that all point to one parent account saying like basically I could have uh you know my primary account it controls all of my sub accounts. If I do a key rotation on my primary then all of the sub accounts are referencing that primary account. So it's only like one hop and it's more of like I delegate my uh key types to that account. So it's really only like one it's just a one misdirection of like whatever that key

so whatever that count account account defines its key types works for me and it allows so like if I had 20 sub accounts because we're also trying to work on this sub account model uh more where it's like you know if I had many sub accounts I don't want to have to do a a key rotation for all of them I can have one parent account um in terms of like denial of service yeah like the one Uh so yeah like all everything done here is trying to not hit any sort of arbitrary code. So that means we never go into the EVM to like do a token transfer or do validation against a wallet. So it's not that type of delegation. It is like uh basically one additional hop on the slot but the main

consideration is like yeah we do want to avoid some sort of mass invalidation. Um so there there would probably be some sort of mempool limit of like um you know I don't it doesn't it doesn't it can be large like you know large enough that it's not uh painful to any kind of average use case or or like even just yeah if if you could have another question Sarah >> so so just to clarify the these were like limited to one hop right like let's say address A delegate to address B and address B happened to >> be delegating to address C. When we try to validate the the transaction signature using the delegate key type, it would only be validating against

>> the but non but non uh contagious, right? Non propagation to the next delegate >> in in that in the delegated the account that it was delegated to. So only one hop per delegate. >> Yeah, >> makes sense. Yeah, that I think that significantly reduces the attack surface for DOS. Thank you. >> Great. Thanks for sharing. I think um we have three minutes left, so let's call it here. Um final reminder, we're on on demand. If you want to have a meeting, let me know and we'll make an agenda. Um thanks again for everybody for sharing your your work and um talk to you all on

the Discord server. Take care. >> Thanks [snorts] all. Thank you.