Create a "feathered" wrapper around shardtree
to enable tracking witnesses for multiple candidate chains
#1367
Labels
A-wallet
Area: light wallet backend.
Milestone
As part of enabling wallets to track multiple candidate chain tips (instead of implementing rewind logic for reorgs), it is necessary to track multiple alternative evolutions of the commitment trees in order to enable building witnesses at any candidate chain tip.
Currently
zcash_client_*
use theshardtree
crate to manage a single datastructure for tracking all information about a wallet's notes. It includes checkpoint infrastructure to enable rewinding state.The proposal in this issue is to transition to using
shardtree
to represent the stable base of the tree (for which we, along withzebrad
, assume there is a single canonical chain), and then as a layer on top of that we track the commitment data for the last 100 blocks for all candidate chains that are observed. This layer would combine that information with theshardtree
data to enable a caller to obtain witnesses for tracked notes anywhere within any of the tracked candidate chains.Unlike
zebrad
, the data inshardtree
would not be immutable; due to its structure mutations would occur as a side-effect of non-linear scanning, and we also want the capability to import new viewing keys. But semantically it would only be responsible for tracking data obtained from a chain that itself is treated as immutable.The
shardtree
checkpoint infrastructure would then be repurposed for enabling old anchors within the stable chain section to be used for witness generation (which can be useful when a wallet has been offline for a long time, or when doing a rescan to import a new viewing key).The text was updated successfully, but these errors were encountered: