Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warp sync without download histrocial blocks #8

Open
xlc opened this issue May 10, 2023 · 10 comments
Open

warp sync without download histrocial blocks #8

xlc opened this issue May 10, 2023 · 10 comments
Labels
I5-enhancement An additional feature request.

Comments

@xlc
Copy link
Contributor

xlc commented May 10, 2023

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
Copy link
Contributor Author

xlc commented May 10, 2023

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?

@xlc xlc changed the title warp sync warp sync without download histrocial blocks May 10, 2023
@ggwpez
Copy link
Member

ggwpez commented May 10, 2023

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
Copy link
Member

ggwpez commented May 17, 2023

cc @bkchr

@bkchr
Copy link
Member

bkchr commented May 17, 2023

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
Copy link
Contributor Author

xlc commented May 17, 2023

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
Copy link
Member

bkchr commented May 17, 2023

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
Copy link
Contributor Author

xlc commented May 17, 2023

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
Copy link
Member

bkchr commented May 17, 2023

Something like this: #523

@the-right-joyce the-right-joyce transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I5-enhancement An additional feature request. and removed J0-enhancement labels Aug 25, 2023
fixxxedpoint pushed a commit to fixxxedpoint/polkadot-sdk that referenced this issue Jun 19, 2024
@girazoki
Copy link
Contributor

girazoki commented Jul 3, 2024

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
Copy link
Member

bkchr commented Jul 3, 2024

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.

liuchengxu added a commit to subcoin-project/polkadot-sdk that referenced this issue Sep 20, 2024
* Introduce sc-fast-sync-backend

* Introduce subcoin-test-service

* Introduce various block executors

* Integrate new block executor into node

* Assert all executors produce the same state root and fix clippy

* Replace substrate-test-runtime with subcoin-runtime in sc-fast-sync-backend

This avoids more unnecessary deps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I5-enhancement An additional feature request.
Projects
Status: Backlog 🗒
Status: backlog
Development

Successfully merging a pull request may close this issue.

6 participants