Wallet Account eXperiments - Helping wallets, dapps, and SDKs shine

foreign [Music] yeah so my name's James and we are wax we're a team within the privacy and scaling Explorations group in the ethereum foundation and uh yeah our focus is uh well it's pse's focus is enhancing ethereum through cryptographic research and we're one of the teams who is exploring a scaling solution so the privacy and scaling exploration does a lot of things around privacy but yeah our Focus initially was on scaling so in today's talk we'll be talking over the BLS signature aggregation which is where we begin uh we'll be talking about user operation compression and reducing costs with that additional verifications that we'll be exploring in our V2 and also Integrations and how we can make that easier for everyone to integrate and use and then we'll conclude with the summary so let's begin with BLS signature aggregation so the problem we're trying to solve is the roll-up cost problem so we all know layer twos are cheaper but we can actually get more savings by doing something called Signature aggregation for every transaction on a layer 2 you've got the transaction data as well as the signature data that gets rolled up to layer 1 and that's a significant cost with BLS signature aggregation we use a different signature scheme that lets us combine every transaction signature into one so instead of having say 200 transactions with 200 signatures being rolled up only one signature needs to be rolled up so the cost reduction is quite large with um for the signatures and this is possible because rather than use the protocols ecdsa signature scheme we're using a different signature scheme which needs to be verified on chain and for that we need a smart contract wallet so so lots of taking it once but basically the way um yeah the way that works the way I sort of visualize BLS signature aggregation is that you'll have many unique transactions um sorry many individual signatures but they can be combined together or aggregated into one uh basically the space of one but still give you the ability to verify that all of the individual transactions were signed by the corresponding public keys so again it's just a nice um thing mathematically that BLS does that I don't understand but we just get to use it from the outside which is quite nice so we want to make that easier for others to use and benefit from under the hood it's something like this each public key and private key um so each private Key signs a message to use the corresponding public key to verify um all against the single signature but we don't need to worry too much about that um overall the way we can make that work is that within the wallet we'll need something that can sign with the BLS scheme and that's a client module on the left that'll then send to the signed user operation as we're calling it to an aggregator which will combine many different user operations and BLS signatures into one and then submit that on the right to the smart contracts on a layer 2 which is our verification Gateway and BLS Watts that's sort of just the pieces broad brush stroke but when we zoom in a little bit this is what it looks like adapt will propose a user operation now this terminology that we're using is 4337 terminology or account interaction as you've probably heard of and so the user operation can consist of multiple actions those are um then yeah the depth proposes that to the user's wallet the wallet will then sign that user operation and many wallets in parallel are obviously signing um different transactions those get combined together or aggregated via the aggregation server but also there's additional compression that we do to again reduce the size of what gets rolled up so in the end basically the essence of this is where trying to reduce the data that that will get rolled up so some of the yeah we'll talk more about compression after with those bundles um with that bundle of operations and the single aggregator signature we then make the call to the smart contracts that bridge across to these contracts is what we want to reduce so now that it's small we've passed the Gap we've had our savings we now need to expand it again to fully verify it so we'll have the expansion done on chain as well as the verification done once we have all those user operations verified we can then get each smart contract wallet to call its corresponding data so that's sort of the end-to-end flow but with the um yeah with the smart contracts uh well we have to do things on chain that would normally be handled by the protocol like the non-cern gas so those are additional parameters now we had to send that we didn't have to send before so let's look at how we can do some compression to save that so thank you James so yeah I'm Andrew and let's talk about user op compression so I want to give some context uh zooming out um you know I'm talking about compression so let's talk about the actual bytes um that we have to work with so this is what a vanilla transaction looks like to just send some eth um and uh about roughly the second half of this transaction data is your signature so you might imagine when we switch to using BLS signatures that the effect of that is going to be something like removing the second half of uh of these bytes however the reality is a little bit more complicated than that and so instead of going from 120 down to 60 by doing that if you just call our Gateway directly in order to process your operation your transaction data is going to look like this instead um so what we but we can fix this problem um with compression there's quite a bit to do and then we can realize the benefits of those BLS signatures and also take it a step further and apply that compression in other ways as well for additional save it so zoom in a little bit because I don't expect anybody to just understand a Big Blob of bites like that um this is the same bites as the previous slide all of the examples by the way here are like properly encoded transactions and a couple of them are posted on chain as well and there'll be QR codes for uh viewing those on the Block Explorer um so yeah so here is just pointing out the the bits and pieces that are in there or Draw your attention to the signature which is on this slide this is the transaction on part of the transaction envelope that's around that orange data section so we're using BLS signatures and you know a different system and all that but in order to actually get this data on chain we still need an eoa transaction which means that there is still an ecdsa signature involved here and so that becomes part of the data that's shared between all of the user operations that we've bundled together inside of this orange data section um so let's continue zooming in and have a look at what's inside of those bytes so this is them um so like this is the solidity ABI to specify what's going on and so we just have that little uh each transfer in there as those represented by those red bytes the ones that are in Black are shared bytes and when you compress those as well um but it's mainly about these red bites we're just currently sitting at 640 at the moment and so those bytes the compression that we can apply to those how small we can get that determines the uh like the long-term cost performance of this model um so 640 is a lot but we can also reduce that by a lot as you'll see uh some of you may be familiar with this tweet from vitalik last year we've been inspired by you know this and also from the Hubble project and also other sources um so I won't go into this in detail if we don't have time um but I'm pleased to say that what we've implemented is very similar to what's represented in the ideal stateful compression in the bottom right corner there um so without further ado this is what the same transaction as before looks like when compressed so we've got the link there you can go view that on the Block Explorer if you like but the main thing to to note here is the 640 bytes from a couple of slides ago are now represented in just those 17 bytes there instead um and so now that I can fit this all on one slide as well um we can have a look at what this looks like when you include multiple operations into one bundle so have a look at that empty space uh in there that uh just underneath the red bites so we're going to include two more transactions uh let's make them erc20 transfers um which is important to note that you can actually include all sorts of different transactions into the same bundle and they all benefit from the combined signature aggregation so that's what that looks like there uh you see we can just slot them right in there and we have some erc20 transpose as well so continue to zoom in let's see what's actually going on with those 17 bytes how does it represent uh what's uh what's actually happening um in that operation so this is then the annotations um so all of these fields I won't go through all of them all of these are variable length Fields so in particular um you take for example that non-spilled is only currently taking out one byte but one byte can only represent 256 different nonsense so there will be a big limitation if it was only that but this just expands gracefully like all the other fields if necessary to accommodate the extra space so as you get into hundreds of nonses then you'll start using two bytes eventually you might use three bytes if you're really prolific and interior can go up as much as you need but you probably won't go more than three boats um secondly I'll draw your attention to this build is particularly special so this is representing the BLS public key of um of that account and so yeah three bytes is not enough to represent a public key and so but what we're doing instead is we're saving this data in a registry so the idea with that is that you know your BLS public key that we use to identify you that does need to get posted onto L1 at some point but what we can do is effectively it's compression we're deduplicating that data but instead of having to do it in one uh within one block or like within one batch that gets rolled up like in the um the z-lib stuff that some of the chains are doing now instead we're deduplicate sorry deduplicating it across a much wider time span by just saving those bytes on chain and then we can refer to them again later um another thing that we are leaning on quite heavily with the encoding uh is this format called pseudofloat which is a format for representing decimal quantities really efficiently what this format allows us to do is if you've only got three digits of precision uh in your font scene say you're sending you know 0.101 eth that's only three digits in there and we're we're able to represent that quantity in only two bytes if you need more more digits than that obviously sometimes you do need more digits um then it again expands gracefully and you can still do that as well and it supports the full un256 range um finally on the compression side I'll leave you with this um to just summarize the amount of bytes that you need for an erc20 transfer under different scenarios so in the vanilla transaction which is this is the status quo today you're looking at 150 bytes to 180 bytes depending depending on how you count them but if you use wax if you're in a bundle of five transactions uh then you're only going to have to pay for 55 bytes each and if you can aggregate into uh 100 then you're only paying for 22 bytes each so this is pretty exciting we're looking at reducing the amount of cool data by almost a factor of 10 and so chorus that corresponds to being able to do 10 times as many transactions so we're pretty excited about that um all the stuff that of this compression stuff that's all implemented in our B1 contracts uh but we're also looking towards a B2 with uh some new and exciting features so to talk more about that I give you Jake thanks Andrew so next we're going to go over um for our V2 some additional verification methods we're looking into using the ERC 457 kind of framework before we jump too much into that kind of talk about what kind of accounts currently exist on ethereum and verification methods we use with those the most common one you have nowadays is an externally owned account also known as an eoa uses ecdsa signatures and the same curve that Bitcoin uses as far as for the crypto asymmetric cryptography these commonly are hierarchical deterministic wallets and sometimes can also be multi-party computation wallets with a like shared private key um but then on the other side we also have Smart contract wallet accounts which really can use any sort of signature or like verification uh sorry signature curve that's supported inside of the evm it's still commonly is going to be ecdsa but we can really use a lot of different things such as BLS um inside of that um you may commonly know existing smart contract accounts with like safe Origins and different protocols like that so it's kind of two things there's a very good um comparison given by the 1kx network that goes over the difference between all of these different wallets um highly recommend checking it out at another time I'm not going to go in depth into this but I really want to focus in on two advantages that smart contract wallets have which is their ability to be programmed on chain and then also the composability of the different things that you can use inside of those so with waxv2 we're using ERC 4337 to implement using that common account abstraction spec in this kind of uh well we're going to take advantage of here we have our bundler which is very similar to the aggregator Jane mentioned James mentioned earlier which allows us to bring together those user Ops and submit them we have our entry point contract that's going to be connected to our account and then we're going to basically validate those user operations see if we're going to pay for them and then we're going to execute the actual main functionality inside of them one of the cool things about the spec is that the I account interface we use for checking and paying is very generic it basically takes in a user operation and the wallet basically will tell the entry point and the bundler whether or not it's going to work with that validated data um validation data passes at the end as part of that user operation we have a field called Signature which is just an array of bytes and that array of bytes could even though it's commonly going to be a cryptographic signature we can really put anything we want in there um that can be used for the account and for verification so now that we have this what new verifications could we use with this smart contract wallet well we could use some basic web auth maybe have a username and password accessing something but there's better things we can use such as web authen also commonly known as pass keys this is basically using asymmetric Keys similar to what we would use in ethereum and other blockchains for signing into web 2 servers and accounts its device and domain specific and it already has support from companies such as Google Microsoft and Apple but in theory any web 2 company would be able to implement this as part of the login and so we can take advantage of the fact that those are asymmetric I'll be those asymmetric keys to actually allow these to sign for a web 3 account so anyone potentially with accounts already at these places that has the web authen could control an account using those another one is potentially using zero knowledge proofs as a way to sign your user Ops so on your device which is the prover you're going to have your private inputs and you're going to have an expensive computation to generate a proof we then push that proof and maybe the public signals into the signature field of that user op and then finally in the evm and that entry point our contract can go to a verifier contract and verify whether that proof is valid and whether it's going to process that user of and so in this way we can use those proofs uh to authorize a user op this opens up a lot of different possibilities of different things we can do such as using new signatures and curve schemes that the evm does not support so anything we can Implement in cercom or newer DSL such as lunar can be used for example you can already do EDSA Ed DSA signatures inside of cercom so you could use that for verification as far contract wallet you can also use newer BLS curves like BLS 12 381 which is what the current ethereum consensus layer uses to validate those but really we can also do anything that's provable inside of a proof as part of that verification so one thing that's being looked into there's a pending paper that will be coming out soon called contract wallet using emails is using an email as a proof meaning that someone could have a smart contract wallet and actually send transactions just using a normal email message and generating a proof that they control that email address and that the content inside actually matches the transaction they want to do but you could probably think of a lot of other things you could prove with a zero knowledge proof that you could use to verify via Smart contract wallet finally one of the cool things too with the verification is it generally is very is cheaper to do inside of the evm than maybe doing a normal solidity based verification um so the gas costs sometimes are linear with the number of constraints in the circuit but some work that's being done to lower those could eventually make it log of n or constant time to verify those proofs you still have the uh the issue though on the device where the proof generation can still be very computationally expensive so what does this allow us to do we can have multi-factor all situations where we combine and compose multiple of these together and so for an account for smaller things you might be able to use one of these methods for sending small things but if you want to upgrade the implementation or send larger amounts you would need say two or three to do this so in this example you might have an ecdsa or BL assigner your friend may be just using their email to help you and there may be a bank or institution you trust that also is a backup signer for those and so for small things like your bank paying your bills for you are you sending money um like you would on venmo or something you might only need one of these signers but if someone wants to change the signing scheme or do a recovery then you might need two or of three of these people to do it but we can have a bunch of different verification methods for that another one fun one is recovery and migration which we can have basically people move from centralized accounts to decentralized accounts progressively so for this example let's say grandma wants to play web3 poker she's a poker fiend she wants to try it out and so she can actually create an account abstraction account with her Facebook login using web authen she can then choose her best friends on Facebook to be her social recovery people in case she loses access to that counts then let's say Grandma kills it a poker and makes a ton of money now she doesn't want Facebook to be able to rug her and take all that money away so she and her friends get together and migrate her authentication to something like a hardware wallet so she can really have that secure scheme um control over those new funds and so what this really leads to is kind of almost a Cambrian explosion of different verification methods we can use this is when multicellular life kind of exploded into the world uh 600 million years ago into a wide variety of things we see today and so using things like our current signatures BLS web authent and zkps we have a lot of different new verification methods we can use but there also are a lot of cool ones we want to look into that maybe don't exist yet or maybe you will build during this hackathon or some other time and we're excited to see what those are and so to make all this easier we're going to bring on Blake to talk about Integrations thank you Jake um yeah now I want to talk about what our team is doing to actually get some of this work into developers hands and in order to do that we've been recently working on a node module called ethdk um this is a node module that we're hoping that will allow developers to easily add um some of these experimental features into projects that they're trying to get into end users hands um because we do know like sometimes if you're building a product for a user it could be hard to take the time to experiment or integrate a Cutting Edge feature that you don't know exactly how it works so we want to take some of that cognitive load out of the hands of the Developers um when talking about building this node module there were two things that we wanted to focus on um first one is just keeping it simple um and with that uh we wanted to keep it simple just in like the terminology that we use it seems like for example this first one I have up here a wallet first account seems like the ecosystem is like settling on the terminology of account over a wallet so we want to make sure our code reflects that so that users that are developing with this node module know that they're creating an account and it's a programmable smart contract account um and then another example this one's both terminology and in the functionality of a functionally implemented is uh RV once our contract wallets have a form of social recovery available and in order to set that up you need to call the set recovery hash function on the actual wallet contract and pass it a recovery hash but that requires you to know how to generate that recovery hash so in our node module we created a separate method called set Trust said account um the terminology of this better communicates what you're doing you're setting a different account than you trust to be able to recover the original account and then we also just pass two parameters we pass a recovery phrase as well as an address um so that you don't have to know how to actually generate that recovery hash and then we also wanted to focus on just some sensible defaults there's a few things that we know based off of building uh our our wallets and our aggregator that you need to do in order to get the full benefits of our tech for example as we talked about earlier the reduced on costs on layer twos you actually need to be using Layer Two you can't do the big deal signature aggregation on an L1 and get the same cost benefits so we want to make sure that the developers know that they should be using an L2 and then also we want to make sure that our contracts are are already deployed and verified on the specific networks that we're trying to support so these variables can be constants within the known module that are easily exportable if you wanted to you could easily like override any of those defaults but we do want you to just focus on using the features and not finding uh where a specific contract while it's deployed on chain um so where are we now with East DK we currently have a beta version published to mpm um and it works with our implementation of our V1 uh contracts and then we've also demoed it in our instant wallet you might be familiar with a burner wallet uh the instant wallet is just our version of a burner wallet that uses our sort contracts behind the scenes and then we are starting the uh the work on our B2 smart contracts so the hope is that we'll come out of our beta version when we have the V2 contracts available and we could also integrate some of the modules that Jake was just speaking about before mate um and travel the section I just wanted to show a quick example of our V1 um or our beta version of ethdk as you can see at the top I'm importing a create account function as well as the networks objects and then it's just like a few line of codes to actually create an account and then set your trusted wallet so here is I just called a create account Factory function with a couple config properties and I can await that and then print out the address and then down below I just create a recovery phrase and pick an address that I trust and then I could call the set trusted account um so as you can see you don't have to know how like the contracts are actually set up you could just easily use the functionality that we're trying to get into the hands of developers uh but yeah we're really excited where we can go with this especially with our V2 contracts and then with this coming out of the the beta version so keep an eye on the the link on npm and I think to wrap it up I want to hand it over to John who is going to aggregate all the points that we just spoke about cool yeah thanks Blake so to wrap wrap up all that's been said yeah so wax started off to bring cheaper L2 transactions to evm chains to enable new applications and we can do this through BLS signature aggregation which can reduce the call data that gets posted to L1 by combining many signatures into a single signature but the signature aggregation by itself phone gets all the way so we need to do some cool data compression as well using the techniques that Andrew mentioned earlier in the presentation and it's important to mention that the gas savings we've spoken about can be used in addition to the gas savings from l2s so there's a lot of Buzz around the design space that account extraction opens up ERC 4337 in particular is a very unopiniated standard and gives developers a lot of choice in what they can do so a lot of unexplored ground and as Jake mentioned we're sort of anticipating or hoping there will be a Cambrian explosion as such of accounts using lots of different verification methods were in particular excited to try out web or fan and zkp email verification in our upcoming modules I now have the freedom to use these modules in various ways for example you might be able to use werewolfen as a multi-factor authentication say if you're sending a transaction as like over five dollars you can use your web orphan and you might use your zkp email to recover your account alternatively you could even use the the zkp email as your multi-factor authentication the possibilities are you know are fairly Broad and you can do all this while enjoying the cheaper transactions brought about by BLS aggregation and the cool data compression and at the top layer we'll have the fdk which will wrap all the BLS components together in a intuitive abstraction for developers to use so we've just about wrapped up our V1 contracts and we're looking to V2 to apply some of the Lessons Learned there and we're starting that now basically so V2 will enable BLS signature aggregation in a 4337 compatible modular smart contract wallet and you'll be able to add a digital verification modules in there um to enable more expressive transactional verification and recovery options cool so yeah the future of where transaction costs are going and also account ux is very exciting and we're really looking forward to Bringing these new developments to the ecosystem if you want to learn more please check out our website at getwax.org and if you want to learn more about the BSC and what we get up to please check out appliedzkp.org thank you all for listening