2

Question about the ethereum blockchain:

If I walk the blockchain like so:

for block in blockchain:
    for transaction in block:
        receipt = getTransactionReceipt(transaction)
        for log in receipt:
            doSomethingWithLog(log)

Is it conceivable that I could pull down a transaction mined by miner "A" with receipt that appears successful, and has logs, only to have a subsequent miner "B" mine the same transaction and see it fail, and then this second miner's version (failing, no longs) later becomes the accepted confirmed block, so that miner "A"s version is orphaned and removed from the blockchain?

If this is conceivable, then any consequences of "doSomethingWithLog" would have to be un-done when the later version of the transaction (with its failing state and lack of logs) is encountered.

Is it possible for events (logs) to be detectable on a blockchain node at a given point in time, only to be later "revoked" in a later, blockchain-accepted version of the same transaction, if that later version results in failure?

Any input would be greatly appreciated!

Gregory Hassett
  • 121
  • 1

1 Answers1

1

Yes, this is possible, and happens all of the time. Small reorganizations (one or two blocks lost) are quite common.

The solution is to wait for n blocks after receiving a receipt before acting on the result of the transaction. The probability that a block is reverted aftern blocks are mined on top of it is exponentially small in n, so if you wait for say 100 blocks after the receipt is received, then check that the block of interest is still in the chain, you can be quite sure it will be there forever.

Blocks mined on top of the block of interest are called "confirmations", and in Ethereum 12 is considered enough for most uses

What number of confirmations is considered secure in Ethereum?

Tjaden Hess
  • 37,046
  • 10
  • 91
  • 118