AllWalletDevs #19

Transcript

hey everyone um as per usual let's give a few minutes for people to trickle in um but uh on the agenda today we have the uh Wallet account experiments team that's going to be giving a presentation um is this the right Jake or is that a different Jake that's me awesome so yeah we'll get started on that in a bit um in the meantime I guess I'll give a quick update on wall test framework since that's uh at least something I can talk about um so we have almost finished our grant we run out in about uh two weeks actually um and then we're still looking

for funding for our next year um hopefully we'll get some uh and for next year's road map we're going to be working on 4337 uh wallet support wallet connect support and a few other little interesting projects um the past couple of weeks we've been working on reporting so uh generating automated reports of uh how wallets are performing so we don't have to do those manually and that's coming along nicely um that's about it for updates on wallet test framework for now unless Nikki is here and has anything else to add but um if not I guess let's hand it over to Jake and let's uh learn about some uh wallet experiments cool thanks Sam uh my

presentation is going to be short today but I will go over a little bit of what we have been working on uh lately uh mainly on ZK email account recovery so let me do nope okay can everyone see my screen okay yep yeah looks decent yep cool yeah so I'm Jake CT I am the uh Project Lead for the Wallet account experiments team uh we work uh as part of privacy and scaling explorations to help uh mainly promote the scalability of the ethereum

ecosystem and so we do that through kind of uh prototyping and working on things on top of account experiments you may know a previous project we worked on called BLS wallet which was much more focused on the um kind of compression side of transactions for rollups so um without further Ado kind of jump into two things we're currently um actively working on um ZK email based account recovery and then also um user op compression for rups um which has changed significantly with the denune upgrade cool so what is ZK email recovery and essentially it's the idea that we could take an email which from

someone's provider like Gmail Outlook something like that and we could use that email to actually um authenticate and authorize someone to recover an account and so I've thrown together a pretty high level diagram of how this actually would work um and how we're currently um working on building this out with the uh ZK email team which is a another team at psse um so basically you have some email provider who is you know sending this email that could be Gmail it could be Outlook it could be your own you know email you're hosted and one of the cool things about all these emails is they are all asymmetrically signed by by um generally isometrically signed by a dkim

signature and that key is stored somewhere in DNS and so we essentially have this signed message payload where we can say something like recover some account to say some new owner um we know who it's from and we know it's signed um so we take that along with a um salt which helps you obfuscate um the email address on chain because you do need to store that we don't want anyone to see that and you can basically do of two things you can either um have a centralized service that you get these emails at that is generating the actual proof over the email using the ZK email um kind of circuits in Tech and then

submits on chain but this relayer uh is a censorable point because it could reject certain emails and it can also because you're sending it that um obious skting salt it can see everyone's email address so essentially you have to trust that this relayer um is you're okay with it knowing that piece of like personally identifiable information when you're processing this recovery the other way you can do this is you can take that email with those signatures and you can just generate that proof natively so you could do that inside of a browser or some other app um this tends to be a larger proof and so it tends I think locally um one of the other email verification circuits took about I want to say 10 or 20 minutes locally to

generate that proof and so um it just takes a long time but the nice thing with this is you can do your a user can do all this locally on their own machine um without having to rely on some third party service and then just submit themselves either way you're essentially taking this email that is requesting that you change the owner of an account or rotate the keys and from that we get this nice proof that hides the contents of the email but still lets us prove certain attributes about it um just a quick check does this all roughly make sense so in the local proof generation thing you'd send an email to yourself and then get that email and put it into your browser and it would generate a proof based on that or yes I have not actually

seen um I don't remember the exact UK case I think ZK P2P is one of the other projects using this they're using it as an on-ramp through venmo um I believe they have a local option they're working on it I have not seen that but yes um you would send yourself an email one thing I will note is at least in Gmail if you do a loop back email send it generally does not sign the email it's a very like barebones um email template with no deim signatures so you probably would still need to send the email somewhere else in order to get it properly signed by Google okay that makes sense and and obviously this has the the problem that your keys are technically owned by your

