<p>It seems to me that this would be a performance hit with no real benefits.</p>
<p>Committing a Merkle root of the UTXO set to each block would certainly be possible (of course you would need to devise an algorithm to build the Merkle tree deterministically, as each client would have to do that by itself), and with some clever performance optimizations (as you mentioned in the comments, you might not need to rebuild the entire Merkle tree for each block) it might be somewhat manageable.</p>
<p>However, SPV clients (who use the Merkle tree of transactions) can already &quot;prove&quot; (to the extent that non-full nodes can prove anything) that a UTXO has been created by a transaction. Using the Merkle root of the UTXO set would only add the ability to prove that the specific UTXO hasn't yet been spent by another transaction.</p>
<p>If the UTXO belongs to you then you probably don't need to ask other nodes if you've already spent it. If the UTXO doesn't belong to you then you probably don't need to know anything about it. In short, I don't see a use case.</p>

CC BY-SA 4.0
2021-11-06T09:39:08.270Z
2021-11-06T09:39:08.270Z
Vojtěch Strnad
<p>I'm implementing my own Cryptocurrency similar to Bitcoin from scratch in C++ (just for learning and deeper understanding) and had an interesting design question.</p>
<p>My understanding is that the Merkle tree is only for nodes that do not want to download the entire blockchain (&quot;lite nodes&quot;) ... so they can be sent a single transaction and verify it by getting the hashes of all previous blocks and a number of hashes logarithmic in the number of transactions within a particular block.</p>
<p>It seems to me you could accomplish something with similar functionality by instead computing the Merkle tree over the entire ledger state. Even with 1 billion accounts, this comes down to 30 hashes to verify a portion of the ledger. You would write the merkle root of the ledger state to the root of each block node. To verify a transaction you just download the new account value, along with the 30 or so hashes.</p>
<p>Assuming a 20byte wallet address + 8byte double for value ... we get ~28GB of data for a billion addresses... doable in memory on beefy modern server hardware.</p>
<p>This is how I am thinking of approaching it in my design -- am I missing something critical in the security model here?</p>

CC BY-SA 4.0
2021-11-04T21:34:16.423Z
It’s off topic here, but your understanding of the basics here is pretty lacking, I’d do a lot more research on the fundamentals before trying to design something better. You would be absolutely nuts to store monetary values as a float for example.
Claris
CC BY-SA 4.0
2021-11-04T22:54:11.313Z
That's not super helpful. I'm trying to understand why this design wouldn't work. I'm not trying to design something better, just make something functional ... but I feel like I'm missing something.
user491880
CC BY-SA 4.0
2021-11-05T00:01:06.603Z
Hashing the whole UTXO for Bitcoin takes many minutes, we expect the network to be able to synchronize in less than a second.
Claris
CC BY-SA 4.0
2021-11-05T00:36:18.157Z
So if I understand correctly this design is infeasable due to performance rather than the security of the construction? Do you need to hash the UTXO entirely each time though? You don't need to re-construct the entire MerkleTree of the UTXO per block... you just need to re-compute log(N)*k nodes where k is the number of wallets that changed their value or were inserted. The main problem I see is that you will likely be only able to keep a Merkle tree for the current block due to memory limitations...so you would not be able to answer an arbitrary balance query for any block.
user491880
CC BY-SA 4.0
2021-11-05T04:59:30.683Z
You are confusing a UTXO model and an account model, they are distinct architectural approaches. See: https://bitcoin.stackexchange.com/questions/49853/utxo-model-vs-account-balance-model
chytrik
CC BY-SA 4.0
2021-11-05T05:20:48.083Z
Thank You! this account model is more along the lines of what I was imagining. Was not aware other cryptocurrencies have used it before.
user491880
<merkle-tree>
Why store Merkle tree of transactions rather than global ledger state?
user491880
# Why store Merkle tree of transactions rather than global ledger state?

(Asked by: username_0 on 2021-11-04)

I'm implementing my own Cryptocurrency similar to Bitcoin from scratch in C++ (just for learning and deeper understanding) and had an interesting design question.

My understanding is that the Merkle tree is only for nodes that do not want to download the entire blockchain ("lite nodes") ... so they can be sent a single transaction and verify it by getting the hashes of all previous blocks and a number of hashes logarithmic in the number of transactions within a particular block.

It seems to me you could accomplish something with similar functionality by instead computing the Merkle tree over the entire ledger state. Even with 1 billion accounts, this comes down to 30 hashes to verify a portion of the ledger. You would write the merkle root of the ledger state to the root of each block node. To verify a transaction you just download the new account value, along with the 30 or so hashes.

Assuming a 20byte wallet address + 8byte double for value ... we get ~28GB of data for a billion addresses... doable in memory on beefy modern server hardware.

This is how I am thinking of approaching it in my design -- am I missing something critical in the security model here?

**Tags:** merkle-tree

> **Comments:**
> **username_1**: It’s off topic here, but your understanding of the basics here is pretty lacking, I’d do a lot more research on the fundamentals before trying to design something better. You would be absolutely nuts to store monetary values as a float for example.  
> **username_0**: That's not super helpful. I'm trying to understand why this design wouldn't work. I'm not trying to design something better, just make something functional ... but I feel like I'm missing something.  
> **username_1**: Hashing the whole UTXO for Bitcoin takes many minutes, we expect the network to be able to synchronize in less than a second.  
> **username_0**: So if I understand correctly this design is infeasable due to performance rather than the security of the construction? Do you need to hash the UTXO entirely each time though? You don't need to re-construct the entire MerkleTree of the UTXO per block... you just need to re-compute log(N)*k nodes where k is the number of wallets that changed their value or were inserted. The main problem I see is that you will likely be only able to keep a Merkle tree for the current block due to memory limitations...so you would not be able to answer an arbitrary balance query for any block.  
> **username_2**: You are confusing a UTXO model and an account model, they are distinct architectural approaches. See: https://bitcoin.stackexchange.com/questions/49853/utxo-model-vs-account-balance-model  
> **username_0**: Thank You! this account model is more along the lines of what I was imagining. Was not aware other cryptocurrencies have used it before.  

---

## 1 answers

### Answer by username_3 on 2021-11-06. Score: 0

It seems to me that this would be a performance hit with no real benefits.

Committing a Merkle root of the UTXO set to each block would certainly be possible (of course you would need to devise an algorithm to build the Merkle tree deterministically, as each client would have to do that by itself), and with some clever performance optimizations (as you mentioned in the comments, you might not need to rebuild the entire Merkle tree for each block) it might be somewhat manageable.

However, SPV clients (who use the Merkle tree of transactions) can already "prove" (to the extent that non-full nodes can prove anything) that a UTXO has been created by a transaction. Using the Merkle root of the UTXO set would only add the ability to prove that the specific UTXO hasn't yet been spent by another transaction.

If the UTXO belongs to you then you probably don't need to ask other nodes if you've already spent it. If the UTXO doesn't belong to you then you probably don't need to know anything about it. In short, I don't see a use case.


---

