Explorer transaction inputs and outputs don't sum up to the same number

[tdroxler]

Copied from alephium/alephium-frontend#1014

https://explorer.alephium.org/transactions/5dd003e4b7f93c06e4c05c0600dcd1a4a8294bfcc648d0c0dc0bc8bd15a4c229

the output exceeds the input by a lot, it looks like the input being displayed for the contract address is wrong and that's what is causing the issue.

It’s a display issue. The full node data is correct:

curl -X 'GET'
'https://node.mainnet.alephium.org/transactions/rich-details/5dd003e4b7f93c06e4c05c0600dcd1a4a8294bfcc648d0c0dc0bc8bd15a4c229'
-H 'accept: application/json'

[tdroxler]

Description

A tx can be submitted in multiple blocks, but eventually only one will be in the main chain.

If we get the output_ref from the problematic input in the tx reported in this issue. We can see that a tx is used in two blocks one is in the main chain, the other is an uncle block

We see that amounts are different, the one in main chain is correct value but the uncle block one is the wrong value returned by the explorer-backend.

uncle block in FE and in backend

main chain block in FE and backend

We can also check the input from the tx 5dd003e4b7f93c06e4c05c0600dcd1a4a8294bfcc648d0c0dc0bc8bd15a4c229

We can see that the explorer-backend has updated the wrong amount.

What's wrong?

I was surprise that the output with key 25bc8e3e4e5022312847ae17a361a40efd90919e0e1ba0d207b3c7b5e29cd9e5 could be defined in two blocks, but with a different amount.

The Output key is derived using the Transaction Id and index. So if the transaction id is different, we'll have a different output key.

The TransactionId is derived from the unsigned tx.

If anything is different in the unsigned tx, the txId will be different. So if the amount of an output is different, it will produce a different txId as well as a different output key.

In our cases here, the contract's inputs aren't defined in the UnsignedTx, but in the Transaction.

So we can totally have a contract output with a different amount but the same output's key.

Which mean outputs in DB are correct.

But why inputs are wrong?

Currently when updating the inputs with the corresponding output, we were assuming that for a given output key, every info: output_ref_tx_hash, output_ref_address, output_ref_amount and output_ref_tokens were unique, even in two different block. So we were updating both main_chain and non-main_chain input with the same info.

This is correct for every fixed output, but not necessarily for generated output as seen previously.

Current impact?

Thx to ChatGPT, we can run this query to find contract outputs that have mismatching amount:

SELECT 
    o1.address,
    o1.key,
    o1.tx_hash,
    o1.amount AS amount_main_chain_false,
    o2.amount AS amount_main_chain_true,
    o1.block_hash AS block_hash_main_chain_false,
    o2.block_hash AS block_hash_main_chain_true
FROM 
    outputs o1
JOIN 
    outputs o2
ON 
    o1.address = o2.address
    AND o1.key = o2.key
    AND o1.tx_hash = o2.tx_hash
    AND o1.main_chain = FALSE
    AND o2.main_chain = TRUE
    AND o1.amount <> o2.amount
    AND o1.block_hash <> o2.block_hash
    AND o1.fixed_output = FALSE
    AND o2.fixed_output = FALSE

On my machine, on the ~80'000'000 outputs and ~ 2'000'000 contract one, the query returns only 80 items, so the migration will be quite light

Nice catch on this case.

How to fix:

We could fix the InputUpdateQueries, but this issue will also be fixed by using the rich-block endpoint, as I was anyway going to work on this very soon, I think it's better to directly go that way.