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)?
up vote 3 down vote accepted
+150

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.

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).

  • 1
    How this answers the questions? – Badr Bellaj Jun 19 '17 at 14:50
  • @BadrBellaj I don't think my answer is an precise one. In fact I think there is no precise answer. I would like people to answer/reply/argue with sensible arguments. – earizon Jun 19 '17 at 14:59
  • 1
    Hi there. Do you have a link to where you read the 40 tx/s? – Richard Horrocks Jun 19 '17 at 15:25
  • @RichardHorrocks (40/sec Speaking from memory). Notice this number is orientative to provide an order of magnitude (tens vs thousands). Notice also that pow mines in pseudo-random time and that the network just warrants an average time. This link (reddit.com/r/ethereum/comments/3m7ley/…) speaks about of tens txs for POW vs tens of thousand for POS. That's a theorical maximum allowed for all users. 10.000 thousand different users transacting simultaneously will provide for an average of 1 tx/sec per user. – earizon Jun 19 '17 at 16:22

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.