2

A few hours ago, I was testing my dapp on ropsten and something strange happened.

I sent a transaction (A), to the blockchain, it got mined and my server synced it. Then 30 minutes later, I sent another transaction (B) and called the same function. B was mined successfully and A was mined again in the same block as B. There is no trace of the transaction A that I sent 30 minutes before like it was rolled back. It's like it was mined, then reverted and then remined 30 minutes later.

What is happening? My dapp relies on live-sync and this would be a game breaking. Thanks for your help.

pan1994
  • 169
  • 7

2 Answers2

2

This is normal in the event of a chain reorganization. Blocks can be rolled back if newer blocks with more work appear (basically, if your chain is at block N, and someone broadcasts block N+1 with a different block N as its parent, the chain will reorganize and drop the block N you saw previously).

When this happens, any transactions in the rolled back blocks are returned to the txpool. Moreover, since block template construction tends to pick similar transactions based on gas usage and price, many of the now-unconfirmed transactions will be mined into the blocks that are now part of the chain, resulting in only a small portion of transactions returning back to the tx pool.

These transactions can then be mined into a future block, which is what you seem to have encountered.

Note that even in all this reorganization, transaction A will always be before transaction B since the nonce order is still respected.

This is also why exchanges and other services wait for multiple confirmations before crediting a user account with the results of a transaction. On the mainnet, you are unlikely to see reorganizations spanning 30 minutes, but it is certainly not impossible. Testnets tend to be a little less reliable, however.

Raghav Sood
  • 4,040
  • 2
  • 11
  • 20
1

What could theoretically have happened is an ephemeral chain fork, and then a chain reorganisation.

This happens when part of the network accepts a block containing your transaction to be canonical, only to find that another larger part of the network has accepted a different version of the same block to be canonical.

The version of the block containing your transaction is then marked as invalid, and your transaction put back into the transaction pool. If there are other, higher-priced transactions in the pool, then your transaction will have to wait for its place in the market.

My dapp relies on live-sync and this would be a game breaking.

I'm not sure how you're defining "live-sync", but a couple of things to think about.

Firstly, your transaction may or may not be mined into a block in what you consider a reasonable time, depending on the load on the network, and the current state of the gas price market. If your transaction is priced too low, then it is less likely to be included in a block in a timely manner.

Secondly, it's worth waiting for a certain number of confirmations before considering a the block containing your transaction as valid. (This previous answer recommends 12. I'm not sure if this number is still standard practice.)

(Here's an article on handling chain reorganisations from the perspective of Dapp development. External link.)

Richard Horrocks
  • 37,835
  • 13
  • 87
  • 144
  • By live-sync I mean I'm syncing every event on a centralized database to recreate the state of the blockchain and be able to query data. It would be unacceptable for an event to be reverted after it has been synced on my database. Would waiting for 12 confirmations give me 100% finality? Thank you – pan1994 Oct 11 '18 at 09:12
  • Okay, understood. Currently, there's no hard-and-fast finality in Ethereum, even with 12 confirmations. With enough hashing power, an adversarial user could re-mine a chain of arbitrary length to their suiting, choosing which transactions to revert. However, this is unlikely to happen, given the hashing power required. For all intents and purposes, 12 confirmations is considered probabilistically "safe". – Richard Horrocks Oct 11 '18 at 09:23
  • (To add, stronger finality guarantees will come into force once Ethereum moves to proof of stake. My comment above is for the current proof of work consensus model.) – Richard Horrocks Oct 11 '18 at 09:33