Atomic Batched Transactions — Solving ERC-20 problems through MetaTX
Executing multiple arbitrary blockchain transactions at once
Co-authored by me and Ivo Georgiev
Preface: Meta Transactions
Meta Transactions are extremely cool. If you do not know about them — you should. Here are some links for you to learn about them:
Changing the Meta Proxy to support batches
The idea behind the Meta Proxy contract(sometimes called Identity Proxy or Identity Contract) is for it to be a representer of the user and obeying to messages only signed by its master. For you to use MetaTx, you (or someone else) must deploy your own MetaProxy that is going to execute your signed messages.
While the community has been focusing on making a better relayer network or standardizing the Meta Proxy, we had the idea to try and batch multiple transactions together. This new-found atomicity of multiple transactions together seems to come quite handy in multiple scenarios. Some of them are:
- ERC-20 approve+transferFrom based interactions
- Decentralized exchanges
The batched transactions are achieved through simply changing the to, data and signature params to arrays. Now, all we do, is loop through them, validating and executing them. If a single transaction fails — the whole batch is going to be reverted. Look for the code below.
Use case: Solving ERC-20 non-atomicity through batched meta transactions
In order to showcase the batched MetaTx, we are going to fight the non-atomicity of the approve-transferFrom mechanism of ERC-20. I’ve gone ahead and created a code example that illustrates that.
The main idea is that we build the two transactions with their signatures and send them to the MetaTx proxy. The two transactions have different ato, but will be performed in batch.
One of the main problems of the ERC20 token interactions is that they require 2 different transactions — one for approve and one for doingSomethingWithTheToken towards arbitrary contract (that internally calls transferFrom). This introduces all the problems of non-atomic transactions. The simplest problem is that even if your doSomethingForTokens transaction fails, your approve does not and your allowance still stands.
In the example above I’ve created a dummy token and a dummy service contract — Billboard. The Billboard contract has a buy function that allows you to buy the Billboard space for at least the amount the previous person has given.
Now on the positive scenario — we’ve built approve transaction data plus transaction signature, and buy transaction data plus transaction signature. Executing them together goes through successfully and we’ve been able to buy the Billboard space.
In the negative scenario, we reuse the same approve and buy artifacts. The difference is that the Billboard smart contract is now supposed to revert, as we are not sending a bigger amount of tokens than the previous time, thus we should not be able to buy the Billboard space. The test reverts successfully and in addition to the reverted buy transaction, the approve reverts as well— no attack vector is left to steal from your approval.
Conclusion
Batched MetaTx have enormous applications. We believe that many projects and initiatives will find uses for them in the future. Have a use case in mind for them? Keep us posted here or on Twitter ;)
About the authors
Ivo Georgiev is the founder of AdEx Network, an advertising protocol mostly built on Ethereum. Twitter handle: @Ivshti
George Spasov is Blockchain Architect and Co-founder of LimeChain. Twitter handle: @GSpasov
