Both zcashd and zcash_client_* build their state around a canonical chain tip. When a reorg happens, that state is rewound to undo the effects of the old chain, and then the effects of the new chain are applied. If a miner battle is ongoing, this could result in repeated flip-flopping between chain states.
zebrad takes a different approach: it treats all data that is at least 100 blocks behind the current chain tip as "stable" (and writes it to persistent data storage), and then tracks all state about every candidate chain that exists within the last 100 blocks of the current best chain tip. This means that there are no rollbacks: new blocks always advance one of the existing candidate chains (or create a new one), and then when a new block advances a new chain beyond the existing "high water mark", the non-canonical chains that branched from the now-stable height are pruned and the stable block is persisted.
We should enable wallets built with zcash_client_backend to represent this in their wallet state. These wallets would maintain "alternative wallet views" based on the chains they have experienced, with the "real" wallet balance etc. coming from whatever is the current canonical chain tip.
Then at the stabilisation boundary, any now-pruned chains have their corresponding wallet states merged as appropriate into the remaining wallet states (e.g. any transaction that was only mined on a now-pruned chain would still be visible in the wallet, but as "expired unmined" or similar).
Both
zcashdandzcash_client_*build their state around a canonical chain tip. When a reorg happens, that state is rewound to undo the effects of the old chain, and then the effects of the new chain are applied. If a miner battle is ongoing, this could result in repeated flip-flopping between chain states.zebradtakes a different approach: it treats all data that is at least 100 blocks behind the current chain tip as "stable" (and writes it to persistent data storage), and then tracks all state about every candidate chain that exists within the last 100 blocks of the current best chain tip. This means that there are no rollbacks: new blocks always advance one of the existing candidate chains (or create a new one), and then when a new block advances a new chain beyond the existing "high water mark", the non-canonical chains that branched from the now-stable height are pruned and the stable block is persisted.We should enable wallets built with
zcash_client_backendto represent this in their wallet state. These wallets would maintain "alternative wallet views" based on the chains they have experienced, with the "real" wallet balance etc. coming from whatever is the current canonical chain tip.Then at the stabilisation boundary, any now-pruned chains have their corresponding wallet states merged as appropriate into the remaining wallet states (e.g. any transaction that was only mined on a now-pruned chain would still be visible in the wallet, but as "expired unmined" or similar).