EthCC 2: Yoav Weiss

okay can you hear me hi everyone so my name is your advice I am a CTO at Ibuki and today I wanted to talk about the gas station network and how we decentralize metal transactions so before we actually before we start talking about the gas station network let's try to understand the problem we are facing and the problem is a gas payment in having to hold ether so the table on building today is totally broken if you want to if you want to on board used to Humble the new user who doesn't come who doesn't come from the crypto space he needs to he needs to jump through several hoops so first it okay what happened here yeah okay so the user the other first needs to go to an exchange needs to go to an exchange because it doesn't have any felt to pay for the transactions then he needs to pass kyc at the exchange before we could do anything this can take a couple of weeks then he needs to transfer money from his bank if his bank is willing to do so to transfer money to the exchange then use it to buy ether at the exchange install metal mask on his browser finally move move the funds from the exchange to a meta mask and only then get to the DAP by that time we probably lost the user so so we may be we may be the users for the apps but normally users are not going to come so the question is how do we move from this to that and that's the problem that's a problem we're trying to solve here and it turns out that the community has been doing a lot of work solving this problem already all of these solutions are based on something called the meta transactions with meta transactions the idea is quite simple you put a real layer it's a service it's a server that you put between the blockchain and your user so now when a user and when a user generates a transaction and doesn't have ether you can sign the transaction regardless send it to every layer there really wraps it with another transaction and then sends this transaction to the blockchain because now the gas is paid for so the relay pays for the transaction so what's wrong with this picture why did we need anything more so the problem with meta transactions is that it's a centralized solution and we don't like that so its first of all the relayer is a single point of failure when you put a relay instead in front of your DAP if the relay dies it dies for whatever reason let's say someone tries to attack it in order to take your dap down then your dap is essentially dead it exists on the blockchain but there's no way for you users to communicate with it which means that it's no longer decentralized and the other big problem we have is that is that it requires blind trust it's the relay becomes becomes a problem a part of your trust base whereas until you edit the real layer all of your trust was embedded in a smart contract which is open source and can be verified on the blockchain so all the users can look at it and know exactly what they are what they are facing they know exactly what the app is doing whether it's going to be fair but once you add once you add the relay server in front of it you lose that because now the relay the relay can decide for example to favor one user over the other or it could just decide to send those certain certain types of transactions the also simply has no way to know so it becomes a trusted component and we don't want that either and this goes against our core beliefs at tabaqui we don't want we don't want a single point of failure and we certainly don't want any blind the blind trust in any component we want everything to be verifiable so we looked into this centralizing that and it turns out that the community has been working on that problem for a while but all of the in all of these attempts we're going in we're going in a direction that ended up having to solve a difficult problem what they tried to do is to create to create a secondary transaction pool so you have a transaction pool of gasless transactions and you have relays competing over them mining from the spool taking transactions and signing them to pay for the gas and delivering them to the blockchain for a fee and while this solution may sound may sound reasonable once you start looking into the details you realize that there's a synchronization problem that turns out to be quite hard to solve the problem synchronization is that if a relayer needs to then a relay will always pick the most expensive transaction because that's what what's profitable for it so it will take the most expensive transaction put it on the blockchain all of them will do so the first one is going to be successful the other ones are going to get revolted and actually lose money because the transaction can only be put there once but most importantly the the cheaper transactions are never getting to the blockchain so this solution doesn't fly and after we saw it we saw how hard it is to solve we thought about the problem again and we realize that maybe we don't really need to solve this problem if we can we can change the problem definition and get to a solution without going through this synchronization issue so we wrote a ip68 in which does basically that we realize that the sender is already then the user is already most incentivized to put the transaction on the blockchain it just lacks the tools to do so so we thought what what minimum toolset needed in order to support that and it turns out that what you need to be able to do is to to discover relays in a design in a decentralized way so you can select you can select a relay from a pool and then you need to be able to verify the service without waiting for mining and in a trustless way if you can achieve these two these two goals then then you can turn the problem upside down instead of having a transaction pool you ever realized pool and you let this end I'll select the real layer and that's what we did in our solution so the solution revolves around the around the central s contract called relay hub it's a single tone there's exactly one on the entire blockchain all the really all the relays have to register with real a hub they have to place a stake which is used to guarantee their service quality it has to announce its fee so everybody knows how much how much they need to pay for the service of this particular relay and finally the URL so that clients know how to reach it and as then as the relay is being used in the system the relay hub contact also emits useful events that can be used to calculate reputation for relays and knowing women so all the clients can look at relays and know which ones are a good should be used but all of that would have been useless if we couldn't solve the immediacy problem if if we needed to wait for mining every time we put a transaction in order to know that the service has been provided then the system wouldn't work what would happen is if you have a small number of even a small number of non-functional relays the situation would be something like this the the center the center connects the set of pics are real a sense the transaction then waits a few minutes until it realize that the transaction is not is not getting mined for whatever reason so it drops it moves to the next relay waits for a few minutes again have just just a few of these makes the system useless so so we figured out this solution for the immediacy problem the way the way it basically works is when the center when the user wants to send a transaction it finds a relay in relay hub and agrees to pay the fee so it connects to the trail a sends the transaction now during the relay er looks at a relay hub and then checks and then check the destination contract the recipient making sure that it's willing to accept the transaction and pay for it once it figures that out it does two things so one thing is it puts it on the blockchain so it will get mind but the other thing that he does exactly I mean concurrently at the same time is return return the signed transaction we sent the designed meta transaction back to the user so now the user doesn't wait for my need the user can just look at the transaction the client checks the transaction it makes sure that it is exactly the transaction it requested that it is properly signed by the relayer the nonce is the nonce for the transaction matches the current nonce of the real layer and that the relays balance is sufficient to pay for it with these conditions the user knows that the transaction will be mined if it is put on the blockchain and in fact the user could just take the transaction and put it on a blockchain itself so it doesn't need to wait for it to trust the real ale to put it there there are still a few criminal cases a few ways in which a real ale could return a signed transaction but then do something to make to make the transaction fail on the blockchain but luckily all of these all of these attacks are provable on the blockchain there are ways that there are ways to provide a pool for it that can be verified by a by the contract so we added a penalized function to whether a penalized function to relay hub well and anyone can anyone can find a proof that the relay tries to a cheetah user put it on put these transactions on chain and then take away the stakes so the penalised function will keep this relay out of the system and give the stake and give the stake to whoever proved it and the client doesn't even need to worry about that or the client does is take the sign transaction and get take the sign transaction give it to another relay at all maybe more than one and forget about it because now the relay and now the relays are incentivized to watch each other so if one really all catches another reader trying to cheat they are going to take away stake there's a there's a strong disincentive for cheating in the system oh well even I wish we had more time to explore the game theory around this there's a lot of a lot of game theory went into design but since we want to have time here you can read all about it in a pea 1613 and specifically maybe scroll down to the ataxia mitigation section which shows exactly a show that shows the attack center and the way we mitigate to them a through a game theory so we have the we have the medium article here and the the EAP that explains the details but now I would like to do I like to do a demo and it is that one so in today's demo I'm going to do something something I haven't tried before instead of using our own demo I'm using since we started engaging the community and now apps are being built on top of it I'm going to use an app developed by the Polti steam didn't they wrote they wrote a game that uses this so you can play you can play this crypto game without without owning either so I'm going to do a transaction in this game and then we look at the transaction and see what happened behind the scene yeah so that's so that's the game and now we are going to we're going to try to adopt - adopt one of these doggies and what's going to happen is we need to we need to pay a token for it and then it became and then the address will change and the doggie will be will become ours so now as I can as I clicked it and the transaction is going through what's happening what's happening behind the scene is that the app the web app looked at real a hub it found the relay looked at the fee and decided that's the relate wants to use now it sends the it send the transaction to the tutor a layer the relay took the transaction and made sure it's going to be paid for using a view function once it knows that it's going to get paid it put a transaction on chain but it also returned the transaction to us so here we see that the transaction has already been mined before we look at the transaction I'm going to I'm going to briefly look at the wallet address so you can see that you can see that there were no transaction on this the no transaction where ever done with this address which is not surprising considering that it has no evil so it couldn't make any transactions but if we look at ELC 20 transactions we will see that one minute to go a token was transferred out of this address which means it had to be done by someone else so this was done by a relay now I'm going to click the transaction so in the transaction you can see that so you can see that the token was transferred from this address but if you look at the form address you see a different one so so you see that this this relay actually had this relay had five ether which it could use to pay for the transaction this is the relay I'm going to copy a part of its address it will be useful in a moment okay so also let's look at the internally the internals of the transaction so internally you see the transaction consists of three different transactions the first transaction being a static call this is a call to a view function where is equal to a view function where we ask the relayer we ask the adapt whether it's willing to accept the transaction and pay for it once we got once you got confirmation on that the second internal transaction is the actual transaction that the adopt transaction that gave us the doji and the last and the last call is a post relay call that tells you that tells the DUP how much the transaction ended up costing and this is very useful if you're trying to implement your own accounting system and charge the user by other means for example if you are a if you're an LC 20 token you could let the user interact interact and transfer your tokens and pay for the transaction using your own token instead of using ether so this function tells you how much you should charge the user now I'm going to click the we see the transaction went to relay hub so I'm going to click the relay hub contract we see all the transactions done here and I'm switching to the events so we see that the last event is so the last event is the it's an event that shows that this particular relay was used on behalf of that address of that user delivering the transaction but now let's see how did we find and how do we even find this relay so I'm going to look at another type of event here this is the registration event so when you have so you see these really added events these events are emitted or emitted every time it really registers or when it really registers to relay hub or when it refreshes its parameters which happens every once in a while and you can see that it it announced it announced its address its transaction the steak size and and most importantly the URL so I'm going to click this here let's see it as a text so you see this is the actual this is the actual URL where the transaction or transaction went for so you see the address of a so this is that is often really this is how we knew which relate to talk to so so that's so what we saw in this demo is a how seamless it is for a user to interact with the dap now while still retaining the decentralization property that we like and making and having the DAP a for it and this is all using the gas station at work so tanks port is for a for building this great demo so how do you use this in your own DAP so how do you use this in your own DAP you have so in order to use this you have to make four little changes to your smart contract the first one is you need to inherit relator CP and that's a base contract that tells you that that gives you the code you need in order to interact with it with with a relay hub then you need to write two functions one function is a view function called accept relay call which which is the way your dub says whether it's whether it agrees to accept a certain transaction from a certain user and then you need to implement the the post relay hole which explained earlier this is a use for accounting you can leave this empty if you don't have your own accounting and finally you need to want to change message dot sender to the gates and alcohol everywhere because message or sender is now the other so familiar which is not very relevant for your DAP so get sent there gets you message sender from for the electrons actions but for real a transaction it gets you the rim Center and you can look at this hands-on tutorial that we published which shows you exactly how to how to modify or on your dub to use this so recently we started engaging with the community and engaging with the community to get these two met and to get and to make it the standard for a meta transactions so the first thing we did is we took a burner wallet by Austin Griffith just before if Denver and we put it on we sent a pull request that adds that adds grassless transactions using the gas station network so if you're using the burner wallet and you have no and you have no ex die to use to pay for the gas it actually gets paid and it gets paid by the DAP so in order to do it we deployed a few relays within a few relays on the XD Network we've also partnered with Zeppelin who are now helping us get is to maynot so we hopefully will get there soon so thanks it's a plane and you saw and you saw the demo from a party's other projects are also starting to use this and we also we are getting support from the aphelion foundation now which is also great and it's going to speed things up there's the medical tale with an medical tale is a group that has been working on the meta transactions for a long time and we have a meet up tomorrow so you can come there and we're going to talk a little bit more about this it's a medical medical tell is pushing this solution to become standard so with that I think do we have some time for questions okay let's do bed first of all thank you great stuff so how serious is is the attack surface where like a malicious actor can kind of extract value from the DEP itself through artificial transactions can you explain that attack what do you mean yeah I mean like so it's not organic usage of the DEP but some like somatic that is spam spamming transactions draining value out of the depth yeah so so that's what the accept relay call is for your dub doesn't excel doesn't accept random transactions from a unknown sources it it gets it can look at the transaction and agree to pay for it and so if someone if someone sends you a transaction the relayer can check whether the transaction is going to be accepted and paid for so if it's spam if it's a spam transaction the relay will not delivery because it knows it's it's not going to get compensated for it and if you have a user that is one of your users and is spamming you then it's your responsibility as the DUP to remove that user you can ban him from your you can you can have a ban list of you of offensive users if you have those you are telling us to change or dabs to accept Lakers what about using proxy smart contracts that can be used as identity for the users and that will relay so the depth one see any change I'm sorry I could not I could not tell you well my question is what about using proxy smart contracts for user identity that will relay between your layer and the Dubs so we don't have to change or that we can't hear you maybe you can discuss later ok let's say so yes yeah definitely that's that's one way to do it so you could have in that case the proxy would inherit the relay recipient contract so you can put a proxy in front of your you can put a proxy in front of your DAP and have the proxy interact with with relay hub that's certainly possible you still there's there is one yeah that's yeah yeah you still need to be aware of who the user is so either you deploy a unit either you deploy a proxy for each user with it which is uh needlessly expensive or you say all you need to change the message center to get Center because otherwise you don't really know who the user is it's a you need get Center so you find the relay you find the real user all right thank you [Applause]