Farming Pools and InfiniteGB Nodes

Looking for feedback on whether this scenario is feasible and / or likely.

Some background info:

Currently (based on rfc0057) new nodes are only allowed when there are more than 50% full nodes [1]. If less than 50% are full the existing nodes keep getting filled until the 50% full threshold is crossed. Maybe the 50% number will change, maybe the disallow rule will change, but the idea of farming pools is still valid if there is any situation where new farming nodes are not allowed to join the network.

Here’s the farming pool idea:

I try to join the network but my node is not needed so is disallowed. I really want to start farming, and I come across something called a ‘farming pool’, a service offered by an existing node on the network. The node allows me to join their pool right now and they’ll give some chunks to look after and a proportional share in the rewards (they take a small fee but I’d prefer a small fee compared to not farming at all). Great, I can start farming right now! I join the pool and in the background I’ll keep trying to join the network as a real farming node. This pool lets me earn rewards while I wait.

This makes the pool operator node appear to the network as a very large node (the network has no idea it’s a pooled resource). Ironically, the pool participant has reduced their chance of being able to take part as a ‘real’ farmer because now it’s become even harder to cross the 50% full nodes threshold.

Does this sound like a feasible situation? Would it be a problem?

A second similar thing is if datacenters start taking part they could do the same thing, appearing as one massive node (or more likely a maximally-viable number of not-full nodes). There’s incentive to do this since full nodes earn less reward (rfc0057 says reward is halved for full nodes [2]), so two full nodes are rewarded less than one not-full node. The incentive to not be full is very strong.

I feel like using full nodes as the measure for when and how to take action is potentially dangerous to the health of the network.

Just brainstorming here, would be interested in other views on this.

I feel like rather than using full nodes as the measure, we could use degree-of-redundancy as the way to decide network actions (like the sacrificial chunks idea in rfc0012 but a little more flexible). There can be a fixed minimum redundancy but any amount of extra redundancy that floats above that can be used to measure how excessive or how stressed resources are.

For example, enforce a minimum of 8 redundant chunks. If measured redundancy is 20 there’s a lot of spare resources and the network can maybe start rewarding less to weed out inefficient resources. If measured redundancy is 8 the network keeps the reward where it is. If measured redundancy is 7 the network takes immediate action to bring it back up to 8 by increasing the amount of reward.

Allowing a floating amount of redundancy means there is no disallow rule, any node can start farming at any time (onboarding may take time due to bandwidth constraints, but there is never a disallowed node). The lack of disallow rule means there’s no incentive to have pooled farming, all nodes may as well join the real network.

The disallow rule is seen as a necessary security mechanism to reduce the chance of the network being flooded with new nodes. But I feel the disallow rule also has other side effects which are potentially quite dangerous (eg farming pools). Is the disallow rule a net positive? Tough question…

[1] rfc0057 “if that ratio of good nodes drops or remains below 50%, vaults will ask routing to add a new node to the section.”

[2] rfc0057 “if flagged as full { node’s age/2 }”. Age is used to weight the reward, so the effect of halving the age is not exactly to halve the portion of reward, but is close to that.

12 Likes

Can you look at scenarios in which there is more than one Safe Network. Let’s say this farming pools farms simultaneously in all available Safe networks and moves the resource where it pays the most…

2 Likes

Wondering what the consequences would be for the pool if one or more of the nodes misbehave. Does the network punish the main pool node? I would assume node age is affected but what about getting booted by the network entirely, which I believe has been mentioned before? If so many nodes are part of this pool, how does the pool operator guarantee that he won’t get punished when a bunch of careless or malicious nodes can join the pool?

Perhaps pool operators will have to have their own malice detection?

5 Likes

I like the concept of maximizing redundancy. Imo unused disk space is just a wasted resource. Better to fill it with extra copies of data from N nearest neighbors. Intuition tells me an algorithm that is consistently trying to maximize chunk redundancy would be more robust than one that seeks to maintain a fixed number or enforce a minimum. The communications overhead is the main drawback though.

