AllWalletDevs #33

Transcript

Uh welcome to meeting number 33. Um we have three items on the agenda today. We have uh an introduction to trillion dollar security. Um a kind of a retrospective discussion on 7702 and then a discussion on calculation and standardizing uh base fees. Um so with that I'm going to turn it over to Frederick and uh we can talk about trillion dollar security. Yeah, thanks a lot. Um so just to give some information about what we're about or what I'm about to speak about. So the trillion dollar security initiative is uh this idea that we have things within

the Ethereum ecosystem that are that has room for improvements with regards to security. Um it can be anything really. It could be things related to the protocol. It can be uh wallet UX. It could be censoring uh RPC endpoints. Uh it could be concerns about privacy or um you know the fact that a lot of people are falling victims to um various attacks and uh etc.

this um this is an so so what we're trying to do is kind of collect information from the ecosystem about what areas they feel need some type of improvement. Um and when we have this uh information, the idea is that we will compile a report and then start working on executing uh these necessary changes in order to kind of improve the overall security of the Ethereum ecosystem.

Um I guess for this call um we don't have to dive deep into the uh like specific security concerns or thoughts that people have. If you do have any, I'm more than happy to speak about them on this call. But otherwise it would be uh interesting to get your feedback in some way or another uh on how we can improve the overall security of Ethereum you know so we can hopefully onboard billions of uh of users and we have a few ways of doing that. Um we have a form on our website on the blog blog.org

org or you can also schedule a short call with me and we can discuss it oneonone uh if you would be open to that. [Music] Um, I'll post the links here in the chat if anyone do have any comments and want to discuss any or give any feedback or such at this point in this in this call. I think it would be very interesting to hear your views. Uh, so feel free to provide feedback.

Sure. So I kind of have a question. So um what are the roles of like the EF going to be versus what you expect from say wallet developers or other ecosystem members? Yeah. Okay. Yeah. So the EF is uh in my view the EF is acting as a coordinator here. Uh we're collecting the feedback from various parts of the ecosystem. Um I've talked to or we have talked to a lot of different entities such as you know end users uh projects um developers security people um various financial institutions uh staking operations uh VCs etc etc just to get this kind of overview of what what

people are seeing as sort of the weak weak points that we need to improve on. Um once we have done that like I said we are compiling this report of of this feedback and these findings and my view is then that you know the EF continues to act as this kind of coordinator um to kind of provide feedback. Um know from a wallet point of view we've heard we like some some of these comments that we heard is that it's hard for a nontechnical user

to understand what they're signing. Um and maybe you know part like an action point from this could be to discuss with uh a lot of the wallet developers around like how can we improve this? Should there be you know some type of standard around how wallets should ensure the security of the users or minimize the risks of the users etc. Um I think that's that's the next kind of step to to figure this out. So it's not the idea in my opinion.

It's not that the EF should be doing everything. It's more like trying to help facilitate and provide um necessary resources that might be missing. Uh for example, might be relevant with some grants or other aspects to to help uh improve this this security. Great. Thank you. And um I guess what you're looking for from wallet developers is to to come on and fill out the form uh that you were talking about and schedule some time with you. Yeah.

Yeah. Exactly. Yeah. So um it would be super interesting to hear the uh the insights of the wallet developers uh what what you perceive as the uh the major security concerns uh that the Ethereum ecosystem is facing. Um, you know, if you have any thoughts on how that can be improved, that's great. But otherwise, you know, feel free to just uh let us know about the issues themselves and then we can work together to try to find uh potential solutions to these problems. Awesome. Thanks so much. Um,

does anybody else have any questions or comments? All right. Uh, so I guess that means we can move on to our next topic, which is um talking about 7702 and how it's been going so far. Um, how has it been going? Um, I know some of you um are from clients, some of you are from wallets. Um, yeah, if anybody has any insights, things to talk about, please do. It kind of sounds like no one has any

