Running two or multiple farmers on the same node - not allowed

This question was asked on Discord:

I have not found information yet, also not in the forum on how to successfully connect 2 farmers to 1 node

The short answer is you cannot.

The way consensus works is 1 farmer <> 1 node. If you want to run multiple farmers you need to sync multiple nodes separately. However, for all these separate farmer nodes you can use the same reward address, meaning rewards will be sent to the same address for simplicity, but they are still separate farmers with their own ID.

The motivation is the following, I have noticed that in a typical home environment ISP, Router, Wifi (192.168.1.x network) it appears not possible to sync more than one node concurrently successfully.

node/farmer pair 1 runs on 192.168.1.212 30333 is configured on the router for port forwarding
node/farmer pair 2 runs on 192.168.1.114 now what do I do with the second node/farmer, port 30333 is taken.

1 Like

Yes you can run multiple farmers on the same computer, if your memory and CPU can handle that. You just need to specify a different port. Please see this post. E.g. for the second now you can open port 30334 by specifying --rpc-port 30334

1 Like

I wasn’t asking about multiple farmers on same computer I was asking about
computer1: node
computer2: farmer

node and farmer communicate via computer1 and computer2

Could you please elaborate a bit more what you are trying to achieve with as much detail as possible? That way it might be easier to assist you.

Your follow up question was literally below, I have one node/farmer running on this computer, 30333 is taken, I want to run a second node but port 30333 is already taken :sweat_smile:

node/farmer pair 1 runs on 192.168.1.212 30333 is configured on the router for port forwarding
node/farmer pair 2 runs on 192.168.1.114 now what do I do with the second node/farmer, port 30333 is taken.

My scenario is, I have one public IP from my ISP. I want to run 2 nodes and farmers on 4 computers.

node1: computer1
farmer1: computer2
node1 & farmer1 are connected via eth

node2: computer3
farmer2: computer4
node2 & farmer2 are connected via eth

Before starting this thread, I was thinking I can do this
node1: computer1
farmer1: computer2
farmer2: computer3
farmer3: computer4
farmer1,2,3 all connect to node1 via eth

I want to start with the premise that you need 1 node 1 farmer match. Any attempt to have more farmers running in parallel with the same node will fail, because that is an attack on the consensus, and the network will automatically detect and ban your nodes → your plots get burned and you have to restart from scratch (syncing and plotting).

That said, on the change port forum post I linked, Justin showed how your node client sets the port and you point your farmer client to that node’s specific port via WebSocket RPC connection --node-rpc-url ws://.... tag. I’m not a networking expert, so I cannot guide on how to set up your ad-hoc situation. Maybe some additional research on your front is needed. I hope some community members can share. Unfortunately, we don’t give ad-hoc implementation guidance, because everyone has their own flavor of a custom setup.

The example provided is about changing ports but still using localhost. I have changed localhost to actual IP. I could not get it to work, see error message Discord Unfortunately I have no text copy of the error message anymore.

Going to move on from this more enterprise style config and keep it simple.

Is the ‘best’ route at the moment is to run an archival node, then spin up node/farmer machines that point to the ‘local’ archival node. This is attempting to min total bandwidth utilized.

If this is correct, is there a ‘best’ (better?) route to accomplish this?

i.e.: “–reserved-nodes XXX --reserved-only”
or
“–discover-local”
or
“–allow-private-ipv4 XXX”
or
something else.

@xorinox Jeff is on the right path here, it would likely be better to just have the one node connect “externally” to the network and the rest connect to that node.

While over ethernet I assume this should be possible to connect node 1 on computer A to farmer 1 on computer B.

You will likely need to do a few things.

  1. You will want to ensure DHCP is not enabled on both computers.
  2. Verify both computers are on the same subnet on the same network.
  3. Verify firewall/ports/etc are all open to allow the two computers to talk to each other.

Note: This is just general networking advice, i have not attempted this configuration myself just yet.

Thanks! I have one node receive traffic on 30333 forwarded by firewall, node has local firewall configured to allow traffic on 30333. I found subspace is also listening on a couple other ports, so I opened them also, see below.

All other nodes, aren’t receiving traffic via 30333, e.g. obviously port forwarding is a 1-1 relationship between external port, internal port/ip…

In any case all nodes have also configured
–discover-local
–allow-private-ipv4 @Jeff_Flowers aka to help doesn’t take any arguments

I cannot tell for sure if this works as expected, but all nodes have synced meanwhile. Without previous flags it didn’t feel like they would.

firewall-cmd --zone=FedoraServer --permanent --add-port=30333/tcp
firewall-cmd --zone=FedoraServer --permanent --add-port=9944/tcp
firewall-cmd --zone=FedoraServer --permanent --add-port=9933/tcp
firewall-cmd --zone=FedoraServer --permanent --add-port=9615/tcp
firewall-cmd --zone=FedoraServer --permanent --add-port=9955/tcp

1 Like

Awesome! Glad you got it working!

To add some insight into the various ports.

  • 30333 is the main node port
  • 9944 is the node RPC port
  • 9955 is the farmer RPC port

So generally 9944, 9955 only need to be available locally (unless you were setting your node up to be an underlying service for like a block explorer, etc.)

Can you explain why running 2 farmers with 1000G plots is an attack vs. running just 1 farmer with 2000G plot size?

It shouldn’t make any difference… and how are you going to detect it anyways? It’s an implementation detail.

3 Likes

To clarify, that this means two farmers with the same exact plot. (you copy plot from Farm A, and farm it at the same time with Farm B) meaning the same plot is being farmed twice by two separate farmers, this is something that will get your plot burned.

But if you have two farmers with two different plots this is fine, though with the current implementation i would suggest a node for each farmer (down the road we will optimize multiple farmers to one node connections)

This medium article dives into some of the security implementations for Subspace (though it is just a touch out of date, still applies) Spartan v3: Secure Proof-of-Capacity (PoC) Consensus on Substrate | by Jeremiah Wagstaff | Subspace Network | Medium

Ok but that’s not what the thread is about? I don’t think anyone is trying to farm the same plots multiple times. At best you’ll get the same result multiple times, it won’t increase your reward.

So if two or more (different) blocks are received with the same solution at the same height, the plot will be burned?

1 Like

Ok but that’s not what the thread is about? I don’t think anyone is trying to farm the same plots multiple times. At best you’ll get the same result multiple times, it won’t increase your reward.

Just trying to reclarify your response to Wei regarding the potential “attack” and any confusion there. Just a few minor details I felt needed clarifying.

So if two or more (different) blocks are received with the same solution at the same height, the plot will be burned?

Overall yes if two separate farmers try to submit blocks with the same solution at the same height the plot will be burned. (remember each plot is salted with the farmer ID, so if the solution is the same, then it was taken from the same exact plot) @nazar-pc will be able to speak more accurately in regards to some of the security implications, though might be better for another thread :slight_smile:

In regards to this thread, the setup @xorinox is describing is completely possible assuming the connection can be established with low latency with the two computers, more of an implementation challenge, not something that is strictly blocked/disallowed on the network.

1 Like

@madMAx43v3r thank you! I never imagined my question would make anyone assume, farming clones of plots… It was always about leveraging one node by multiple farmers, that each have their own unique set of plots!

It was never a recommended setup and will not be. Depending on when and how you start your farmer you’ll be wasting space unused unless you have 1 node per farmer.

As it might not be recommended, I didn’t come across a single user reporting it actually works.