For this reason I don’t see pools as a technical problem for the network. However, their existence would represent a failure in the realm of user experience.

Not sure if this really applies anymore with node age at play. The nodes could be brought in at age zero and assigned a variety of grunt work tasks or serve as cache. So they can join, they just wouldn’t be full fledged nodes or become a real vaul until they are older.

7 Likes

Farming pools is mainly a discussion about managing incoming resources, I think you are trying to bring in a different topic about how to manage departing resources. Departing resources is definitely a worthwhile topic, but is probably better to discuss it in the multiple Safe Networks topic or in a new topic about managing departure of resources.

edit: I think you have raised important points about the departure of resources, I’m not trying to sweep it under the rug here, just I want to try to keep this topic on track and focused on how to best manage incoming resources. If you feel I’ve misunderstood your point please do clarify further.

Yeah I feel your latter question here is probably what would happen, pool operators would mainly end up managing and judging their underlings and would end up as kind of a meta-node in a lot of ways.

Yes, certainly farming pools would not be a problem in the technical sense. However they increase centralization and undermine the benefits that node participation brings to the governance of the network. So to me farming pools seem to be a ‘suboptimal solution’ rather than a ‘technically incorrect solution’, and one that hopefully can be avoided if possible.

8 Likes

Agreed. There’s no need for middle men between a vault and the network.

6 Likes

In my opinion, it is reasonable for such a pool to maintain nodes in all available Safe networks and to direct the incoming resources to which network pays the most to make the most money.

This does not mean that it will departure resources from the less popular Safe networks, this is not optimal, because there is no way to know if the price will not be the highest there tomorrow.

2 Likes

I wonder what the extra lag time might do to chances of being rewarded.

If all nodes (not considering pools here) participating successfully in retrieving a chuck are given something in reward then a pool node might still make reward anyhow.

But if it is only the node (or nodes responding quickly*) that “wins” then the pool may miss out on many chances for collecting a reward. For instance I join a pool in the USA, the lag is round trip since the request has to be sent to me and the response sent back.

But this is an interesting idea and eventually may have success. It also may be a way for a home user with spare drives and SBCs could pool rather than have multiple nodes. No lag

3 Likes

Somewhat surprised there is a limit to joining, as for all the risk that those joining see a small return in coin, that enthusiasm surely only adds to variety, which lends to stability and perhaps affects speed.

50% arbitrary?.. why not 20%… more the merrier.

I suppose there’s risk to volatility but impt there is fast response to growth… and those using the network initially will tend to be those hosting vaults??

1 Like

I’m not sure, but think the reason was efficiency :wink:

2 Likes

Iirc it’s a defense mechanism. Consider an adversary that spins up 1M vaults. If those were all accepted immediately, the might could swamp a network section. Instead they go in a waiting pool. This gives time for many other potential vault operators to join the waiting pool/queue. When the network actually needs a new vault resource enough time has passed for the pool to have accumulated another 1M non-malicious nodes. The probability that it will randomly select a malicious node from the pool is now only 50% instead of 100% under the direct join scenario.

4 Likes

I thought that’s the case to make the network resilient against vaults trying to game the network by storing no data at all. By making GETs when they need to serve a GET themselfs and acting as a mere “proxy” to other nodes.

1 Like

This pokes at a lot of different ideas…

Let’s say there’s no join limit. Anyone can join any time.

This doesn’t mean join is instant. It still takes time to redistribute chunks to the new nodes.

Let’s say a section would split if the two new sections would have 100 nodes each (so probably splitting when there are about 200-250 nodes). If there’s a section with 150 nodes, then suddenly 1000 new nodes join the section all at once, should the section split now then redistribute chunks, or should it split only after all chunks have been redistributed?

