Meta Transaction Relayers at Scale by Isaac Patka (Devcon5)

Transcript

[Applause] hello everyone looming today I'm here discussing our meta transaction tree layers so what are the transactions first benefactors enable fund lists keep bears too and use smart contracts rather than spending gasps they signed their intended action and using their private key and then a new layer broadcasts on their behalf and pays the associate entities so that bloom in the past year we've submitted over 250,000 of meta transactions on bayonet sometimes it has six six thousand management actions in a single day during this time we were spending up to one to three eat per day just to keep our benefits actually was

going this has to do with like identity credential issuance so what we've learned pretty early on is that simply broadcasting the transactions does not scale you can't just call web 310 directly to SMEs and hope that it's going to work confirmation times are long and they're inconsistent gas prices can be volatile and there are frequently trade chain reorg switch drop transactions so the first thing that we encoded into this service which handles very high volume transactions is non store casting so the in a simple piece on the left you can see that we broadcast one transaction witness one zero zero one and everything else is

blocked so they can't all be mined in the same block instead what you can do is use the nos field of send transaction so that you can do one thousand one three one thousand five and you can have all of these tapped into the same block without waiting for mining when there is a non set blocking the next one so if we're waiting for one zero zero two two mine we need to aggressively rebroadcast that transaction with a high of gas until it goes through so this happens in the service every 30 seconds it rebroadcast with a point one Waymire gas price in order to force it through so that every other transaction will endure blocked we found that on an average each transaction needed to be broadcast twice to go through so this when I set up this inelastic sac when I looked in the

morning this look healthy to me there were transactions being created on the bottom and then they were being committed or rebroadcast on the top gas prices sometimes spiked very high that's important to set a cap and wait it out because gas prices are volatile but if we filter out everything above a hundred way it's actually pretty consistent so if you were spending you know maybe somebody has some arbitrage opportunity way back in a sip end in February you didn't want to be competing with every gas just wait a little bit and then you can get your transaction through our actual spending ended up being far less than the average but we still have very high throughput also during when the network

is very congested mining will sometimes lag by many hours and you might be concerned that it'll never catch up but as soon as the number congestion goes away the backlog clears and then you're broadcasting at mining times get much closer together one last thing that you also shouldn't look for is chain reports so we have first you think that something was mined but later your transactions are not being broadcast you should go back and look at the most recent transactions see if it's dropped and then you can either fulfill it value exacted or you can actually go back and read broadcast at one so finally I just open source this about ten minutes ago this service that

actually handled all this logic for you and it's very balloon specific now you actually have to encode a lot of the contract logic that I would love that I try to get some other companies set up with this service it does a lot of a camel a lot with us awhile to the to figure out so please take a look let me uses PG boss for the queuing is all paid script so use type chain for contract leggings check it out and every little T with it thanks [Applause]