You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Archival nodes (i.e., kaspad instances running with --archival flag) are suppose to keep all header and block data forever. However, currently if an archival node is offline for more than 3 days (aka the pruning period), it syncs using a pruning proof and as a side-effect deletes all historical data.
The following steps can be added gradually in order to make archival nodes more robust:
Even if the node is offline for more than a pruning period, make sure all data is kept, despite the possible gaps. Essentially, an archival node should never delete validated data.
Add a mechanism to sync missing gaps from other archival nodes (no need for proofs because history is known before and after)
Some archival node maintainers do not require holding the data forever, but simply for longer periods of time (e.g., for a month for the sake of proving to a costumer a transaction was made). Add a command line flag allowing to specify an --archive-period such that data older than this period is deleted and the node has a limited-size DB and is not ever-growing.
The text was updated successfully, but these errors were encountered:
Archival nodes (i.e., kaspad instances running with
--archival
flag) are suppose to keep all header and block data forever. However, currently if an archival node is offline for more than 3 days (aka the pruning period), it syncs using a pruning proof and as a side-effect deletes all historical data.The following steps can be added gradually in order to make archival nodes more robust:
--archive-period
such that data older than this period is deleted and the node has a limited-size DB and is not ever-growing.The text was updated successfully, but these errors were encountered: