78e2e35f80
## Description When locally working with golangci-lint, we can see that there were many deprecation warnings about sdk.Int. This PR resolves that and makes 1-2 other linting related changes. Issue on linting coming next. This also moves BitCurve to bitCurve. I expect that this set of changes will require several pull requests, one of them to the settings for the linter. It also does a gofumpt, because we had various formatting-related linters fail, too. --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [x] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [x] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [x] reviewed "Files changed" and left comments if necessary - [x] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) |
||
|---|---|---|
| .. | ||
| mock | ||
| types | ||
| README.md | ||
| export_test.go | ||
| manager.go | ||
| manager_test.go | ||
README.md
Pruning
Overview
Pruning is the mechanism for deleting old application heights from the disk. Depending on the use case, nodes may require different pruning strategies. For example, archive nodes must keep all the states and prune nothing. On the other hand, a regular validator node may want to only keep 100 latest heights for performance reasons.
Strategies
The strategies are configured in app.toml, with the format pruning = "<strategy>" where the options are:
default: only the last 362,880 states(approximately 3.5 weeks worth of state) are kept; pruning at 10 block intervalsnothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)everything: 2 latest states will be kept; pruning at 10 block intervals.custom: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
If no strategy is given to the BaseApp, nothing is selected. However, we perform validation on the CLI layer to require these to be always set in the config file.
Custom Pruning
These are applied if and only if the pruning strategy is custom:
pruning-keep-recent: N means to keep all of the last N statespruning-interval: N means to delete old states from disk every Nth block.
Relationship to State Sync Snapshots
Snapshot settings are optional. However, if set, they have an effect on how pruning is done by
persisting the heights that are multiples of state-sync.snapshot-interval until after the snapshot is complete. See the "Relationship to Pruning" section in snapshots/README.md for more details.