Allow users to sync from a specific block height

Summary

Currently, creating / restoring a Wallet takes a long time, dependent on the blockchain size. We should explore the option to optimize performance by allowing users to sync from the point when the user's wallet has been created.

This epic captures all the requirements and the work needed to fulfill this initiative.

Requirements

Let users specify the block height to sync from on Wallet restoration (with a link to Wiki, also should be emphasized it's an optional step)
Allow users to switch between sync from the genesis or a specific block height (option in Settings)
Make sure the Restore wallet flow is triggered if a user tries to access a wallet, different than the currently stored one in memory
Make sure new Wallet doesn't sync from the beginning of the blockchain (Create Wallet flow)
Display the current block height on Wallet creation, emphasizing saving this is not essential (unlike the seed phrase) and can be retrieved later from the Settings pane.
Redesign the landing page so that unlocking with a quick access to creating, resetting, and unlocking a Wallet

Each requirement needs a design, as well as making sure we have the APIs on the service side, dusk-wallet-js (eg. for setting the height to sync from, to receive the current block height, etc).

Tasks

web-wallet:

[x] #1535
[x] https://github.com/dusk-network/rusk/issues/1561
[x] https://github.com/dusk-network/rusk/issues/1568
[x] https://github.com/dusk-network/rusk/issues/1567
[x] https://github.com/dusk-network/rusk/issues/1570
[x] https://github.com/dusk-network/rusk/issues/1595
[ ] https://github.com/dusk-network/rusk/issues/1569

wallet-js:

[x] https://github.com/dusk-network/dusk-wallet-js/issues/75
[x] https://github.com/dusk-network/dusk-wallet-js/issues/76
[x] https://github.com/dusk-network/dusk-wallet-js/issues/77
[x] https://github.com/dusk-network/dusk-wallet-js/issues/93

docs:

[ ] https://github.com/dusk-network/docs/issues/57 [In PR]

Benefits

Syncing from a recent block height is considerably faster as there is significantly less historical data to process. Partial synchronization also uses less disk space and reduces network bandwidth consumption, which could be important for users with limited resources.

Risks

There are several risks related to syncing from a specific block height:

Missed relevant transactions which can lead to incorrect balance.
For entities that need to maintain comprehensive records for regulatory or compliance reasons, not having the full blockchain data could pose legal risks or complicate compliance efforts.
Syncing from a later point could expose the wallet to vulnerabilities that might have been patched in earlier blocks.
In the event of a blockchain reorganization (reorg), it's possible that the user's chosen block height becomes invalidated.

Risk Mitigation Strategies

Clear Warnings: Strongly emphasize the risks of missing transactions and security issues.
Guidance on Block Height Selection: Provide resources or tools to assist users in selecting a suitable block height that maximizes chances of not missing relevant transactions. Ensure that the initial block or snapshot used for synchronization comes from a trusted and reputable source.
User-Controlled Checkpoints: Allow advanced users to specify their own trusted block height or checkpoint, offering flexibility to those who have the knowledge to make informed decisions about their starting point.
Signature Verification: Implement a mechanism to verify the integrity and authenticity of the initial block data or snapshot through cryptographic signatures.
Robust Reorg Handling: Implement a reliable mechanism to detect and handle blockchain reorganizations, including automatic resynchronization if necessary.
Fallback to Full Sync Option: Offer users the option to perform a full sync from the genesis block if they prefer the highest level of security and verification.
Regular Software Updates: Maintain and update the wallet software regularly to address any emerging vulnerabilities or threats.

Mar 10 '24 15:03 nortonandreev

This is what Monero does: https://www.getmonero.org/resources/user-guides/change-restore-height.html#what-is-the-wallet-restore-height

Mar 11 '24 11:03 ZER0

This is what Monero does: https://www.getmonero.org/resources/user-guides/change-restore-height.html#what-is-the-wallet-restore-height

Lovely, thank you! Was looking for this info. To sum up, Monero:

suggests the custom block height should be the number of the block which included the first incoming transaction to your wallet
if unsure of the block height, suggests entering a lower restore height instead of a higher one (so that transactions are not missed)
supports a date – apart from the block height (I think this is useful, as users might not remember the block height, but instead might have an estimated date on when they have created their wallet) [Update: Won't do]

set_new_restore_height-date