email provider right yes so um we can we can get a little bit more into that but yeah basically the um you have to assume that the uh yeah the provider obviously you're trusting them as being a good email custodian you also are going to be trusting um I will get into the DNS stuff in a second um you what was the other thing I was thinking yep that they the email and they sign correctly uh and then also that the account is not compromised so there could be cases where um you may temporarily lose access to say Gmail account because you got hit in the fishing attack and so we can use things like in the next section I say like a time lock to basically set up um a

window in which like we will do this rotation so if you were able to say get your Gmail account back from the person who fished you um within like a day if your time locks up to two days you could always cancel them uh like attempting to take your account cool anything else before I move on all right so then what actually happens um on chain which is this is the part we are still um actively working on with a ZK email team is you essentially have that email proof as your payload to a recovery you know transaction or user operation and so you're going to go to

your account usually the 437 I account um or some module that's attached to that account that is authorized to do recovery and it essentially can go out to this email off contract um there's also an account recovery specific one that has specific um functions you to call in it and it is linked into a um onchain de registry what this basically is is every email provider has one or more generally dkim keys they publish to DNS and they are uh kind of separated by these selectors and so you essentially have to have some Oracle process or offchain entity that's pushing these DNS updates into some dkim registry contract and so

that is another point of potential um kind of uh centralization risk or um like places where things can go wrong so for example you could imagine that someone pushed a malicious say dkim update to try and pass some email process they're going through or maybe there was just something that went wrong so um this registry um I think right now is mainly only being run by the ZK email team but in theory anyone could run any registry they want so even if you don't necessarily um trust the DNS updates that someone else is doing in the registry you could always run your own or have ways of like for example having a perus user override that allows them to override what key they want to use

for verification um but that still is a place where we're taking that offchain DNS data and we have to push it somewhere for this proof verification um anyways so then that recovery process will go through and then eventually goes to the ZK email verifier contract which is generated off those circuits and this is actually what's going to go through and check that for that DM dkim key that the um the email was signed properly from that uh from the provider um it's going to check the subject to make sure it matches hey yes we're trying to do this recovery op operation on this account to this new owner and then you might also check um that the from is going to match the Salted onchain value that we have and then also some things

around Tim stamp as in because you may not want to say let a very old email proof trigger account recovery um so yeah that's kind of the the flow we're looking into and um building out right now any questions on this so I think that looks really cool um what's like the main use case for this like who's who's looking to authorize ethereum transactions with their email yeah so I would I would say that um this is not authorizing any general ethereum transaction um there are going to be issues especially with

4337 um with um having stateful access during that validation phase and so um from what another I think it was Cil on the ZK email team looked into doing that and uh there were just some complications at at least at that time in terms of what 437 would and would not allow during that validation um in terms of like the actual like product use case for this I think the most common one we've seen is people who want to set up guardians or people to help them recover or rotate keys that don't have ethereum Accounts at all so you could imagine that if you have a family member or someone else you trust um they would be able to help you potentially recover your account without having any sort of

uh crypto account set up and that would be the case where like they would either um go through a relayer that say like that wallet was providing that would help um actually get that on chain or you can imagine situations where this user Op with the email recovery maybe has like a pay Master associated with it and if someone's calling recovery for this specific you know Waller account um you could use a pay Master to subsidize the actual sending of that so the end user who's sending the email has no idea any of this is happening in the background that's really interesting okay cool cool um yeah so that's kind of um

on that so we are um currently building this out um with the ZK email team I believe um Soul wallet already has a implementation of this using some other um circuits they wrote and then um we are also looking at doing example modules of this for um I think right now specifically safe and then the 4337 simple account but we're also considering um other module specs like 6900 and 75 or 7595 I believe is the other one um as well for just kind of providing um implementations of this for different accoun EOS systems

