warp sync without download histrocial blocks

[xlc]

Any docs about it? Can't find them.

To my understanding, it will download finality proof and put the best block to latest block and download historical blocks.
Is it possible to not download historical blocks? I tried with --blocks-pruning=128 --state-pruning=128 and that doesn't seem to have any impacts.

Basically I want to minimize the resource requirement of a parachain node and I don't want to download and store all the relaychain data.

[xlc]

Had a quick check of the code and yeah I don't think it is currently possible to not download historical block. Can we change that?

[ggwpez]

I abused --in-peers 0 --out-peers 0 to prevent that by restarting after it had downloaded everything.
But you probably want current and future blocks to be stored, so its different.

[ggwpez]

cc @bkchr

[bkchr]

I still need to write some issue. I would say that we currently should disable blocks pruning at all. We need some more features to have this working properly. Otherwise we may loose block history.

[xlc]

My goal is to setup lightweight bootnodes that doesn't require too many resources (mostly disk) so we can have multiple of them distributed in different hosts. We have other RPC nodes to archive all blocks and states.

[bkchr]

We have other RPC nodes to archive all blocks and states.

Yes, but the problem is that if enough people are running with blocks pruning other people needing to find these archive nodes in the network.

[xlc]

We need some more features to have this working properly.

Could you explain a bit? Because otherwise I don't think the right solution is don't allow people to run lightweight node.

[bkchr]

Something like this: #523

[girazoki]

hey @bkchr sorry to bother, is this issue still relevant? I find it quite useful for parachain collators as these dont need the whole chain history to produce blocks. The last time we proposed something #2710 we closed it because sync 2.0 would have new features including (potentially) something along this line, is that being worked on?

[bkchr]

I would still say that #2710 (review) holds. I don't think we need/should wait for sync 2.0, because no one is working on this right now.