Support changing/downgrading state pruning mode

[nazar-pc]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

State pruning modes can be seen as subsets of each other. For example archive-canonical is a subset of archive, while constrained to a number of blocks can be a subset of both archive-canonical and archive. Even constrained pruning with 10k blocks is a subset of constrained pruning with 100k blocks.

Unfortunately right now node will refuse to start if pruning mode is different from what it was when database was created originally, even though technically it should be possible to downgrade from one of the pruning modes to its subset.

While current behavior generally makes sense for Substrate CLI, when Substrate is used as a library it might be desired to be able to change pruning modes over time. Our Subspace protocol didn't support pruning of some kinds originally, but then evolved to support it, but we're stuck with large state databases for existing users due to lack of upgrade to more constrained versions of it.

Request

Support changing/downgrading of pruning modes like this:

• archive -> archive-canonical
• archive-canonical -> archive
• archive or archive-canonical -> number
• number -> lower number

Solution

No response

Are you willing to help with this request?

Maybe (please elaborate above)

[bkchr]

• number -> lower number

This is already supported.

For the other ones, it makes sense and we should also support them.

[liuchengxu]

Another use case is to sync a partial archive node, i.e.,

• number -> archive/archive-canonical

Specifically, a new node is started with fast sync to get synced quickly, afterward, it can be transitioned to operate as an archive node. The key difference for a partial archive node is the state before the snapshot is not accessible. In Ethereum, it's possible to initiate with snap sync and later switch to an archive node.

[nazar-pc]

number -> archive/archive-canonical

This will require more implementation logic, the cases I described are much simpler because they are subsets of each other.

[liuchengxu]

I feel that supporting number -> archive/archive-canonical may be easier since no pruning will be required. Anyway, I was just adding that we should support it as well since this issue is generally about changing the state pruning mode :P

[nazar-pc]

This is about simply removing stuff from the database that is no longer needed. Downloading stuff that is missing involves networking and a whole bunch more complexity.

[liuchengxu]

Well, I don't see how number -> archive/archive-canonical adds more downloading logic, it's okay that the state before the transition point is missing, which makes a partial archive node as Ethereum supports.