Proposal: Create a 3-node Subnet for Real-Time Multiplayer Game Canisters

[icarus]

@Sormarler

@Manu

Great job writing such a high quality proposal @atomikm!

@atomikm

Since this subnet is purely for visual purposes and does not depend on the security of consensus, I’m leaning towards a 1-node subnet

I think running something on a single node is a bit questionable wrt it being “on chain”. Of course it technically is, but having no fault tolerance at all makes me wonder what the advantage is of running it on chain. So I think I would prefer 4-node subnets as minimum.

I support the overall proposal. A 4 node subnet is preferable since you get some fault tolerance and still be on chain. A single node is asking for trouble as if that single stop working then the game will be down for a while.

If a 4-node subnet is the practical minimum cluster size and lowest possible latency and cost is the goal for an on-chain multi-user real-time gaming server, then we are already talking about a low-Nakamoto co-efficient cluster of nodes. So let us consider another part of the equation.

I am assuming the other main factor relevant here is to have very low-latency network links between the 4 nodes. So if the 4 nodes are all located in the same data centre or in difference data-centres which are geographically nearby (maybe with dedicated inter-data-centre network links) then I expect the IC update query consensus between the localised cluster of nodes would be optimised. It should be easy to test with a 4-node local testnet hooked up to the same switch I would think.

Obviously this kind of IC subnet is special purpose because of its low level of effective decentralisation (# of nodes, # of DCs, # of NPs) but could it still be much more resistant to attacks and outages than a single node. And if we have one city or data centre (DC) with more than one Node Provider (NP) in the one place that would be obviously better. In the near future as more IC node providers on-board you may find one location in EU or USA where you can connect 4-6 replica node machines in a low-latency network configuration that includes 3 DCs and 3 NPs, thereby maintaining a low but still effective Nakamoto co-efficient for this specialised subnet.

You could label these special subnets as an L3NC subnet-type , where:

• L3NC == LLLNC => Low-Latency, Low Nakamoto Co-efficient (subnet)
  or equivalently
• L3NC == LLLNC => Low-Lag, Less Nodes Cluster (subnet)

OR just use some real word for the subnet-type instead, like a normal person would

And this L3NC subnet-type would support applications other than gaming that have similar low-latency optimisation requirements. Then (as @atomikm said above) the standard application pattern would be to make cross-chain calls to pull “permanent” data back into standard 13-node application subnets for security.

Also, a L3NC subnet would need 1 or 2 colocated boundary nodes that clients connect to directly to guarantee the minimum latency.

PS: there is a highly applicable discussion thread here What is the theroretical number for txns per second on Internet Computer right now about transaction throughout related to geo localised and reduced node count subnets.