Open
Description
Summary:
I propose merging the Pruner package into the DASer package as a subcomponent. DASer is currently responsible for sampling blocks within the configured sampling window, downloading, and storing them. The existing separation leads to inefficiencies in both DASer and Pruner operations.
Motivation:
- DASer currently lacks direct knowledge about which blocks require sampling/storage. It begins checking from height 1 and calls
WithinPruningWindow
via the Availability interface for every block height, causing unnecessary overhead. - Similarly, the Pruner is unaware of DASer's progress in sampling/storing blocks, resulting in redundant looping from height 1 to identify deletable data.
- Additionally, if the Pruner runs ahead of DASer, it might create a false state where blocks are marked as pruned but remain persisted because DASer stored them after the Pruner's check.
Proposed Solution:
- Merge Pruner functionality directly into the DASer package.
- Use a shared state within DASer that tracks blocks already sampled, stored, or pruned.
- Remove store-related logic (
put to store
/prune from store
) from the Availability interface implementations, simplifying its responsibility.
Expected Benefits:
- Reduced redundancy and improved efficiency for DASer and Pruner operations.
- Simplified logic and clearer codebase through shared state management.
- Performance gains by eliminating unnecessary repeated height checks.
Feedback and suggestions are welcome!