storage - How exactly are the undo files used when a re-org takes place?

storage – How exactly are the undo files used when a re-org takes place?

 

Firstly, why don’t the CTxInUndo records contain any mention of the parent TXID of the outputs used? Won’t this information be needed to insert these outputs back into the chainstate as UTXOs? How is the chainstate restored using only the information contained in these records?

The block itself is also used in the undo operation. It lists the UTXOs (by txid and output index) which are being spent. The undo files contain the contents of those spent UTXOs in the same order.

Secondy, what about the outputs created by the transactions of this block? Since they should be removed from chainstate after a re-org, why are there no records for them in the undo files?

This information is also extracted from the block data, as it lists the transactions, so the txids of UTXOs that need to be removed in a rollback can be computed from that.

Lastly, why is the height in the CTxInUndo record stored as 2*height (+1 if it was a coinbase output) and not just height? Is the shift by a bit used to store if the transaction was coinbase or not?

UTXOs store the following information for each entry:

  • The txid that created it
  • The output index in the tx that created it
  • The scriptPubKey
  • The amount
  • The height it was created at (to be able to enforce relative timelocks)
  • Whether or not the tx that created it was a coinbase transaction (because the special maturity rules that apply to spending coinbase outputs).

These last two items need to be stored in the undo data, as they cannot be inferred from the spending transaction.

The encoding used is to store the height and coinbaseness as a single number (2*height + coinbase), so it only takes up minimal space in the database.



Source link

Leave a Comment

Your email address will not be published. Required fields are marked *