Try to combine different types of quicksync nodes

[evan-forbes]

Other cosmos networks have occasionally had to rely on quick sync instead of state sync. Quick sync has also been used as an extremely crude form of service discovery for downloading an archive of some sort (block data or state snapshots).

Ideally, service providers could serve each type of archive node and they could be combined later if need be. This would prevent the service provider from having to serve three types of archive nodes. This should in theory be possible, but we first need to try to 100% certain.

To close this issue we should spin up block data archive node and a state snapshot archive node and halt them at some identical height. Then try to add the relevant portions of the data directory to a different node, creating a frankenstein mega-archive node

Note that when we try to combine archive state snapshot nodes, the configuration in app.toml is very important. For block data nodes this should in theory be very simple, and block data could be added to any node type with little configuration.

[rootulp]

Quicksync

Quicksync considerably improves the time it takes to re-sync nodes to the current block. We achieve this by creating various compressed archives that we deliver from high-performance services. The service is crucial for validators and other service providers who require fast deployments or quick recovery of existing services.

State sync

With fast sync a node is downloading all of the data of an application from genesis and verifying it. With state sync your node will download data related to the head or near the head of the chain and verify the data. This leads to drastically shorter times for joining a network.

Notes

• In config/app.toml we need to set snapshot-interval = 0 for Quicksync
• In config/app.toml we can use halt-height to stop node at a particular height