AllWalletDevs #25

AllWalletDevs · 19 Feb 2025 · 19:46

Call 25 of AllWalletDevs, held on 19 February 2025. Wallet developers meet to coordinate on the Ethereum standards and protocol changes that affect their products.

Topics

From AllWalletDevs, hosted by ECH Institute.

Transcript

hey everyone welcome to this month's edition of all wallet devs um today we have three topics on the agenda um we're going to be talking about EP 5792 and it's uh companion EIP for flow control um but we're going to start off with a little demo of our updates on wallet test framework um if you're not familiar with wallet test framework it is a a suite of tests that can be adapted to work with any wallet um and it checks things like you know sending transactions fetching logs um basically end to-end UI testing and backend testing for wallets um our goals for for the past year have been to Port it to work on

mobile wallets uh using wallet connect um and I'm happy to report that we have our first um wallet that actually runs on mobile so uh here's a little video of our recording um so I'll just play this and kind of walk you through it so um it is a little slow this is kind of our first stab at um automating this this metamask by the way um yes so the way this works the wallet test framework has a um dap uh that connects through wallet connect to metamask and uh then it uses uh appium uh so standard app automation framework

to interact with the the wallet on the phone um there we go uh so this is the the DAP view um and you can see we're using appium here to connect to the various pieces click on things and then we can jump ahead here to um one the actual test is taking place so right now we have wallet test framework stap connecting to metamask um in the back end um apium or or the test itself is is currently looking at the page to determine whether we need to input the password or or what window is popping up um so that takes about 30

seconds to to happen uh we'll just skip ahead a little bit [Music] here get to the interesting part um yeah so now after we make the connection uh it switches back to the um tests page um and then starts running the tests let's see if I can go and find yeah okay so here's wallet test framework adding the test chain so in the back end we use uh currently ganache um running in the browser and then it's proxy through our backend server to the

wallet um so you actually get like n end testing with a a chain running in the background where we can like control Mining and blocks and all of that fun stuff um and if we jump ahead yeah so this is the test activating the chain and then we can jump ahead a little bit more and we can get to here we go so this is what the test results look like as it's running um this is using mocha um so nothing too fancy here um and we use VM in the back

end to to interact with the test chain and the wallet um and then if we speed up a little bit more here yeah so and then here we can see um walls framework actually making and confirming a transaction on chain yeah I really should have edited this video down a little bit I forget how long it is okay there we go um so that's that that's wallet test framework here's a demo of it working on mobile um that's about it for this part of the uh the call

um yeah so we're going to continue working on this um our next goal is to automate some 4337 wallets uh we're looking at Pillar ambir and a few other ones um to see which one would be the easiest for us to start with um and then we'll have a proof of concept of it working for uh pretty much like browser extensions mobile wallets and uh 4337 smart contract wallets and uh yes and that'll cover you know 98% of the market space uh or the the wallet space um yeah so I guess uh unless anybody has any questions about we can move on to talking about uh 5792

cool U I had a question just about the the test run does the is um does it generate a new account or does it just use like a pre-existing account that's already has some test stuff in there I missed the part where oh sure so um when the wallet starts up for the first time uh the tests will input a seed phrase um and the tests then fund that the first account from that seed phrase with uh fake ether super cool yeah it's um it's really just end to-end testing we noticed that not a lot

of wallets have full UI testing so so we're building it and we're building it for everybody so yeah cool yeah remember um I was speaking to somebody at metamask I apologize for forgetting the name at the moment but about internal UI testing um and it'd be neat to catch up with them at some point and uh see where we're at with that um yeah yeah I can I can just add on that we we have some testing um it I think we might have like a somewhat similar stack I guess um I'm also curious how um how you handle like other like UI differences

right so like with metamask we can like kind of hardcode it to our UI but I'm curious how if you're having to like remap that for every wallet yeah so we try to avoid the uh M * n problem that you get by uh like hardcoding each wallet uh so we we Define um like an API uh we call it the glue interface um and it has things like approve reject um it has events for notifying when um dialogues pop up in the wallet um and that's all defined in in like a typescript interface and then uh for each wallet we build um basically just like a regular like

note executable that uh translates between our API and the particular wallet's UI so we do have to build custom code for each wallet but we don't have to rewrite the tests for each wallet um and that's kind of the acceleration that we're going for it's just a very small piece of code that we need to rewrite and then everything else is the same I see so there's like a a kind of adapter that that each wallet creates and yeah Maps it to their particular uh interface yeah that's great okay cool cool um so unless there's anything else on that we can move on to 5792

um let me just share my screen again all right so um if you've been following along with EIP 5792 um you're probably well aware of all of this but if you haven't been uh 5792 is an API uh for wallets um it defines a couple end points uh for sending batches of transactions um so this is going to become increasingly relevant as uh EIP 7702 gets deployed on chain in the Prague hard Fork um and we're trying to push this API as like the standard way for daps to take advantage of

7702 uh so the way this works works is it defines two um actually I just view the file here yeah so it defines two uh endpoints while it send calls and actually three um and all get capabilities are the main ones so send calls lets you define um a bundle of calls um each call is basically like equivalent to an eth call um so you have a two value data um and all of them are committed together in a

