Storage and Fees with the Cosmos SDK and Ignite CLI

Tobias Schwarz

21 Jan 2025 • 4 min read

How transactions are handled or stored on a Cosmos SDK blockchain has the biggest impact on the size of your blockchain.

Blockchain bloat, spam, transaction validation and data availability are important points for any blockchain.

In this tutorial you will be learning how to mitigate spam or address blockchain bloat. How data availability works in the Cosmos SDK ecosystem and how to configure your node.

Adjusting Gas Fees in Ignite

In the Cosmos SDK, gas fees are essential to protect the network from spam and to compensate validators. Ignite CLI simplifies configuration of these parameters, which you can manage within the app.toml file located in your chain's config directory. (~/.example/config)

Setting Minimum Gas Prices

The min-gas-prices parameter sets the minimum amount of tokens per unit of gas that validators are willing to accept for transaction processing. In the app.toml file:
```
min-gas-prices = "0.025stake"
```
- Each transaction has a gas cost, which represents the computational effort needed for processing. For example, a transaction with a gas cost of 200,000 and a min-gas-prices set at 0.025stake would require:
  - Total Gas Fee=Gas Cost×Min Gas Price=200,000×0.025=5stake
- Adjust this value based on your network's economic model, where a higher min-gas-prices makes it costlier to interact with the blockchain. For instance, setting it to 0.05stake would require users to pay more for each transaction.
- Lowering gas prices can incentivize transaction volume but might reduce validator rewards.
Impact of Gas Fees
- Network Security: Higher gas fees discourage spam but may restrict access.
- User Accessibility: Lower fees make it more accessible but could lead to network congestion if not managed correctly.
- Validator Incentives: Validators are compensated through fees, so fee adjustments impact their incentives and long-term participation.

Adjusting gas fees requires careful calibration, as excessively high fees may discourage network usage, while too-low fees could lead to congestion and insufficient validator incentives

Pruning Settings and Their Impact on Storage

Not every node needs to have the full archival history of the whole blockchain.
Some nodes need to know only the tip of the chain to quickly validate incoming transactions while other (mostly public accessible) nodes would provide more history and data.

Pruning removes historical data to reduce storage demands on nodes. In the Cosmos SDK, you can configure pruning options in the app.toml file as follows:

Pruning Options in Cosmos SDK

In the app.toml file, under the [pruning] section, you’ll see different pruning strategies:
- nothing: No pruning; retains all historical data. Best for archival nodes but requires the most storage.
- everything: Prunes all state history except the latest. This saves storage significantly but limits query capabilities.
- default: A balance that keeps recent history for querying while pruning older data.
- custom: Define custom parameters with keep_recent (number of recent states to retain) and interval (frequency of pruning).
Example for custom pruning:
```
pruning = "custom"
pruning-keep-recent = "100"
pruning-interval = "10"
```

Pruning-Keep-Recent:
This setting defines the number of recent states the node will retain. For example, if set to 100, the node will store the last 100 state heights (blocks) only.
Keeping fewer states reduces storage requirements, but it also limits the ability to query older transaction histories and state snapshots.

Pruning-Interval:
The pruning-interval determines how often the node performs pruning. For example, setting it to 10 means that pruning occurs every 10 blocks.
Frequent pruning helps reduce data storage progressively, maintaining a clean and manageable node database over time.

Using custom pruning settings allows a Cosmos SDK chain to operate efficiently without overwhelming nodes with excessive data. Validators and end-users can select settings suited to their role: archival nodes might avoid pruning entirely to support complete data availability, while validators can prune aggressively to optimize performance and resource use

Impact of Pruning Settings
- Storage Efficiency: Aggressive pruning (everything) conserves storage, ideal for validators who don’t need historical data.
- Data Availability: Nodes with less pruning (nothing) retain complete data, beneficial for applications needing transaction history but increasing storage demands.
- Network Performance: Reducing storage requirements for nodes can lower entry costs and attract more validators, improving network decentralization and resilience.

Each setting impacts storage requirements differently, so align pruning strategy with the intended role of each node (e.g., archival vs. validator)

Optimizing Storage in Cosmos SDK Chains

Reducing storage is essential for network efficiency and longevity. Here are several optimization approaches:

Optimize Block and Transaction Size
- Adjust block parameters (e.g., max_bytes and max_gas in app.toml) to limit the size of transactions and blocks, controlling data growth on the chain.
Utilize State Sync
- State Sync allows new nodes to rapidly join the network by downloading only the latest state rather than the full history, significantly reducing initial sync times and storage needs.
Snapshots and Archiving
- Take periodic snapshots and archive older data off-chain. This lets you keep a lightweight node while offering optional access to historical data when needed.
- Cosmos SDK has built-in snapshotting capabilities that can capture the current state at defined intervals, useful for faster recovery and state sync.
Implement Custom Data Compression
- Use custom modules to compress or discard redundant data. Modules can be designed to avoid storing unessential data or to aggregate records more efficiently.
Selective Data Retention
- For blockchain applications that don’t require all historical data, periodically clearing unneeded records can conserve storage.

Optimizing storage in Cosmos SDK chains is a balance of managing the data needs of dApps, validators, and end users. By leveraging pruning, efficient block management, and advanced storage techniques, a Cosmos-based blockchain can remain both performant and scalable.