We have received reports that some DApps have been having issues of dropped transactions on the network. We are investigating the issue. This could happen due to different reasons and we do not have a definite conclusion at the moment but we will share more details once we have it. Why it might happen?
- Nonce issue: if multiple txs are being sent via the same address, a pending tx can hold up the queue for the newer txs
- Transaction volume is pretty high currently on the chain
- Transaction pool limit - each node in the network (validator node / full node) has a specific tx pool limit. Depending on the volume of txs that come to a particular node, the txpool may not be able to handle txs over a particular limit
- Particularly for a particular address, each account can have 16 pending txs in pool at a time, resulting in 8192 account to live in txpool at a time, because global slots is 131_072 - these are current numbers in some nodes - these are being tweaked suitably to handle higher tx pool load, but this cannot be raised indefinitely
- There is also a limit on account slots
- Depending on tx propagation, some txs may get dropped from the txpool
- There is also a global limit on txs. if there is just no more space left for any tx, it will be dropped
What we are doing to address this?
- We are recommending validators and full node operators to change to the below txpool config
- We are putting in robust transaction pool monitoring infra to get more granular data on this issue so that this config can be tweaked better
- Note that these config values cannot be increased indefinitely
Instructions to change the txpool config: In your ~/node/bor/start.sh file, please add/update the following parameters:
--txpool.nolocals \
--txpool.accountslots 16 \
--txpool.globalslots 131072 \
--txpool.accountqueue 64 \
--txpool.globalqueue 131072 \
--txpool.lifetime '1h30m0s' \
After editing the file, restart bor: sudo service bor restart