BLS wallet, Layer 2 smart contract wallet + transaction aggregation - present by Jake Caban-Tomski

Transcript

hey everyone and welcome uh this is jake kevon tomski and today i'm going to be talking about a bls wallet which is a layer 2 smart contract wallet that includes a novel way of trans uh aggregating transactions let's go ahead and dive in um for the bs wallet team you have myself up there in the top left corner jake we also have our team lead james sackey and we have two other developers katuk and andrew working on the project as well before we go too far into uh the what and how of what bls wallet is let's go into why

we are doing this project so as everyone knows gas costs are currently uh can be historically a problem on the normal l1 chains and even potentially sometimes on rollups making it so that certain um kind of decentralized apps or other opportunities or protocols or things people want to do become more difficult to do with those with those higher transaction costs users tend to have a poor experience when they're attempting to interact with those the apps when there are those higher transaction costs versus using something like a rollup where you're going to have the kind of the faster uh transactions and the lower transaction costs which makes the

usability of a lot of more decentralized apps uh possible and so we're kind of in a world right now where there have been proven out some really good solutions for kind of people doing high value asset transfers people doing kind of larger defy apps or things involving kind of you know big ticket nfts with those higher transaction costs um as we move more into rollups and other like layer twos we've been seeing the ability of certain casual games um and some other applications kind of to open up within that but we think that by getting those transaction costs even lower we can do even better

and so using those evm roll-ups and bls signatures which we'll go into a little bit more later we think we can open up things such as microfinance for developing economies and potentially even uh d apps that we have never seen before and potentially other applications by having those very very low transaction costs there is a significant portion of the world that lives on dollars a day and so the kind of gold standard we would love to hit in the future would be something like a penny or less per transaction and by being able to kind of reach that goal it just opens up a whole world of different things we can all build

so let's go into what bls wallet is and some of the kind of technology underpinning all of it it is cheap contract interaction at the end of the day um these are numbers taken from april of 2022 from l2fs.info um and as you can see here and kind of this first column is the cost of sending a single token on these different networks with the um arbitrary optimism being layer 2 rollups being significantly cheaper than the ethereum l1 for this and we have been able to get that cost even lower using a compressed uh bls transaction bundle uh reducing that by almost

uh down to 25 percent of what the original cost is uh we'll go into some more details on the gas for that and how that happened uh in a bit and in addition because bls wallet is a layer 2 smart contract wallet we have this novel bls singer scheme we have the ability to do gasless transactions using that we have all the standard account recovery uh functionality that you'd expect from a smart contract wallet it can be upgraded to have new functionality and these bls bundles allow us to do multi-action transactions which we'll demonstrate later in a little demo and these are all things that are mentioned um by vitalik and eip-4337 which goes into kind of account

abstraction so where did bls wallet come from well as with many other projects we are standing on the shoulder of diet giants and a lot of previous work that others at the privacy and scaling explorations group have done to allow us to build this very cool wallet um to start we have bls signatures which are bone lin and i probably butchered that last one uh signatures which is a pairing cryptography based signature scheme that was done in uh first illustrated in 2002 um it is actually used for the ethereum phase zero deposits the beacon chain and a number of other projects um for specific details the post merge

consensus layer is using a newer bls 12 381 curve for that consensus layer and currently on the execution layer what we are using is the bn 254 curve um which we are able to use thanks to eip 197 which includes a comparing cryptography pre-compile located at address um 0x8 and so um these uh signatures have a number of cool things for them one of which being deterministic output for a signature given the same message in public key but what we actually really like and want to take advantage of is going to be

signature aggregation so what why we want to use the signature aggregation is normally when you write transactions 2 and l2 you have to include all of the ecdsa signatures for each of those transactions in the actual roll of data you push to that l1 if we were able to somehow reduce that we could save on the actual overhead in space and then using something like multi-call as far as the kind of transaction bundling does not really allow us to reach the scale or thresholds we want to for a kind of multi-wallet public key batching to try and drive those transaction costs even lower so with that um what does this bls signature

aggregation kind of look like at a high level well this is kind of a very nice thing but you can think of each of these shapes as being a separate transaction and then the kind of envelope around them being the signature for that transaction and so what you're able to actually do with these bls signature aggregations is you can take many different signed messages and merge the signatures into one signature covering all of those transactions but that signature just takes up the same space as a single signature was that does so you're essentially compressing that signature while not still being able to keep um all of the verification for that and what and who signed it in place