cool um yeah and then so the second major thing uh we're working on wax asides from this is going to be user Rob compression and the the thing I can basically tell you about user op compression based on some research uh my colleague Andrew has been doing um I unfortunately didn't bring his notes because I think he might still be actively working on them but the tldr is that Denon and 4844 have basically made um the L1 costs of rollups pretty much zero um I think it's one gay per bite currently because the blob space is currently unutilized and so any compression we could do on this so for

example if we take a look at um what this compression actually does um where we are taking um a very large amount of data that we normally have for like user op note that this is for um ERC 437 version6 not the latest 7 um and you can basically shrink it down to a very much smaller set of could you increase your font size a little bit here um it's very blurry all right there we go that's okay yeah so you know taking a pay master and data of a specific length and then shrinking that down to uh let's see here did we get that down yeah there's

no bites in this case because we basically just removed all the zeros um we're doing all this compression um Bally trading compute for call data in the actual data that's rolled up to um L1 and since that data is basically free at the moment or very very cheap um this kind of compression doesn't um it actually ends up costing more because you're using more of that rollup L2 compute and so the tldr is just at the current in the current fee market and going forward unless blob space starts being used um more gets much more usage um it's not really worth compressing um a lot of that data including the signature stuff um but if

you're interested in learning more about that compression work um you can find in our main repo under the compression packages and that link I posted um which I'll share all of this in the chat as well um goes over the kind of um kind of size savings you can get if you really aggressively start compressing the different user op fields and different things like the entry point in it are you looking at like a general purpose compression is this like deflate or gzip or is this something specific to um yes this is this is specific to um specific accounts so in this case it has to be specif it's specific to um this is

for uh sending ethereum um and then you also have like compression you can do on tokens so this would be an example of like translating say like a token from a index to an address so doing like a lookup scheme um or using a construct like a pseudo float to shrink the amount that actually is being sent into a smaller value so in this case it's very application specific compression um most rollups already do uh gzip or some other General compession by General compression by default on the call data they're submitting to L1 so it would not be very valuable to um do just do another layer of like say gzip on top of that okay that makes

sense yeah that's cool thank you uh yeah so yeah thanks again for coming out and giving the presentation I think that's really informative and it's I know I'm pretty excited about anything zero knowledge related so I appreciate that um we don't really have anything else formally on the agenda for today um so we can end it here we can hang around and and discuss random topics if anybody wants to bring anything up um but I yield the floor to anybody else if they want to talk uh might be a dumb question but like given that you said uh the like L1 costs are like quite low like doing these comparations like like

do you have any rough ball bug like how much it would actually save and like given that like you're doing custom comparation like algorithms like is is that uh do you think like that's necessary yeah I think in the case of really common operations it is so for example that erc20 compression um you have to get much if you want to get into much like higher data savings you have to get much more specific in like what Fields you are shrinking and and in what way like are you shrinking a long value padded by zeros into just a smaller like representation of that um or those like

address Registries the the main cost before dank sharding of um a lot of transactions was the actual call data is being rolled up primarily to the um ecsa signatures having to have that RS andv component in every single transaction that you post as part of that call data if you're able to um one of the things I did not mention for the compression is we also have um some of that happening via BLS signatures so the ability to take uh I think an ecdsa signature by default is 32 bytes and a BLS signature um is about 64 on the curve of the evm supports and so basically if you get above two ecdsa

transactions um and you would instead be able to use one BLS signature to represent them those both um obviously the savings just stack up from there um in terms of really trying to shrink that call data that the rollup has to push up um before the Dank sharting there were cases on optimism because their compute costs are generally lower that let me see if I can find in the doc the actual stat it was about I think 2x lower or more I'll have to find it um but because the now L1 data costs are so low you're basically just wasting compute on on shrinking those values does that answer your questions yeah

yeah that's a good point of view uh because like right now is it yeah like I haven't looked into the data yeah it's like if we see the like the cost distribution as like the L1 storage and L2 storage and L2 compute uh yeah would be interesting to see okay like which ones are like yeah the most expensive and then yeah like maybe optimizing optimizing on that but yeah like over all I guess like the L2 St is is something we can't do anything about like we can because yeah like if you're transferring tokens yeah like it's just going to change the same storage values like doesn't matter how you do it uh so it's yeah it's more

