Batching 300 Ethereum Transactions for NFTs
At the end of July, the Pixura team had a great time attending the Christie’s Art + Tech Summit in London. As a way fun way to introduce the concept of digital art collecting, we gave away 300 unique, AI generated digital artworks by Robbie Barrat on SuperRare, our CryptoArt platform. This post explores the technical challenges we faced in creating and transferring the 300 non-fungible tokens that represent the artworks.
The UX Challenge:
As with most dapps, building a great user experience into SuperRare has been a challenge, and something we’re always trying to improve. But, once an artist has become accustomed to signing transactions, tokenizing a single NFT is straightforward. Fill out a form, accept a MetaMask transaction, and boom! They’ve got a shiny new token with their rad artwork. Unfortunately, this UX flow falls apart once you get into the 10+ range of tokens you’d like to create. With 600 transactions to create and sign, manually approving each transactions was not an option.
The Solution:
The solution to our problem was a bulk tokenizer and transfer tool, which batch uploads tokens from a CSV. The CSV describes the tokens to create and the new owner addresses to transfer to. The creator runs the program from their own computer, enters their seed phrase when prompted, and so begins the tokenization process. A couple hours later you’ve got 300 tokens distributed to 300 wallets!
Lessons Learned:
1. Sequential Transactions
When batch-running any transactions on a blockchain, one must keep in mind that sequencing the transactions is really important. Tools such as MetaMask will handle this for you and keep the low-level transaction details hidden. With MetaMask not an option, we found ourselves manually building and sending the transactions. In an attempt to “optimize” this process, we sent each transaction to the node with a 100ms delay. Once sent, we verified that the node received the transaction. To those familiar with Ethereum, the potential issues with this approach may be obvious. To those who are not, the problem is with the transaction nonce. Since the eth-node is forwarding all the transactions it receives to other nodes, there’s no guarantee that the transaction with nonce 4 will be mined before the transaction with nonce 5. This would invalidate the transaction with a nonce of 4. So much for optimization :(. To deal with the problem, we sequentially waited for transactions to be mined before sending off the next one.
This is by no means the best solution, but it is the solution that worked for us given our time constraints. Our next iteration of the tool will have robust parallelization to handle and resubmit transactions with valid nonces..
2. Testing Locally vs Live on a Testnet
Once you’ve overcome the hurdle of getting a local node set up, (check out this awesome tool if you’re looking to do some local eth development) it’s pretty easy to start developing your dapp. Too often, I find myself overly confident once I have my dapp working on a local Ethereum network. Network delay is all too real and has shaken my confidence when a perfectly performing application suddenly reveals bugs due to unforeseen edge cases. I would like to stress getting the MVP of your dapp/smart contract onto one of the testnets as soon as possible. The previous section was one of those issues that we only discovered once we were deployed on the Ropsten testnet. The sooner you get your dapp on a testnet, the sooner you are be able to handle the trickier, distributed system problems that crop up.
3. Two batches of 300
This last section describes the foolishness on my part when we ran the bulk tokenizer for the giveaway. All 300 transactions to create the tokens went smoothly; it took about two hours–but successful nonetheless. The second batch of transactions for the transfers did not work. Not a single transaction went through. All the transactions were rejected due to invalid nonces. Quickly, it became clear that I was reusing the same nonce I started with for the creation transactions rather than bumping that nonce up by 300 as we needed. The lesson learned here is to always check your nonces or, an even better solution, move the responsibility to someone else’s library that has spent the time making all the mistakes for you.
Conclusion
Ethereum and blockchains in general are amazing and powerful, and the developer tooling has come a long way, but bulk or batch transactions are tricky and the tooling could still use some work. A summary of advice for fellow dapp devs:
- Go to a testnet ASAP
- Leverage existing libraries as much as possible to handle lower level transaction logic
- If you are doing things yourself, check your nonces!!
Get involved
At Pixura, we’re passionate about non-fungible tokens and the future of digital assets. We’re building the tools to empower anyone to painlessly build an NFT marketplace, starting with easy-to-use developer APIs. If you’re interested in starting a business selling digital goods on the blockchain, hit us up!
- Say 👋 to the team — hello@pixura.io
- Follow us on Twitter
- Sign up for our newsletter
- Join SuperRare, our CryptoArt community
