Decentralizing Gasless Transactions

okay so uh today's Meetup is about decentralizing gasless transactions and um the reason or um what gasless transactions or meta transactions are trying to do they are trying to solve the problem of usability uh on um especially for the new users or at least this was the pitch for um for metat transactions back in the day so they uh they want to help new users to on board and interact easier with deps or with smart contracts because so usually new users have no e in their wallet there therefore they cannot pay the gas so uh that means they have a higher barrier barrier to entry that means that they have to go through uh an on ramp register 31 exchange do the kyc process link a bank account deposit money and then um withdraw that uh whatever if they need to interact with the smart contract to their wallet and uh all this process uh is meant to be shortened and uh eased by the fact that you you would offer meta transactions on your dep and uh even so even ADV users I would say I think this is the second problem that is uh people not talk often about uh even Advanced users have um the situation where they simply have no eth in the wallet and maybe they do not want to transfer eth uh from their M main wallet where they hold I don't know large amounts one e two E 10 e or whatever they have in order to interact with smart contract so in some cases they might want to use transactions so for example imagine you get an airdrop you have no e in the where you receive the air drop you would need eth to pay for guest to claim the airdrop tokens and uh or another let's say you have rewards on synthetics and you want to claim your uh uh collect your St rewards from there and again you you need need it and whatever other uh other other um normal normal contract interaction another reason why would you would probably do not want to do uh that to move to simple try out wallet is just because of privacy because you do not want to link your main account with all your funds in there to the smaller account that you're just uh would that would be a burn um or throwaway account yeah so the conclusion either you're a new or experienced developer you might have problems just because not have eth in your wallet yeah so who can or what's the solution so that's why gasless uh transactions or meta transactions have appeared in ethereum ecosystem in the scene because um because they thought that it's a good way to uh on board or to lower the barrier of 2 for new users uh that one and high gas prices and all the other things that U that kept users away from ethereum until now so um and who can do this that's Deb developer so basically as a de developer you can choose to make meta transaction available to your users and uh this way you you would use the annoyance for um situations where people do not have uh eth in their wallet and they do not intend to transfer to that wallet um meta transactions themselves are what they are doing they are uh separating the signer from the guas payer so and this is uh kind of um so imagine that the user would sign a transaction it will send it to a an operator let's call it an operator or the way we'll call it uh later more technically correct relay server and that the relay server would pay for the guest to push the transaction to the ethereum blockchain so that's basically the way meta transactions work they separate the signer from the guest payer and um then the question is at what cost so in the end someone has to pay for that transaction so who does that and uh the good thing is that this is programmable at least in the way that we'll present it today for example you as a de developer you want to pay the gas uh gas fee for your users in exchange for other tokens let's say your users do not have eth in their wallet by but they have some usdc or die or whatever other stable coin and you want to allow them this option to pay with one of the tokens that they hold in their wallet another thing if you really want to do it that's probably I know let's say you want to pay you are okay to pay the gas for your users transactions if they do fill in a form or they I know watch some ads or if you want to go into that direction or another um situation which I'm also actually familiar with is the fact that you totally want you want to totally subsidize method transactions or you uh totally want to subsidize the the gas cost for for your transactions through meta transactions as an user acquisition cost right that means that you as a company or as a team are okay to uh pay gas for the transaction of your users and you consider that that is part of the user acquisition cost and um this is uh Argent uh which builds uh ethereum wallets for Android and and iPhone uh they do that they initially at least at the time when I worked for for them as a backend developer they were subsidizing gas for all the users that were uh installing their apps and uh would create a smart contract wallet that they U that they actually provided and then that the users could do anything like transferring even swapping tokens on Unis swap B1 at that time and um I was involved in actually writing the code for um relay service that would take the transaction pay for gas and propagate it to the to the ethereum network and um initially I thought that it's no big deal right it's an easy easy task you take the transaction you okay you decide the gas price that you want to to set on the transaction and you push it to the network and that's it you use a library to like web 3js or ethers and then you're done it's not that easy because there are many complications in there so ethereum um because of it's sequential way of processing transactions on account uh does not allow use or you get into the situation where you cannot process transactions for one users for one user just because uh the transaction for another user who sent late earlier was not processed and then you have to think of the way of scaling it probably own multiple accounts that you send transactions from because the a relay server uses an EA an externally owned account just as any human user there is no other way to do this and then um there are different situations where you want want to send a transaction uh you do that you pick a guess price and that that transaction is not accepted by the network it's not mind and what do you do they have the options you have to Treo the situation like you resend it with the higher gas price the question then is how uh what gas price to use maybe the moment there's a spike in gas prices uh maybe you should wait for longer and it's difficult to to program all these kind of different alternate cases yeah so it's not as layers so um as in um we we do have two different options so we can have meta transactions on our DAP in a easier way in a centralized way so that's the blue pill and we can have them in more in align with the ethereum ethers uh in a decentralized way and um it's not necessarily such a big thing because the user still holds the private key and uh there's no problem of um custody in there so the user still holds the private key to to the wallet but your centralized relay relayer co could uh go down and that's basically a single failure uh single point of failure problem or maybe a centralized relayer could uh ban some transactions based on users API uh users uh IPS or users ethereum address and uh that's that's where we get the problem of censorship so in this presentation we we'll take a look at uh both um both sides we'll take a look at uh first at how uh what are meta transactions how they work in principle and then we'll take a look at one centralized layer or centralized option and one decentralized option may I ask a question um does the I don't know the central layers have any vulnerabilities because it's centralized except um they can ban some addresses maybe maybe they someone can introduce malicious code or change the relayer to as long as you have as long as you host that service this comes down to this uh securing your uh web service and uh the same security rules applies to any other web API or HTTP API so yes there are of course risks because someone can hack your web service but um so and why why someone um would choose a centralized way instead of decentralized does any advantage yeah it's a bit easier and uh we'll see why okay yeah it's a bit easier and the decentralized option that we'll talk about openg GSN is not um that popular at the moment but we'll get to that so we'll talk about that to okay thank you now problem good so the let's jump into okay so what are meta transactions are there some kind of special transactions or um what what do I need to do or how how can I identify a meta transaction on the ethereum blockchain and the thing is that I cannot so basically there is no native support for meta transactions in ethereum or in the ethereum virtual machine so very much like your c20s there is no native support for tokens right you do have a cryptocurrencies cryptocurrency called eth and you have Smart contracts and um they have built tokens based on a standard called erc20 and uh that uh that standard is basically what makes or simulates tokens uh or other types of cryptocurrency the same goes for meta transactions So Meta transactions are normal transactions regular transactions and uh they they contain the actual transaction which are sent by the user right so the relayer or the operator will take the users trans users transaction and wrap it inside of its own transaction and that's why it's called meta transaction this is the reason and there are so in this case a meta transaction if it's sent by the relayer it will go from the relayer address it will go to um to a forwarder address or let's say for now to the destination contract we'll talk about the forward later it has a guas limit just as uh regular transaction has a guess price or in the I5 59 transaction it has a Max uh guas price and the Max uh uh Max priority fee field and then it has the value just another transaction and um yeah one thing to mention about the guas price the guas price is usually uh determined by the relayer right because you want to separate uh and to give this decision to the operator that sends the transaction other than that everything is uh everything that the user sends will be filled in into the call data of the meta transaction and now let's try and implement this so there are different ways to do this either you do it uh in a custom way and uh uh when I say meta transaction it's just a concept you can do it in any any way possible and there are people who initially started and developed it developed this uh unwrapping of the original transaction in their contract together with all the logic business logic of their contract and doing things manually until a standard emerged and um uh that standard which is called uh iip 2771 is um basically defines the way meta transaction should look and uh it's all in all it makes easier for developers to add support of meta transactions to their contract so this is one benefit of the standard and then uh another benefit is that this is a standard way for a client to discover that your de has metat transaction support right so just as in case of tokens if you implement erc20 token or you use rc20 standard you um uh it's easier for a wallet for example to discover the fact that your contract is actually a token or the contract of a token and then that wallet can display the balance of whatever token that is and uh make trans first and so on so the same thing in here as benefits good so let's take a look at how it works in at least this is the way uh normal centralized relayer would work so we have the transaction signer or the user and we have the recipient contract or Target contract I'll refer to it with Target contract too okay so I want this transaction signed by the user to get to the recipient contract and to be processed without user paying for gas what I'll do I'll put a relayer in between the user and the contract now my relayer can have uh an API or expose an API um endp Point um doesn't have to be necessarily in the format of Json RPC API like uh uh if you nodes do it can be any type of pp API or whatever other way of you think is better for your relayer to transport Port information from the user's browser to to its service and then this relayer will take the information that the user sends it will uh probably run some validations first to know if it wants to pass the transaction further and then it will would take the guas price from the network and it will create uh or it will WRA the all the parameters sent by the users plus the parameters that uh that it considers to be important like and of course the guest price and send it to a forwarder and this forward is basically the component that I was telling you that people were kind of uh integrated in the early days in their own contract but uh in this standard in EIP 2771 they have decided to separate this concern and put the uh forward as a separate contract that would call directly the recipient contract or the Target contract and now the only responsibility for this forwarder Al the standard I don't think it states that but the only uh or the most important uh responsibility is to verify the signature uh and um you can use various forwarders that are implemented or Implement your own but when you deploy your contract your your Target contract you have to specify which for order you trust because what the forwarder will do it will verify the signature of the user and the test the fact that the transaction or the forwarding request has been signed by the user and then it will extract the data the call data that is sent by the user and it will append the user address at the end of the call data so and then it will create a direct call to the recipient contract and it will include in the call data the the two parts right so the original call data and by user or whatever relayer has constructed in there so there's also a trust relationship between the user and theayer and it will also append the address of the user and then uh the recipient contract would um uh would be able to extract the address of the user what as We Know contracts or whatever smart contract cannot [Music] extract uh via MSG do Center variable the address of of the color or at least not in this case and then it's we'll take a look at how it's implemented and uh how can it get to u to use this function MSG Senter function to get the um Center adjust can you explain a bit why message sender doesn't work like the normal way and you have to use course yes so I have a contract in here trusted forwarder is another contract this is a web service and this is the signer let's say the browser uh if I uh log or if I use MSG do sender variable in the recipient contract which address will it display or which address will it fetch from MSG do Center depends if it's a call or a delegate call but yeah probably gas relay or or gas relay or trusted for order okay uh yeah the way they have decided to do this this is a normal a simple call so that means that the MSG do sender value will be the value of the trusted forwarder correct yes yeah and uh because in the delegate call I didn't I'm not sure but if you do a delegate call and you maintain the entire state of the contract on the trusted forward I think you might get into some situations that are probably more complicated I cannot explain why I didn't thought of this option but anyway they have decided that it's best to separate this uh signature verification into another contract that calls directly the recipient contract or the Target contract okay so MSG do Center variable will get the adust of this one and uh even and by the way even if uh we didn't have dist trust it forwarder we with MSG do Center we would have the address of the rayer but we're interested in the address of the signer because the signer is an EA this is a web service and the blockchain only starts in here yeah so somehow the gas relayer is also an EA yeah exactly yes that's important gas relayer uh is in EA because U so there is no other account type that you could use for gas relayer basically the gas relay initialized the transaction right yeah okay so that's exactly so the transaction signer it's not the eoa it can be just the guess relat just the GU uh correct the transaction signer of the transaction of the meta transaction yes okay the transaction get that gets to The Trusted forwarder and we'll take a look at the code but it will also uh include the signature of the user and and let's let's take a a look at the code it will be a lot easier to understand so if you want to make your smart contract meta transaction ready you have to do two things uh at least according to the to this standard you have to extend an abstract contract in order to gain access and to MSG sender and replace and refer to MSG sender with the this function and when you deploy the contract you need [Music] to uh to specify which forward you trust and why uh they called it specifically trusted forwarder is because this is the Smart contract that decides the address that is appended in here or the user address value that is append so that means that the aware of how the trusted forwarder contract uh is implemented to know its source code and uh all the other all all other things that um are required to trust it yeah probably If U the web service the gas relay would try to use another forwarder is impossible because this trusted forwarder is implemented in the main contract mhm exactly that that's another thing exactly correct so if I want to someh uh hack this contract and do it through another forwarder that would probably temper this address the user address then I would get into the situation where uh the recipient contract uh would reject the trusted forwarder uh would reject the the new forwarder or the forward that is not a good actor let's say and uh now let's take a look at the the code it's a very simple contract and there's not not much here so as I said you have to extend this RC to 771 context or in case of open gcn is called RC 2771 uh recipient and here is the function the mg sender function so what it does if it first checks if the MSG do sender is the variable is the trusted forwarder so it first check checks that the call comes from this trusted forwarder and then uh if it does it will grab the last 20 bytes from the C data that's that's what's happening here and it will uh return this as the the as the return value for the for the function uh in case the and the same goes for the uh for the call data if you need it in your contract and you want to use it so um you would not use MSG do data you'll use this function and this will again check that the call comes from the chasset forwarder and will it will take the entire MSG data that comes from the trusted forwarder except the last 20 bytes which is the length of the sender address and uh of course on uh we also have the situation where you want your uh metat transaction ready contract to accept normal transactions so probably you in some cases you do not want to limit your users from paying for guest themselves or the users that want want to do that so you would allow users to interact directly with the recipient Contra to in order to have more flexibility okay and uh what happens in this case uh instead of um going through this if Branch it will go in the else Branch uh which uh basically means that uh the that this code did not recognize a trusted for order and it will go to on the default way way of getting the MSG center it's a bit confusing that they still use a function in here but if we take a look at the context uh smart contract this function actually returns MSG do center it's probably just the way they decided to do this so let's take a look in the TOs uh yeah so the context AB contract will return MSG do Senter and they probably did it like that because um they wanted to have a default value otherwise they could have Define this as an interface or um anyway probably other design reasons that I'm not aware of can you go back to the last contract please sure so um on the line uh 29 so it it is removing the address of who of the EA or or forward I I'm not I don't understand which message sender they replace yeah so so it it does not replace it takes the last 20 bytes of the call data as we mentioned here it uh the call data in this case will contain the original call data plus the last plus the address of the cender so everything that this fun this function does it's it's interested in get it getting the address of the user and that's encoded in the last 20 bytes of the call data okay don't ask me with the shift right operators I I don't know exactly yeah it's so this this is why it must be trusted probably because as I observe you can manipulate what data you want from the transaction yeah exactly so the trusted forwarder would add this this 20 last 20 bytes in the Cod data so you need to trust it so basically you in trust for can modify everything you want from that transaction yeah that's crazy yeah correct yes but in the end why would you temper with it if you are the contract that would accept transactions from it yeah you can think of different scenarios but theoretic theoretically a user should be very aware with what it interacts what it signs uh what Gess relayer it uses and even the contracts that it interacts with with yes yes nice yeah so not necessarily easy for new users H not not us yeah so they have to trust the more experienced users okay and let's take a look at the implementation of The Trusted forward so this one so very small or very short implementation um so there is a minimal forwarder contract that is uh made available by open Zeppelin uh Expos an execute function it's not actually send and verify it's function and this execute function will first verify the signature right so it verifies the signature of the of the otherwise doesn't doesn't make sense to to proceed and when it verifies the signature uh it uh when it extracts the signer from from the signature it will check that the signer is actually the address of the uh of the that is specified by the request and the forward request looks like this so very much like a normal ethereum transaction there is a from address there is a two address value guests know data called data and uh what this means is that at this point I already have the from address of the signer or of the user the two address of the Target contract the uh value U if there is a value that needs to be sent the guas limit and the data the nons is managed by the forwarder so the second thing that the the forwarder has to check is the fact that the nons uh has not been reused this is a very important thing so uh what this basically means is that uh the requested or that uh actually I said that the no is um determined by the for but that's not true the the forwarder Only Stores the used noes and um uh in this case it will check that the nons that comes from the request is the same as the knows that is current available for the for the given sary chest and the uh the reason to do that is to make sure that you do not repeat the transaction so imagine that uh I would enable meta transactions on my token contract and I would allow the user um to send guest transactions to make a transfer let's say it would transfer 5,000 tokens to another adress and then the relayer can take this and rerun it again and that would be basically replay this is the reason why we have a nons that is constantly incremented for each signer address and uh um okay guys give me a second I'll be back okay so I'm back so where where can I hear we can hear you hello yeah so the minimal forwarder I'm not sure why why they call it minimal because it kind of has the most important features so I like to ask so if the data have the the last 20 bytes have the address why is necessary if we have that from from transaction mhm I why is necessary to have the from in the yeah in here exactly uh okay good question I don't know okay because okay let's see why uh ah okay so I know why that was the the second um so he caught me there the forwarder will get the forward request that contains the two address right and then it will take the the from address and it will take the from address and the pend it to the to the to the call data so oh I understand this address is not is is not uh provided by some other means than uh the forward request Yeah so basically the call data always have the selector and the the function the parameter of the function and they add to the call data the address so they can manipulate the address on the smart contract I think this is how it works nice okay so that was the minimal forward let's take a look at an actual transaction be okay so this is the transaction as it is executed this is the execute transaction that is implemented by uh let me from here so this is a relayer that goes and executes whatever transactions with the forwarder and this is the forwarder address right so this is the minimal forwarder and uh because this is an external call you can see the entire effect of this transaction in here don't have to go deeper into the Target contract so in this meta transaction this level um the user in this case the end user has uh minted rc7 21 token with id11 whatever this token is and if you take a look at the C data so this is the C data as we talked about in here in uh in the forwarder contract right so and here's the the information we have the request from that the forwarder receives the request uh or basically this is the user address that will be appended by the forwarder during its call to the Target contract at the end of the call data then we have the two address which is the whatever nft contract this one is some mean staking whatever and then we have other information like uh that we saw in in that uh in that struct like value guess uh the nons and the call data as um sent by the user together with the user signature so this is basically the transaction that we we we see happening in here right good question so far so is it clear how the transaction is forwarded here yeah at least for me it's clear cool so the destination contract will receive this uh this data plus the from address at the end this 20 bytes at the end it will be um appended to the end of the data as it comes from the user and will of course check good now there are we said that we'll talk about two options centralized thre layers and decentralized one so centralized layers um one of the centralized Solutions is offered by open zapping through their autotask um mechanism but so how it works works is basically uh the sequence diagram is very similar to what I showed you uh in this standard except there are two components uh and that's just because of the internal function and the internal structure of open zeppel in infrastructure when it so it uses it leverages its autotask uh components uh and it creates a new component which is the actual relayer or that the AO us will interact with but we can see these two as one component and again just as in the other diagram the client signs the transactions uh sends it on a post request to autotask to open Zeppelin and then op zein uh verifies it it first does a pre-check on the forwarder and then it goes and executes it uh and then it gets to the Target contract or that verifies the trust forwarder executes its logic and then the the execution ends and um that's about it except the fact that this request is not synchronous so this is a synchronous request so probably after this verification and even uh faster than that the client will receive a transaction request and then it can listen or it can PLL for results for the transaction um ID and let's take a look at the the dashboard so here I have a relayer which is this component in open Zepplin um um so I'm on the open zeling Defender dashboard uh and this relayer has its EA address which is filled with 1.96 Matic in in here and this balance of Matic will be used to send meta transactions or to pay gas um on behalf of the users and then uh this relayer is connected to an autotask which is this component on the diagram I don't have U successful uh items in my run history uh I'm sure that I had at least two transactions I I think they are not displaying the entire entire history of the transaction or they cleared the cash from time to time so the autotask will be called with you would send the transaction to this URL and then it will go through the entire process so that's the open zpp layer it's pretty easy to integrate uh in your API in your front end and then uh they have pretty good documentation on how to integrate it um you can there's very much Half Baked code that you can reuse and uh it's the fastest way to to have meta transactions for your de so that's the centralized solution and um the decentralized solution is the actual topic of this stock and it can be covered in this diagram so this is the open Gas Station Network architecture this um the reason why they did that this entire architecture is that they wanted to have multiple Rel layers so this is the decentralized part that they were or this is the centralized part that they wanted to decentralize so to allow the client and the dab Builder to use whatever layer is registered on the network and not just one one layer which is considered to be a centralized solution then um to do that they have separated the relay Runners from the dab devel Vel opers so the dab developers uh would have to develop a pay Master contract we'll take a quick look on this and then the relayer uh sole responsibility is to make sure that they have the relayer running and um they have enough up time in there and um thus through this relay Hub contract they they have created a trustless relationship between the uh between the relay server and the pay Master contract why because for example if I'm a relay server I want to make sure that the dab developer through its pay Master contract will refund me all the funds uh in the same transaction all the funds that I uh have paid to deliver the client's um metha transaction so this is the most important architectural decision that they have to and everything is coordinated through the relay Hub the pay Master contract would have a balance in here so uh you as a d developer besides creating the pay Master contract you would have to also uh deposit ether or Matic or whatever if uh blockchain use you would have to deposit it to the relay Hub contract and then uh the relay server would um make sure that it uh that that your dab has enough balance so that it can um can send me to transactions pay for gas and then get refunded from that balance here okay so is it uh clear so far so why why open GSN is implemented this this way yes it is yeah so the block the blockchain side is in here all these components are this are in this side and this is the web service side and this is the front end or the client side so as a um as a developer what you need to do if you want meta transactions with open GSM you have to uh make your recipient contract meta transaction compatible which is that you have your recipient contract needs to extend that EIP 2771 upster contract and register a trusted forwarder uh you do not not either you either deploy your own forwarder or you can take a look at the list of forwarders that are available made available on the website by open jsn let's take a look here so if I go to their docs I will see that Unfortunately they do not have uh ethereum mayet launched yet on openg GSN 3 but if I go to polygon okay so here's the forward that you can use and it's kind of um it has the status of the official forwarder that open JN has deployed to polygon main then you also have the relay Hub address I'll talk about this in a moment okay so we have the recipient contract we have the forward recipient contract is uh um knows about this forwarder in a Rel in a trust relationship and then um you deploy your pay Master contract you either create a custom pay Master contract or reuse one depends on what you want to do so uh the pay Master contract basically contains the payment logic and I will explain some uh reason or basically here is the part of the programability that I was referring to when uh when we started talk okay so you have your pay Master contract you deploy it you the payment contract like can it be a simple wallet that maybe approve the transaction I I mean approve the maybe rc20 transactions so it just hold it's like a cold wallet and but the the transactions can't take the money from it well no because we'll take a look at the how it's constructed it it needs to uh comply with two things or at least besides the fact that the relay Hub is forwarding the call to the forwarder into the Target contract it also does a preall to the pay master so that the pay Master can decide do I want to take this transaction further to my dep or not and then it would do the execution and send the call to the to the Target contract and after the actual forward call the relay Hub will will do a post relay call to the pay Master contract uh just in case the pay Master needs to add some logic to before it completes the transaction this is the external transaction this is the m main transaction action so everything in here happens in one transaction these are all internal ones so the reason is that there is a preall and a post call otherwise is I don't think there is a way to hook in some logic into this flow from an UA account okay okay understandable so you have the pay Master contract is deployed you register it with the relay H contract you also uh say what forwarder you want um to use together with your your pay Master contract and then you uh deposit make a deposit so that the relay service will be refunded for all the transactions that they sent and basically you are ready with the blockchain part you can all theoretically you can launch your D at this point in time you don't have to worry about the relay server if you go with the uh relay servers that are provided by by the network uh and of course you need to do the front end work and the front end work is pretty uh easy if you use openg gsn's uh Library JavaScript library which what it does it has this uh relay provider so very much like you know the web three provider that you use to interact with smart contracts uh you use this relay provider that abstracts away all these detail so uh and the way it abstracts it is to the point that the client or the your react code or angular or whatever framework you use does is not aware of the fact that it uses meta transactions to interact with the contract it thinks that it's basically a normal transaction so uh and if you use use ethers as a library it looks so to the front end it looks like it interacts with normal contract um object that is provided by ethers so that proxy object that it interacts through so that that's why they have created this dotted line because this is a nice abstraction that they hide behind this uh their uh open jsn relay provider and this provider of course Al also take behind the scenes to send a request to lay server and uh and so on okay and um after you use the provider you can also do the following thing you can uh state that you will you have a preferred list of uh relay servers so maybe you don't want to use the relay servers which charge uh fees for sending mental transactions the relay servers that are are by default registered with uh with open jsn and at the configuration level uh this is not agnostic anymore so you need to know well the the fact that you are configuring your client to work with a preferred list of relay servers and in case of fallback it will pick a a a relay server from um from uh the ones that are registered on the network and that's what what the diagram says in here so they call it relay Discovery so they first uh check if your D is configured with uh a relay server that you run yourself and this is recommended by them so theoretically it is recommended that you as a DA uh developer run your own relay server and the registered servers are in there only for fallback so only for Plan B in case I know your relay server is um out of service or whatever happened uh in there uh in the infrastructure okay so that's about it uh on the way open JSM Works questions so far okay if now let's rush in into actually running a meta transaction so there is this okay so the easiest way to test it is to go and take this repo and this is a demo app that they have created on top of G the entire open GSN stack and uh it's a very simple game it's um let me actually open the code so this demo app only does the F thing so this is the Target contract or the recipient contract all it does it takes the addes of the sender through the MSG sender function that weal talked about and it sets uh assigns the value of the addes to the current holder and then you can read the current holder value so whoever runs this um this function will'll see its address in here until next one who runs this uh execut this function and then the addresses address changes so let just just a very simple demo uh contract it's basically a Setter contract okay and um let me start the app so to have it on your laptop you just uh don't want it in here I want it on Firefox so all you do you uh clone that uh rapple you run yarn install and then you run yarn start and there you go you'll have this uh gorgeously looking user interface with enough information for you to understand how open JSM works from um technical important to actually get the feel of it okay so my account is this one I am connect currently connected with my another [Music] one okay so my account is FFC so I have zero Matic in my wallet uh okay uh the address of the C CTF contract or the demo recipient contract with took a look at the source code current flag holder is the value of that uh field that we took a look at and then you have different information related to the uh gas station network uh infrastructure you have the relay hub from uh have the relay Hub where is it yeah so that's the relay Hub address then you have the pay Master address and then you have the forwarder address right so these are the three most important uh components okay and it says that it has a layer we'll take a look at theayer okay so everything I need to do now as a user so C currently I'm here I'll click the button uh this the provider will send the request to the relayer it will verify that it has that the pay Master contract can pay me whatever amount um back and then it will send uh because it's a ma call it will send the meta transaction ID to the client address and then it will pause the make the actual call the actual external call to send a meod transaction to the recipient contract so everything happens in here everything I need to do as a as a client I need I need to sign the transaction be aware what you signing on the web with your wallet and in this case because uh the data is structured through EIP 712 metamask is also compatible with that I can see all the information that I'm signing so uh I'll see information related to the relay here how much guess will be used uh the pay Master address the for order address and so on okay now I'll sign the transaction and then this transaction will be sent to the Rel layer and then we'll we'll have our meta transaction posted sent to the network let's see okay H now I got an error or actually no I think I think it's a problem with um this front but let's take a look so if I P Master contract is the first contract that I um Myer interacts with except I cannot Happening Here can flick it okay so this is the pay Master contract uh oh no sorry sorry my bad we need to look at the relay Hub oh okay so this is my transaction 56 seconds ago Okay so this is the first point first thing that I see on the blockchain so I'm looking at the transaction that is accepted by the relay Hub contract and if we look take a look inside we'll see um okay it has been sent by this relayer uh it goes to this forwarder which is uh FC no not for the Relay hub and then let's take a look at the call data we have the following uh three most important things are the relay request which contain the uh address of the sender address of the destination contract whatever other parameters in here like gas and so on uh so this is basically the actual request information and then the relay data which contains uh this is the address of the relayer zoom in a bit this is the address of the forward and that's about it okay so yay I have a transaction sent to polygon I didn't pay a dime so of course I don't see the activity in metamask because metamask didn't add support for this but with Z Matic I have sent metha transaction to to open jsn and it got to the to my contract and now if I'll take a look yeah this is current flag holder or the value has been updated and this is my address that's cool nice yeah yeah nice uh good okay if you have questions otherwise I'll go I'll go quickly through what you can do with P pay masters so where have 20 more minutes so give me 10 minutes and then we'll also loate time for questions okay so why would I need to implement a custom pay Master contract so in case of the demo app and the transaction that I just run you do not have any type of uh logic pay paying logic in that so in that this case I have a simple pay Master contract that doesn't do anything when it is called with a pre- relay call and then a post relay call it just accepts any any address why would I want to do a different pay Master contract that's say let's go back to the um air drop thing so let's say you want to uh pay gas for a meta transaction that uh is targeting an airdrop claim right so I have an um some year C20 token that has been air drop and I need to go and click claim on that and uh send the claim to transaction but I don't have any e in my wallet I can go through a meta transaction and my pay Master contract might agree to take my meta transaction to the air drop contract in exchange for a share of the tokens that are returned by the relay Hub Contra uh that are return as part of the air drop and then the relay Hub contract how does it happen the relay Hub contract will go to pay Master contract and say okay so this is the post relay call what do you want to do and the pay Master contract will uh probably take or a share of these tokens and send the rest of the tokens to the client and what happens here let's say I get I don't know an end of 1,000 tokens the pay Master determines the fact that it will cost me 10 tokens to claim this without having e in my wallet and uh the user let's say in the ideal case it sees that okay there are I'll receive 990 tokens if because that's the price that the pay master has estimated I either going to Unis swap or whatever um price Oracle and so on uh much more simpler cases are when the user does not have uh if in this wallet but it has let's say usdc or usdt or whatever stable coin or D and it does not and it chooses to pay with d stable coin instead of e and in this case the pay Master contract let's take a look at the the example that is actually implemented in here do you know this guy yeah it's here okay so um so the token pay master that will charge me as a user with some kind of your C20 tokens instead of for for sending the transaction for paying e to send my meta transaction so let's take a look at how it's implemented have preate call right so what it does as I said the um Hub will first call the pre- rate call and in this case this implementation of token pay Master does the fallowing it will take uh the preferred token that the user is willing to pay with it will calculate the price or how many tokens value the max possible gas that would cost to send this transaction so this is the value in eth or in way and then this function would calculate that okay so this payer would have to be charged with this amount of tokens let's say five die instead of whatever amount of we needs to be used to send a transaction good now this contract will ch transfer that amount from uh from the user it will take from the user provided the fact that the user has approved but that's another another part that won't go in there so it will transfer um the given amount let's say five di from the user's address to its own address that's the amount of five die token precharge and then it says okay everything done um then so that was the preall the relay have goes and forwards the call and does whatever the contract in the amount of uh gas that was set as gas limit and then that call finishes and this does the Post call they have does the Post call it executes the uh this uh post post relay call internal this is the part what it what it wants to do it wants to refund the the user with whatever Surplus that it had so for example maybe this call to the cont did not consume the actual gas that did not consume the entire amount of Max possible gas but let's say just three three fours of it three qus of it and that then it will um take and calculate the actual charge in E then it will calculate the token that it should be charged with let's say it was 370 die instead of the initially five D that were charged from the user and we'll calculate the refund subtract uh subtract here and get to 1.3 die and it will refund the pair which is basically um transfer uh to to the payer and it also does a deposit proceeds to H uh which means in this case they chosen to convert the amount of tokens that those 3.7 tokens that they charge they chosen to convert that to e so theay Master converts it to to e and then uh it would depay deposit in its own account on the relay Hub so so the pay Master received the tokens it goes to unof and changes it to e and deposits back to L up so that it uh can continue serving um meta transactions okay short question about pay Master contract uh you say that U it should be custom as I see it's a basic procedure you have to do the pre-lay call and the post relay call and it will refund the tokens to you and maybe the guess that didn't it wasn't used what what should be custom uh mhm uh it's not entirely Custom Custom meaning you can reuse one of the contracts and redeployed meaning it's either you can take a look of already deployed contracts I meaning custom as custom deployment so you can take the exact same source source code and but you deploy your own uh pay Master contract why is that because uh the relay Hub might uh actually I think you can go if with all already deployed pay Master contract instead of redeploying it yourself with the same source code or basically the same contract but you need to check that the relay Hub uh is okay it reg it's registered with the p Master contract it's already register with the chust forwarder and uh yeah now I realize what it why it is not a good idea because let's say you find a Pay Master contract that uh that is deployed to a certain address and you want to use that if you reuse that you also reuse the balance that the original developer has has added for this pay Master contract and if you reuse the same pay Master contract even if you uh Define correctly and configure correctly your client and provider and so on you together with the initial deployer would have to share the the balance that is deposited for this pay Master contract I'm not fully aware but I [Music] think this is also a restricted operation yeah I I don't think you use it for I think pay Master contract can be modified to hold maybe balances for each relay and just build one pay Master for each relay I as I don't like a bank each each relay to have an account on the pay Master contract maybe for room is a good choice to not redeploy on contract I'm just wondering well uh I I'm not sure how you get through the shared balance situation with other developers so if you if I have a d with everything set up P master and so on and I have deposited the balance and you have another D and you want to reuse my payman contract exact deployment you would uh you would basically stick your dab in in here and people would be able to send met the transactions through from my balance so I think that there is a there should be some kind of uh limitation in here if not in the relay Hub then at least in the trust in the for order I'm I'm not sure exactly we we could this is a bit more advanced so I didn't look too much uh in detail at the relay hub contract but I'm sure that there should be some ways to prevent someone from using the funds that you deposited for your D and fund meta transactions for their own D so that's my longer answer okay okay guys uh other questions related to the decentralized transactions do you know um any use cases like maybe for gaming it's the best to have centralized relay H to be honest they are not very popular or at least not as it seems in here ah and by the way ethereum is not available eum main net actually I told you is not available on the last version of GCM GSM which is version three it's only available for um for version 2 to5 so you can find the minute information here okay but back to the question I'm not sure so so we could take a look and and see different um [Music] let's take a look at the status page so this is the status page of open jsn with the deployments on all the blockchains that it supports so let's take a look at polygon main net and we can see information related to the r layer so this is the r layer URL if I click on this I'll get this um um Json that basically is the meta information related to the thing that uh is going [Music] to the the entire infrastructure setup for for for this layer and then we have a status we know that it charges 30% so when you this is an official relayer registered on the network when you if you want to make profit you can register your only only layer in here uh and you can char Char in fixed amount of gay plus percentage of um of the gas cost if you want to but you would also have to stake a given amount of um tokens or native coins so this relay relayer has a stake for a very long time of one Matic uh and in case it doesn't behave properly it get slashed slashed and though it will lose this amount I'm not sure exactly how slash works but uh this is the principle and then we have the address of I think these are the adjusts of the workers yep so there there is a main relayer and a worker relayer which is the same source code but with the switch flipped in the configuration so these are the actual layers so if we take a look at polygon at least through the official Rel layers there is not very much uh lot lots of activity so we have calls from time to time and we can take a look at whatever contract has been called in here so I think it's it's oh this is the Target contract what's this ah this is the actual Capture the Flag I think that's actually my transaction this is product why why is not used I mean I I see the utility I don't really understand what why people don't use it yeah yeah well it's a very good an interesting idea it seems that sometimes the market does not go into the direction of that the technical people thought of or maybe I don't have enough information because keep in mind that many uh there there are lots of so it's recommended for a DA developer to run its own relayer so there are I'm sure there are many relays that you would not see so we theoretically should look at the relay Hub contract to understand uh was the yeah to understand to see what addresses or what um what transactions are done um not sure why they manager owner oh just curious yeah no why because version three has a relay manager that sits in front of the relay Hub they have it's even more advaned so let's take a look at the manager no transactions here and that's weird or the address is not correct I'm not exactly sure why also try the worker address I'm curious maybe I made a mistake this one no interesting where because I just saw my transaction and they're going through this one 434 so this is the okay so this is the relay call this is the relayer it goes to this is the Hub okay so this this is the hub for the correct adjust for Hub fce just as we saw in in the the Capture the Flag game fce okay and these are the so not very often at least not on polygon so everything that's relay call is natural method transaction maybe it would make sense I don't know let's think of other use cases maybe this case with uh airdrop would be nice and more applicable popularize decentralized Network for sending meta transactions like the one that you have a n drop you don't have any e and you don't have any erc20 to pay with and you just um enable meta transactions for that contract and then you allow people to uh to claim their rewards without having any e wallet it depends it's also lots of let's say marketing or product Market feeds uh situation yeah I think the only use case I see only when you have something to claim like airdrop or gaming nfts or you you have to claim something to pay with yeah that's an example but another one imagine that I want to allow my users and don't hate me for that I want to allow my users to Mint nfts with credit card and it's possible to do in a decentralized way with uh uh with open jsn the credit card payment is just the way that the user would compensate for the gas that has been used to in the nft and it's uh pretty much doable [Music] um with some tweaking Engineering in this area so you basically get the you are paid out of the blockchain and you pay to the in the block op yeah so in the in yeah so no no no so you pay with a uh credit card in the pre- call uh but no I I would need to think but I I feel like it's possible to be done MH okay cool guys so um other questions okay thank you very much um in this case we'll uh wrap it up in here and I'll um see see you in the next talk I think we'll have the next talk in probably three or four weeks from now and uh again if you have an idea uh to do a presentation and um let's let's talk and we're trying to GA as as many speakers as possible and again I think it's the best way to to learn um to learn something for example I did didn't have any idea about how guest open GSN works three or four weeks ago and I have decided that okay I want to study this I'll do a talk and then I had no choice other than to actually study well enough in order to be able to explain at least uh the mo most common questions cool thanks very much and see you next time thank you too for valuable information was a good presentation yeah yeah see you guys byebye bye