Spent and Unspent UTXO Append-Only Merkle Roots for Fuel Block Header Design

Research
1

Reposting this from the fuel-specs repo:

Many developers and researchers have been inquiring about proving a users balance at a specific block height with a Fuel light client, presently this sort of thing is not included in our base specified block header design.

If this is a feature people want for cryptographic verification purposes, we should consider this. Happy to open the discussion here on the forum.

3 Likes
2

I have a follow-up question to better understand the topic.

Fuel light clients can only prove inclusion of UTXOs and transactions

So, the light clients are capable of determining whether the transactions and UTXOs are valid. Is there also a way to determine if all transactions and all unspent UTXOs (plus maybe some spent ones) are being returned by a node? Or some of them might be skipped?

3

So, the light clients are capable of determining whether the transactions and UTXOs are valid.

More that they are included, validity would require the entire state and full node to check. But we can show that the UTXOs are included, if they are not slashed within the challenge window they are considered final and are likely to be valid in almost all cases.

Is there also a way to determine if all transactions and all unspent UTXOs (plus maybe some spent ones) are being returned by a node? Or some of them might be skipped?

You could infer this information if a full node doesn’t return a transaction proof of the specific index of transaction you are looking for in a block yes. So if a block has 3 transactions, that transaction count will be in the header, and the full node should be able to surface the transaction inclusion proofs for each one of those transactions to the transactionRoot in the block header.

So in theory, you could demand the proof for every transaction from every block yes.

1 Like
4

Great explanation! It’s clear that light clients can verify the inclusion of UTXOs and transactions, but the validity still requires full node checks. The ability to request proofs for every transaction from the full node adds a layer of security and transparency. Looking forward to seeing how this feature evolves!