what this looks like in a bit more advanced practice which this article on cryptology i would highly recommend if you want a kind of a good high level overview of how those build signatures work it's like this where essentially those uh that compressed signature as you see on the right is made for all of these different messages and signed they are all hashed into the kind of pairing friendly um domain uh that we need to have for verifying and then finally we check to make sure when we are verifying a given public key against those messages that all that comes out valid and so we're able to essentially have these large bundles of messages or in our case transactions that we can

verify using that compressed signature and then the public keys for each of those smart contract wallets so the start of this project actually started with another project called the hubble project which was a pst pse excuse me layer two which was focused specifically on um very very cheap erc20 token transfers and so those would all be done off l1 and done in a merkle dual merkle tree system which maintained both the kind of account keys and the signature uh and the balances for the tokens in these two merkle trees but this system did not have any general evm

compatibility so it was only able to do very specific things with kind of token transfers deposits and withdrawals but the bls technology that was used in there which allows for verifying bls signatures on chain as part of the rollback mechanism for that hubble optimistic roll-up gives us actually the bls signature libraries and verification for signing and for verification that we use in the bls uh wallet project today and so we spun up uh bls wallet or rather james did in late 21 as kind of a way that we could take this hubble bls kind of tech that's usable in the evm

and have it work um just for any evm general transactions and so what this project contains involves are a number of core kind of components which include the smart contracts for the smart contract wallet and the signature verification for those transaction bundles a aggregation server which runs on top of an l2 and we'll take these um bls sign transactions and merge them all together so that we can uh kind of uh reduce the um amount of transactions responding to that l2 a client module you can use to integrate with those two components the smart

contracts and aggregation service and a prototype browser extension called quill which allows you to uh kind of try this out and use this in a standard ethereum d app which we'll go into a quick demo of later so when we have less l2 transaction data we save on l1 gas and so once again the main ways to emphasize we're doing this is we're taking all of those different signatures per transaction and aggregating them into one and then we also can do some things uh with some more common use cases like say a token airdrop to try to do some additional transaction data compression to save on what is being kind of rolled up into l1 from that layer 2 roll up

so to dive into some of those gas savings we kind of saw earlier with the token transfer this uh test stock goes specifically over a test run we did on the arbitrary test net um going over the gas costs with basically just sending a token transfer normally versus doing a deduped 31 token transfer um using our expander kind of contract to reduce that transaction data and what the actual costs were all these the different layers there with the compressed signatures this top row here is going to be all of the bls stats and the bottom was going to be the normal ones just for the normal token transfers there are a couple of interesting things

to note here as to why the costs are different so you can see from bls we're using less call data in terms of the units used um you can see here that we're actually using more computation units than the normal one would use this is not as big of an issue as it would be on l1 because the computation costs on most l2s and roll-ups is very cheap because the entire network does not need to execute all of those all the time and so the computation gas is generally much much cheaper than it would be and you can see here over on the l2 computation cost that is higher than for that transfer where we actually and then you can also see here there's one storage unit used

um this is uh most likely from the nonce in the smart contract wallet being increased to show that that transaction happened in increment the nonce prevent replay attacks you can look here for the call data costs though significantly different so those bls transactions take up much less call data than a normal transaction would and that is due to that signature aggregation and also due to just having uh less or having all those transactions aggregated together into one versus having them as being separate ones uh we remember that storage cost here so just minor increment from that um what we get at the end though is the difference between doing those 31 transfers individually and just doing

that one bls kind of bundle in that expander contract is uh 25 roughly uh reduction in gas costs so um that's pretty nice to be able to save on that um versus doing all those um separately and not having that signature compressed so as you can kind of see here a lot of gas savings being able to use this kind of bls transaction format and that aggregation without too much cost overhead from the smart contract wallet so for how this is configured today um there's kind of a couple different layers of our stack that can be brought in

we have our extension prototype which consumes our client module which it uses to talk to the browser d app as well as talk to our backend aggregator service that aggregator talks to a l2 node and submits all of those bundled transactions then inside of the actual evm we have a thing we call the verification gateway that processes um all of those bls assigned transactions and then executes them once they are verified against those smart contract bls wallets at the very end to actually uh run those transactions as far as scaling how these integrations kind of work out a bit more in depth is uh we have that

