-
Notifications
You must be signed in to change notification settings - Fork 128
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Work with the new dcrd reorg ntfn sequence
This modifies reorg handling to work with dcrd RPC v5.0.0. - Modify collectionQueue to verify that new blocks are in sequence - Bump required dcrd JSON RPC version to 5.0.0 - Create rpcutils.CommonAncestor function to provide full reorg details to each reorg handler and avoid redundant RPCs. - Rewrite each ChainMonitor's reorg handling. Each of dcrsqlite, dcrpg, and stakedb use a switchToSideChain function. With blockdata, ReorgHandler simply stores the new chain tip's block data in the reorgDataSavers, which is presently just the explorer UI update. There is no longer a need for BlockConnectedHandler in dcrpg and dcrsqlite, so it is removed. The goroutines are no longer started of course, and the synchronous collectionQueue now includes only sdbChainMonitor.BlockConnectedSync and wsChainMonitor.BlockConnectedSync (the synchronous collection and storage functions for the stakedb and blockdata packages). In short, the roles of each data saver's ReorgHandler are: blockdata: Collect and store in the special reorgDataSavers the data for just the new chain tip block. This is presently used to update the explorer UI. stakedb: Disconnect the old chain blocks from the StakeDatabase, then connect the new chain blocks. dcrsqlite: Collect and store data for the new chain blocks. The data for the old chain is not presently removed as it is not critical. dcrpg: This is the most complex one. All data related to old chain blocks are updated to reflect their new side chain status. The blocks in the new chain (from a side chain) are stored in the DB, while updating existing records, which may be from the disconnected blocks. The entire process is much simpler overall. One source of complexity is the new reorg queue in the notification package, and the new and expanded txhelpers.ReorgData type that adds the entire lists of blocks in the old and new chains as well as the common ancestor. The reorg queue is processed by notification.ReorgSignaler, which uses the new rpcutils.CommonAncestor to get the common ancestor and the full list of block in the old and new chains. rpcutils.CommonAncestor finds the common ancestor and full list of block in the old and new chain by iteratively interrogating dcrd via RPC for blocks' previous block hash until the same hash is encountered for both chains at the same height. This approach is used as opposed to two other ways: Figuring out the common ancestor in each package's ReorgHandler using whatever data resources they have. This is redundant and more error prone. Going back from the old chain tip until dcrd indicates the chain has gone from side (-1 confirmations) to main (non-negative confirmations). This is not robust as there may be data races if subsequent reorganization takes place during the handling of an earlier reorg.
- Loading branch information
Showing
11 changed files
with
800 additions
and
662 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.