Oct 28, 2024

TLDR: we don't mark block txs. We can write an entry into the validated_tx table with the tx state and validation context. We don't do this during block download because blocks are validated as a whole, so there is no need to relay the transaction state, block state is sufficient for the next (confirmation) checks, which are necessarily block-based. We considered (and designed for) individual transaction-based validation stage fan-out, which could either use this table or synchronize on the block. However, performance testing showed that as long as there are as many blocks as threads it is much faster to validate whole blocks. The same fan-out was tested for confirmability (within a block) and was also found to be not worth the fan-out cost (although was much closer because it's a single block at a time, and there may be configurations where it makes sense). And the tx validation entries are not necessary apart from validating the chain (the plan was to purge the file periodically). So this will probably end up being used only for transactions that enter via the pool. However validated_bk is written with current state (no context required, as block context is inherent and stored with the header), which allows the confirmation chaser to proceed across validated blocks (changing them to confirmable or unconfirmable. A confirmable block may cycle between confirmed and unconfirmed, but the confirmability state is final.