BLS Signature Aggregation - level up wallets with this one weird trick / James Zaki

EthPrague 2022 · June 2022 · 21:03

James Zaki shows how BLS signature aggregation can level up wallets at ETHPrague 2022. Layer 2 rollups already lower gas costs for transactions, and he explains how the properties of BLS signatures push those costs down further. He introduces the BLS Wallet project, developed within the Ethereum Foundation under the Privacy and Scaling Explorations umbrella.

Speakers

Topics

From EthPrague 2022, hosted by ETHPrague.

Transcript

foreign all right so yeah level up wallets with this one weird trick uh l1s will hate you l0 will love you um let's go so yeah the project is called BLS wallet and it's part of the privacy and scaling Explorations group within the ethereum foundation if the yep cool so the QR code's there you can look more um and I'll shout out to that at the end as well uh this is the team

um we've got uh yeah four developers at the moment we've recently hired two more and um yes just expanding more so in terms of bringing this technology out into um into the ecosystem but I kind of like to start with you know why we're doing this um why we you know working on this project and what do we hope to achieve and for that I start with sort of this graph and looking at feasible applications that use blockchain with respect to transaction costs so when you have layer one costs of like whatever tens or hundreds of dollars say per transactions depending on the time only so many applications are actually feasible and will sustain themselves and solve problems at that price point with Roll-Ups we can go a little bit further and we can have more applications but

still we're not really reaching you know those really lower levels yet on top of that if you increase usability and have um more people able to use the technology then you can increase the impact that this technology can have on the world or in again specific applications that use it so this is roughly what we see at the top end you've got defrost running some hyped up nft drops everyone's just scrambling to pay for the transaction for them they consider it worth their while and projects are existing in this space doing those kinds of things high value acid transfers as well work on L1 Roll-Ups let you get more casual gaming so people can spend five ten twenty dollars or you know tens um under ten dollars a transaction and

and do casual gaming and that makes sense at that point but we kind of want to go here so the BLS wallet applies to evm Roll-Ups and it reduces the cost even further and then we can start to Target things like microfinance for developing economies there is an application that I know of that is doing that not with our technology but they've just spun up their own blockchain because it's cheaper and that's on the unfortunate reality of it they're you know they may compromise on security just to have a feasible application that solves their problem so I'm always like reminding myself of this to say you know what are we trying to achieve and that's to bring yeah these solutions to effectively L1 ethereum rolled up so what have we achieved so far again staying a bit high level this isn't actually from L2 info it's just a

representation of it um but if you've got something like optimism and arbitrim getting like 30 40 cents a transaction um the the BLS wallet which combines both the signature aggregation as well as some parameter deduplication you can have some significant savings that brings it down to something like this so this could be in terms of an application of a lot of the same types of transactions you can actually get a lot of deduplication of parameters but also in reducing signatures that get written to L1 but I will go into a bit of details Now by virtual of it being a smart contract wallet I just sort of incidentally added these other things which for me when I started this a year and a half ago was just sort of hacking

away at a smart contract that Barry was saying oh we want to do this savings and I started that with the BLS signature scheme but I thought well it's a smart contract well I can add a few more things and and what that introduces now is sort of gasless transactions account recovery upgradability and this multi-action but we'll see more of that later account abstraction is spoken about by vitalikin 4337 and we're working on like just communicating with them on the V2 of 4337 and how it will include BLS signatures so sort of starting with what's pragmatic what what I can get out there now and then moving towards standards and bringing those in later so let's just quickly go down the origin of this and it's going to Prior work all the way down so you know I'm always building on the shoulders of giants so starting here was actually

relatively recent in history I'll say that the um I'm going to send it wrong Bonnie Lynn and uhm they wrote this paper about um yeah pairing crypto cryptography based signature scheme which is used for uh ethereum phase zero deposits but the key attribute we want from it um which is what makes us pay less gas is the signature aggregation and just to sort of go into how that or why that saves US money uh trans or saves us gas is that um L2 is right not only the state um the new state to L1 but also writes the all the transactions that progress that state so for every transaction you have a corresponding ecdsa signature as well so that's that's a lot of data what

signature aggregation does um well specifically the BLS signature scheme permits is that instead of having every transaction with this corresponding signature you can just aggregate it and it will take the same amount of space as one signature and you can still verify all of the transactions so imagine if you've got 30 transactions you can compress the signature to one and have one thirtieth of the signatures written to L1 therefore that's the saving in terms of signatures this was implemented in the Hubble project but that was a erc20 focused Network so it was its own roll-up effectively and it wasn't evm compatible but it but it was able to use that and they wrote some libraries that I've been

able to use and bring into this project called BLS wallet so we'll get the QR codes again at the end but yeah that's when that started and uh yeah so I started with the smart contracts then we've implemented an aggregation service so that's something that's hosted that will take transactions and do the aggregation for you and sending that to l2s or evm l2s the uh client module that we'll be getting into wallets and then we have a prototype extension that we call quill that just shows an example of a wallet using the client module so this is like I said that's um yeah reducing the L2 data that gets written to L1 and that's both via signature aggregation but also then parameter

