Should I use different sender addresses for multiple transactions in same block?

Question

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.

Answer 1

I'm not sure that this is necessary in practice; The advice you quote is for a situation where you're making raw transactions offline and may drop some of them, but if you just send your transactions through Geth it should handle the broadcasting of the transactions and the nonce incrementation, and things should generally Just Work. However, it's true, at least in theory, that sending the transactions from the same account makes transmission failures cascade in a way that you don't need.

If you do want to send your transactions from different accounts but you don't want to force the rest of your app to have to deal with hundreds of different account addresses, you could abstract that part out: Use a single key to make a separate signature which you transmit in the data part of the transaction. Send that to an intermediate contract that accepts transactions coming from any address, and instead checks that the signature passed to it as a parameter matches your single signing key. Then have the intermediate contract do whatever you originally intended to do. That will appear to any subsequent contracts to have come from the intermediate contract, so you'll have a single common msg.sender just like you would if you were sending all the transactions from the same address.