1. What is the function of the database cache in a non-pruned node? Given plenty of non-volatile memory space, is there an ideal value?
During the initial block download, Bitcoin Core validates all of the blocks and builds the chainstate as it synchronizes. There are a lot of operations within the chainstate as the blocks are being synchronized and hence they're constantly being added and removed. Hence, dbcache will cache the chainstate to ensure speedy access of it in the memory and hence it allows the client to synchronize faster.
The ideal value is less than your ram, ensure that you're leaving enough ram for your OS and other processes. I personally go for 4gb when I've got an 8gb computer.
2. Ditto for "Number of script threads verifications."
Don't have to change the value. Bitcoin Core automatically uses as many threads as your CPU have, minus one.
1. Any idea why "minus one (core)" when script threads are automatically assigned? Perhaps it's just being conservative to not impinge on other user functions?
2. I am building a Full Node glossary, which I'll transfer to a spreadsheet, and now I add the term "chainstate." Per ChatGPT 4o, is this a valid definition?
Brief: In the context of the BTC blockchain, the "chain state" refers to the current state of all unspent transaction outputs (UXTO's) at a given point in time. Extended: It is a snapshot that represents the set of all active balances and addresses that can be spent in future transactions. The chain state is continually updated as new blocks are added to the blockchain, reflecting the latest valid transactions.
Further, I see that the chain state is stored in permanent memory, I'm assuming, when a block is finalized and added to the height, but that during processing, the chain state is cached in RAM, thus the benefit of increasing RAM to increase efficiency. Agree?
