10

Discussion in another thread raises an interesting point. how many transactions could be included in a new block from the same account?

Since

  1. miners can opt to omit a known transaction from the block they're working on
  2. miners don't have simultaneous knowledge of pending transactions

is it correct to conclude that transactions submitted from the same node more or less simultaneously (and with ascending nonce) are not necessarily mined in nonce order?

2 Answers 2

14

The protocol requires that transactions from a single account are executed in nonce order. It's still possible for an account to have many pending transactions, and as long as the nonces are contiguous, a miner can include as many of them as desired in a single block, as long as they're executed in order.

There's no guarantee of ordering of transactions issued by different accounts.

0
-1

Transactions are processed independently and without any explicit dependence upon any other transaction being serialised in a block. IOW A miner doesn't care that a bunch of pending transactions might be from the same origin and that origin wishes to have them serialised in a particular order. The miner will serialise the pending transactions however it wants. If some transactions have a dependence upon any transaction which has not yet been verified, then those transactions will fail.

This is not the case for internal transactions where a contract calls another contract as it is still only one transaction.

So there is nothing wrong with a user initiating as many transactions as they wish for any single block, as long as they are independant

5
  • 2
    Are you sure? The whitepaper says the miner's state transition function must "Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.". If the miner processes transactions out-of-order, won't the nonce fail to match the nonce in the sender's account? That would imply that the user's wish to have them serialized in a particular order (as expressed in their nonce) will be honoured. Commented Mar 22, 2017 at 3:04
  • 3
    This answer is incorrect. Transactions from a single account are always processed in nonce order. Commented Mar 22, 2017 at 13:29
  • This answer should be unchecked. It's not correct. Txs from a single account must be in order. I learned that many, many years ago when I overdrew my bank account the first time. Commented Mar 22, 2017 at 16:19
  • Ok, thanks Nick, Edmund. My understanding was that out of order transactions would simply be failed. Given the chance that a series of transactions could be sent in order but received by miners out of order or across block boundaries, it would look to be the case where one miner may validate the whole series while another may not. As Edmund points out, a miner is looking for equivalence of nonce values, but this does not imply it is testing for a series of nonces from a single address as the TX's are atomic, and such would require a indefinite wait queue
    – o0ragman0o
    Commented Mar 23, 2017 at 3:59
  • @EdmundEdgar which brings up an interesting point, if a prior transaction remains unmined, i.e., disappears/drops from transaction pool due to low gas price or misfortune, a later-deployed transaction will remain stuck even if it is completely unrelated to the prior pending transaction and whether its gas price is set astronomically high or not. If a user isn't sufficiently savvy, their wallet is stuck in this ineffectual state rendering it pretty much useless. Maybe an ERC that provides a prop to link related transactions together is in order. Commented Aug 23, 2018 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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