opinions apparently. So, um I kind of suggested it because I was interested in um uh sort of client def um there's some limitations that was done in the memory pool. Um, and actually I was kind of interested in uh in how different wallet implementations was handling this or if they experienced any issues, but uh if no one has any opinions, I guess it's not much of an issue. Sounds like this might be a question to

post in the Discord and collect some responses async. Yeah. All right. Go ahead, Nicholas. Hey, I don't have like a direct feedback because I don't run a wallet, but I would have a question for MetaMask. Um, I think 7702 is still like behind the developer uh site and like not directly rolled out to like the entire user base. Um, do you have any rough estimation or plans to

share about like when would you roll this out to um the greater user base? Uh, this one this one is directly for you, I guess, because I guess you're the only Metam mask people person here. Jo's here as well. Uh, I don't know. Oh, okay. Yeah. Let's see if he he's he's the more technical one, but um Okay. What's up? Okay. I can I can answer.

Sorry, Nicholas. You were asking about when are we rolling it out to all our users? Is that it? Yeah. What is like the plan? I I think it's still behind the um developer settings. So support for 72 should have should be rolled out for everyone. Um okay. The the only thing is the first version that we've rolled out like there was no way for a user to upgrade from within the wallet. So we're leveraging 5792 uh to perform like an upgrade just in time. So when uh uh ADAP you know wants to submit

a batch transaction that's when the user will need to upgrade. So at that moment we prompted the user and say you know to proceed please uh you know confirm that you are willing to upgrade your EOA to a smart contract account. Uh with I think the latest version that we've uh that we are rolling out it's it's already possible to upgrade from within the wallet like you can just go to your account details and uh upgrade from there and upgrade or downgrade either way.

All right, I'm I'm checking right now. Okay, thanks. Uh yeah, that's exactly what I was uh asking for. It's like the force upgrade uh button within the wallet. Yeah, that is ruling out on the current release. Oh, okay. Okay. So Vand in the chat asked is the question about whether we would do a mass migration. No, no, no. Like I I mean you can't force people to uh Yeah. Okay. Yeah.

Cool. It's Yeah. Go ahead. But so then it's triggered currently on the only if the DAP request. Uh so like are you expecting most people to like use that to trigger this for the first time or like will you push this button to be the main uh distribution arm of 77 kind of like what what do you expect? So that that's that's hard to say like uh ideally you know we would like there would be no reason to push a user to upgrade EUA unless there's a

reason that will benefit the user at that moment right and once that moment comes that's probably when we'll prompt him and say you know to proceed and from here onwards to get you know you are going through this flow so probably you'll benefit from a improved UX then you know please do upgrade Now the first use case was batch transactions via D apps but uh as we've rolled out more and more features on top we'll probably prompt the user you know more and more times until it gets to a point where we just say you know it's better if you upgrade to get an overall improved experience it's better to just upgrade straight away.

Um but yeah okay sounds fair. Great. Thank you. Cool. So, we're joined with uh by light client or Matt um who probably has a little bit more of an update on how 7702 is doing on mainet. So, if you want to give us a little bit of an update, that'd be very appreciated. Hello. Yeah, I mean, honestly, I think that most of the wallets probably have a good idea of how it's working out for them. I can really only see right now what Dune is able to tell me. And unfortunately, because Dune doesn't have a way for us to know what

the address is that authorized an account, we really only kind of know who or which wallet uh delegation contracts are getting um delegated to right now. So, I would like to have a better idea of what the total value locked is. I know that there's like some metric for total value of ETH locked. I want to say it was a couple million dollar of ETH, but that doesn't really tell you what the total value of the ERC20s are. It doesn't really tell you how many transactions these delegated accounts are using yet. So, we're missing a lot of like the most important metrics. But overall, it seems that 772 adoption is coming up. I saw MetaMask kind of overtook OKX as the top delegated

contract a couple days ago and I think that yeah total we're a bit over 40,000 authorizations in two weeks. So I think overall things are are pretty good especially considering that wallets are continuing to roll this out. Um, but yeah, if anyone has those metrics, I would be curious what the TVL or I guess asset owner management of the contracts is so far. Do you know roughly what percentage of like new transactions are uh to 7702 accounts?

