Vnodes Selection for Unique IPs versus Same IPs (different ports)

I had a question for all the experienced validators in the community. I apologize if this question has already been asked and answered. I searched for past topics/posts but I couldn’t find any.

Are the odds of randomly getting your vnode selected for an epoch weighted differently for nodes with unique IP addresses compared to notes hosted off of the same IP but different port numbers?

For example, imagine a scenario where you have four nodes (A, B, C and D) - all hosted from the same IP but ports 9334, 9335, 9336 and 9337. All four nodes are hosted off a powerful dedicated server with 16 cores, 16 GB RAM, 512 GB SSD and Unlimited Bandwidth.

Now imagine another scenario where you have four nodes (E, F, G and H) - all hosted on 4 different VPS servers, with unique IP addresses. These four nodes are hosted off separate VPS servers each with a configuration of 4 cores, 4 GB RAM, 128 GB SSD and Unlimited Bandwidth.

While selection of a vnode for staking is random, would the odds of nodes A, B, C or D be the same as the odds for E, F, G or H? Or would one have better odds than the other?

Likewise, are there any other criteria that ties to preferential selection of a vnode? (like geographic location of the server/country, performance history, server uptime, past staking history/rewards, etc.)

5 Likes

Besides meeting the basic system requirements, the truly important requirements are simply keeping a Node powered and online. If a Node is powered and online, it will eventually be randomly chosen for committee, regradless of a shared IP. Here is a primer on selection probability.

Eventually slashing will be introduced which will penalize Node configurations that don’t provide for optimal validation. You can read about that effort here and here.

7 Likes

Thanks @Mike_Wagner! Those references are a big help!

Speaking of optimal validation - would this be defined based on recommended node configuration specifications (CPU, RAM, Storage, Bandwidth, Up-time) or would there be additional criteria tied to other parameters like geographic proximity to the requesting transaction, etc.?

3 Likes

Optimal validation would be the capability of a given Node to perform the required consensus tasks in the required time. For example, a Raspberry Pi 4, meets most of the basic requirements for RAM, CPU, etc. But in previous testing, the Incognito Dev team found that a RPi4 just cannot keep up with the validation tasks during committee. It becomes unstable and increasingly fails consensus. In a future version of the Incognito protocol, such a RPi4 Node would very likely be deprioritized over Nodes that maintain consensus during committee.

To your question about shared IPs – the concern would be oversubscribing the internet link and overprovisioning the hardware. 4 nodes on your 16 core setup would work quite well. In contrast, 24 (or more!) nodes on your 16 core setup would probably degrade performance for all 24 nodes. This would thereby increase chances of slashing for each one, once slashing is implemented in the Incognito protocol. Similarly 4 nodes on 20Mbit circuit would likely be just fine. 24 nodes would surely congest the same internet link, thereby decreasing performance for all nodes at that IP address.

The project is still early, so there isn’t a hardline guide for knowing when host hardware has been overprovisioned or an internet link has been oversubscribed. It will take a bit of testing for yourself on your own setups, to find the limit.

3 Likes

Thanks again @Mike_Wagner! That makes prefect sense.

1 Like

I think it should be one node per ip because on a larger scale multiple nodes per person doesn’t support decentralization, weakens the governance model if there will be one at some point, could possibly allow for chain manipulation…maybe. it could be that one in a millionth chance that all those nodes selected as validators belong to one user who could then control the chain? Just a thought idk really. That being said the “one node per ip” still won’t prevent that from happening but at least it is a slight move towards deincentivizing that behavior since it could be slightly more expensive to maintain multiple ip addresses at least on some vps systems