Onboard The World Into Your Rollup dApp with BLS Wallet by Jacob Caban-Tomski | Devcon Bogotá

foreign [Music] itos and welcome everybody how's everyone doing today nice all right I'm Jacob montowski I'm a developer on the BLS wallet project and here with me today is James Zacky who is our uh Project Lead and we're going to talk about BLS wallet anyways what we're going to cover today when the next slide pops up is we're going to go over at a high level the team and project outcomes a little bit on the basics in a high level overview of BLS signatures and aggregation we're then going to cover um where BLS wallet is today with some examples and some of the features we have built in and then we're going to cover where we're going next with the project and finally we should have ample time for questions so we'll kind of go over the team and some project outcomes to start this is our wonderful team right here off of it off little that's okay um we're scattered all across the globe we're part of the privacy and scaling Explorations Group which is a subgroup of the ethereum foundation we work mainly with zero knowledge proofs and layers get layer 2 scaling technology um our goal is to bring more privacy and scalability to the ethereum blockchain system so cut some of the outcomes we want to try to reach with our project and the primary one are North Star or here in the southern hemisphere the Southern Cross is going to be reduce the uh the cost of L2 transactions primarily by reducing the amount of data that is rolled up into l1s by reducing transaction size currently with some initial numbers uh which are a little difficult to see right now we've essentially simulated running 150 erc20 transfers both regularly normally on a roll-up as well as bundling them all together into a single L2 transaction using BLS wallet and we've gotten it down the transaction data size by about a quarter um we're hoping that we can go even further than that uh we still need to measure the impact that we're going to have on layer 1 gas costs to see how the transactions are actually going to be reduced um but our team likes to limbo and we want to see how low can we go with using some things involving address books um as well as some other indexing things to reduce that call data even lower than uh where it's at we'll get into um how we reduce that size in a moment so another outcome we're looking for is to be able to improve wallets um one of the features with that is going to be account recovery sometimes people talk about a social recovery so if your project keys are compromised is there a way you can swap to a more secure set of private keys and what kind of features functionalities and security that will enable and then we also want to have upgradable functionality for wallets so you can change what features and things it has over time so that wallets can serve a more diverse set of users across the entire ecosystem and finally we want to make D apps a lot easier to use and so part of that is by having a baked in multi-call um or we call it multi-actions where you can take multiple transactions and put them into one and then also having sponsored transactions where the user does not have to pay gas on their end and the D app sponsors it instead so that way when users first come in to try at the app for the first time they don't have to go stay tuned exchange to buy ethereum so they can pay gas for transactions so to start off we're going to cover Els signatures and aggregations at kind of a high level uh BLS stands for bone Lin chacham uh is a pairing cryptography based uh signature scheme used in the ethereum consensus layer zcash and a number of other projects it is um deterministic for a given public key and message um validators currently are using BLS uh signatures specifically on the bls-12381 curve uh two uh sign messages on the consensus layer um and then inside of the evm execution layer we have access to the BN 254 curve via eip197 that allows us to um which we use in BLS wallet for both signing and then verifying on chain the transactions uh we're hoping in the future via a newer EIP that we will be able to actually move to the beacon chain uh curve for more security and for better access to Frameworks that the beacon chain is using uh to improve that signature but the most important thing for us is Central aggregation and what we're able to do with the BLS signature scheme is take multiple signatures let's work yeah and merge them into one signature so normally with the signature space you'd have taking up we can shrink it into just one um and this is really good for reducing uh the data that we roll up into an L1 because normally when a rollup goes in it takes all the transaction data as well as the signatures for each of those transactions specifically the RS and V components of that signature instead we can use one BLS signature across all of those transactions plus one is ecsa signature and save on that data that we roll up and that's in the example we saw before why the actual transaction data payload is much smaller um if you're interested in learning a bit more about the underlying of pairing cryptography um there's a really good visual guide at cryptology which will go into the actual aggregation and more about the actual BLS signatures so let's get into where we are today with BLS wallet so at a high level as per most normal D app usage you're going to have a browser that's going to have a extension usually in the wallet and that's going to be communicating to some RPC node and we have the same setup in our example prototype extension we're then going to in our case though have a set of user operations that we forward to an aggregator service which is going to take many to separate operations and merge them all together into one and submit them to an L2 node which then will execute against our uh contracts for the verification of the signatures and then through the smart contract wallet to dive into that a little bit more at a high level we're going to have a DF starting out by generating the operations which contain a set of actions and we'll go into what that format looks like in a second the wallet extension will then use the BLS client module to sign all of those with those BLS signatures those are then submitted into this aggregator service to create a single a bundle of operations with one aggregated signature then the bundler will aggregator will take that set of transactions and we'll submit them into the layer 2 evm where we can do some work with expansion to expand the call data parameters into more uh Advanced or more verbose data we do the BLS signature verification across those and then finally for each of those operations and actions we submit it to the actual contract wallets and uh that is then executed against the actual underlying DF code so the first feature we're going to dive into is the multi-caller action um for this so uh this is a library that our teammate Andrew helped uh right if you want to try it out you can npm install BLS wallets Dash clients still keeps in that edge of that stage um in there we're going to have a bundle that we're generating and the wallet's going to sign it that operation is going to have a nonce which is going to be the current wallet nonst for if the wallet hasn't been created yet and it's going to be lazily created it'll just be zero we then have an array of actions where those actions are Atomic so if any one of these actions were to fail then they all would fail um inside of that you can specify an F value as part of that the contractor targeting and then finally the encoded function that you'll send over in the case of the example we have up here we're doing an approve and a swap on a simulated decks and instead of it having to be two separate transactions we can just merge it into one via that format um using building on top of this we've built a prototype uh browser extension wallet called quill and fast cool called quill uh with Andrew and katuk and and as you can see here in an example we have a standard transaction confirmation which contains three actions inside of it one of them in the middle being an approved so instead of a user having to go in and separately run the transaction for approve and say transfer and something else we can do it all in one and have just one confirmation dialogue pop up to them um if you want to learn more about how we have this set up and how you can integrate the D app into it right now um You can find out more of the link below in our GitHub repo on how to integrate that in so next we'll get into sponsor transactions so right now the pattern we're using to have these sponsored transactions is to have our normal flow but in the middle we're injecting in this top Center portion the aggregator an aggregator proxy which essentially is taking those operations we would normally submit to an aggregator and is instead sending them to it where it qualifies to see if they're uh if they can be you funded uh for free gas basically and so then that aggregator proxy will add that payment bundle in on uh in there and then submit it to the normal aggregator which requires the fee and this allows for us to have those gasless transactions our teammate John has built a uh very cool demo using uh scaffoldeth for the scaffoldeth community which is a single pool Dex as you can see here it's a just single pool decks with a swap um it does use the multi-action as well to do the approve and the swap inside of it and then it all runs inside of the browser with no need for like upfront gas because the aggregator proxy is going to subsidize it and so that allows for free transaction you can find out more at this uh the GitHub repo below and it also is deployed at single pool Dex react app.versel.app um we're also looking into doing this directly via a contract um the way the aggregator currently works is when it receives a bundle it's going to actually introspect and look at um whether when it stimulates executing that transaction if it gets paid either in F or we also allow erc20 tokens if it sees that it happens it will include it in the bundle it's going to submit to layer 2. so one of the ways you can take advantage of this inside of a contract is just have it pay transaction origin and then the every year will get paid um you can also do things potentially like gate this payment via an allow list ownership of an nft or potentially even something like a zkp proof so that you can only allow certain people to have access to that this also allows anyone potentially to be a bundler and submitter potentially even Mev Bots that are looking for profits and be able to um submit those in so that you don't have to go through a specific aggregator and you could submit to say just a general say bundle mempool going on top um we still have more research to be done to figure this out but we believe it should be uh pretty feasible and possible to do all right and now I'm going to hand things over to my teammate James James thank you yeah you've done pretty well given uh the slides have been a bit often we've just lost our speaker notes but okay uh yep so with recovery um it's kind of catastrophic with an AOA uh if your private key is compromised you're basically racing against an attacker to secure your assets but with a smart contract wallet we've implemented a recover function that requires basically setting a recovery hash from that hash yeah we've got the notes now behind the timer um yeah so with a recovery hash it just consists of the address that you're going to trust to call the recovery function um and the the hash of the wall the wallet's public key that you're addressing and some salt so that you um so that an attacker can't actually deduce your recovery um address or the wallet that we'll call that so when you do call recovery you pass in those parameters and you are the caller itself then you can immediately reset your BLS key and uh yes basically stop the attacker who's Set uh who may have attempted to um take some of your assets or set some of the other functions so if an attacker steals your key and tries to reset your key they can't do that because there's a one-week delay in setting that parameter with your recovery you can do that straight away so as soon as you see a problem um in that someone's trying to set something you didn't you can intercept it with this we take advantage of um the fact that when you first set your recovery hash it will set it immediately but otherwise it's a secure function so it will have a delay and in doing that you can do something quite fun with that in that if you want to onboard your users you can put a wallet inside the browser and have them use that you can send them some assets like give them basically a web 2 usability experience but you they actually have web free assets in their browser wallet but then at some point they may say they may wish to secure those assets further so you have the smart contract deployed you have the key inside the browser but that's not very secure so you can do something like suggested the user that they set the recovery hash of their browser wallet and you can do that via the DAP and then from the secure wallet that you've prompted them to install like if it's our prototype extension quill you can then recover the wallet that was in the browser and what you've done is effectively set a private key to the extension key rather than the one in the browser so that is lost and you've secured it we find that's just a smooth way to onboard people so where to next so let's sort of start with where we began so we were looking primarily at aggregating signatures obviously to reduce the call data towards layer one on Roll-Ups and we wanted to I don't have slides here so yeah I wanted to leverage account abstraction which was at the protocol layer first so that was eip2938 with that we realized there could be some delay for that and also that seems to have paused since then so we decided at that time to focus on a BLS only signature scheme because that's what we needed and that would be a contract wallet uh we did some preliminary optimizations like parameter deduplication so if you have a bundle with a lot of common parameters you can effectively like factorization you take it once out the front and fill in the gaps so something like an airdrop is is really valuable so if someone wants to do an airdrop they can send a bundle of transactions they pass in one contract they're interacting with it's one sender it's one address it's calling it and then um yeah some of the parameters are the same except for the recipient and in that case you can effectively yeah deduplicate parameters uh there you've got to ignore that screen there we go uh yeah some of the wallet features we then focused on were as Jake described sponsored transactions multi-action recoverability and upgradability and then we heard about eip4337 and started getting some interest in popularity um and at that time our contracts were going for audit so we're trying to figure out do we just finish what we're doing or look at that so then we decided to yeah look towards being compatible with four through the seven so that's where we are now where to next we still focusing on aggregating signatures for the lowest cost transactions on Layer Two we will be focusing oh my slides moving around yeah still focusing on aggregating signatures and then we are working on being 437 compatible one of our colleagues is almost there with that and I noticed that draw in the background say hi uh so he's working on 4337 um what I should explain yeah 4337 is doing account obstruction on chain so they've um got a basically a smart contract template for that and a structure for how that will work um regarding paying gas as well the way we originally did it as Jake described is putting in a reward to the TX origin so that Mev Bots can process the transactions but there's also the way using the Altman pool that 4357 proposes it so we can do either of those depending on what the DAP wants further optimizations the 4337 user operation contains you know more gas parameters to take care of the way they do that but for when we want to do it the direct payment way we can again optimize those parameters out by not passing them in having a preceding function that then populates them with zeros and then from there we can do public key mapping so we have um yeah smaller data sent in for the larger addresses sorry larger public keys and also doing things like floating points so if a bundle has a lot of variables that are actually within a specific range we don't need to pass in a un256-bit number for each of them we can actually have some smaller range for those so saving bytes wherever we can there's a lot of things we want to do there some of it just almost like it would say a refactor phase we want to bring some of the stuff we have in our current wallet basically into modules so we may consider using safe for that and some of the examples in 457 and then we will inherently benefit from 4844 which is um yeah towards dank shutting so when we take a step back what we're doing is lowering the transaction costs on Layer Two and when you do that it increases the number of viable applications that can be built or viable solutions that can be put out there to solve problems and I'd like to sort of visualize it like this on the um the x-axis we've got transaction costs and we have a lot of defy things going on and that works on layer one even if it's a um you know during a busy time and there's uh you know high gas costs a high value Asset transfer is worth it you will pay a hundred dollars a transaction to move something of significant value similarly if you're there's a hyped up nft drop people will spend the gas to do it but that's not everyone that's a that's kind of I would say very small set of a population um with Roll-Ups you can get cheaper transactions towards tens of cents or less and then you can casual gaming at warrants that you can spend tens of cents for a certain type of interaction and that works there but what we want to do is go towards this we with evm Roll-Ups adding the BLS signature scheme gives you some savings and obviously all the other things that that reduce the layer to transaction cost um will open up the applications towards a microfinance in developing economies so this is where we are now we're live on arbitrim nitrogioli test net and we're going to be deploying to Arboretum and optimism after some autofixes and other layer twos that evm compatible or equivalent we'll seek to do what um basically get this into wallets currently and to encourage ducks to use it so we'll first Target applications where this will have a direct benefit to help help sort of priced out users and of course support regular web free wallets with integration via 4337 because that seems to be where the attention is with wallets and further optimization will just be ongoing we'll look to do those other optimizations to make transactions cheaper for the wallets that already have it integrated and of course things just get even better when when uh four eight four four drops so this is how it feels to me that we've got on the one hand a lot of real world problems that kind of a cut out from the web free Solutions due to the cost per transaction but um we hope that we sort of once that joins in that we will get these real world problems being solved by web3 Solutions and uh yeah we just sort of are looking forward to that time because I think that's when we'll get again a Resurgence of a lot of activity we have a lot of users will actually be able to benefit from The Primitives that we're building but everyone's building in the community So This Is Us where web BLS wallet if you want to learn more check it out in browser demo it's at BLS wallet.org maybe don't hit it all at once in case it crashes but it'll be fine check it out GitHub there's a Discord web3well and um yeah are there any questions okay I just question yeah okay um again uh congratulations for the project it's very it's going to be very useful to the community my question is um when you create the wallet and make this this changes you're proposing that is great you need also to update to the clients because for instance to support the multiple transactions they want to sign it it's amazing idea are you talking to the I don't know with execution layer clients to help them to adopt their clients how are being those conversations absolutely yeah so um quite a while ago we we started that Journey we started contacting I think there was even end of last year I started contacting some wallets just to see which ones might be interested how to begin that conversation and so it's a very good question um we had some interest from wallets certain wallets are saying yes we want to do this it's quite interesting but with what we had it just seemed to not get integrated so there was a bit of a delay I think from wallets but we were also not live yet so I think once we're live that will be helpful when 4357 came about which is the on-chain account abstraction there was a lot of conversation interest around that standard and so maybe the wallets will integrate that standard sooner and then we can have those conversations again and to say look here is an implementation and these are the features of this one and I'm sure there'll be other implementations for other signature schemes so there will be a change on the wallet side so that I have to sign with a different signature scheme and then obviously in the UI and all that apart from the quill extension which is the um basically a reference browser wallet we've also gone through a large design um I guess um yeah a large design a set of design and to look at what future wallets can look like so these can form a bit of a you know a bit of design help for wallets as well um oh yeah okay oh uh yeah with the clients like Geth or neighbors are you talking to those teams so so foreign maybe shows it better um this is a bit slow yeah so the the nodes don't need to change so so the clients that uh the um say the aggregators here we go uh this one so at the moment we have a dedicated server that will do the bundling we've already had conversations with um one particular Layer Two about this to say that they would want to integrate this um so for us that's been not been the barrier we've heard great enthusiasm from um the layer 2 networks to say as soon as wallets are doing this they're going to put it in like the nodes have a vested interest to reduce their costs so so that like for us that's been a like that was I did an early litmus test in a sense to talk to them and they're like if this is in the wallets we'll put it in the next day almost like that was the the signal I got from them but as it stands this is one solution um the 437 solution is a little different because I think it's an alternative mempool um but yeah you can maybe check out their talk for more information on that we've got a couple of questions over oh sorry over here yep hey Jesse from coinbase um two questions one is if we're exploring kind of eip3 4337 is there anything specific we should be keeping in mind with BS BLS to make sure that there's like compatibility there just on the coinbase side and then the second question is how does the atomicity actually work in the user operation transactions how is that actually implemented and like executed on the actual uh layer yeah um I can cover for the BLS signatures um both the the current I think it's f inflatanism is the repo um and our wallet under the covers are using the same BLS verification and solidity and also the same client libraries so they should be largely compatible um for that yeah and and yeah regarding the what's required on your side it would just be the signing like the client side would just need to sign the BLS um signature for that pot and then uh depending on which way you go directly or via4337 it will just be interacting with the contract wallets that it deploys uh the second question sorry what was the second one again the oh yeah sorry that's right so for the multi-actions we have a set of um it's basically uh an array of actions inside a user operation and and I think 457 has done the same thing it's it's the same format um that you can specify a set of actions I use a um uh so yeah it's kind of a cascaded function so that I can call it a try on one of them and so if one of the actions fails then it reverts and then so all of them revert within that try and then I catch and then I go on to the next user operation so each user operation is in a loop and within there it calls the set of actions to the wallet and if one of the actions fails only the user operation is reverted not the rest of it because of the try catch which was nice the facility has that now yep um who do you anticipate running these aggregated proxies we hope that they get merged into the nodes into their later nodes yeah to start out um we would expect like the app would probably run its own aggregate proxy just to kind of like bootstrap the process eventually um it could potentially be like uh a larger swath of say like nodes having compatibility with that we also think that um if we're able to kind of move more towards that like contract funding for the gas that will make it so it does not matter kind of where you submit it when it eventually is executed on chain um that's when the actual like payment subsidation will happen and so then it's less important but just to start out we're having that kind of more like centralized service just kind of get things going thanks for this presentation appreciate it does quilt have any sort of priority on test automation for end-to-end testing um you know usability testing seems like wallets right now don't pay very much attention to the user experience yeah because what are users seeing what are they clicking on yeah no definitely that's a very good question so firstly the quill isn't um we don't want to release Quail as a wallet it's meant to be like a reference implementation to show how other wallets can integrate the client we had considered spending more effort making the UI match the designs that have come about so the designs we have over there so if you go to our Discord I think in in The Design Channel we have a link to the design brief that was done or does it I forget what we call it as a whole but there's just been a large design process done to look at what wallets of the future can look like multi-chain multi-wallet and all of that being very usable so we've done that as more of an exercise to say this is what wallets can do but again we had considered putting that into quill but because we don't want to necessarily launch it we leave them there as reference implementations quill being the technical one and the design being for other wallets to learn from if if that's a value so there was some user research done with that as well and yeah I think we still have some time for questions we've got another yep we go question up the front thank you so much this is amazing um I'm just learning about BLS so don't mind if my question is too naive but with developments like ZK evm on layer twos um for Signature aggregations uh and atomicity like I can basically do like as you showed like approve and then transfer like bunch of things what do you think about like recursive proofs uh so if I've I I have like multiple transactions I have each proof and I take them and just submit recursive proofs so in that case how like how do we think about developments in ZK evm and BLS going to get I'm going to yeah I think um and you might have some fastness two James um I think we haven't really fully looked into what it's going to look like but we think um this wallet PLS wall ecosystem would work in any evm compatible system and so we might be able to even reduce some of the data that needs to be proved or run over in those eke evm setups but I we haven't done a ton of experimentation yet but there is the possibility that it will help at South China that's our time thank you thanks everyone [Applause] [Music] [Applause] all right thank you so much for that next up is a talk by Patrick who claims to be an intern at infuria and in the past has been an assistant professor at many universities uh please welcome Patrick for his talk on validating Bridges Roll-Ups and plasmas thank you