Nov 4, 2024

Yes, verifying prior existence and unspentness in the strong chain is more expensive for a number of reasons, though the size of the index isn't really one of them. Indexation performance is almost entirely a function of rate of hash collisions, and that is controllable via config. It is also affected by the amount of RAM, and with sufficient RAM the entire store and all indexes are memory resident. One of the reasons it's slower is that the data model is relational, so there are a large number of queries involved in comping to resolution of this question. Another is that we store conflicting txs and unconfirmed txs in the same tables. However these are tradeoffs. Rapid response to these two questions is not the measure of performance during catchup, compact notification, or otherwise. The time where it would be considered most critical might be during compact block notification for a miner. We operate under the assumption (as does the usefulness of the protocol itself) that in this scenario we have already seen most if not all txs in the block, apart from the coinbase. In that ideal case libbitcoin has already validated, stored, and indexed all but one tx, which itself does not spend. These txs are not revalidated (unless there is a context incompatibility from the time of pooling, which would be very rare), moved or modified in any way upon possible confirmation. We also don't construct or serialize a block. We store/index only the header and coinbase, under PoW protection, and then ensure that the block is valid and confirmable via navigation of the tx graph. Unless there is a miss in the pool (which may require a store lookup or peer query) the question of validity can be answered without querying the store. Similarly block templates can be generated from the pool without hitting the store. The graph does not store txs, and for a miner it would be entirely reasonable to have every confirmable (including conflicts) tx ever seen represented in the graph in RAM.