3

There are two transactions I would like to make as close to each other in time as possible. In a SQL database I would make them appear in in the same transaction (in the SQL sense).

At the moment, when firing two transactions consecutively (using web3py) they are typically mined 3 or 4 blocks apart.

Improve this question

1 Answer 1

Reset to default
6

These sort of questions come up when seeing blockchain "only" as a new database technology. However, we are forced to think in a new - decentralised - fashion: It is solely up to the miner to select transactions from the backlog - currently we have a few thousand transactions waiting to be mined.

Keep in mind that the selection and ordering of transactions in a block is not defined in the protocol and can hence be implemented differently by different clients or client versions. While two transactions from the same sender will be executed in the order of their nonces, you do not know how many other transactions of other accounts will be included in between.

But practically it's not that bad: Usually miners sort transactions by gas price first (check the gas price of all transactions in some block to see for yourself), so you could try setting an unusual gas price (e.g. 23.0000023 GWei). Now you should have increased chances of having them in the same block, because many people choose 21GWei so there is a chance the clients dont order by account and just randomly split your tx up. This also depends not stability of network latency, specific client behaviour, so is likely not going to get you as far as you'd like to.

Beyond that, at high level there is no way to enforce transactions in the same block. However, if at least one of the functions is in a contract that you are currently writing yourself, you could re-structure to execute both functions in one transaction. This is in any way usually a lot more gas-efficient as you would not have to pay the 21'000 flat fee for the second tx - for simple function calls without too much data and storage writes this is usually significant. Of course this does not always work and would notably fail for restructured versions of a token transfer() because the msg.sender is different.

Improve this answer
6
  • "ordering of transactions in a block is not defined" Worth noting that (currently) the nonce does enforce ordering of transactions from a single account.
    – carver
    Oct 11, 2017 at 17:47
  • @carver: it seems that most clients currently do enforce this on block level but this is not defined on protocol level so you cannot rely on it. e.g. i (as miner) could withhold your tx with nonce 2 but include your tx with nonce 3.
    – SCBuergel
    Oct 12, 2017 at 16:15
  • I read the yellow paper differently; so does this answer: ethereum.stackexchange.com/questions/13376/… . I encourage you to offer an alternative answer on that question outlining your understanding.
    – carver
    Oct 12, 2017 at 16:21
  • ok we're talking about slightly different things: Yes youre right tx ordering is enforced on protocol level. But a IIRC it would be ok for a miner to withhold nonce 2 and publish the tx with nonce 3.
    – SCBuergel
    Oct 12, 2017 at 16:32
  • my last point was incorrect: myetherwallet.github.io/knowledge-base/transactions/… "No Skipping! You cannot have a transaction with a nonce of 2 mined if you have not already sent transactions with a nonce of 1 and 0."
    – SCBuergel
    Oct 12, 2017 at 16:37

Your Answer

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

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