deduplication is what I've implemented but there's um I think currently l2s do something or if they use kind of like zlip compression optimism and arbitrim I think are looking to things like that for what I did we had 31 transactions and these were the results this was someone who who knew sort of more about the block structure of arbitrim and they were able to measure this for us so that's where the the results are for that and I am just skipping along so I can get to the oh yeah so the layout of it of the components is like this we have the Prototype extension inside the browser at the moment but that could be any wallet um it uses the client module that does the signing of the um yeah the BLS signatures we are hosting our own aggregator at the moment

and that allows you to send transactions or have multiple wallets send transactions to this aggregator which periodically can effectively batch them together and aggregate the signature into one so you get that's how you get those savings and then it submits it to L2 when you have something like gasless transactions you can effectively reward the aggregator for submitting the transaction for you and on chain we've got the verification Gateway that checks the um yeah checks the signature and the corresponding transactions and then can effectively execute them with each of the wallets uh so kind of like I just said the DAP will create an operation which contains multiple actions to say we want to do something like a proven transfer or a proven swap or whatever we want to do a set of actions that are executed

atomically as one operation so that's quite a handy ux feature I think that is then sent uh yeah the client then receives that in their wallet um it signs the operation and and you know many other wallets are doing the same thing those get aggregated together and uh sent yeah to the aggregator that bundles it that bundle is then sent um to our smart contracts the expansion is what we had for the parameters and then the signature verification calls each of the wallets with their corresponding operations obviously in that case the the wallets and the verification Gateway are kind of paired in that sense the verification Gateway will be is getting audited pretty much this week or next week uh yeah and then

yeah in any actions are fed back to the DAP so hopefully this video works oh so they've put the PDFs here I sent the full thing great because I specifically send the PDF well I'm a line of code no I can't actually so basically um what we would have seen is um I think he goes from scratch so he installs it the uh and again the Link's not showing the color so around there it says BLS wallet client it's really disappointing so now my Talk's gonna be five minutes early so please prepare a bunch of questions because there's going to be five extra minutes to fill or we go for wine early um so basically you can install this

client module and uh you'll have uh yeah npm install it you can connect it to your web3 provider in the client and then we'll expand upon the signing part of it but it's uh wallet.s I should be pointing to the screen uh well DOT sign will expand that in the next one uh here you can have client-side aggregation so if it makes sense for you to combine multiple operations you can do that here with multiple bundles and then this part here is uh sending basically creating an aggregator and sending the bundle to the aggregator to be put together with other user wallet operations and then aggregated so just in summary connect the Wallet create and sign a bundle of operations

you can aggregate locally if you like and then you send it to the aggregator to submit or to aggregate with others and then submit for you and that's when you get all the savings so this is expanding out the bundle this is what it is so you just call wallet DOT sign you pass it the wallet nonce because it's a smart contract wallet um we did have a chat about the nonce with um the gas station network people who are doing uh who initially wrote four three three seven um and for our case whereas we are assuming and incrementing nonce which is not ideal because nonsense can take you know there's different ways of implementing knots um to have uniqueness um but yeah consecutive nonsense are what we're using for now um and these two actions were the two

examples that he showed basically it was a live demo on video um of uh adapt that he'd written the cortic had written that doesn't approve and then a swap as one because again right now the ux is just hideous where you have to connect um sorry perform one operation and then perform another and you have to wait for that so this sort of gets rid of that problem so where to from here we have again the top row is what we had but what we're doing is talking to various wallets and to get them to have the client module in there there's existing there's other l2s that are basically Forks of ethereum that are interested in doing this so for their own reasons they're like jumping ahead to do this we spoke with um uh arbitrim specifically but I

believe optimism as well is Keen to get this code into their nodes because it makes sense for them because anything they can compress and reduce they're just reducing the cost on L1 to quote I've I forgot his name who um yeah the guy who talks about arbitrim he had said if metamask were to have this on a Tuesday they would have it the aggregator code in there on a Wednesday like once BLS is in wallets it's just it becomes a no-brainer for it to to work because everyone's paying less more users more feasible applications everything just grows from you know the right direction from from people actually wanting to use it we spoke with Nosa safe who have their own smart contract wallet and they had a suggestion that their wallets allow you to

um highlight a a trusted module that trusted module could be our verification Gateway so that's these are just ways we're seeing our pieces go out and and get used by whomever it makes sense to use so it would be um again evm Roll-Ups and you know if and when or when zika evm's out there this can perhaps be parts of it go in there as well so we are oh yeah so so we've created this name just calling it the web 3 well so the idea is that we want to provide sort of pure resources that people can use and and leverage and you know you know have some open conversations with different ecosystem Partners um or people in the ecosystem building um components of it um we've further BLS wallet we've

improved the dev docs um we're defining more issues in our repos um and yeah good first issues and whatnot um because our contracts are upgradable we are looking at the standards perhaps we're looking at the standards such as 4337 but also any other wallet standards or or other paradigms that you know or security improvements or feature improvements we can upgrade the wallets so this is I can actually go into this a little bit because I now know I have a bit of time um the verification Gateway will be a single audited thing that everyone will make peace with and understand that that is solid and checked from all angles when you interact with it you get your smart contract wallet created with

