Parity-ethereum: Feature-request: Be able to prune old blocks in disk
As in pruning mode in Bitcoin client, it would be useful to have an option to prune old blocks so the disk usage will be much less and it will facilitate the possibility to have a full validated node (a much more close approach to "don't trust, verify"). Despite it won't provide old blocks to newcomers, will provide security by validating blocks against consensus rules and propagate only valid ones.
albpal
All 4 comments
Adding to this, perhaps adding an archive mode with a blocknumber option at which to prune at so it does same as full archive but only has historical state data up to that block.
For dapp devs this is something of great value as you don't care about blocks before your contract deployment and can then possibly serve a full archive node on a dev machine and not have to store one in AWS etc. at cost.
For eg. if I am interested in state starting at block 6m it syncs and auto-prunes up to this block at which point it start to store it. Now I can perhaps host an archive node on my local machine with the much reduced ssd footprint.
I would want to be able to export/import this data to share this with fellow devs.
We can then work fast with a local node with the state data we need and not need to pay AWS fees for a 2TB+ archive node we share.
AC0DEM0NK3Y
on 6 Feb 2019
This is a huge feature, a must have, especially when you're short on fast storage (SSD / NVMe) and don't want to keep old blocks available.
gituser
on 23 May 2019
related: #10760
XertroV
on 19 Jun 2019
Closing issue due to its stale state.
adria0
on 27 Jul 2020
Related issues
retotrinkler
·
3Comments
area
·
3Comments
danfinlay
·
3Comments
0x7CFE
·
3Comments
stone212
·
3Comments
Most helpful comment
Adding to this, perhaps adding an archive mode with a blocknumber option at which to prune at so it does same as full archive but only has historical state data up to that block.
For dapp devs this is something of great value as you don't care about blocks before your contract deployment and can then possibly serve a full archive node on a dev machine and not have to store one in AWS etc. at cost.
For eg. if I am interested in state starting at block 6m it syncs and auto-prunes up to this block at which point it start to store it. Now I can perhaps host an archive node on my local machine with the much reduced ssd footprint.
I would want to be able to export/import this data to share this with fellow devs.
We can then work fast with a local node with the state data we need and not need to pay AWS fees for a 2TB+ archive node we share.