[feature]: Add `block_header` SQL Table

[ffranr]

The chain_txns table currently stores block_hash and block_height, but not timestamp, which the TW team needs to improve UI/UX. They're currently doing an external lookup to get it. tapd should retain this information instead of discarding it, as it currently does.

Proposed Changes

• Create a new block_header table (integer primary key for re-org simplicity):

  CREATE TABLE block_header (
      id INTEGER PRIMARY KEY,
      hash BLOB UNIQUE NOT NULL,
      height INTEGER NOT NULL,
      timestamp TIMESTAMP NOT NULL
  );

• Update chain_txns to reference block_header(id).

Notes

• Using id as the primary key allows multiple blocks with the same height (re-orgs).
• timestamp can be NULL by default; tapd will populate for new entries, simplifies migration and is fine for out use-case.

Follow-Up Work

• Add and populate the block header timestamp field in asset.ChainAsset.
• Ensure the new asset.ChainAsset field is included in the relevant RPC response messages.

[guggero]

Can make sense as a performance shortcut. But since we can always call ChainBridge.GetBlockTimestamp() or ChainBridge.GetBlockHash() to find out this information (and even a Neutrino client will have all block headers available at all time), I don't see it as super critical.

But if we're going ahead with this, since the block hash is already its uniquely identifying feature, I think we should use that as the primary key. Makes it slightly easier to debug if chain_txns have a block hash rather than a numeric ID.

[ffranr]

@guggero Another reason this issue matters even less is that the full block header is actually already included in the accompanying mint/transfer proof. I totally forgot about that while writing this up. But I suppose eventually the block header will be removed from the proof?

[guggero]

But I suppose eventually the block header will be removed from the proof?

No, I don't think so. It'll always be an integral part of the proof, since it contains the link to the Proof of Work.

[ffranr]

But I suppose eventually the block header will be removed from the proof?

No, I don't think so. It'll always be an integral part of the proof, since it contains the link to the Proof of Work.

@guggero I don't think that's accurate. Please help me to fill in my mental model here:

The block header links the anchoring transaction to the Proof of Work for that block. It also links to the preceding block PoW via PrevBlock. However, this is only useful if the block header can be traced back to the genesis header. Which means that the entire block header chain must be available.

Therefore, if the block header chain must be available separately from the proof, the proof only needs to include the block height for lookup; the block header itself can be omitted from the proof.

Note that the proof already includes separate fields for the block height and tx merkle proof.

[guggero]

the proof only needs to include the block height for lookup; the block header itself can be omitted from the proof.

I disagree for two reasons:

1. With the full block header you can validate the proof of work. Sure, you cannot verify if there's sufficient proof of work in the block to satisfy the difficulty at the given height. But you can verify that some work has gone into the block, so it's worth consulting the chain backend for more information (without this I could spam a universe with fake proofs and cause a lot of requests to the chain backend).
2. The block height is not a uniquely identifying characteristic. Because of re-orgs, we at least need to have the block hash in the proof. But due to the reason above, I think we'll always want the full header to have an initial, self-contained proof of proof-of-work.

[ffranr]

the proof only needs to include the block height for lookup; the block header itself can be omitted from the proof.

I disagree for two reasons:

1. With the full block header you can validate the proof of work. Sure, you cannot verify if there's _sufficient_ proof of work in the block to satisfy the difficulty at the given height. But you can verify that _some_ work has gone into the block, so it's worth consulting the chain backend for more information (without this I could spam a universe with fake proofs and cause a lot of requests to the chain backend).

2. The block height is not a uniquely identifying characteristic. Because of re-orgs, we _at least_ need to have the block **hash** in the proof. But due to the reason above, I think we'll always want the full header to have an initial, self-contained proof of proof-of-work.

Good points. I'm convinced. I understand that even a small amount of PoW, such as a single block, still conveys meaningful information.