ETHWarsaw 2023: Callum Grindle, LUKSO - Building gasless dapps using universal profiles

next talk uh we have Kum grindle uh speaking about Gast of deps from lukea give him a warm welcome everyone hello can you hear me sounds good cool thanks so I hope you're all enjoying the first day of eth Wasa today it's nice to be here um yeah my name is Callum I'm a software engineer at um Luxo blockchain and that's me you didn't recognize this QR code is my link tree with links to like telegram GitHub stuff like that I'm also here in person um which is probably easier um that's my uh GitHub there which is some project pinned if you want to check that out a later date um so to just set the agenda for the talk um the talk is on building gas lless um D apps with universal profiles so to start I'll give some context on what Universal profiles are what Luxo is and just some background so we know what we're talking about um the problem which we're trying to solve um which this talk is about namely that there are transaction fees which block new users from us using blockchain technology um and then the solution so talk about how Universal profiles can solve this and then go on to talk about what you can do next um so some background on um Luxo Luxo is a new layer one evm blockchain um the idea of the blockchain is it's focused on the new creative economies so improving the user experience of blockchain Technologies um to on board the next billion users that's um that are not familiar with this technology and have not necessarily used it before before so um to achieve that we've developed a suite of um user user experience focused smart contracts and we call these uh standards LSPs which is luo standard proposal so similar to ERC ethereum request for comments but this is luo's version of that and these we think of as the the building blocks for the new creative economies so these are individual smart contract standards which you can build up in new ways to create more sophisticated smart contract applications um focused around these social and creative use cases so I added this is Turtles all the way down um this this is taken from an anecdote from at the start of Steven Hawkings book A Brief History of Time and he tells a story of a lecturer who's giving a presentation on the nature of the universe and the cosmos and someone at the back of the room puts their hand up and says um everyone knows that the the world is just riding on the back of a giant turtle and uh the lecture responds okay interesting but if that's the case what's underneath that turtle and the person responds well of course it's just Turtles all the way down and this isn't a turtle conference we're talking about blockchain here so in this case it's LSPs all the way down the idea being that we have um smart contract standards that are built on top of other smart contract standards and these combine in interesting ways to give us new um and sophisticated smart contract applications um and our sort of Flagship product is what we call Universal profiles and Universal profile is a smart contract based account um this is different to uh like a metamask um eoa key it's a full fully functioning smart contract account system that comes with um a bunch of features like you know profile pictures uh usernames all of the kind of features that we used to from a web 2 experience like Facebook and Twitter but now coming to the blockchain and actually coming from like a native um experience so the universal profile is composed of um two different smart contract standards which is lsp0 lsp0 is the face of your smart contract this is the part which has the the profile metadata um and then there a key manager and the key manager is a fully upgradeable permission system so you can have um scoped Keys which control different aspects of your Universal profile um and these two things together uh create a universal profile and to make this as easy as possible for our users um at luo we've developed our own browser extension and this is uh similar to metamask or any of the other browser extensions but this will be used uh actually to control a smart contract contract um account or the universal profile so you can see here I have the profile picture username this just looks like a web two profile but this is all coming from chain so it means when you connect to D apps with your Universal profiles all of this can be read from the smart contract and decoded and you can have a much more seamless um user friendly experience so that's uh some background of what what we're talking about and the problem we're focusing on here is that before using any decentralized applications users first need native tokens to be able to do anything on the blockchain any state change on the blockchain requires um requires paying gas fees and to pay the gas fees users need um some tokens to be able to pay for them and just to illustrate why this is an issue um just to raise this scenario um imagine you are a d developer and you want to go to market with your own new application it's a really cool application it's the best e apppp that's ever existed so you go to to Market and expect that you're going to get loads of users this is what you expect the users can see it and say hey this is cool D app I want to start using it and then they can start using it but the reality is more like this where a user can see that your DF is cool and come and try to use it but immediately they can't use it because they don't have the fees or they don't have the tokens um to be able to pay for the gas fees so they then need to go away to a centralized exchange like binance input their credit card details buy the tokens transfer them back to a wallet and only then can they actually use your application and the question I want to sort of put forward is like how many users do you think you lost in those steps between 1 and seven and I'm going to assume that it's a lot and the point being that um it's the blockchain technology isn't where limiting ourselves um just to those users who are already in the club those users who have already gone through those steps are the only ones which can actually use blockchain based applications new users who just see your application and want to start using it are immediately turned off and a blocked because they can't they can't um they don't can't pay for the gas fees so this is what we want to get back to where a user can see your application say hey this is cool I want to start playing with this and then just be able to start using [Music] it so uh well one way that we can solve this is uh using these Universal profiles it's a smart contract based account system and these can actually execute gasless transactions so using a universal profile your users can come to your D and just start playing that immediately without having to divert away to binance or some centralized exchange buy the tokens and transfer them people can immediately just start messing about with blockchain technology and the way this works is um using relay transactions so the universal profiles come with relay transactions out the box it's already ready um and works and just to illustrate the flow of how it how it sort of works under the hood is a user signs some transaction so there's some transaction or some action the user wants to perform on the blockchain it might be minting an nft it might be uploading uh like changing a profile picture on their Universal profile or sending some tokens to a friend any action any state change on the blockchain requires some gas fees to be paid so that's the action the one user wants to perform and what they can do is they're able to sign this transaction and it's signed in such a way that it can actually be relayed to a third party and that third party is then able to pay for the gas fees because the the signature and the payload was given to this third party it's the third party which is executing the transaction therefore it's the third party which pays for the gas fees and this enables a whole new use case of applications which we call transaction relay services this is just um a service which is this third party relayer this is the this is the party who is actually interacting with the blockchain to execute the transactions for the universal profile users and this works and is enabled by this function here this is called execute relay call this is a function on on the universal profile so on the user's Universal profile this is available this I mean this is just a a smart contract function so it's available for anyone to call that means that anyone is able to create a transaction relay service it's entirely open and accessible to anyone who wants to build this is they can so there's I mean there's four parameters here in this function I'm just going to focus on these two um for this it's just the signature and the payload so the payload is the content of the transaction which I talked about that's the action the user wants to perform so that's the the message that says Hey I want to Mint this nft and the signature is just that payload signed to prove that it is the user who is executing that action so to illustrate it again the user has some action they want to perform there's the payload of the transaction they package that up in such a way that it can be sent to a relay service and that's the signature so the act of signing it acts as like packaging it up into an envelope so it can then be sent on to a relay service and that relay service is then able to call this execute relay call function on the on the universal profile and that's when it gets dispatched to the blockchain and all of this is actually abstracted away from the user entirely so the user doesn't know any of this is really happening um the browser extension that we've built handles all of this signing and relaying to the to the relay service um natively and out the box so to just show you what what this would look like um this is the transaction confirmation window in our browser exension um I've just highlight here in red what we s want to look at so you see on the left there's this um terminology of a quota this is a concept which we've sort of come up with where we think that these transaction relay services will behave similarly to like a mobile phone contract or an internet service provider where you pay per month and you get some amount of data that you can use for that full month and as you go through the month you use some up so here I've used 75,000 out of 40 million gas and then it resets um at the start of the month and within the browser extension this this drop down here this is actually where you're able to select which transactions of relay service you want to use as I said anyone is able to run a transaction relay service it's entirely open and permissionless anyone can do it um but you within the browser extension the user can choose which one they want to use and you can see here the the the last option the controller key is actually disabled and that's because the user has has no tokens so the user is still able to confirm a transaction here and send a transaction even though they have no tokens available and that's only because the relay services are doing that Gas payment for you so as I said anyone is able to create these relay services to actually make them compatible with the browser extension they need to follow some sort of rule set there needs to be a common interface which all relay Services adhere to because the browser extension needs to know the correct format of the message sending to the third party relay service so it needs to have the correct API structure so as I said at the start we have H standards built on top of Standards so this is uh another standard we've developed called lsb1 15 this is the transaction relay service API so this is the standard that all transaction relay Services should meet so it's I mean it's a simple interface it's a post request to a rout execute and it Returns the transaction hash and in the body of that um payload we're just sending the address which is the universal profile address and then the transaction parameters and if you notice these four parameters inside the transaction exactly correspond to what is going to be passed inside execute relay call so here there's the ABI and the signature the ABI is just the payload again that's the content of the action the user wants to perform so the ABI is where you have the instruction to Mint this nft send this token or change this data key whatever it might be and the signature is just that message signed to prove that this is address wants to execute this task and this is all sent to the relay service and the relay service then just inputs these parameters into the execute relay call method on the universal profile so the user calls the/ execute on the transaction relay service the relay service passes that into the into the smart [Music] contract so um that's I threw quite a lot at you there so you might be thinking okay that sounds like a lot that I need to do to change in my codes to make this work um so you're thinking like what do I need to do in my D app to make it gasless and the answer is nothing all of this is handled within the browser extension there there is nothing if you want to just run your D app and benefit from um transaction relay Services you you can do um because there's nothing else that needs to be done um so for instance if you wanted to within your D app you were sending a transaction you just use the ex exact same RPC method that you would be using whether it was metamask or any of the other wallets or Universal profile browser extension so using the smart contract account system is no different to using metamask the D apps that you already have and have already built with um to be used with metamask they're entirely compatible with universal profiles except the universal profile is able to execute these transactions for free without paying any gas and know the bow extension handles all of this yeah so as I said it's all of the D apps are compatible with universal profiles and externally owned accounts without any code changes necessary so the D apps you've already are built benefit from transaction relay Services immediately without you changing anything in the D app although if you wanted to just deploy your um have your D up and benefit from the transaction relay Services which exist you would then be assuming that there is someone else somewhere running a transaction relay service with you your users can use and you might actually want to guarantee your users a gasless experience and to do that you could run your own transaction relay service which is specifically for your dup the idea being that you set aside some amount of tokens and say hey I want to set aside these tokens and see it as a kind of loss leader where you you pay for your users's uh gas in the hope that they have a much smoother experience and are then able to onboard a lot more users so it ends up being worth your time to do that if you want to run a transaction relay service for your application so if you did want to do that these these would be the steps that you'd have to to implement so the first thing is the lsp1 15 as the transaction relay service API which I showed earlier so that's the common interface that all of these transaction relay Services should should adhere to and then you would need to implement a transaction relay service um which takes those parameters received from the uh the execute endpoints from the lsp1 15 API standard and passes those parameters into the execute relay call function and this third part here this is new I haven't mentioned this before we the browser extension the universal profile browser extension actually has a custom RPC method so you can dynamically add a transaction relay service into the browser extension without having to require your users of copy and pasting links and pasting them into the browser extension back and forward which means it's a lot a lot a lot smoother and um I I'll demonstrate this in a minute so it'll probably make more sense um and it's not as complicated as it maybe seems but this is this is what it looks like where you say up adds transaction relay service you're telling the browser extension I want to add this this specific relay service um and you pass the name of it the URL which the browser extensions should call to pass on the transaction parameters and the chain IDs of the networks that your relay service works with so here is 42 which is the look on Main net and then once you do that this RPC call will trigger this uh transaction window not a transaction window sorry but this confirmation window where the user um is asked to confirm whether they want to add transaction relay service into the browser extension and they need to confirm which Universal profiles they want to add that relay service with so um that was a lot of information um I'll I've got like a video of this also kind of working and what what the user would see and you'll see it's much less than what I've shown you um but just some things to sort of uh highlight and pay attention to so you'll see that the user well this D app is a is a a universal profile name updator so it's just a simple D app with one form input the user can change the username of their Universal profile and you see the user connects with the D app the D app then is able to dynamically pull in the the profile picture and the metadata of that Universal profile straight from the smart contract itself and then we'll call this m custom RPC method to add the transaction relay service into the browser extension and we'll see the user executing a gasless transaction and that the username updates correctly so so first the user connect the universal profile and they need to select which Universal profile they want to connect with so there pulls in the metadata I enter my new username that I want to update to and hit update username and this now triggers the add custom transaction relay service RPC call um which I mentioned so this now is adding this relayer that is in the background going to execute this transaction for the user so the user now selects which relayer they want to use it in the future this this will be default the user won't have to manually select this dropdown it will default to the most the most recent one that was called with ad relay and then the user sends the transaction you should be able to see that the the username updates inside the extension so all of that that the user just did all of that was gasless there was no gas P paid by the user there the gas was paid by the the organization that was running this D app the idea idea being that it creates a much more seamless experience for the the users of this D so this is what we wanted to get back to um the sort of uh the flow where users can just see a cool D app see a cool application on the blockchain and start using it without having to worry about all of the prerequisite stuff that we usually need to worry about to use blockchain technology so if you want to start read it if you want to start playing around with this stuff uh you can read our documentation as a QR code for the docs there there is a section in the documentation about this relayer API standard I have um I'll take I'll take questions and minutes um if you want to read more about the API standard and um this repo here this is on my um is on the Luxo uh networks uh GitHub um organization and it's a basically a mock relay repository and it shows you how how you can actually build your own relayer and you see it's there's really not that much involved it's just implementing this um API standard um and it shows you how you can pass the parameters that are sent to the API into the the smart contract all so you can you can clone this and rip it apart do what you want with it but the ideas you play around with it and um start integrating this um so I see how time yeah good thanks um yeah so I'm going to preempt a question the account abstraction ERC 4337 is a big Topic at all of the conferences um the ethereum conferences at the moment um you see here there's already lots of talks about RC 4337 so the question is like how is this execute relate call stuff this gas abstraction different from ERC 4337 and just to do a very brief brief summary made up this um table where both of these execute relay call which I discussed now and ERC 4337 these are both gas abstraction Solutions so both of these Solutions end up with users having a gasless experience and both of these are also compatible with universal profiles so whether you want to have um a specific relayer application which you use with your Universal profile or set up pure Universal profile so that it works with ERC 4337 both of those work it's just up to you um in terms of how these are implemented the E 433 sorry execute relay call is just implemented with one function there just one function call which gives you this uh gives you this gasless experience ERC 4337 is a bit more involved um in terms of its implementation you need to run these bundler nodes on the network which gather up these transactions and pass them onto the blockchain but at the same time that that does come at a cost where these these transaction relay services are offchain solutions they're not integrated in the blockchain you need to have some API running somewhere on some server which is listening for these incoming transactions but that gives you some benefits because it means that you have more control over how this this transaction relay service works so you could actually run a transaction relayer which is specific to your application so that you're only paying for the gas fees of your users you don't have to worry about paying for the gas fees for users to use someone else's D because that wouldn't make any sense so now I think it makes sense as people start building out um D apps and trying to get new users to think about how they can onboard their users and building in this gasless component into the D itself I think is how um we start getting more users of blockchain Technology but really these are just two different solutions for different use cases it depends what you want nor one is not necessarily better than the other it's just they're different um and have different pros and cons and both of these are compatible with universal profiles so whether you want to um have a transaction relay service or ERC 4337 or both uh it's entirely up to you so yeah that that's it for the talk um thanks for listening that's me again that's the links if you want to contact me and I'm also in person I'll be here tomorrow too so um yeah come and say hi and thanks for listening uh how do you protect against malicious users that create thousands of profiles and drain the Rel layers yeah the spam so uh the way this is done is because the transaction relay services are like offchain they are they are sort of necessarily centralized you can have a lot of them but each one is centralized and run by some entity so at look so we will subsidize our users who come to the blockchain and we will pay for the deployment of their Universal profiles and their um and their transactions but because that is not an onchain solution we can actually control that so if we see that users are spamming stuff we can shut them off that that's that's the first point the second is that that's why we came up with this notion of a of a quota so the idea that you have a monthly allowance of the gas [Music] that I mean I'm not one profile with like you know malicious user that creates like thousands or millions of sure sure so actually with our implementation um you will have to authenticate with some social media account there's kind of like a proof of humanity step involved um so there will be some barrier to entry which means you can't have like Bots just creating infinite Universal profiles um and will allow like a certain number of universal profiles for each user and um that way we can kind of restrict how many Universal profiles users are using and they can't just Spam it with with Bots and and things like that I hope that answers the question who's next yeah in the back hi um what if user uses all the quota can he switch to his own wallet and pay for for for his fees sorry I didn't quite catch if the user is the user uh depletes all his quota oh in relay in his account can he easily switch to his own wallet or somehow top up this account yes they can um so if I can find it so see here uh within the Brows extension when you're confirming your transaction this third option controller key is always available it's just here it's grade out because the user has no tokens so they can't execute the transaction so if you were using a lot of gas you used up all of your relays then you would just have to top up your your own key um to do that but also you could have many transaction relay Services as well so you'd have to use all of your relay Services up and then and top up your key if you if you run out of quota but but this kind of like how much quota you get is really down to the implementation of the transaction relay service so different like organizations might have different models for how how you get the gas so you it might be like an ad spend ad thing where you watch some adverts and then you get some gas credits and you can spend it that way or it could be like a a staking thing you stake some tokens and you get whatever you earn you whatever you earn on what your Stakes as gas credits as well like there's loads of different ways this this kind of thing could be implemented um it's just down to whoever whoever creates it thanks who else yep uh yeah thank you uh so if I'm just uh building some D with M contract and small like uh front end should I be worried about my own relayer or uh you could you could just uh like a universal profile could like handle all of this stuffff so user just talk with uh like up uh extension and for instance to top up directly to to the yeah I mean it's it's really up to you if you want to um implement it it it I mean if you just have a small D app that you've just released for fun it probably doesn't make sense to build your own relayer unless you're specifically interested in doing that um as I say at Luxo we will subsidize the transactions of our users and when they first come so there will be transaction relas services available they can use it it's more for um applications where the the D app has an interest in onboarding a lot of users and getting a lot of activity on their platform in that case it might make sense to actually set aside some tokens and say okay I lose these like this 10 lucks which I'll spend on gas fees but the benefit is I get to on board a lot more users than I otherwise would have because you run into this problem where users have to go away to the centralized exchange and do it so it it it it's really up to you um whether you see this a benefit um for your for your application okay thank you second question uh so uh sorry uh if user uh like um if user uh don't have any like looks uh will it possible in future to up with like V on apps profiles or will it be possible to to do just to pop uh his balance with uh yeah you mean like the the quota balance yeah um so yeah absolutely I mean it's down to the the relay implementation um at the moment with our the implementation which we will give to people there isn't currently a way to bump up your gas balance as I said the idea is that this behaves exactly exactly like a mobile phone contract where if you run out of data you just buy an add-on for the month you spend like5 and you get another 4 gab but here would be 5 and you get this much more gas or whatever the model is like it's entirely down to the service relayer implementation to make up their specific business model and any specific bespoke functionality they want to build inside that um and that that's really where like the uniqueness of the service re layers comes in um because that's how you know different service Rel layers will have different unique sailing points that makes their thing more attractive to users it's just down to the implementation uh yeah thank you sorry the last question uh I think it's common question question to like look team why did you decide to just build own like blockchain and didn't uh didn't do it on like is or something somewhere else so the question is why is Luxo a layer one and not a roll up or on ethereum um just quickly the answer is that um the ethereum space is very busy with different standards um so for instance this ERC 4337 and all these other different solutions to the same problems which means you have a lot of competition about which standards are the best and which ones people should be using um our motivation was that if we launch a blockchain with a blank slate then we are able to have a blockchain where everyone is using this same teex stack and using the same standards based on the tools which we provide um and that way you get more interoperability and the D apps are all agreeing on which standards they're using rather than this sort of fragmented um fragmented ecosystem and the second reason is also spec specifically for this transaction relay functionality is that by launching a layer one we're able to um actually subsidize our users which we wouldn't have been able to do if we launched on ethereum yeah thank you thank you okay thank you C cool thanks a lot