around just like how efficiently you are able to do it um like while posting it on L1 yeah and what I'm seeing and the numbers of the original doc Andrew shared which here I'll just post that real quick um so this was pre um DK charting it looks like it in one of the examples for say the um arbitrum transfer it cut it by about uh 80% the actual like dollar cost um because of those data savings so in if we see more L2 activity or more

blob space usage this could still be um useful in the future um but it doesn't really seem feasible now yeah makes sense uh everyone uh I'm Lucas uh at coinbase I was hoping to talk a little bit about a proposal we recently put out for uh new wallet rpcs um I don't know Sam is that please do yeah go for it okay cool um awesome so I'll just share my

screen okay can everyone see this yep I'll also drop the link in the chat uh just so you can go and read it yourself if you want um so yeah uh basically um we recently launched a new RC 4237 wallet um and uh we kind of realized uh you know the the ux for 437 while it's is really promising uh but the problem is that Beyond like uh onboarding and things like recovery uh the story is kind of not that compelling because the ux uh once you are in the context of an

app is pretty much the same um so we realize that it's kind of time to to think uh about how apps can better communicate with wallets and take advantage of uh like new ux enhancements so like batch transactions and uh sponsored transactions via pay masters in this case um so uh we put together this proposal for uh four new rpcs um one is wallet get capabilities uh this is for um like open-ended communication between apps and wallets to find out the kinds of features that a wallet uh supports um so for example understanding

if a wallet can support a pay master um or batch transactions wallet send transaction this is kind of like the new eth send transaction um this allows you to pass uh an array of calls so that wallets that can support submitting multiple function calls in one transaction so like in a user op in the case of a 4337 wallet um and it also allows you to pass uh a capabilities field so that you can talk about the capabilities that a wallet support so uh simple example would be like passing a pay Master URL so that the wallet during user op construction knows where to get a uh pay master and

data um wallet get transaction status and wallet show transaction status these complement wallet uh send transaction and it's for um getting the status which we Define as like a pending or confirmed enum and uh a subset of a transaction receipt and um showing the transaction status is delegating uh to the wallet to show the information about a um a transaction uh these are heavily inspired by EIP uh 5792 which is um was around uh primarily just uh sending um batch transactions um so we took a lot of

inspiration from that and kind of extended it so that you can kind of uh think into the future of like not just pay masters and Bach transactions but whatever else might come up um yeah so I won't go into the details too much of the spec uh but that's kind of the uh tldr and um I guess a few of our guiding principles are like one we don't have we don't want to have apps think about like user Ops or regular transactions right they should just be able to call one standardized API and then the wallet should be responsible for deciding how um that lands on chain um and uh we

also kind of wanted to leave room for things that go beyond 4337 so like right now this is uh geared kind of towards 4337 because we talk about pay masters a lot in Bach transactions but uh this like capabilities thing um we think can be useful going forward when there's some new type of wallet implementation um so yeah that's kind of like the the highle overview um would love to hear like any initial thoughts reactions or happy to also like answer any questions or go into more detail if anyone wants to know more about any of the methods specifically hi Lucas um so I obviously

just started looking at this but uh since there's currently a bit of an active conversation going around um e EIP 3074 and 5806 like different capabilities that allow EAS to have Smart contract capabilities including things like batch transactions and sponsor transactions I definitely think it's worthwhile to just check that this works well together right so like to adjust this so that it basically works for both use cases in the same way so that 4337 and for example 3074 accounts can basically interact with the same way I think it's totally doable I just didn't check if it's already

tailored for that yeah definitely and that's that's definitely one of our like guiding principles is that um uh developers should be able to call these rpcs and expect that wallets uh um land uh their transactions on chain as expected um and uh the idea is that it's kind of up to the wallet to make sure that when they receive these uh these calls that they handle them accordingly and uh make sure that the calls land on chain yeah definitely something that we're we hav't mind yeah yeah for example like with the pay Master like what are the parameters we need to make sure that are in there so that all kinds of like calls work right those kind

