Simplify chain update #9
Conversation
These methods allow us to query for checkpoints contained within the linked list by height. This is useful to determine checkpoints to fetch for chain sources without having to refer back to the `LocalChain`. Currently this is not implemented efficiently, but in the future, we will change `CheckPoint` to use a skip list structure.
We impl `PartialEq` on `CheckPoint` instead of directly on `LocalChain`. We also made the implementation more efficient.
This creates a checkpoint linked list which contains all blocks.
Previously, we would update the `TxGraph` and `KeychainTxOutIndex` first, then create a second update for `LocalChain`. This required locking the receiving structures 3 times (instead of twice, which is optimal). This PR eliminates this requirement by making use of the new `query` method of `CheckPoint`. Examples are also updated to use the new API.
These methods are no longer needed as we can determine missing heights directly from the `CheckPoint` tip.
This gets the genesis hash of the env blockchain.
We ensure that calling `finalize_chain_update` does not result in a chain which removed previous heights and all anchor heights are included.
I felt things didn't have to be so complicated. The chain could easily be updated in one function rather than spread across two. The logic needs at least one less loop.
evanlinjin
force-pushed
the
clean_esplora
branch
4 times, most recently
from
91e8c91
to
bf74f18
Compare
evanlinjin
force-pushed
the
clean_esplora
branch
from
eaebdee
to
e5c81a2
Compare
There was a problem hiding this comment.
This looks really good. Thank you for showing me a much cleaner approach. My only concern is the following:
The reason why I split chain_update_... into two methods is we want to fetch latest blocks before getting transaction update. We are using the local tip to determine "last-scanned block" and there are users which want to alternate between Esplora and block-by-block sources.
I will try update this to fetch latest blocks before getting transactions.
I don't think so. We want these two things to be completely decoupled. A chain update is orthogonal to the transaction update except that you want to try and grab heights that transactions seem to exist at. I didn't understand the motivation you gave. Why can't you switch between block-by-block and esplora here? |
evanlinjin
force-pushed
the
clean_esplora
branch
4 times, most recently
from
a504a1d
to
77d3595
Compare
No description provided.