1

There are currently multiple transaction hash collisions in consecutive blocks in EOS as noted below:

  1. 7dcdcdb558028c7703faddee96e1aa48e9bbe7cd3a07cd0a74513a3599185b40 at block 10712420 and 10712421
  2. 23361432428f9fdf3f6c2d567b1742e365016d44866f41fceac41962855788ef at block 12587093 and 12587094
  3. 12e1ff77c2353e6c6aedbfdbc553d5ef37795060bc950ba5ae3184309d3f8008 at block 13669127 and 13669128
  4. 58fd855c2351c07daefb947fd8996381ae10b788812bea903ceffa668a451112 at block 13669235 and 13669236
  5. 1d3c6d1db78b1c76b5aedd75c5825fac2a2a81dddfaa29966fd4f6a1afa56fd1 at block 15717258 and 15717259
  6. 1109ca2314426f745f378d3ae7384c859e9a60b8b254ab87e0ad6c41b444d8ed at block 19109823 and 19109824
  7. 2fc89e92e8e5230d18e3611ed37bf628db94463d9ad62be1e763111bf2ad1cc6 at block 19656619 and 19656620
  8. 6a94a62c6467de6392bb7a6b2106d84414c1fcaaa8e1bc47b053e8213f422f73 at block 22037546 and 22037547

Using the Trace API, I have found in the case of the above 8 collisions, the transactions to be exactly the same in the consecutive blocks with the only difference being CPU and NET usage.

However, in the following two transaction hash collisions in consecutive blocks, the transactions are not exactly the same and have different set of eosio.token transfers associated with them:

  1. 0bd119c4fea6a1147b0eb6cfab1363c1c83b12eaab466fae35b74906d4cf69bc at block 24301274 and 24301275
  2. f0da5255676a1789b617fad1cd1940eba308d89013d03b963ecf6bbda5931288 at block 24305245 and 24305246

I'm sure I'll find more collisions as I progress through the chain. So I had a couple of queries:

  1. Are these transaction hash collisions a feature or a bug? I'm inclined to believe it's a rare feature related to some form of smart contract activity since they always happen in consecutive blocks. But I can't seem to find any documentation on this.
  2. If it's a bug, has it been fixed later in the chain and do you know at what height? Also do you know how many such collisions are there in the chain?
  3. If it's a feature, what exactly is causing this peculiar behavior and what is the suggested workaround to handle this since traditional understanding is that transaction hashes are unique and only occur once.
  4. In the case of 0bd119c4fea6a1147b0eb6cfab1363c1c83b12eaab466fae35b74906d4cf69bc at block 24301274 and 24301275 which has different set of eosio.token transfers in each transaction instance, which one is the valid transaction? Or are they both valid transactions with both set of eosio.token transfers taking place onchain?

For reference, here's different Block Explorer views on transaction 0bd119c4fea6a1147b0eb6cfab1363c1c83b12eaab466fae35b74906d4cf69bc:

  1. EOSPark: https://eospark.com/tx/0bd119c4fea6a1147b0eb6cfab1363c1c83b12eaab466fae35b74906d4cf69bc. Seems to have aggregated both transaction instance's actions under the same transaction in Block 24301275
  2. EOSFlare: https://eosflare.io/tx/0BD119C4FEA6A1147B0EB6CFAB1363C1C83B12EAAB466FAE35B74906D4CF69BC. Seems to have aggregated both transactions instance's actions under the same transaction in Block 24301275
  3. Bloks.io: https://bloks.io/transaction/0bd119c4fea6a1147b0eb6cfab1363c1c83b12eaab466fae35b74906d4cf69bc?tab=traces. Seems to have included only the actions from first instance of that transaction in Block 24301274
Improve this question

0

Reset to default

Your Answer

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