Store Retention and Pruning Configuration
In current Waku Store implementations, retention is primarily managed through a Time-to-Live (TTL) mechanism. Because the protocol defines the interface rather than the resource management, pruning is an implementation-specific configuration. Full nodes typically use a TTL parameter to define the maximum duration a message remains in the local database before it becomes eligible for deletion.
Implementation-Specific Behavior
While specific flags vary by client version, the general behavior follows these patterns:
- Asynchronous Pruning: To prevent blocking the main message processing loop, pruning usually occurs as a background process that scans for and removes expired entries.
- Resource Balancing: Node operators must manually balance the TTL duration against available disk space. There is typically no "auto-scaling" pruning based on disk percentage; the node will continue to store messages until the TTL expires, regardless of disk pressure.
Permission Boundaries and Resource Caps
There is currently no protocol-level permission boundary restricting which light clients can query a full node's store. By design, the store is intended to be an open resource for historical retrieval.
Rate Limiting and Resource Caps
Per-peer rate limits and resource caps for store queries are not defined at the protocol level. This means that unless the specific node implementation (e.g., a specific Go or Rust client) has added a custom middleware layer for request throttling, a full node is susceptible to resource exhaustion if a light client issues an excessive number of expensive historical queries.
Verification and Monitoring
To ensure your long-running node is not growing unbounded, use the following verification steps:
- Config Audit: Check your environment variables or configuration file for TTL settings (often labeled as
store-ttl or similar).
- Disk Monitoring: Track the growth of the database directory. If disk usage increases linearly without plateauing, pruning may be disabled or the TTL set too high.
- Retrieval Testing: Attempt to query a message with a timestamp older than your configured TTL. A successful retrieval indicates that pruning is not functioning as expected.
Diagnostic Note: To provide a more specific configuration command, please specify which Waku client implementation (e.g., waku-core) and version you are currently deploying.
waku