Yeah, that's the thing. It's not really possible to determine this right now via um Dune because if you you can't just you look at the number 7702 transactions because that's only the beginning of the 7702 story. You need to know which account signed the authorization. And because they don't have that recovered address in their database table, we can't then go look up to see how often that account is transacting after they make the authorization. You can't count calls into the delegate target. I don't know how Dune works. Yeah, Dune unfortunately in the trace doesn't have a way to know. It doesn't expose that

the 7702 proxy has really occurred. I don't know. I also try I tried to like look into doing something like looking through every call and then pulling up the code related to that call and seeing if there's a prefix of EF related to it and I ran into an issue but I'm forgetting what the issue was now but I could try and look into it again. Yeah, if anyone has a connection at Dune that we could talk to that would be great. I feel like this is a pretty easy thing for them to do and I assume they're kind of aware of it, but it would be very helpful to get this sorted out in the next couple weeks. And I've talked to Kofi a little

bit and he's planning to have these stats in his in his website Bundlebear, but as of now it doesn't look like he has rolled any of that information out. Cool. Well, thanks for the update, Matt. We appreciate it. And I guess on that note, um, is Smart Programmer 93 here by any chance?

because I know you wanted to talk about standardizing base fee um calculations. Hey. Yes. Um so we've been looking into how uh wallets calculate base fees and uh also suggest priority fees for transactions for different chains. And we've been noticing that there is a lot of discrepancy between one wallet and another and how they implement this. Um some of them actually use the RPC calls that they're supposed to use uh for example or like they they they

directly call the RPC endpoint um that uh for for ETH v uh ET get V and uh the even for the suggested fee and the other one if I don't remember the exact name let me try to to get a um um Yeah. So max.

Yeah. Yeah. Um so there is the E uh gas price there is EV3 and there is also uh E uh my priority gas right right [Applause] u uh supposedly should be such like like for transactions Now the reason I'm asking about this is is and talking about this is that because there are more mobile L2 calculating

the basic for these sometimes uh different uh depending on what uses it's using it's using so because it's not just about uh congestion more and more it's more related to um objecting that the cost of hosting the blog uh of verification proofs of the uh blockchain etc all all of this counts in as part of coast now now most of

networks they do have that they they they they sometimes tends to subsidize these these costs and that's fine fine but but um at at one point when we're trying work on L2 L2 transaction fees we found ourselves in a need to tell wallet what what the priority should potentially be um the base Right.

Um probably more will be needed for uh precisions uh in the future. Um but should should uh basically cover uh partially some L1ation cost. uh it's it's still a little bit tough tough and and some of the wallets actually internal API public uh they have like some some and and those APIs do some unknown calculation on how to get different fees. Um so so we we notice for example that uh in metam mask met mask will call an

internal AI. Um uh that that turns state data um rainbow actually calls an internal AI also but then this internal AP we notice that in Rainbow uh this internal API then calls the RPC to get the data from it. Um, so if your RPC is a local machine, it won't work. But if it's a public IP address, it will work because it's uh it is accessible by the by the like internal uh API service that Rainbow is calling. Um, for Rabi that's not the case. Rabby directly for example calls

the RPC endpoint and and gets the data from it. So my sorry for the long explanation but uh my my idea here is that I want to discuss why is there no like standard for for how this is done and how can we make it become a standard um and how we can uh reach uh a a a good implementation for Yes. So, I think this is definitely an

important issue to raise. Um, I'm not sure if we're going to get much like synchronous feedback today. Um, if somebody wants to talk, feel free to interrupt me, but it might be better to post like a summary in the Discord channel and um, we can maybe start an async discussion about it. Um, that tends to get a little bit more response. Sure, we'll do that. Thank you. Cool. Does anybody have anything else uh, they want to talk about today?

Otherwise, we can wrap it up. Great. Well, we'll see you all uh next month.