<p>The UTXO set cache is not a fixed size and the limit isn't a hard limit. New entries can be added to the cache without regards for the maximum cache size. In fact, the cache object itself doesn't even know what the limit is.</p>
<p>Rather what happens is that the cache is flushed periodically. Because the UTXO set only changes during block validation (mempool UTXO set is handled separately elsewhere), this periodic flushing is primarily tied to incoming blocks rather than a timer. After each block is validated, the node determines whether it should flush the cache to disk. There are several conditions that would cause a flush, including being close to the cache limit, and being over the cache limit.</p>
<p>So if during the validation for a block, the cache became full, it would actually just keep growing until the block is fully validated. Then at the end, the entire cache would be flushed to disk and the cache emptied.</p>
<p>Note that LevelDB itself has a cache that is independent of the UTXO set cache.</p>

CC BY-SA 4.0
2020-12-30T06:41:37.887Z
Thanks, I get it. But I have another question.Does the node flush the entire cache to disk every time? Or the node can flush part of the cache to the disk? Can the node decide the flushing stradegy?
GoneV
CC BY-SA 4.0
2020-12-30T06:56:15.040Z
Maybe what I said above is not very clear. I mean, the node flushes the entire cache to the disk every time, or only flushes the UTXOs which is spent in the just validated block?
GoneV
CC BY-SA 4.0
2020-12-30T18:37:53.823Z
The entire cache is flushed, but there is some optimization to avoid writing unnecessary items to disk. For example, if a UTXO was created and spent in between flushes, that UTXO is never written to disk.
Ava Chow
CC BY-SA 4.0
2021-03-12T00:45:13.527Z
What’s the mempool UTXO set and when validating a new transaction,which cache  does the node query?
GoneV
CC BY-SA 4.0
2020-12-29T19:20:39.577Z
2020-12-29T19:20:39.577Z
Ava Chow
<p>The UTXO set is stored on the disk, but some UTXOs are also stored in the cache. When validating a transaction, you need to query the UTXO pointed to by the input of the transaction. First, you go to the cache to find it, if it's not found, you need to go to the disk to find the UTXO. Due to the characteristics of levelDB, the UTXO searched on the disk needs to be written into the cache. If the cache is full at this time, how does the node make room in the cache for the UTXO just found?</p>

<transaction-verification><utxo><leveldb><utxo-set><cache>
When the UTXO in the cache is full, what strategy is used to replace one UTXO with another in the cache?
GoneV
# When the UTXO in the cache is full, what strategy is used to replace one UTXO with another in the cache?

(Asked by: username_0 on 2020-12-29)

The UTXO set is stored on the disk, but some UTXOs are also stored in the cache. When validating a transaction, you need to query the UTXO pointed to by the input of the transaction. First, you go to the cache to find it, if it's not found, you need to go to the disk to find the UTXO. Due to the characteristics of levelDB, the UTXO searched on the disk needs to be written into the cache. If the cache is full at this time, how does the node make room in the cache for the UTXO just found?

**Tags:** transaction-verification, utxo, leveldb, utxo-set, cache


---

## 1 answers

### Answer by username_1 on 2020-12-29. Score: 5 | Accepted answer

The UTXO set cache is not a fixed size and the limit isn't a hard limit. New entries can be added to the cache without regards for the maximum cache size. In fact, the cache object itself doesn't even know what the limit is.

Rather what happens is that the cache is flushed periodically. Because the UTXO set only changes during block validation (mempool UTXO set is handled separately elsewhere), this periodic flushing is primarily tied to incoming blocks rather than a timer. After each block is validated, the node determines whether it should flush the cache to disk. There are several conditions that would cause a flush, including being close to the cache limit, and being over the cache limit.

So if during the validation for a block, the cache became full, it would actually just keep growing until the block is fully validated. Then at the end, the entire cache would be flushed to disk and the cache emptied.

Note that LevelDB itself has a cache that is independent of the UTXO set cache.

> **Comments:**
> **username_0**: Thanks, I get it. But I have another question.Does the node flush the entire cache to disk every time? Or the node can flush part of the cache to the disk? Can the node decide the flushing stradegy?  
> **username_0**: Maybe what I said above is not very clear. I mean, the node flushes the entire cache to the disk every time, or only flushes the UTXOs which is spent in the just validated block?  
> **username_1**: The entire cache is flushed, but there is some optimization to avoid writing unnecessary items to disk. For example, if a UTXO was created and spent in between flushes, that UTXO is never written to disk.  
> **username_0**: What’s the mempool UTXO set and when validating a new transaction,which cache  does the node query?  

---

