Skip to content

Conversation

@martintomazic
Copy link
Contributor

@martintomazic martintomazic commented Nov 4, 2025

Closes #1469.

Considerations

  • We should be careful to not trigger data availability issues of the whole network, with new pruning suggestions.
  • Encouraging validators to only keep minimal state may allow us to also encourage them to enable checkpoints for consensus and runtime state (possibly making this default), solving another availability issue :).

Possible follow-up

#1506

Hardening data availability.

@netlify
Copy link

netlify bot commented Nov 4, 2025

Deploy Preview for oasisprotocol-docs ready!

Name Link
🔨 Latest commit 2dbbd19
🔍 Latest deploy log https://app.netlify.com/projects/oasisprotocol-docs/deploys/697775bc4c6b8e0008fcafb7
😎 Deploy Preview https://deploy-preview-1526--oasisprotocol-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Comment on lines 75 to 78
To configure pruning it is recommended to set `n=250_000`. The maximum value is
`n=400_000`. If you need to preserve more data (e.g. nodes serving historical
state) you will have to keep the entire state from the genesis.
Copy link
Contributor Author

@martintomazic martintomazic Nov 10, 2025

Choose a reason for hiding this comment

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

Unfortunately if you preserve runtime state, to serve historical queries, you are also forced to preserve all the consensus data, as consensus light block are computed ad-hoc (see). A requirement that should probably be documented somewhere.

We could open an issue, so that consensus light blocks are not computed ad-hoc and are instead stored in the separate DB, with different pruning config. This would allow to run Observer node with much lower hardware requirements, assuming most of the consensus data could be dropped.

Not sure this is a critical priority right now, but issue definitely cannot hurt...: oasisprotocol/oasis-core#6430

@martintomazic martintomazic force-pushed the martin/task/update-pruning-documentation branch from af27d24 to f4fe4e5 Compare November 19, 2025 15:16
@martintomazic martintomazic marked this pull request as ready for review November 19, 2025 15:32
@martintomazic martintomazic force-pushed the martin/task/update-pruning-documentation branch from f4fe4e5 to dc2e4fb Compare November 25, 2025 22:19
@martintomazic martintomazic requested a review from ptrus November 25, 2025 22:24
@martintomazic
Copy link
Contributor Author

martintomazic commented Nov 25, 2025

We should probably wait with merging this until https://github.com/oasisprotocol/internal-ops/issues/1221 (snapshots without holes) is merged finished.

Copy link
Member

@matevz matevz left a comment

Choose a reason for hiding this comment

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

I left some suggestions.

Can you also update https://github.com/oasisprotocol/docs/blob/martin/task/update-pruning-documentation/docs/node/run-your-node/prerequisites/hardware-recommendations.md?plain=1#L153-L168
Perhaps just title it "Pruning" and replace the links with the new one to your chapter.


To configure pruning it is recommended to set `n=250_000`. The maximum value is
`n=400_000`. If you need to preserve more data (e.g. nodes serving historical
state) you will have to keep the entire state from the genesis.
Copy link
Member

Choose a reason for hiding this comment

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

you will have to keep the entire state from the genesis

Is this that speceific ParaTime's genesis or consensus? Where does the 400_000 limit come from?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes Paratime specific, updated the text to make it clear.

Where does the 400_000 limit come from

Is not hard limit, but something that as from my experiments am willing to vouch it will still prune with reasonable speed.

@martintomazic martintomazic force-pushed the martin/task/update-pruning-documentation branch from 79708d0 to 3f60752 Compare January 26, 2026 13:28
@martintomazic martintomazic requested a review from matevz January 26, 2026 13:40
@martintomazic
Copy link
Contributor Author

Perhaps just title it "Pruning" and replace the links with the new one to your chapter.

Added new links, further refinement should be done as part of #1506 as is completely outdated :(.

@martintomazic martintomazic force-pushed the martin/task/update-pruning-documentation branch from 3f60752 to 2dbbd19 Compare January 26, 2026 14:10
@martintomazic martintomazic merged commit 11fca84 into main Jan 26, 2026
6 checks passed
@martintomazic martintomazic deleted the martin/task/update-pruning-documentation branch January 26, 2026 14:49
@martintomazic
Copy link
Contributor Author

As agreed with the reviewer in private this was ready to be merged. Future refinements can be done in the follow up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs/Run your node: Add dedicated section about pruning

3 participants