How many transactions per second can we safely send?

Question

We're working on a large-scale application that issues a lot of transactions and we are not sure what exact guarantees Ethereum/Geth gives us.

On Ropsten testnet, we try to issue 100 transactions at once but only a fraction get mined. It seems like some transactions get discarded by the transaction pool and therefore mess up subsequent transactions because of the transaction nonce.

I looked at the code here: https://github.com/ethereum/go-ethereum/blob/master/core/tx_pool.go#L80-L83

• How is "non-executable transaction" defined? I assume this defines transactions that can't be executed because of a too high nonce
• If AccountSlots is set to 16 (and I assume the majority on the network has set that), does that mean the 16 lowest transaction nonces will go there?
• Is the number of possible transactions per account in the tx pool AccountSlots + AccountQueue or AccountQueue?
• What if I try to send more than that? Will Ethereum silently drop the transaction? (as I assume that this is what is happening at the moment)?

Answer 1

here is how you handle this issue in a practiced and proven way.

First, before planning your organization to be too large-scale, please make yourself familiar with the characteristics of the Ethereum blockchain. Transactions per second is a bad measure, as the critical part here instead is the block and the time it takes to mine it. Also consider the block gas limit, which is around 4.7 Million gas right now. Depending on the gas costs of your transactions, and even ignoring all other users, there are only so many transactions you can fit in a block - the others have to wait. And here comes the technique of concurrency into play.

As we are dealing with async computing here, simply firing hundreds of transactions will make most of them just fail, as you correctly noticed. Therefore, you set a limit for the number of transaction promises being generated, and do not create another one until at least one has resolved. Compare it to juggling: Not more than X balls at once in the air, or it will end in a mess. Technically, this is being done with the concurrency feature of the Promise.map function in the Bluebird Promise Library. The number you set for the concurrency limit depends on many factors, prepare to make it variable and adjust it to the state of the network.

Have fun.

Answer 2

I imagine you want to work with the public ethereum network (main net). I ignore the exact answer, but I have read it's about 40 tx/sec for all the network, including your transactions and anyone else transactions. And since the number of users using the public network increases, the number of tx/sec per user decreases. According to the CAP theorem/problem (https://en.wikipedia.org/wiki/CAP_theorem) blockchain is very good at consistency and partition tolerance and very bad at availability . That is, only low frequency/high value is suitable for the public ethereum network. "Side-chains" or any other mechanism must be used for other scenarios. For controled networks (for example consortium ethereum blockchain) the performance can be tuned at will tunning the consesum algorithm (Parity is much better than geth in this sense, allowing for different plugable consesus systems with different algorithms).