Sharding in numbers — every new node lightens the load for everyone
At 24 nodes each one holds about 61 % of the chain, at 1000 nodes only 3 %. We walk through the DataVeritas storage model step by step.
A classic blockchain asks every full node to store the entire history. For a quality network with hundreds of participants — plants, labs, suppliers, inspection bodies — that is wasteful: the same terabytes sit around a hundred times over, and small participants cannot join at all.
DataVeritas takes a different route. The chain is split into 1000 storage blocks, and each node keeps only a share of them. The network as a whole always keeps everything.
The assumptions
The figures below come straight from the simulator with its default parameters:
- Chain size: 4 TB (one full node)
- Data volume: 250,000 records per day at 8 kB ≈ 1.9 GB per day
- Link: 10 Gbit/s per node, 70 % usable ≈ 875 MB/s
- Maximum redundancy: 30 copies per shard
At 1.9 GB per day, the 4 TB chain holds roughly 5.9 years of quality data. Each of the 1000 storage blocks is therefore about 4.1 GB, or a little over two days.
How many copies does a shard need?
The number of copies per shard grows with the network, but more slowly than the network itself:
k(n) = min(30, 1.145 · n^0.8)
share per node = k(n) / nUp to three nodes, everyone holds everything — splitting there would be reckless, because losing one node would leave shards without a copy.
| Nodes | Copies per shard | Share per node | Storage per node |
|---|---|---|---|
| 3 | 3 | 100 % | 4.00 TB |
| 6 | 4.8 | 80 % | 3.20 TB |
| 24 | 14.5 | 61 % | 2.43 TB |
| 100 | 30 | 30 % | 1.20 TB |
| 1000 | 30 | 3 % | 123 GB |
From around 60 nodes on, redundancy hits the cap of 30 copies. After that, every new participant lowers everyone else's share — the curve drops steeply.
What happens when 30 % drop out?
Take 24 nodes, 7 of which disappear at once. Each held about 61 % of the chain, i.e. 2.43 TB. The remaining 17 nodes have to re-replicate those shards:
- Data to move: 7 × 2.43 TB ≈ 17 TB
- Aggregate bandwidth: 17 nodes × 875 MB/s ≈ 14.9 GB/s
- Duration: about 19 minutes
Redundancy dips during that window but never falls below one: every shard sat on 14 to 15 nodes beforehand. Coverage stays at 100 %.
Roles for every size
Not every participant can or wants to contribute the same. That is why there are four roles:
- Full node — the whole chain; audit anchor for a regulator or consortium lead.
- Scaled node — the computed share, shrinking as the network grows.
- Tiny node — a scaled node with a hard cap, e.g. a plant PC with 100 GB.
- Light node — headers and inclusion proofs only, about 12 GB. Ideal for customers and auditors who verify but do not store.
Work it out yourself
Every value can be changed live in the simulator: chain size, redundancy, bandwidth, NVMe capacity, data volume. With the "real time 1×" clock, transfers even run at their true duration.