On a canister level this is what we call a ‘guard function’. I don’t see this happening on a subnet level anytime in the near future. How would you do the initial access granting to access the subnet?
I think it is possible to change the rules for the subnet in the sense of layer-2. If one is created.
IMO a 1-node subnet would still be perfectly sensible, for basically whenever you need a best-effort cache. While you don’t gain anything in terms of resilience over just an AWS box, you still gain a lot of convenience - you have the same programming model, you can rely on inter-canister messaging, operationally it’s a lot simpler.
In terms of “artificial limits”, there is currently some rate limiting done by the boundary nodes. Perhaps this can be removed once we have decentralized boundary nodes; the decentralization is being worked on but I’d guess it’s still at least few months out. Still, I’d expect that to land sooner than the other blockers for low-replication subnets that Manu mentioned (cross-subnet cycle transfers, and the upgrade problem).
6 Likes
good idea. We will wait for your decisions. We plan to test WebSocket for this in the near future. Probably, there will be new ideas on how to implement this on the IC
2 Likes
What is your exact goal of having everything “on chain”? Such ping-optimized setup (low Nakamoto coefficient, geographic co-location) will never be considered decentralized yet it will suffer from the inevitable on-chain drawbacks: e.g. if one node goes down, then while the subnet will still finalize the first thing that will suffer is the latency which will potentially make the game unenjoyable. With this setup you have neither security, nor latency robustness. Given that this computation (visualization) is not even security critical, I cannot understand the rationale behind having this infrastructure on-chain and squeezing this data through the consensus.
Did you consider something like sharing the list of player IPs among peers and then connecting to each other via WebRTC for real time data exchange?
4 Likes
Hey Icarus!
Yes, we completely agree that with 4-node subnets, having the nodes be geo-located close together will tremendously improve latency. Ideally we want a 4-node subnet in each major region: North America, Europe, Asia etc. for low latency update calls that don’t require high security or decentralization.
Many applications can benefit from this tradeoff of security and latency. Storage, AI, and Multiplayer Gaming are all areas that can benefit from performant subnets with reduced node count.
For 1-node subnets, the same applies but there would just be 1 node in each region of the world 
1 Like
Yes I think a 1-node subnet could be a great option at first, assuming all security vulnerabilities related to faulty subnets are resolved as it’d be very easy for a node to turn a subnet malicious.
Something to keep in mind, in the future it may be possible to have smart contract logic related to enforcing player movement in the real-time multiplayer canister. In this case, it makes more sense to use a 4-node subnet because valuable outcomes may be tied to player positions in the game.
We’re open to either 1-node or 4-node. In the beginning, perhaps a 1-node subnet could be more efficient. As we continue to built more complex real-time multiplayer canisters, we can explore a 4-node subnet.
2 Likes
Yes, this is a great question, I’m glad you asked Our conviction for running real-time multiplayer fully on-chain is not for decentralization but for composability.
I wrote a tweet thread that summarizes our thesis here:
TLDR:
The real power of open-source smart contract standards is that any game can leverage them to immediately access the liquidity and user data of thousands of other games.
We believe the “moddable” nature of smart contracts enable new use cases we haven’t even thought about.
Imagine creating multiplayer events across games or cross-game simulation, it’s easy to do if they use the same real-time multiplayer smart contract.
In the future, we may add smart contract rules that enforce movement constraints. Thus, we could have smart-contract-authoritative movement, and players could be rewarded by smart contract logic based on their position in a world.
Lots of possibilities open up when everything is in transparent, composable, and extendable contracts.
Regarding WebRTC:
P2P solutions rely on third party libraries, STUN server, and TURN server (which haven’t been re-written on-chain yet). So a lot of dependencies. Having everything in canisters streamlines the developer experience and promotes all the great composability mentioned above.
Could WebRTC be used on top of a multiplayer smart contract to do client-side prediction? Absolutely.
But I think the smart contract should be built first, and not the other way around.
WebRTC also has its own limitations, like the amount of players that can connect at one time.
6 Likes
I think this is the first idea I know of a really unique use case for Web3 gaming. There’s a lot to think about there. Well done, @atomikm
1 Like
Please don’t ruin the entire IC consensus for your not fun game!
1 Like
Hello,
I’d like to understand your concerns for how this would ruin the Internet Computer consensus.?
If you read the discussion in this thread, security measures will be in place to prevent a malicious subnet subverting the IC network. When these measures are in place, a low-node subnet poses little threat to the safety of the overall IC network. Only the canisters inside of the low-node subnet would be affected. And those canisters would be built assuming low security and would not contain any valuable data or logic. Dapps will be able to leverage both high-node and low-node subnets depending on the security and latency requirements of certain canisters.
Of course I read the entire thread. I also listed the white paper of ic, have you read it carefully? IC is a blockchain, not a game server, and the Dapp owned by IC does not only have one game. If you feel that the network is lagging, then your team’s first priority should be to optimize your game. We should stick to the principles and design of IC to ensure the security and stability of the network, instead of pursuing short-term performance improvements by weakening consensus nodes. At the same time, we should also look for other feasible ways to improve the performance and scalability of the network instead of sacrificing the security and stability of the network. It is undeniable that placing the Dapp front-end on the IC Chain will slow down the speed, but we cannot put the cart before the horse and sacrifice consensus. Without consensus, is it still called a blockchain?
I can’t agree to create a subnet for game that can’t even finish loading. Why waste resources on this.
BTW, I’ve been working in the game industry for 16 years. I know very well what a game is and what is the core of a game. Again, please don’t be totally on-chain for the sake of full on-chain. Focusing on the 2-year IC dapp projects, totally on-chain has become the best excuse to defraud Dfinity grand and funding.
We should rethink.
1 Like
I don’t quite understand the complicated technology here! ICP’s homepage states that ICP can host web2, then your game speed can run at WEB2, hosted on ICP, then I think you can still be called a blockchain game because of ICP endorsement for you
I totally agree with you. 
In this thread, many Dfinity team members disagree with the current situation of using low-node subnets. Please close this proposal and vote “no” until the Dfinity team confirms that it is safe and feasible. For IC, Please.
1 Like
Why would this ruin the IC consensus? I have not seen any Dfinity engineers express this concern.
Then Dfinity needs to stop selling it as a replacement for AWS.
Less than 3 nodes would be a problem. If it’s a single node, then why not just go with AWS?