I am designing an off-chain service that handles requests and posts a transaction to the blockchain when each request is complete. During the time interval of a single block, the service may handle many requests for many users. The completion transactions are functionally independent of each other and the order in which they are executed doesn't matter. I want to reliably post each transaction without worrying about interactions that might cause failures.
In Multiple transactions from same address, Paul S writes:
If you have transaction dependencies in your off-blockchain application you should wait until the prior transaction has been mined before submitting the next transaction.
I don't have functional transaction dependencies, but still: As an example of the sort of problem I would like to avoid, suppose I simultaneously send N transactions from the same address, correctly incrementing the nonce for each. If all of these transactions are to be included in the same block, the miner must ensure that they occur in increasing-nonce order to compose a valid block. Or if only a subset of K<N transactions is included, the subset must be the first K transactions, again in order. Given the way pending transactions are probabilistically relayed throughout the network, I am concerned that a burst of transactions from the same address may not be reliably mined into a block.
Is the best approach to use a different sender address for each transaction?
That seems to solve the transaction pool and nonce issue, but complicates other aspects of the dapp, such as private key management and sender address whitelists in contracts.