I’m not going for a binary ‘this or that’ answer on this, I’m just trying to conceptualize the relationship between chunk stability and section membership stability. When is a node “a node”? When is a node “queued”? When is a chunk “stored”? When is a chunk “at risk” or “lost”?

Looking at the waiting pool idea by @jlpell, I’ll call it a queue, would I be able to get a hundred new nodes from my laptop into the queue? Or a million? Or only a few? What’s the limit? Presumably being ‘in a queue’ is not a resource intensive action, otherwise it’s not queuing, it’s joining. Having more nodes in the queue increases my chance to be selected for the next join. So I’m not really too clear on how the queue mechanic would function as opposed to simply joining. Maybe I’m not looking carefully enough into the queue and there’s a simple way for it to work?

(If we call the queue a membership pool we can stir up some confusion by calling it mempool, which in bitcoin is short for memory pool! No let’s not do that :slight_smile: )

A disallow rule or a join limit etc, it’s sorta naturally going to happen anyway since chunk redistribution isn’t instantaneous. But a disallow rule is also sorta naturally not going to happen because resources spent managing a queue is a wasteful-type-of-joining.

Perhaps this all just adds a lot of mud to an already murky pool…


Let’s look at the idea of chunk redistribution when new nodes join, since this seems like a key part of whether or not new nodes are disallowed.

Maybe chunks do not need to be redistributed? This is sorta natural anyhow since if vaults can be full then chunks must be ‘near’ their xor address, not ‘closest’ to it.

We could have nodes be part of the network without them having all the closest chunks. The new node missing a chunk would not be surprising since it happens anyway with full nodes. (I find this idea unappealing but it seems like a necessary consequence of allowing full nodes; I prefer the strictness of all redundant chunks being at the actual closest nodes, not just nearby).

This raises a question of how new nodes might be filled. Some options for how to do the filling:

  • The node doesn’t store any historical chunks, only new chunks, and fills up as new PUTs arrive. There is no redistribution process when a node joins (redistribution only happens when nodes depart or sections split). I’m not sure if this is feasible or not, I’d need to explore it further.
  • Elders give the new node a list of all the close chunks to that node (ie all the chunk names that the node is required to store to satisfy the minimum chunk redundancy). The node is responsible for filling itself by doing a normal GET for all those chunks. Periodic audits ensure the vault has done the work and the level of redundancy is correct.
  • Nearby nodes could push chunks to the new node, rather than have the new node pull them.
  • Maybe some other ways are possible?

Zooming way out, it seems like the disallow rule and join queue etc originate from ‘responsibility for redundancy’. How can the network ensure redundancy and detect failures of redundancy? If joining is too rapid the degree of redundancy becomes unclear and might put data at risk when chunks are poorly distributed (there could be any number of reasons for chunks being poorly distributed - maybe lots of nodes are suddenly departing, maybe some nodes become overloaded and laggy, maybe redirection due to full nodes becomes extreme).

It feels to me like elders are in the best position to manage the redundancy. Maybe that’s not necessarily true, perhaps redundancy can be managed in a less strict or controlled way?

Maybe instead of looking at the potential damage from farming pools and how to avoid the damage, maybe we can say if farming pools are a natural consequence of unavoidable network friction how can we incorporate them into an intentional network mechanism (btw I don’t think farming pools are inevitable).

6 Likes

Don’t attribute this one to me :sweat_smile:. It’s just my current understanding of what the intent was for a defense mechanism based on bits and pieces I picked up here on the forum from dirvine’s descriptions and others. The ‘queue’ might just be nodes at age zero, but I’m just guessing.

1 Like

This is actually how it works now, since
earlier this year.

I’m also a bit ambivalent to it. On one hand chunks are not at the closest node, on the other hand there’s no need to sync data when joining.

Wrt join queue, naively it looks to me like the rate of inflow to network is controlled, but it does not prevent the queue from being flooded, which means the network is deprived of inflow of good nodes. Anything it adds will be an attacker.
I haven’t looked at that area though, for detailed solutions.

6 Likes