d-app and it's going to create a operation which has one or more actions inside of it you can think of each of these actions as actually being a separate transaction and we'll go into a bit more detail on what that uh data looks like inside of there um once that the episode has what it wants to do there it can send that to the actual uh wallet extension which has that client module inside and that will take care of the actual signing of those different um operations that need to be sent out those are then submitted to uh our server or uh yeah server for the actual aggregation and compression of those different operations into a single bundle of operations with the aggregated

signature one thing to note that's kind of important here is that these signed operations do not have to be from the same kind of person or wallet they can all be separate and from different people so i could actually have say 10 different bls wallets from different people all submitting their transactions to this aggregation point and having them all merged into one single bundle that will execute for all of those people so then once we have that aggregated bundle of operations that's when we actually submit it into the l2 evm or into that rollup or layer 2 system one thing that can happen is expansion where we have uh for that example that airdrop where there's some common things

people might want to do to save a little bit more on that gas cost for that data compression but then we dive into the core of the bls wallet system and so for that there's the actual signature verification that happens on each of those operations and the actions within and once those are signed we then perform that operation through that bls contract wallet which is going to actually call the underlying transaction here once that's completed and so through that we're able to take this one kind of bundled operation of operations do one l2 transaction but then execute many uh different kind of uh contract interactions through those smart contract wallets um here in the evm

so for the next part of this we're gonna actually see in action with a quick demo we're going to do using uh katuk's demo app he made there's also another one um andrew made that you can look at blow involving kind of a billboard rent and you can see kind of a more detailed inaction demo of all of this at that backup link below all right so let's go ahead and go over a full stack demo of the bls wallet and how it works uh for the i said we're using uh this erc20 demo app here to kind of show that off um up here you can see i have the quill browser extension uh installed here which comes with a nice little kind of basic built-in page where we can see all

of our different wallets here and some other kind of details and settings we won't go into that in depth but mainly to know i just have a wallet here at this address once again going back into here i would connect just like i would with any other kind of d app right now the wallet prototype will just kind of auto accept and do everything that it is told to do so you won't have any sort of select accounts or confirmation that you want to connect we plan in the future on adding that in to make it a little bit more like an existing kind of extension-based wallet so there's my account connected in and so as you can see here i've already kind of done some stuff in the past

in the background behind all of this in addition to having the kind of extension and the wallet running we also have one moment um two main things um that we'll come back to and look at um one is we have this aggregator service this is the one that is taking these transaction bundles from the wallet and is uh submitting merging them together and submitting them into that l2 and then simulating kind of our layer two here we just have a normal hard hat node which will go through some of the contract calls kind of as we run these transactions and so to start let's just do a very simple one which is just meant some more tokens so we'll go ahead and click that here

if we look in the background as to what is being submitted in we can kind of see up here in the send transaction right here there was that token mint that i sent and that's just using the standard rpc call formats we have there here you can see it looking for that bundle and it eventually will find it when it gets that bundle receipt and if we go back into the app by now we should have seen oops pardon me yep that token balance increase so um we ran to that on the back end what actually has happened with that is we have the actual bundle added here um

and then we're gonna have down here the actual submission attempt uh to actually submit that as that l2 transaction there um and then once that's confirmed we get that message out there and then we can see here actually querying for the receipt of that bundle being completed up here in the actual logs we can see some communication going on with the verification gateway which we talked about earlier as being that kind of bls signing gateway to get some details this aggregator utilities perform sequence is actually this aggregator here checking to make sure that that bundle it received will actually work and most importantly right now this aggregator is running in a mode

where it is free to be able to send transactions into in more normal kind of main net production situations we would expect that it would want to be paid a fee in order to run those transactions and so this performed sequence check actually will make sure that the aggregator instance is paid when it after or simulated running a transaction see that it will succeed and that is paid after that transaction is complete to make sure that it actually wants to run it and then finally we have the call to the verification gateway process bundle and that is what's taking that actual bundle and submitting it uh to the individual bls wallets for them to actually execute the calls in

the underlying transaction um and here we can see we just made one call out to mint those tokens very cool so that kind of shows a very simple example but the more interesting one we can get into is where you actually have multiple actions happen at once um which we have with this bundle up down here unfortunately uh their poll portion of it is not working for this demo so we're just going to go ahead and do the bundled mint and approve uh instead and just have those two kind of things function so to see what this actually looks like under the covers if we go to the code for this we kind of do the same thing we would normally do for any um ethers erc20 or you know

