Starton vs Ethers

Ethers.js is a JavaScript library designed for interacting with the Ethereum Blockchain and its associated functionalities. It provides developers with tools necessary for executing on blockchain and interacting with smart contracts. Notable for its architecture, Ethers.js facilitates efficient blockchain operations, enhancing both scalability and security in application development. This library is used for a range of Ethereum-based projects, offering base functionalities for building and managing decentralized applications (dApps). Ethers.js is recognized for its capacity to simplify complex blockchain interactions, making it a practical tool for developers in the Ethereum ecosystem.

1 - Security issues

Working with ethers.js library requires you to store your private keys on a .env file.  You will need to use tricks to secure them to automate transaction signing since the goal is to avoid signing each transaction manually as you could do using Metamask.

2 - Nonces errors

When it comes to broadcasting transactions simultaneously, you will probably face nonce issues such as ALREADY_KNOWN or NONCE_EXPIRED. To do so, you will have to create your own nonce manager, to track which nonce is already used, which ones are available to use, and track which transaction is on-chain.

3 - Gas price issues

Your transaction can be underpriced, meaning that it’s not picked up by the miners because the gas price offered is not attractive in the current market (see TRANSACTION_UNDERPRICED). When implementing a transaction replacement strategy, you can also face this error: REPLACEMENT_UNDERPRICED. Since the gas price demand evolved, the rates set up for a transaction can become insufficient when in need of replacement. But that’s not all. What if there is a bottleneck on-chain? What happens when your transactions are reverted because you didn't put enough gas compared to the current demand? To manage this, you have to develop a strategy to replace stuck transactions by increasing gas prices, and of course, consider how much you are willing to spend. And of course, this has to be managed along with the nonce issue.

4 - Mempool limited size

Another major issue you can face is the mempool. Each node has its own mempool. When load balancers route your queries to a new node, it also means to a new mempool. Each node has its own mempool size. If you broadcast too many transactions with the same signer wallet, depending on the node you hit, some of your transactions will be lost by the mempool. When you want to retrieve pending transactions you must hit that specific node. To manage this, you need an off-chain strategy and rebroadcasting strategy to resend lost transactions and get insights on which transaction is mined or which isn’t.

5 - RPC node inconsistency

Sometimes, it's simply a network issue. Either the network is experiencing an overload or the RPC node times out. Sometimes the RPC node responds to a new error you haven’t accounted for in error management, and the error logs are not located consistently among RPC providers preventing your script from fitting several EVM-blockchain protocols at the same time. To tackle this, you have to manage RPC node errors properly, add a strategy if nodes are timing out, and retry your broadcast when nodes aren't responding anymore.