-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Allow submitting several transaction from the same sender #5864
Conversation
The old check was restrictive - it prohibited the same account from sending multiple transactions before a new block was mined, because the check required that the new tx nonce match the nonce retrieved from the (state in the) most recent block in the local chain. The new check is more flexible - it requires that new tx nonces be greater than or equal to the required nonce. These changes also add a new test which verifies the new behavior.
libethereum/Executive.cpp
Outdated
| throw; | ||
| } | ||
| if (m_t.nonce() != nonceReq) | ||
| if (m_t.nonce() < nonceReq) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is going to break consensus, allowing the blocks with transactions in incorrect order, so this won't do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@winsvega do we have any blockchain tests with blocks containing transactions with invalid nonces?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gumb0 Ah you're correct, I had thought that the Executive was only invoked when submitting txs but it looks like it's invoked when executing txs as a part of importing txs into a block: Block::sync->Block::execute->State::execute->State::executeTransaction->Executive::initialize
...and when importing blocks into the chain:
BlockChain::sync -> BlockChain::import -> Block::enactOn -> Block::enact -> Block::execute -> State::execute -> State::executeTransaction -> Executive::initialize
We definitely don't want to change the nonce check in the Executive since that's consensus-critical code. Thanks for catching this.
Ignore invalid nonce errors at the initial check and let TQ correctly order transactions with future nonces.
|
A couple of unit tests still fails |
| BOOST_REQUIRE(!txHash.empty()); | ||
|
|
||
| auto invalidNonce = | ||
| jsToU256(rpcClient->eth_getTransactionCount(toJS(senderAddress), "latest")) - 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without mining previously sent transaction, getTransactionCount here returned 0, then u256 underflowed, and invalidNonce was max
I replaced it with just using 0 as invalid nonce
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, nice catch! And can we make the invalidNonce const?
| BOOST_REQUIRE(!signedTx["raw"].empty()); | ||
|
|
||
| BOOST_CHECK_EQUAL(sendingRawShouldFail(signedTx["raw"].asString()), | ||
| "Same transaction already exists in the pending transaction queue."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really difficult now to hit this error, because we check the nonce now against pending block, and the first transaction is added to the pending block faster than we manage to send the second, duplicate one.
So sending the duplicate transaction still fails, but with "Invalid nonce" error.
I haven't found anything better to do, than remove this test.
(changing the expected error would work, but then it would be kind of the same test as eth_sendRawTransaction_errorInvalidNonce above)
Codecov Report
@@ Coverage Diff @@
## master #5864 +/- ##
==========================================
- Coverage 64.03% 64.01% -0.03%
==========================================
Files 364 364
Lines 30970 30994 +24
Branches 3434 3435 +1
==========================================
+ Hits 19832 19840 +8
- Misses 9913 9925 +12
- Partials 1225 1229 +4 |
|
With this PR I am able to import multiple transactions from same address for blockchain test generation. |
Fix #5863
The old check was restrictive - it prohibited the same account from sending multiple transactions before a new block was mined, because the check required that the new tx nonce match the nonce retrieved from the state in the most recent block in the local chain. The new check is more flexible - it requires that new tx nonces be greater than or equal to the required nonce.
These changes also add a test which verifies the new behavior.