I put my calculations in the google spreadsheet Safe Network growth.
It’s interesting because all the ability to grow comes due to parallelism, so almost all the growth happens in the last two or three iterations of network growth.
The key to getting a large network is always more nodes, not bigger nodes.
The numbers for this are pretty eye-opening (from the spreadsheet):
| Node Size (GiB) | Iterations to 2 EiB | Time to 2 EiB (h) |
|---|---|---|
| 1 | 21 | 2 |
| 10 | 19 | 18.1 |
| 50 | 17 | 81.1 |
| 100 | 17 | 162.3 |
| 500 | 15 | 715.8 |
| 1000 | 15 | 1431.7 |
| 2000 | 14 | 2672.4 |
| 5000 | 13 | 6203.8 |
| 10000 | 13 | 12407.7 |
Onboarding large nodes takes longer so it also takes longer to get to that juicy late stage exponential growth.
Very small nodes mean the network can get the exponential growth cranked up much faster.
I should put a caveat here that the model assumes constant focused growth, when in reality the network will have other demands, has client bandwidth demands as well as node joining, will have varying node speeds, and lots of other factors that make the growth rate not perfectly exponential.
This has really made me reconsider the value of having a fixed target node size. Rather than have elders target 50% full nodes, they could target 50% nodes above/below X GiB (which is really easy to do since they track the chunks for each node anyhow). The average node size has a huge implication on the overall network growth rate.
And I have also come to appreciate how important it is to have a large network for security. More sections means more opportunities for a diverse range of node operators to join. When the network is small it’s harder to join and we have to queue nodes up, which becomes a risk since the smaller operators are probably less inclined to queue, and can also be drowned out of the queue by bigger operators.
Relatively smaller node sizes helps increase parallelism and reduces bottlenecks. Elders can only track a certain amount of churn, so the longer any one churn activity takes the more it blocks other churn from happening. The longer it takes the current node to join the longer it takes before the next two can join after it (the numbers are specific to the model but the idea applies in general).
This is a nice set of stats! The two most common buckets are:
22.83% of users have between 100-249 GB spare space
23.46% of users have between 250-499 GB spare space
50 GiB would be between 10%-50% of spare space for these users. 50 GiB sounds like a reasonable amount in those circumstances.