# Meta Transaction Relayers at Scale by Isaac Patka (Devcon5) - Speakers: Isaac Patka - Channel: [Devcon](https://streameth.org/devcon) - Date: 2020-10-09 - Duration: 04:26 - Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology - Watch: https://streameth.org/watch/yt-jJFUDvkF7Lw - YouTube: https://www.youtube.com/watch?v=jJFUDvkF7Lw ## Description Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/meta-transaction-relayers-at-scale Earlier this year Bloom’s smart contracts were consuming over 2% of all gas on Ethereum mainnet. All coming from one meta transaction relayer. In this talk we will cover the techniques implemented in Bloom’s transaction broadcasting service to meet strict requirements of transaction ordering, fee management, chain reorg detection and alerting. We will also cover the challenges of moving a Meta transaction service from test nets with low, consistent volume and quick confirmation times to main net with irregular costs and spiking periods of congestions.We will officially open source the service at Devcon and discuss future work involving how to reliably cache and batch transactions to further reduce meta transaction costs. Speaker(s): Isaac Patka Skill level: Intermediate Track: Developer Infrastructure Keywords: technical Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/ ## 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]