How do I know the current size of the blockchain so that I can plan the size of my VPS HDD ahead of time?
The beacon chain is ~19GiB. Every Node continuously syncs the beacon chain, thus this becomes a starting base of ~19GiB.
Then you’ll need to account for each shard’s chain. Each full shard chain appears to be ~45%-70% of the beacon chain size. Once a Node has fully synced the beacon chain it will sync a randomly assigned shard chain for committee participation. Your Node will need as much as another ~13GiB per shard. As the Node moves from committee to committee, it stops syncing the previous chain and syncs the new chain. The previous shard’s chain data is retained by your Node. Thus if your Node were to participate once in every shard’s committee as quickly as possible, you’d need around ~125GiB of disk space: 19GiB beacon + (13GiB per shard * 8 shards) = ~125GiB
Now take that amount and multiply it by a how much space you expect to grow before changing your VPS’ storage allocation. Growth of 50% should cover you for about a year. Thus an allocation of at least 190GiB would be reasonable with a set-and-forget vNode, for up to a year.
Here’s some recent data from @fredlee. Please note his data is for a Full Node. A Full Node continuously syncs all chains, not just the beacon chain + single assigned shard chain. Thus his overall storage requirements are greater than a vNode. However the data is still relevant for the current size of each shard, even if your vNode isn’t continuously updating each shard chain.
As a follow-up, since my post in June, the full node has grown into 130GiB. Shard 0 seems to run the hardest, for whatever reason, I do not know.
21G beacon 30G shard0 12G shard1 11G shard2 15G shard3 10G shard4 9G shard5 13G shard6 14G shard7
That is an increase of 18GiB in roughly 6 weeks. With linear growth, it would hit 200 GiB at the end of the year. I believe the pNodes came with a 512 GiB SSD.
You can save almost 10% with lz4 filesystem compression, not much, but it might help if you’re low on space. If you run a validator, you can erase old shard data when outside of the committee. Not sure I would recommend it, because next time you will have to re-download the whole shard again. However, with the random assignment, it might take months before you are part of the committee in the same shard again.
If you run multiple nodes you can pull off some space-saving wizardry if you’re tech-savvy enough.
Hi, thanks for the reply. Do you have any ideas on saving space since I’m running multiple nodes on my VPS.
The blockchain is the same for all nodes, but each node creates their unique data files when they run. So trying to find common data between them does not work. What you can do however is “bootstrap” your validators by starting with a full node and reconfigure it to run as a validator.
You can for example create a full node vm, clone it as many times as you like and then reconfigure them to validators. Each node would share the clone snapshot that contains the 130GiB block data. Everything written after that goes into the individual vm diff disks.
Another way would be using a filesystem with de-duplication or snapshot cloning support.
What you can do to save space depends on if you host your own servers or what the provider has to offer.
Along this same train of thought… @fredlee and @Mike_Wagner…what does this all mean for those of us with pNode devices and their overall storage capacity in the short term and long run if you might know?..thanks in advance by the way…
pNodes have 500GB SSD so it should last for a few more years. There’s also loads of improvements and cleanup that can be done on the protocol to further reduce/compress the size.
Thank you @adrian for your response…it is much appreciated and I believe other community members will also appreciate the info and insight…