 Invenidos and welcome, everybody. How's everyone doing today? All right. I'm Jacob Kwantomski. I'm a developer on the BLS Wallet Project. And here with me today is James Zaki, who is our 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 and a high-level overview of BLS signatures and aggregation. We're then going to cover 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. I'll move over here. Off of it. Off a little. That's OK. 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 layer 2 scaling technology. Our goal is to bring more privacy and scalability to the Ethereum blockchain system. So some of the outcomes we want to try to reach with our project and the primary one, our North Star, or here in the Southern Hemisphere, the Southern Cross, is going to be to reduce 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, which are a little difficult to see right now, we've essentially simulated running 150 ERC20 transfers, both regularly, normally on a rollup, 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. We're hoping that we can go even further than that. 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. But our team likes to limbo, and we want to see how low can we go with using some things involving address books, as well as some other indexing things to reduce that call data even lower than where it's at. We'll get into how we reduce that size in a moment. So another outcome we're looking for is to be able to improve wallets. One of the features with that is going to be account recovery. Sometimes people talk about a social recovery. So if your private 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 upgradeable 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 de-apps a lot easier to use. And so part of that is by having a baked-in multi-call, 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 de-app sponsors it instead. So that way, when users first come in to try to de-app for the first time, they don't have to go stay to an exchange to buy Ethereum so they can pay gas for transactions. So to start off, we're going to cover BLS signatures and aggregations at kind of a high level. BLS stands for Bonelin Sachem, is a pairing cryptography-based signature scheme used in the Ethereum consensus layer, Zcash, and a number of other projects. It is deterministic for a given public key and message. Validators currently are using BLS signatures, specifically on the BLS-12381 curve, to sign messages on the consensus layer. And then inside of the EVM execution layer, we have access to the BN-254 curve via EIP-197 that allows us to, which we use in BLS wallet, for both signing and then verifying on-chain the transactions. We're hoping in the future, via newer EIP, that we will be able to actually move to the beacon chain curve for more security and for better access to frameworks that the beacon chain is using to improve the signatures. But the most important thing for us is signature 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. And this is really good for reducing the data that we roll up into an L1, because normally when a roll-up 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 ECDSA 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. If you're interested in learning a bit more about the underlying, oh, pairing cryptography, 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 DF usage, you're going to have a browser that's going to have an 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 de-separate operations and merge them all together into one and submit them to an L2 node, which then will execute against our 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 bundle of operations with one aggregated signature. Then the bundler 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 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 wallet and that is then executed against the actual underlying DF code. So the first feature we're going to dive into is the multicoller action for this. So this is a library that our teammate, Andrew, helped write. If you want to try it out, you can MPM install BLS dash wallets dash clients. Still keeping that edge of that stage. 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 nonce. 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. Inside of that, you can specify an F value as part of that, the contract you're 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 DEX. And instead of it having to be two separate transactions, we can just merge it into one via that format. Using, building on top of this, we've built a prototype browser extension wallet called Quill. And, whoop, too fast, cool. Called Quill with Andrew and Katuk. And, whoop, 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 approve. 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. If you wanna learn more about how we have this set up and how you can integrate the DApp into it right now, you can find out more at the link below in our GitHub repo on how to integrate that in. So, next we'll get into sponsored 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 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 can be funded for free gas basically. And so then that aggregator proxy will add that payment bundle in there and then submit it to the normal aggregator which requires a fee. And this allows for us to have those gasless transactions. Our teammate John has built a very cool demo using a scaffoldeth for the scaffoldeth community which is a single pool dex. And as you can see here, it's a single pool dex with a swap. 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 a free transaction. You can find out more at the GitHub repo below and it also is deployed at single pool dex reactapp.versil.app. We're also looking into doing this directly via a contract. The way the aggregator currently works is when it receives a bundle, it's going to actually introspect and look at whether when it simulates 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 that's going to submit to layer two. 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 aggregator will get paid. 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 profit and be able to 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 mem pool going on top. We still have more research to be done to figure this out but we believe it should be 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 the slides have been a bit often we've just lost our speaking notes, but okay. Yep, so with recovery, it's kind of catastrophic with an EOA 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. Yep, we've got the notes now. Behind the timer. Yeah, so with a recovery hash it just consists of the address that you're going to trust to call the recovery function and the hash of the wallet, the wallet's public key that you're addressing and some salt so that an attacker can't actually deduce your recovery address or the wallet that we'll call that. So when you do call recover, you pass in those parameters and you are the caller itself then you can immediately reset your BLS key and yes, basically stop the attacker who may have attempted to 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 in that someone's trying to set something that you didn't, you can intercept it with this. Take advantage of 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 Web2 usability experience but they actually have Web3 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 suggest to 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 the private key to the extension key rather than the one in the browser so that one's 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 rollups and we wanted to I don't know the slides here so yeah I wanted to leverage account abstraction which was at the protocol layer first so that was EIP 2938 with that we realized it 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. 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 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 some of the parameters are the same except for the recipient and in that case you can effectively yeah, deduplicate parameters there you've got to ignore that screen there we go yeah some of the wallet features we then focused on were as Jake described sponsored transactions, multi-action recoverability and upgradeability and then we heard about EIP 4337 to start to gain some interest and popularity 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 look towards being compatible with 4337 so that's where we are now where to next, we still focusing on aggregating signatures for the lowest cost transactions on layer 2 we will be focusing oh, my slide's moving around yeah, still focusing on aggregating signatures and then we are working on being 4337 compatible one of our colleagues is almost there with that and I noticed that drawer in the background so he's working on 4337 what I should explain, yeah, 4337 is doing account abstraction on-chain so they've got a basically a smart contract template for that and a structure for how that will work regarding paying gas as well the way we originally did 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 alt mem pool that 4337 proposes so we can do either of those depending on what the DAP wants further optimizations the 4337 user operation contains 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 smaller data sent in for the larger public keys and also doing things like floating points if a bundle has a lot of variables that are actually within a specific range we don't need to pass in a UN 256-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 a say a refactored phase we want to bring some of the stuff we have in our current wallet basically into modules so we may consider using save for that and some of the examples in 4337 and then we will inherently benefit from 4844 which is yet towards dank charting so when we take a step back what we're doing is lowering the transaction costs on layer 2 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 like to sort of visualize it like this on the x-axis we've got transaction costs and we have a lot of DeFi things going on and that works on layer 1 even if it's during a busy time and there's high gas costs a high value asset transfer is worth it you will pay $100 a transaction to move something of significant value similar if there's a hyped up NFT drop people will spend the gas to do it but that's not everyone that's kind of I would say a very small set of the population with rollups you can get cheaper transactions towards tens of cents or less and then you can casual gaming it 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 with EVM rollups adding the BLS signature scheme gives you some savings and obviously all the other things that reduce the layer 2 transaction cost will open up the applications towards microfinancing developing economies so this is where we are now we're live on Arbitrum Nitro Geoli testnet and we're going to be deploying to Arbitrum and Optimism after some order fixes and other layer 2s that EVM compatible or equivalent we'll seek to do wallet basically get this into wallets currently and to encourage dApps to use it so we'll first target applications where this will have a direct benefit to help price out users and of course support regular web 3 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 haven't integrated and of course things just get even better when 4844 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 3 solutions due to the cost per transaction but we hope that once that joins in that we will get these real world problems being solved by web 3 solutions and yeah we're just sort of looking forward to that time because I think that's when we'll get again a resurgence of a lot of activity we'll have a lot of users we'll actually be able to benefit from the primitives that we're building that everyone's building in the community so this is us with a web BLS wallet if you want to learn more check it out in browser demo it's at BLSwallet.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 web 3 well and yeah are there any questions? OK I just have a question yeah OK again congratulations for the project it's going to be very useful to the community my question is when you create the wallet and make these changes you're proposing that is great you need also to update the clients because for instance to support the multiple transactions you want to sign it it's an amazing idea are you talking to the I don't know with an execution layer clients to help them to adapt their clients yeah how are being those conversations absolutely yeah so quite a while ago we started that journey we started contacting I think there was even end of last year 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 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 4337 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 they 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 basically a reference browser wallet we've also gone through a large design I guess yeah a large design a set of design to look at what future wallets can look like so these can form a bit of a you know a bit of design helpful wallets as well oh yeah okay yeah with the clients like a geth or nibbles are you talking to those teams sorry for a question no no that's okay no the diagram maybe shows it better well this is a bit slow yeah so the the nodes don't need to change so the clients that they say the aggregators here we go this one so at the moment we have a dedicated server that will do the bundling we've already had conversations with one particular layer 2 about this to say that they would want to integrate this so for us that's been not been the barrier we've heard great enthusiasm from the layer 2 networks to say as soon as wallets are doing this they're gonna put it in like the nodes have a vested interest to reduce their costs so 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 the 457 solution is a little different because I think it's an alternative mempool but yeah 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 two questions one is if we're exploring kind of EIP3 437 is there anything specific we should be keeping in mind with 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's that actually implemented and like executed on the actual layer yeah I can cover for the BLS signatures both the current I think it's eth infantilism is the repo 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 for that yeah and regarding what's required on your side it would just be the signing like the client side would just need to sign the BLS signature for that part and then depending on which way you go directly or via 437 it would just be interacting with the contract wallets that it deploys 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 it's basically an array of actions inside a user operation and I think 437's done the same thing it's the same format that you can specify a set of actions I use a so yeah it's kind of a cascaded function so that I can call 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 into 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 is nice that Solidity has that now yep who do you anticipate running these aggregator proxies? we hope that that gets merged into the nodes into the layer two nodes yeah to start out we would expect like a DApp would probably run its own aggregator proxy just to kind of like boost trap the process eventually it could potentially be like a larger swath of say like nodes having compatibility with that we also think that 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 that's when the actual like payment substitution 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 usability testing? seems like wallets right now don't pay very much attention to the user experience yeah good question what are users seeing, what are they clicking on? yeah definitely that's a very good question so firstly that Quilt isn't we don't want to release Quilt 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 are there so if you go to our Discord I think 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 Quilt but because we don't want to necessarily launch it we leave them there as reference implementations Quilt being the technical one and the design being for other wallets to learn from 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, yeah we've got a question at the front thank you so much this is amazing 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 for signature aggregations and atomicity like I can basically do like as you showed like approve and then transfer like a bunch of things what do you think about like recursive proofs so if 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 are going to get yeah I think and you might have a thought on this too James I think we haven't really fully looked into what it's going to look like but we think this wallet BLS wallet 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 ZK EVM setups but we haven't done a ton of experimentation yet to see that I think but there is the possibility that it will help I think that's our time that's our time thank you thanks everyone alright thank you so much for that next up is a talk by Patrick who claims to be an intern at Infura and in the past has been an assistant professor at many universities please welcome Patrick for his talk on validating bridges, roll-ups and plasmas