vitaliy
2018-04-20 10:06
hi, just read the thread. Some thoughts, might repeat what was already said:
1. We used to have no gaps before, because we always calculated nonce based on `eth_getTransactionCount`. Then we noticed that we might execute quick requests in succession with the same nonce obtained via`eth_getTransactionCount`, and get same tx hashes. We should have been refused all subsequent txs with the same nonce, but given Infura?s load balancing sequential requests might well have been processed by different nodes.
2. Whenever we invoke `eth_getTransactionCount`, we are not sure if this the canonical one because of load balancing. The value returned might differ depending on where the request landed in Infuraland. Do you think it is correct to say that?
3. Also, there can be 2 kinds problems with txs: they either get refused outright and we get an error during the invocation of `eth_sendRawTransaction`, or they might not get mined after we get a tx hash. The former we can catch, but how do we reliably check for the latter? The problem is (as I see it) that we can know for sure that a tx has been mined if there?s something in `eth_getTransactionReceipt`, but how do we know if tx was dropped? Check for some time, like an hour or 30 mins? Or verify block counts? What do you think?
4. Now we changed the logic so we increment nonces ourselves, therefore introducing ?speculative? nonces. Because of 2 and 3 we never know for sure if the nonces were right and/or will get mined. Even without speculative nonces we had the same problem, but it manifested itself less
5. Good thing is that we have the logic in place to check for tx errors, there are scheduler threads that try to get tx receipts each minute. So we can use them to check for unmined txs and therefore release associated nonces, if a tx was dropped from the pool.
6. The objective would then be to decrease the amount of failed txs, this means essentially the amount of wrong nonces we submit. The problem is interesting, given the amount of uncertainty. I like it though)
7. There has to be item number 7. Most primitive nonce speculation logic would be for instance to rely on our replay features and use no speculative nonces, always relying on `eth_getTransactionCount`