a batch uh so this lets you you know do approve and swaps in one step this lets you do like a lot of complicated UI flows that would require multiple signatures it lets you do it in a single um RPC call which is uh definitely a UI Improvement um but where this proposal really shines uh is it has this capabilities uh extension Point um where future eips can Define um new capabilities for uh the calls so for example uh 4337 is defining a paym service I'm not super familiar with that particular capability so I'm not going to talk about it um but uh the one that I will talk about is the

flow control capability so uh by default um wallet send calls requires sending an atomic batch um so all of the calls either must appear on chain or none of the calls appear on chain um if you're familiar with how eoa wallets work they can't make that guarantee uh so I've ined this this new EIP called flow control um and this allows for um more fine grained um customization of the atom a city guarantees and uh what happens when you get a failed call so uh like in 57 92 you make a call you send uh some data to a contract and then that call May succeed or it may fail um flow

control let you decide what happens on a failure um the two together um so flow control plus 5792 um can actually implement this as well so um we'll have a uniform API for sending batches uh that works for smart contract wallets 7702 and traditional EAS um and I just wanted to present that here um get it on every body's road map or or at least um get people thinking about it um since 7702 is landing really soon uh so we have a question here I think pay masters there is Fu colb type example yes so that was an example but there is a um capability as well uh let

me just go and find it yeah the the pay Master one is 7677 okay yeah there we go um so there are people working on standardizing it um yeah so that's that's pretty much it um go tell your wallet developers about um 57.92 um and flow control and uh yeah come come to this Discord or the telegram chat for this if you have any problems with it or if you have any input um that's pretty much all I have to talk about for for this month um so turn the floor over to anybody else who wants to talk um can I ask a question about 5792 and the in the flow

control yeah of course uh piece um so I shared yeah the latest with with our team at metamask I'm not an engineer by the way so maybe speaking kind of uninformed to some extent but uh the group was curious or I think our the pattern we were expecting was having to call or having daps have to call get capabilities first before they um use send calls is is that the expected pattern uh that would that would be involved with also with flow

control um so the way flow control is written um if you actually the way 5792 is written overall um is that if you request a capability ility that isn't supported the wallet has to reject it um so it is safe to just skip the gate get capabilities call um but we do think most daps will start with the get capabilities and then tailor their batches to the wallet support and the the reject scenario you mentioned uh our team was I think asking to see if there was like a standard way to handle that or if there was an error that's standardized uh yeah so think that is one of the

um yeah so um we are talking about that and we're going to get error codes in here for all of the failure cases they're just not in here yet ah great okay so those are just coming and and yeah great yeah our our team sort of deep in implementation so definitely curious uh where all of this is is landing but that would be great to to get in so we can follow yeah the standard if um you guys already have error codes that you're returning like feel free to open up or request I don't think we've really decided on anything firm for them yet so if you if you guys have just add it to the proposal okay sounds great thank

you um oh sorry I don't really know the the format of this can I just like ask questions oh it's just free just chat like yeah there's like eight of us so whatever um yeah same I'm wondering given the um uh given the the kind of uh gu for people that aren't keeping up the telegram there's kind of some disagreement about this like atomicity requirement um I'm kind of wondering if the best way to uh resolve is to bring flow control into 5792 I think this is kind of what you wanted originally too uh but just wanted to like float that idea and see what you think about it

today um I don't feel strongly about it either way um if it makes it easier for people to swallow it then put them together by all means okay yeah I'm uh I'm chatting with some some people uh in the background let me let me kind of circle back to you and uh that might be the the best way to just get people on the same page about this sure that makes sense yeah that's what I mean uh Bumble fudge also make it a a mandatory part of the standard kind of thing yeah and I I

think what what is maybe missing or it might already be part of flow control is like uh similar to how um with atomic batch there was like a way to express um that your that you can do um Atomic batching I feel like that's still uh that's still necessary because I've talked to some app developers who like would only uh do send calls if um if the wallet can do atomic batching yeah that makes sense so you can tell in get cap abilities um where is it here yeah so you list your um supported

types of atomicity in the get capabilities response okay gotcha um yeah that's what I would to bum fudge but you know we're we're a year into this so yeah it's been a while we've been we've been working on this for a long time yeah I think we're close though I I feel like this atomicity thing is kind of the last big hurdle and then there's just some like polish around you know like error codes and stuff I'm I'm really excited to see this

like we need for seven 72 on Prague like otherwise it's just going to be a mess of daps trying to use it like willy-nilly yeah right does prg have a schedule like date yet I should know this but I don't I also do not know if the top of my head sometime in 2024

yeah um yeah I guess we'll figur that out at some point um cool so we can probably sort out the error codes and stuff asynchronously um shoot me a message vanan if anybody wants an invite to the or or or Lucas to the 5792 telegram chat um yeah other than that I think that's it for today cool yeah thanks Sam and uh van and please uh reach out to me on I just pm' you my my telegram uh we've been wanting to to chat to to met mask for a while um really excited to hear that you guys are interested in this sure thing yeah absolutely I'll get I'll get the rest of

the group uh yeah pulled in it would be great to collaborate on it awesome for sure drop see you guys around thanks Sam thanks for coming take care everyone thanks