search

paritytech / subxt

Interact with Substrate based nodes in Rust or WebAssembly
Other
411 stars 245 forks source link

Can we improve on the `chain-spec-pruning` feature flag from the CLI tool? #1313

Open jsdw opened 10 months ago

jsdw commented 10 months ago 
# Compute the state root hash from the genesis entry.
# Enable this to create a smaller chain spec file.
chain-spec-pruning = ["smoldot"]

This non-default feature is used to provide an additional flag to let users prune the returned chainSpec. The reason that we have a feature here is because we have to pull in a number of additional dependencies in order to do this pruning (ie smoldot).

One issue that Tadeo pointed out (https://github.com/paritytech/subxt/pull/1278#discussion_r1406345412) is that this feature flag suddenly means that different users can have different "variants" of the CLI tool.

I think there are a couple of options:

  1. Just remove the feature flag and suck up the extra dependencies. Primarily this will slow compile times a bit when building the CLI tool, but I hope wouldn't have much impact on the overall CI workflows since smoldot is a part of the dependency tree anyway.
  2. Make the feature flag be enabled by default. This means that everybody will get all functionality by default, but if people have a specific reason to want to opt out of certain features, then there is a way to do so. This is different from having to tell people to enable specific functionality by using feature flags, and by default having a less capable CLI tool.

With either of these, we could also try to reduce the number of dependencies needed for this chain spec trimming. Perhaps we can avoid needing to depend on so many things with a bit of work in Smoldot? This is orthoganol to 1 and 2 but makes them a little more appealing :)

I'm torn, but either 1 or 2 would suit me! What do you guys thing @tadeohepperle @lexnv @niklasad1?

niklasad1 commented 10 months ago

Option 3) is to extract the light-sync-state stuff to a separate binary such subxt-cli-lightclient because it's fundamentally different from the existing subxt-cli which is used to generate a subxt codegen from the metadata.

This is on the other hand is used to generate a chainspec.... by calling lightSyncState and AFAIU is that the chainspec may be "outdated" more often then the metadata itself because some bootnodes disappears or something similar.

I think it would be neat to support everything in a single binary without feature flags... if the number of deps are not extreme