transaction but instead of actually running the transaction we're going to just do a populate then in the actual window.ethereum call to send instead of just sending one transaction through we're actually going to send two in an array and what the extension will do under the covers is take both of those and convert them into that bundle format for use for something to that aggregator back there so let's go ahead and run that real quick we can see here in the background that when we submit that transaction it actually contains both of those transactions with our tune from and data inside of here that we're going into so

in that way you can essentially have a multi-action occur where only one transaction is going to go out and sure enough the token balance has increased and if we go back into once again our aggregator and that command line we can see that we had the bundle added make sure that's not the original one it sure is not um we are waiting a little bit and we're checking for that bundle receipt and then finally we're submitting that on chain and we actually go on chain though so we can see once again there is that uh kind of perform sequence to check the bundle there um we process that bundle but then you can see there are multiple um eth calls that are going out for that call because we are processing more than one in that

single bundle um once again out to that erc20 contract for the mint and approve so uh that is kind of showing what you can do with just even though this is only one transaction on chain there is still a bunch of uh you can still do multiple calls and multiple actions outside of that cool uh and with that we'll go ahead and go back and talk some more about uh why you might want to use a bls wallet oh sorry we're gonna go into more details about how to use the vls wallet client module and then some cases why you might want to use this in your d-app wallet or other application

all right so we've just seen the kind of bls wallet and used in the browser so let's talk about how you can actually use this code inside of your own project the main thing we have is a npm module called bls wallets wallet clients which kind of abstracts and takes care of a number of operations involving interacting with that smart contract wallet and with the aggregator service so in this example we are essentially connecting to our wallets we're going to create a bundle um you can aggregate multiple bundles together if you need to on the client side or in another instance and then you're going to send to the aggregator for that so it's pretty easy to set up

and so once again just kind of connect to that wallet create inside the bundle of operations you can optionally aggregate them together and then we're going to send those to an aggregator instance so um kind of pretty easy to get up and running there using that client then let's dive into the actual bundle format and what it looks like and it's going to look very similar in the actual structures that you would have in solidity as well for how it's represented in the evm so we create a bundle we haul into our wallet instance and we call sign we provide a nonce for the bundle which normally we just grab that from the wallet itself and then we're going to provide a number of actions in order to kind of execute as part of that bundle um one thing to note is that in a bundle all of these

separate operations can um uh a operation in a bundle can fail and the rest of the operations will succeed however inside of the actual bundle anything that's part of this actions are going to be atomic so if one fails all of them fail which can be really useful when you're trying to kind of figure out how you want to execute different transactions so for example one reason you might want to do multiple bundles from a single client is you're okay with one operation failing but uh you want another one to kind of be separate from that so in that action we provide the f value we're going to include for that transaction the address we're going to hit and then the actual encoded function of what we want to do in this case this is an example kind of

using a erc20 contract to approve and swap in a single transaction um and so here we have the actual encoded approved function for that erc20 for the dex contract and then here's the actual swap running inside of just that one single bundle so why should you use bls wallet so we've kind of gone over what it looks like when it's used uh some high level stuff about the project and then how you could consume it in uh kind of javascript typescript in your own application but they're kind of three main use cases we see for where people could take

advantage of bls wallet to save on those transaction gas costs as well as get some other nice features that you get with a smart contract wallet for decentralized apps and kind of uh wallets with bls wallet in them the biggest thing you're going to get is that multi-action support so anytime you have kind of users that have to go through and perform multiple transactions or kind of multiple actions within your kind of d app instead of having to do those all separately you can simply just stack them all up and do them all at once in addition there are ways that you can using this kind of bls wallet framework do cheap or even gasless transactions so

one way as we kind of show that aggregator you can subsidize at that layer using um we have a package called bls wallet aggregator proxy it allows you to wrap an existing aggregator that perhaps takes payment and modify um kind of the bundles people are sending in to add in uh transactions that would pay that aggregator you could also do even at the contract level or say you have an additional wrapper on your contract which will pay your aggregator instance or another aggregator instance um whenever someone runs a transaction on that so by doing this you can essentially uh and you might be able to add people in for this using some sort of thing like an allow list you might allow only a