that's kind of like what I'm thinking about yeah definitely um and the pay Master uh stuff is definitely something that we need to flush out a little bit more we actually have a um a follow-up dock on that specifically um which I can find and and send here but uh um yeah the idea is that uh we're thinking that capabilities should kind of be Community defined so um uh yeah to answer your specific question like the fields of uh pay Master communication are still kind of up in the air and um yeah we want to make sure that we get that right so that it works for all implementations

awesome um I have like a small question so like when I try to like uh fetch any kind of capabilities like using this EIP I like just thinking in terms of like as we go for like there might be like new kind of capabilities that might come in so like how do you think about like like would should this AIP contain these specific types of fields okay like maybe pay master and all that stuff so like do you want to like impose that to like these are the fields that will be used or is that like a open-ended thing that because yeah that that's like a challenge that I could see is it yeah definitely um right now we're kind of thinking that it should be pretty open

um and we've discussed kind of the idea of like wips like wallet Improvement for proposals uh where the community can come together and like Define new capabilities uh and sort of align that way uh but we are currently not planning on imposing any specific Fields uh per capability makes sense yeah like this is kind of where okay uh the DS like yeah like we'll have to figure out like if if this is something that like gets accepted like by like a lot of wallets and like then just need to make sure sure that like each wallet like follows some sort of like standard like across like different capabilities otherwise

like Taps might uh would have to like handle look all the complexities of like maybe if the formats are different across like different wallets for the the capabilities but overall I guess um yeah yeah definitely um yeah and I think that the details around that can be defined like as part of the definition of capabilities um but uh yeah definitely another kind of guiding principles is we want to make sure that uh we can get things right for uh you know any wallet implementation makes sense I'm also uh I found the other doc that we've put together on uh thinking more about like

the pay Master capability if you're curious I just dropped it in the chat yeah sounds good so I I had put a few comments on this document a while ago and I completely forgot to follow up so I'm just going to follow up now yeah so uh I think that the one that stands out the most to me like as a low effort change is just changing the name of transaction so don't call it wallet get transaction status but something else I think the name is a little misleading um um yeah so on that one specifically I actually uh also kind of forgot to

follow up and recently um responded uh we have actually been thinking about changing um the spec so that multiple calls must be um executed as part of one transaction and I guess like a side effect of that is that the the name is kind of no longer misleading so curious if you have a thoughts on that uh so if each action inside of this this bundle whatever we want to call it gets a unique identifier then if you can later call get um okay no I guess this works so yeah I guess transaction makes sense then

um yeah yeah I I guess uh curious if you have thoughts on the I guess kind of the downside is it could be viewed as like a little restrictive to like uh eoa wallets for example but um I I also saw your comment around like having a like a field so that you can specify the like atomicity of this but um yeah I I think the the kind of cleaner solution is to just say if you're going to pass multiple calls they must be executed atomically um so that you know developers don't have to reason about like well what are all the possible ways that this could fail um yeah I think at like

so there's there's a couple reasons why I like the um at time City Field right because then like anything that allows the DAP in the wallet to to communicate more clearly about what they need I think is useful um and in this particular case like there's a difference between bundling because it saves gas like let's say you're you're swapping like a bunch of tokens and you don't really care as long as you know they're all sent together and and um like you don't care if they fail or whatever you just want to save gas on the transaction that's very different than like I want to swap millions of dollars and there's like several hops in this thing and I need them all to work or all to fail and being able to communicate that kind of difference between the DAP and the wallet is is going to be very

important yeah that's fair um yeah gut reaction is I feel like a little hesitant to uh put that in like the core of the API so I I like lean towards Maybe making that a capability or something um but yeah can uh like like I was also thinking about like these kind of cases where um say like if you're trying to do like BGE transfers like in that case you might need to do the approval at first and then the transaction so like it's not exactly automic but like it's uh it's sort of like stepwise that you need some transactions to complete first and then only you can do others and like I I do

