Skip to content

Conversation

fmoletta
Copy link
Contributor

Motivation
Ethrex nodes can get pretty heavy. In order to lower the space of the DB when full syncing large networks this PR proposes adding a prune-blocks tool which will remove old blocks and their associated data.

Description

  • Add prune-blocks tool

Closes #issue_number

@github-actions github-actions bot added the L1 Ethereum client label Aug 22, 2025
Copy link

github-actions bot commented Aug 22, 2025

Lines of code report

Total lines added: 147
Total lines removed: 0
Total lines changed: 147

Detailed view
+---------------------------------------------+-------+------+
| File                                        | Lines | Diff |
+---------------------------------------------+-------+------+
| ethrex/crates/storage/api.rs                | 257   | +1   |
+---------------------------------------------+-------+------+
| ethrex/crates/storage/store.rs              | 1460  | +3   |
+---------------------------------------------+-------+------+
| ethrex/crates/storage/store_db/in_memory.rs | 663   | +15  |
+---------------------------------------------+-------+------+
| ethrex/crates/storage/store_db/libmdbx.rs   | 1494  | +40  |
+---------------------------------------------+-------+------+
| ethrex/tooling/prune-blocks/src/main.rs     | 88    | +88  |
+---------------------------------------------+-------+------+

@fmoletta fmoletta marked this pull request as ready for review August 22, 2025 20:40
@fmoletta fmoletta requested a review from a team as a code owner August 22, 2025 20:40
@ethrex-project-sync ethrex-project-sync bot moved this to In Review in ethrex_l1 Aug 22, 2025
.map_err(StoreError::LibmdbxError)?
else {
// Block must have been already purged
txn.commit().map_err(StoreError::LibmdbxError)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to commit here? Can't we just abort or discard the tx?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had some problems because of this when testing it

Comment on lines +345 to +355
// Remove transaction location and receipts. Note that if the block was obtained via snap sync these are not guaranteed to exist
for (idx, tx_hash) in block_body
.transactions
.iter()
.map(|tx| tx.hash())
.enumerate()
{
txn.delete::<TransactionLocations>(tx_hash.into(), None)
.map_err(StoreError::LibmdbxError)?;
txn.delete::<Receipts>((block_hash, idx as u64).into(), None)
.map_err(StoreError::LibmdbxError)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these aren't guaranteed to exist, should we ignore any errors then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't get an error if they don't exist


The tool takes two optional arguments:
*`datadir`: The path to the DB location, will use the default one if not provided
*`blocks_to_keep`: The amount of latest blocks that will be kept in the DB. This value must be al least 128 and lower than the current amount of blocks in the chain.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
*`blocks_to_keep`: The amount of latest blocks that will be kept in the DB. This value must be al least 128 and lower than the current amount of blocks in the chain.
*`blocks_to_keep`: The number of latest blocks that will be kept in the DB. This value must be at least 128 and lower than the current number of blocks in the chain.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer amount instead of number as number could be confused with an actual block number (aka keep blocks in store as of block number X instead of keeping X amount of blocks from the latest). Fixed the typo

fmoletta and others added 5 commits August 25, 2025 15:49
Co-authored-by: Tomás Grüner <[email protected]>
Co-authored-by: Tomás Grüner <[email protected]>
Co-authored-by: Tomás Grüner <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L1 Ethereum client
Projects
Status: In Review
Development

Successfully merging this pull request may close these issues.

2 participants