I meant, mathematically, you can calculate what your probability of earning a coin is, and it’s not dependent on doing anything unspecified for free.
Its an automatic process and the node operator will not see it unless they seek out the info. If they seek out the info then they will understand its a necessary part of running a node.
Nodes are max of 2GB so not a huge overhead if 1/4 or 1/2 is those relocated chunks.
The earning ratio starts at the node completing its startup and holding the close chunks to its ID.
I mean mathematically you could include the cost of the computer you run, the room in the house cost or any number of factors to create the image of being not worth it. In this case you take the space cost of the requirements to be a good node and say its not good, and as always its up to the person to decide.
Without this overhead each node would fill up and never earn beyond that. This method of accepting close chunks to it for no income allows the node to earn forever (assuming the whole network never fills up). I’d prefer the later where I can keep earning forever and accept I don’t earn anything for 10 or 20 minutes after turning on my node.
At the end of the day the real cost performance will be how much a node earns over a period of time. And most people couldn’t care less if their node holds 500MB of its 2GB or 750MB or 1000MB, but will care how much it is earning and that will be evident by how much SNT they get per period of time.
4 Likes
A few thoughts I’ve had lately:
Using a fixed node size is attractive for its simplicity. But what size? Imo this comes down to what we want the network response time to be. This in turn is governed by the bandwidth available to a node.
Let’s assume that we’d like to keep the response time to 60 seconds. This means that if a node goes offline, we can bring a new one on board to fill its place, copying the same chunks that went offline to the new node (from the redundant copies stored at neighboring nodes).
Presuming a minimum bandwith per node requirement of 100Mbit/s, this means that nodes should be no larger than 750MB each.
Does this mean that you can support only 1 node at 750MB from your home connection? Well, no. While nodes are operating they will consume an average amount of bandwidth. The recent testnet indicates 50kB/s on average. So you can keep increasing your node count until you saturate your link or cpu count.
This being said, 750MB per node is rather small given the availability of cheap storage. It would seem worthwhile to allow for a slower network response time and larger nodes. More redundancy might help alleviate concerns related to slow network response times.
3 Likes
We discussed this elsewhere and i suggested that for the time being 2GB is a good compromise between computer resources (Tasks, memory, CPU usage, etc) and slightly better usage of bandwidth etc. over lot larger and/or smaller node size
Bandwidth will be related to number of nodes more than size of each node since each of the nodes is servicing a larger portion of the XOR range. The amount of bandwidth used by relocating chunks due to nodes entering and leaving and so with increase node count due to smaller nodes then one expects more relocation of chunks to be occurring due to the larger number of nodes being added or removed when a PC is turned on or off
3 Likes
If we assume an average bandwidth of 50kB/s per node, then a typical 100Mbit connection could support about 250 nodes. Using your 2GB estimate leads to a frugle 500GB per operator. This is a very small amount of storage relative to the bandwidth cost invested. For example, assume $50/month to support a 100Mbit connection and a balanced goal that money allocated to storage is equal to bandwidth cost. This means that operators should invest about $600 per year into disk drives. One can support about 50TB per year for that money at current prices. So vault sizes are going to need to grow significantly as we march to beta for the network to make economic sense.
One way to help manage this would be to tie required node size to node age. So all nodes with age 1 might be required to support 1GB, age 2 would be 10GB, age 3 supports 100GB, age 4 supports 1TB, and so on.
2 Likes
I think you also need to consider the bandwidth up as well. Most non-EU people have much lower bandwidth sending than receiving. This is important as new nodes appearing will require other nodes to be uploading the chunks that are closest to it. Also chunk retrieval by uses will probably be more than chunk downed to the node. So my 100Mbps connection is only 20Mbps or 40Mbps up (which one is dependent on the ISP and plan chosen. In AU 100Mbps connection is not the norm. It starts off with 25/10Mbps and the most popular is 50/20Mbps. There is still people on this forum with old ADSL connections (one being a dev)
Problems
- age, who decides. Hey network i am age 20, I dare you to disagree. And who is able to? No one.
- A 1TB size will still service the same range of XOR space as all the 2GB nodes around the place. So really you will waste 998GB.
- There is no authority to control different size nodes and allocate special code to allow it to grab larger range of the XOR space.
- Once sections and elders were removed to make the network simpler and more streamlined (ie faster and safer) there is no authorities to control such things.
Archive nodes will be the solution to having larger nodes but at this time there is not a mechanism or process thought out on how to do it
3 Likes
Let’s not forget the KISS principle as well as ‘the best part is no part’.
More complexity == more attack surface & a slower network.
If SAFE is going to be a functional base layer for a new decentralized Internet it needs to begin with the most basic structure and only add complexity when it’s determined that the simple method just can’t work.
We are a long way yet from being able to say that the simple ant network can’t work. Still many things to adjust and bugs to fix, but it’s doing pretty well so far.
3 Likes
Potential node operators will also be able to do those calculations once the Safe Network is up and running and the statistics / market dynamics are visible.
With Bitcoin mining, nobody could have been sure about what the future difficulty, blockchain storage requirement, and probability of mining a block with a given setup would be before the network was actually up and running so they could get the statistics / variables required to make the calculation.
It’s the same with running Safe node rewards pre-launch, but once the network is running, the information will be readily available for people to calculate whether it’s worth their while to start running nodes / add more nodes / remove nodes.
8 Likes
I have been trying to estimate this for a long time, but one thing I am missing is how much of a node traffic is basic overhead (routing updates, keepalives,…), how much traffic is replication due to nodes coming and what is real payload (client uploads and downloads).
I have 200/200 Mbit line and I am running 260 nodes since start of this testnet. First few hours traffic was only around 40/40 Mbit, then people started hammering it and line was maxed out for several hours. Now it is oscillating from 90/90 to 180/180 Mbit, but I have no idea if the network is mostly idle or how much are people uploading/downloading.
We don’t know how much bigger network will behave, still too many unknown variables.
1 Like
This is doable with poisson disk sampling when selecting from candidates wanting to join the network.
So node age is gone now too? Yikes!
I was not aware of this. Yikes!
In the current testnet @Josh consumed about 90GB over 16 hours for 30 nodes. This averages to about 50kB/s per node. Your own example shows about 100kB/s per node at peak.
Yes, but the question is will it be the same for 1000x bigger network?
1 Like
It seems reasonable to expect that the rate of chunks to be stored per node will reduce as the network grows.
These testnets are seeing relatively few nodes covering the whole XOR address and people doing some rather large uploads compared to total space available in the network.
3 Likes
@neo, would you mind elaborating on this? The whole process of when churn events are triggered and how the data contents of one’s own node can constantly be refreshed with payable and non-payable chunks eludes me.
It would be nice to have assurance on this point. A testnet could be deployed where new nodes come online over time. Perhaps it should be standard procedure.
2 Likes
Lets say we have a operating network for this explanation
- not all chunks held by a node have the same close node group.
- close node group to a chunk is the 5 closest nodes to the chunk’s XOR address.
- one chunk might have a close node group of A B C D E
- another chunk might have A C D G H as its close node group
- and so on
- when a new node appears then
- the close node groups for some chunks will change
- for those chunks some nodes will no longer be in the close node group for those chunks
- those nodes will remove the chunks and may transfer them to the new node
- there will be at least one node holding the chunk and sends the chunk to the new one to populate it. So its not necessarily the node removing the node.
- these transfers do not earn the new node anything
- when a node leaves the close node group for all the chunks it held will of necessity change
- depending on the XOR address of each chunk nodes determines which nodes become a part of each chunk’s close group.
- this means for one chunk, node J is the node entering that chunk’s close group and for another it might be node K and so on.
- in the end there might be 10 or 20 nodes that will receive a portion of those chunks because of the leaving node
- these chunks will come from existing nodes in those close node groups.
- We see that a node will receive without payment chunks when
- the node starts up due to entering close groups for various chunks
- the node enters close groups of some chunks when another node leaves the network
- We also see that a node will lose some chunks when new nodes enter the network as a closer node to some of its chunks enters the network.
Basically there is a ongoing sequence of events that add chunks and remove chunks for a node. These do not involve any payment.
Assuming the whole network never gets near full, then the number of chunks held by a node will be approximately the same %age as the whole network holds. This holds true because of the randomness of the IDs that nodes have when initially starting.
There will be outliers that have significantly more or less, and if you run 20 nodes then maybe one will be high and another low, basically following a bell curve meaning 80% of your nodes will be very close to the average and most of the time the other 20% still close to the average.
This means everyone else is also “suffering” from helping the network remain functional.
Then there is the new chunks uploaded which means the node receives payment.
===================
Without doing this then nodes will only ever receive new chunks and eventually fill up and never earn again.
4 Likes
Thank you very much @neo. So node 1 gains and loses non-paying chunks as new nodes enter the network. When new, paying data is uploaded does node 1 have the same chance of hosting one or more chunks of this paying upload as all other nodes, including the new node that scarfed chunks from #1 in the beginning? If this is true then the oldest nodes in the network will forever be expected to have more chunks, at any given time, than the newbie node, if he has been a good, reliable citizen all this time, right? Or does the network have a “balancing” element where the newbie node will eventually have about the same amount of paying chunks as most every other node?
1 Like
Yes that is my understanding assuming that node 1 is in the close node group for that chunk’s XOR address. If the new node is in the same close node group then it too has the same chance otherwise its not even considered. All nodes on average including new ones will have approximately the same number of chunks.
The way the network works now there is basically no difference between old nodes and new nodes with the main difference being that old nodes have had more time to earn SNT
Additionally as the network grows so the range of XOR addresses that a node covers reduces and thus earnings will relate to the upload rate and total number of nodes on the network. Each node should approximately receive the same rate of SNT as any other. Statistically due to randomness there will be some nodes that are outside of this average.
[EDIT] I am guessing that nodes in the early live network will have the opportunity to earn tokens at a greater rate than later on. I base this on there being a higher ratio of uploads to nodes compared to later on as upload rate compared to network size reduces to a more even value
2 Likes
Nice description neo. I will also point out, again, that poisson disc or “blue noise” random selection of nodes as they join the network will maintain a more uniform average distance between nodes, which will inturn change the bell curve distribution of node storage level to a more uniform distribution, where any single node’s “percent free” or relative capacity, is the same as the network (assuming fixed size nodes).
This feature has yet to be implemented. A naive implementation would involve having a joining queue. The existing nodes in a close group/section would then allow only one node in the queue to join based on it having the best distance metric. A simple distance metric would be to select the node with the maximum “minimum xor distance” between itself and any existing group members. To improve the chances of getting an optimally placed node, one would increase the allowed size of the queue.
1 Like