certain number of transactions to start or paid for by you and so in this way you can kind of people come in and use your d app or your wallet without ever having to buy ethereum initially and transfer it in to that wallet um and it also can help incentivize people to kind of just come in and try your your app with very little risk as far as the payment goes and um one reason you might want to use bls wallet instead of a normal say gas relayer is that by using that bundling and that kind of bls signature scheme you're going to be saving on the gas costs so if you do end up subsidizing those transactions they will be cheaper than they would if you were subsidizing them via a normal gas relayer um another cool thing with the more

smart contract wall aspect of it is it's an embeddable smart wallet so you could see a situation where you could actually set up inside of the browser in your d app a um a wallet that runs for that user just kind of right in there they don't even know that they're using it there's no need to have a kind of qr code to connect someone's mobile wallet or to install an extension for them to have and as i mentioned kind of you may not need that for them to fund it as well then later if someone wants to move to a more secure wallet they can eject by swapping out the bls public key that is on that smart contract wallet to kind of have another account or device take that over if they want to with that

and then finally along with all that you get kind of some of the standard account recovery and upgradeability for that wallet as well so if someone wants to switch to a different uh better signature scheme in the future or if someone wants to upgrade their smart contract wallet to just have some additional kind of functionality or security they can do that later via that kind of those upgrade paths for that smart contract wallet if you are a layer 2 node you may want to incorporate kind of features more on the aggregator side from bls wallet to help make your layer 2 network better this main one for this is mainly just reducing your gas costs on your evm l2 by having those bundled transactions and

by helping to get rid of a lot of that signature overhead in the data you have to roll back to l1 and you get a nice little rank up on l2 fees dot info can be beating all the other networks in addition because we are taking multiple transactions and merging them into one that's going to be able to help reduce congestion if you're getting a lot of kind of traffic on that network via bundling as we've seen kind of with the recent arbitrary odyssey nft giveaway by people using a network they ended up having to postpone that until they made some other updates to their network to handle the high fees for normal usage that were happening due to people participating in the arbitrary odyssey giveaway there may have been a little bit less of

that if they've been able to do this bundled transaction format and then finally by incorporating kind of bls wallet in you can encourage the adoption of the apps and wallets which have chosen to adopt bls wallet for use there and they can just come in and instead of just using an aggregator instance they can just directly submit to your layer 2 node versus having to go through kind of more middlemen in that process so in the future we expect that the configuration options for this will actually change as i mentioned for that kind of l2 node setup instead of having an aggregator and an l2 node running separately we would have just all of that be

running inside of a standard l2 node that could bundle and all those together in addition right now we're just focusing in that browser use case but in the there's no reason why a mobile wallet would not be able to use that same smart contract wallet kind of interface to construct bls bundles and transactions and then finally right now we have our own kind of smart contract wallets but we expect that other third-party kind of contract wallets such as argent or gnosis safe would be able to use this novel kind of bls bundle transaction scheme for their own transactions with that wallet using this bls verification gateway to sign those and or sorry to verify the signature on those

transactions but then execute them through those other um smart contract wallets and so those are kind of where we see things in the future going as far as how they can be configured um as far as next steps kind of following up on everything we've covered um we've created an organization called web3 well where we're trying to get features built that wallets d-apps and l2 nodes could adopt to kind of help make the ecosystem a better place right now we're starting with just this bls wallet project some improved kind of dev and integration docs trying to have good defined issues in the repo and also as part of that we may end up

having some dedicated devs making prs into um different wallet or client repos to try to kind of like bootstrap getting that bls wallet work in um and then the last part of course is adopting and upgrading to standards as they solidify such as the account abstraction in um eip 4337 and then through groups such as the ethereum wallets group where there's been some work going into better ways that browsers can interact with wallets and d apps can kind of figure out different features that are available to them through those wallets um and so we're hoping to kind of help push some of that work forward with this web three well integration initiative

um so come quench your thirst from the web3 well that link on the left is going to be our discord server where we kind of talk about some of this stuff specifically bls wallet at the moment and then finally you can find the bls wallet github project at github.com web3 well slash bls dash wallet please come by and check out the documentation and everything for that as well and with that we will do uh questions um if you have a question and you want to submit somewhere on the privacy and scaling exploration discord server uh there's the gotta question channel and then if you did join via that

previous link on the left there the web3 well discord um for bls wallet specific questions we have a channel called bls signature comp where you can get those answered well thank you so much for stopping by and listening to this presentation