Optimize the setting of sync start block in light client mode

[Danie0918]

In the current light client mode, the user can set the synchronization start block. When the block number set by the user is after the historical transaction block number, then the historical transaction will not be synchronized, but displaying 100% synchronization can be misleading to the user.

This needs to be optimized:

1.Add a strong hint when setting the start block number.
2.Consider optimizing the setting of the start block number range not to exceed the latest block number.
3.Add a reminder that the start block number has been set.

[Danie0918]

PRD

【Optimize the setting of sync start block in light client mode】

• Requirement Description:When the block number set by the user is after the historical transaction block number, then the historical transaction will not be synchronized, but displaying 100% synchronization can be misleading to the user.

• Requirement Contents

1. Add a strong prompt when setting the starting block number and require 5 seconds before clicking to confirm the operation.
2. When the set block number is larger than the latest block number, an error is reported prompting the user and making the Confirm button unavailable.
3. Add manually set starting block in the Synchronization dropdown box to support opening the corresponding block in the Explorer.
4. When the re-entered block number is smaller than before, the user needs to be prompted that it will be re-synchronized and provided with a 5-second confirmation.

[yanguoyu]

1. 

Is it a wrong description? Does it should be Set start block number? Or do you mean it will clear all synchronized data and start from the setting start block number?

2. When the set block number is larger than the latest block it errors and changes the set block number to the latest block number, and it takes 5s to confirm.

It notifies that unable to set a higher block number, should we disable the confirm button? Then it is unnecessary to take 5s to confirm. Another problem is that the latest block number will increase about every 10s, so should we refresh the latest block number and check whether the number is bigger every 10s

[Danie0918]

Is it a wrong description? Does it should be Set start block number? Or do you mean it will clear all synchronized data and start from the setting start block number?

I'll change it. It's still set synchronization start block.

It notifies that unable to set a higher block number, should we disable the confirm button? Then it is unnecessary to take 5s to confirm. Another problem is that the latest block number will increase about every 10s, so should we refresh the latest block number and check whether the number is bigger every 10s

Of course, it would be better to just disable it, I had previously thought that we couldn't get the latest blocks in real time.

It doesn't need to be very real-time here, refreshing is unnecessary.

[yanguoyu]

I suggest clearing all synchronized data and starting from the setting start block number if the set start block number is smaller than the last setting(or synced block number). When users set a smaller setting, it will not sync from the smaller setting because the light client has synced to a higher block number.
Should we notify the user or default execute that?

[Danie0918]

I suggest clearing all synchronized data and starting from the setting start block number if the set start block number is smaller than the last setting(or synced block number). When users set a smaller setting, it will not sync from the smaller setting because the light client has synced to a higher block number. Should we notify the user or default execute that?

Notifying the user would be better, I'll add a popup alert later.

[Danie0918]

UI：https://www.figma.com/file/6XNoimRDbFTTNm016rbIdU/Magickbase?type=design&node-id=28438-26974&mode=design&t=AY5lLSGCmoHUwzpQ-0

[Keith-CY]

Another note could be added that if there are no transactions on the chain, or users assure there are no transactions on the chain, the tip block number could be set.

This note comes from the case that users find empty transaction lists on the explorer and they don't know how to continue.

[Danie0918]

Another note could be added that if there are no transactions on the chain, or users assure there are no transactions on the chain, the tip block number could be set.

This note comes from the case that users find empty transaction lists on the explorer and they don't know how to continue.

Is this prompted when setting the start block?But for new wallets, we are not prompted to set the start block.

[Keith-CY]

Another note could be added that if there are no transactions on the chain, or users assure there are no transactions on the chain, the tip block number could be set.
This note comes from the case that users find empty transaction lists on the explorer and they don't know how to continue.

Is this prompted when setting the start block?But for new wallets, we are not prompted to set the start block.

Yes, it should be noted when setting the start point, but it's not the case of a freshly generated wallet(and a new wallet doesn't need the step of specifying the start point because it will be done automatically).

It's the case that a wallet was created before but never used. So the user cannot find the earliest transaction on ckb explorer when the wallet is imported.

[Danie0918]

Another note could be added that if there are no transactions on the chain, or users assure there are no transactions on the chain, the tip block number could be set.

This note comes from the case that users find empty transaction lists on the explorer and they don't know how to continue.

In order to be compatible with the case of setting the starting block for wallets with no transaction history, we have divided the case of setting the starting block into 2 cases:

1. Wallet with transaction history ： Please note that transactions before the synchronization start block will not be synchronized！
2. Wallets without transaction history ： No transaction history found, you can start synchronizing from the latest block or any known block.

What do you think about this? @Keith-CY @yanguoyu

[Keith-CY]

Another note could be added that if there are no transactions on the chain, or users assure there are no transactions on the chain, the tip block number could be set.
This note comes from the case that users find empty transaction lists on the explorer and they don't know how to continue.

In order to be compatible with the case of setting the starting block for wallets with no transaction history, we have divided the case of setting the starting block into 2 cases:

1. Wallet with transaction history ： Please note that transactions before the synchronization start block will not be synchronized！
2. Wallets without transaction history ： No transaction history found, you can start synchronizing from the latest block or any known block.

What do you think about this? @Keith-CY @yanguoyu

I'm afraid these two messages should be displayed at the same time because Neuron cannot get the transaction count before the synchronization.

[yanguoyu]

nervosnetwork/neuron#2994

[silySuper]

verified