create two so you can you can know the address in advance and if you wish to use a different verification Gateway say in the future a new one's created that has more features or or will we detect a problem and we fix it we'll deploy that audited contract as verification Gateway two and individuals can choose to point their um that or refer to the trusted Gateway is no longer being the first one but then being the second one so it's in the wallets control to choose if and when they point to the new one similarly the wallet smart contract is using the transparent proxy method the library's from open Zeppelin and similarly they can choose to upgrade uh their implementation at their discretion so

which is actually um yeah quite good but but in terms of writing this code you have to be very careful to assume that both parts of your thing can change and how do you keep the verification Gateway pure if people can change their own wallet implementation so that was the cause of a couple of little bugs that were picked up and that's before audit so hopefully the audit doesn't find anything but we kind of hope they do if there is something else wrong with it and again on top of the um yeah just repeating all the features we've got bla signal scheme gasless transactions account recovery upgradability and then multi-action this is all ready now we've got our own Discord there so please jump in ask us questions uh jump to the repo

check it out have a go at using it if you like um yeah we're here to support you we hope other wallets will be coming in soon but there's also another initiative around ethereum wallets that we can start talking uh that we are talking to wallets through and also some direct contact with wallets and again this is part one of the projects within the privacy and scaling Explorations group and um this is the one I would say it's the one scaling project but a lot of the others are around zero knowledge proofs um yeah applications of those projects as well so they're doing some interesting stuff there I think there's also the if you've not seen already in the sponsors area there's a quadratic funding project which is one of these as well which is part of PSE

and oh that's the last slide thank you very much [Applause] wow wow that's a good thing yeah wow wow wow it's true it's a trick you said it would be a trick has anyone got any questions yeah one here in the middle has anyone not got any questions hi I'm Thomas from Minerva wallet uh maybe we talk later um yeah I come down a little that's okay camera's got to follow you so um you have their account recovery could you elaborate on this one as well so

yeah this is kind of interesting because it's usually a huge debate on how right get back you lost Keys okay yeah so the way I've implemented this is um well it looks like they've got the video there um yeah so so the way I've implementing that is just storing it was kind of a simple implementation where it just stores a hash on chain and that doesn't reveal anything so that's the idea if you've got a multi C again it's pointing to a bunch of addresses you don't want to reveal that you don't want to like if you've got a high stakes wallet you don't want to say who has the the keys to to recover your your wallet um so it's just a hash that gets stored on chain for the recovery process you have to call it from a specific address so it's part of the hash that it

generates it during recovery is using message sender so you have to let's say it's a multi-sick you'd have to have the people sign to call the recovery from function as well as I think pass something else so it might just be a salt from memory um and that just is a way to for people to not sort of look up um you know addresses from from known multi-sigs associated with you so if you you have the message sender and the um and the salt then that's the hash that's stored on chain so we kind of we don't do the the multi-signature thing we just say if you're calling it from something that has multi-sig behind it that's it so hopefully I just dodged the debate is it mathematically provable that you

answered his question maybe I'm not sure does anyone else have any any questions from the audience okay one over here hi I'm wondering if uh batches are like guaranteed to be Atomic or uh in order executed in order um there can be some concerns about front running some fingers no good question yeah so um the the struct is effectively a bundle and the bundles contain wallet operations or we call them user operations which is similar to 4357 terminology inside an operation is an atomic set of actions that are in order

a bundler or an aggregator or pretty much like an L2 node can Shuffle operations around if they want it makes no sense for them to shuffle your operations around because you've probably signed it in um you know consecutive nonce order for our implementation currently and yeah so that they can put things between operations but they can't put them between actions and it's it's again it's Atomic so if you um approve and I think there was a recent tweet around take back all your approvals like stop approving everything to dapps um here you'll just be approving the amount that you'll be swapping say in the example that you didn't see and then doing the swap for that amount if the

approve fails or the swap fails neither of those things have happened so if you do a swap that fails you've not left a sort of lingering um approval there so I've probably answered hopefully your question plus plus okay do we have any more questions from the floor ah here we are anything about applications products and where people are looking please unfortunately not so refer to this one so what is the time that it takes um for the bundle transaction to go in so if I want to make a swap it just takes time until you know yeah price change so yeah I'd say our

our aggregate implementation is kind of like simple at this point we haven't put much thought in optimizing too many things um The Sweet Spot will be filling up an L2 block and sort of having the period that we're always filling up L2 blocks so right now because we're it hasn't got huge use at the moment I think we wait maybe a few seconds and we say look if however many wallets have sent transactions in those seconds those get bundled together and then sent so it's just a simple delay um if we if we find that we have enough transactions to fill up a bundle or fill up a block then we just send that straight away and then the timer restarts so simple implementation for now any more questions

I guess then that's a wrap thank you very much James thank you cheers [Music]