understand like this is not exactly watching but like it's uh it's sort of a intent that like I'm approving that you can go in ahead like go ahead and transfer these things but uh yeah I guess like um yeah this might be outside like what this EIP is trying to like uh sort of solve but yeah right so I think it could be done with a capability as long as it's a way possible to do it mandatory like if the DAP says like either you fail this RPC call or it it completes atomically then that that should be fine um but if you if you can't express like binding

requirements and capabilities then that's that's kind of a problem yeah I think that's fair and uh currently and the the draft we're working on it's it's the the former of what you just said I think where uh if it cannot be executed automically then it the wallet should revert um uh yeah and then we can think about how to include like more more like sequenced transactions as a capability well even the difference between atomic and like sorry like flash Bots versus like smart contract wallet because Flash Bots can guarantee atomicity except in the case of a reorg which is a you know a looser guarantee than than some people might

want I'm not sure like if that needs to be represented or not but yeah there's a whole bunch of levels to this y That's fa Okay and like like Vasa said um there's also sequencing right so if you have like a bunch of like if if you created like a a numbering system where you could say like all transactions numbered one have to complete and then all transactions number two have to complete and like you you can get very complex with the sequencing stuff and I don't know if that's easy to represent with this or not but yeah I mean for for just a simple batching API I think this is this

is pretty good cool any other questions or comments um I nothing specific top but yeah like we are also like uh working on like like on openc wallet or like we working like some ideas where yeah like we want to bch things but like our problem statements is that like it's it's very much sandboxed like wallet environment like we're not doing it uh like outside openc at this point so like it's uh yeah like while they are while we have like not thought about an

EIP but yeah like this is something that we can like like sort of contribute to in terms of because yeah like we also want uh sort of an experience where okay you express an intent to like do something and then then uh yeah it can be optain but like yeah like we want the least number of clicks that the user might need to have uh like to do anything so like this uh is something that's like a good direction like not just for like because the problem is that like we can only Power that experience for our own wallet but like for any of the external wallets uh it's it's like very totally different experience so like if we have like some sort of a common ground here like then it's good experience with the KY wallet

yeah cool I'm glad to hear that and yeah I would love to kind of loop you into the conversations more it sounds like you guys would have good thoughts on um how we can do uh like the difference between like uh sequenced transactions and uh um like batch transactions yeah like is there a bullet request for us like and uh check the uh current one yeah but um yeah I can follow up okay anything else not that's okay um but thank you

everyone for the comments and the the feedback this has been very helpful thanks for sharing we appreciate it [Applause] uh like I like we if we don't have anything else and like I've been working on like a uh L2 beats for wallets like I don't like I know like there's like bunch of other uh implementations of of it but uh it's it's more of a

learning thing from myself where like just like try to like work with like different vets and try to understand okay how everything works like within their wallet it's so like most of the wallet compon website they only focus on the features and stuff like I wanted to do like more holistic things so like if you have seen like uh L2 beats so like it has like different versions of it so like you can go to the security or risk analysis or like the uh maybe yeah so so like the categorization of like different tables is different but like for every uh page uh like sorry uh yeah like it's I'll I'll send you like on the chat uh

but yeah the main thing is that okay there's like a main page for each chain and and for each chain um just a second okay yeah so for each uh so like for each chain you have like a single page which has like every detail about that uh yeah chain and then uh different categories of like the table so like maybe security or like uh the overall tvl so like they'll link to like different sections of it so like it's more holistic in some sense and like it's it's not like a ranking thing that which is which gets quite subjective like the way you're like ranking things

so like I don't want to like rank any for it's more around like just like objective comparison that sounds like a super useful project did we lose you did I lose sound no we can hear you

all right um not sure if as is having technical difficulties or what but um or or if I'm having technical difficulties but uh yeah I think that's a really cool project and if if you can link the results um I think that'd be useful oh no worries it happens um yeah so I guess with that um unless anybody else

has anything to bring up I'll give you all back 15 minutes of your time and uh we'll see you in a month thank you see you thanks Sam