So my takeaway is that it can be done but requires some work to ensure security.
I donât think we should go for specialization at all at the moment, how big is your Dapp? How many users? How much benefit does it bring to IC? Why do you have to have a separate subnet? Itâs a waste of resources. There is no profit, and no special contribution, so why take the money from IC fams and enjoy the resources exclusively?
This is the case with openchat, which already has 2 subnets to itself, but if there are really some new users coming in, will open dozens of subnets? The Dapp is a waste of resources with no regard for its own efficiency.
Every day either open a separate subnet for this one or a low consensus subnet for that one, taking the retailerâs money instead of the money. Some people have exclusive access to subnet resources, while hundreds of other Dapps are crowded together. The blockchain is known for its fairness, but it still depends on who is familiar with the foundation and has a good relationship with it.
Which blockchain can also change the consensus strength at will? Want to be completely reduced to an insecure chain?
If you want to it be fast, go open AWS first.
If you have a million users, are really awesome and contribute a lot, itâs no problem to give you a subnet. You donât even have a few hundred daily active users now, so why should you be given a subnet and make it special?
How will users be made aware by the IC that a dApp is running on a low replication subnet for transparency? Developers will want to release the fastest dApp, and install it on a one node subnet, while users will unwittingly trust that it is as secure as IC consensus.
I would say it is on the developer and the users to make sure that they are aware about such thing. The community can also do its part by spreading awareness on different security models for different subnets.
Ridiculous enough! 1 node subnet? 4 nodes in the same region? Go to AWS. Stop ruining the network! IC is a blockchain not your game server
For 1-node subnet, donât even think about it. Since from @Manu you should have at least 4 nodes.
On 4-nodes I support christianâs opinion.
If you are looking for high performance and lower the latency as much as possible. Why even consider getting your game âon-chainâ? In your reply you claim that you are aiming for âcomposibilityâ using smart contracts, that sense of âcomposibilityâ needs to be backed up by a network that is decentralized and secure enough ,right?
Thatâs the purpose of getting things âon-chainâ. If thatâs the case why would you want to increase the security risk?
Every other dapps on IC is trying their best to optimize their performance without changing the consensus. If you think 4-nodes is enough and your project managed to require this 4-node subnet. Then why donât everyone just do the same? I believe every project on IC want their dapp to have a better performance.
A 1-node subnet seems good if it will not ruin the overall IC consensus. Maybe IC can just be a blockchain as well as a game server if IC really wants to replace AWS totally: IC can do whatever AWS can do, but not vice versa.
Hello pphaolu,
First, Iâd like to clarify a few things.
-
This subnet is not only for Plethora. We have met with nearly every gaming project on the IC to discuss their pain points and the infrastructure they need to build. This proposal isnât coming from us, itâs coming from every gaming project on the IC. This is the first step in pushing the gaming vertical on the IC, which until this point has been severely neglected. Gaming and AI will be the catalysts for the next bull market, we cannot overstate how ICP will be left behind if we donât take this seriously. Low replication subnets are required for on-chain AI and Gaming.
-
These subnets are permissionless for anyone to use. These arenât app-specific subnets. Anyone can deploy real-time simulation, AI, storage, or other use cases to these subnets.
-
The entire game/dapp isnât on the 4-node subnet. All valuable data and game logic are on 13-node subnets. 4-node subnets would be used to offload non-critical execution from the main dappâs canisters.
-
Iâm not sure why you believe these subnets would take money away from the ecosystem? In fact, node providers would be receiving thousands of dollars more from gaming and AI projects. Node providers on low rep subnets will be the most profitable because these subnets have the highest cycle burn. ICP projects should be paying node providers instead of AWS.
-
I agree that every dapp shouldnât rush to these subnets. Only certain logic that requires low replication should be on these subnets. And never should an entire dapp be on a 4-node subnet.
Regarding security concerns, these are the measures that would be in place for 4-node subnets:
- Canisters can only have public functions that return void (otherwise callers on high-replication subnets might get stuck waiting for responses)
- Canisters cannot send cycles to other subnets (otherwise faulty subnets could manufacture/export fake cycles)
- Dealing with outcalls to other subnets, in case they refuse to consume the responses
- Handling how to restart faulty/malicious subnets
Hello WoW,
You bring up good points, thanks for sharing.
I like to think of it this way:
Why pay AWS when we could pay Node Providers?
To run a game server on AWS you need to: create an AWS account, set up EC2 instances, configure deployments, firewall, security groups, key/pairs, reverse proxy, SSL, name records, VPC, TCP/UDP ports, and load balancing/scaling systems. This is non-trivial (Iâve done it) and it requires an experienced DevOps engineer.
Also, you have to rely on a third-party multiplayer networking solution which could be written in a language youâve never used before. And each game dev is using a different networking solution/programming language.
What if instead, game projects deployed a motoko canister and within 10 seconds they have real-time multiplayer thatâs composable with every other game on the IC. Better yet, what if they didnât have to deploy a canister. Instead, they just plugged their game into an existing one. Thatâs the power of smart contract standards. Game devs save themselves months of development, and can immediately leverage cross-game data and simulation that was never possible before. Thatâs what I mean by composability.
Why even consider getting your game âon-chainâ? In your reply you claim that you are aiming for âcomposibilityâ using smart contracts, that sense of âcomposibilityâ needs to be backed up by a network that is decentralized and secure enough ,right?
The entire IC network will always remain secure. I think we need to explore having high-security and low-security execution environments within the IC network. This wouldnât compromise the integrity of the entire network, it would just provide islands of computation that devs could choose for their needs. But I agree itâs important to enforce that devs run important logic/state on 13 node subnets.
Non-critical execution can be offloaded to low rep subnets, in the same way they are offloaded to AWS today. But with low rep subnets, game devs would benefit from the composability of the IC execution environment, programming language, and open data standards.
Every other dapps on IC is trying their best to optimize their performance without changing the consensus. If you think 4-nodes is enough and your project managed to require this 4-node subnet. Then why donât everyone just do the same?
Networked games are very different from other dapps. They are extremely complex to build and require faster latency than DeFi, SocialFi etc.
Games arenât limited by optimization, they are limited by the speed of light. You canât optimize the 700-800ms it takes for a data packet to be sent around the world through fiber optic cables.
Instead, games optimize by placing servers geo-located near every large player base. Thatâs why games divide their players based on US, EU, Asia servers.
Also, this isnât a Plethora-only issue. We have met with nearly every game project on the IC to learn their pain points and create infrastructure to help them. This proposal isnât just from us, itâs from every game project on the IC.
So I disagree that a 1 node subnet is a bad thing⌠its just another tool in the box. Not every part of a businessâ webstack needs to be replicated.
See here â Data Processing Subnet
Its all about keeping things on the same stack. If you want to run a non-mission critical bot for your business⌠maybe it just gathers user stats or something like that⌠why does this need to be replicated 13 times?
It comes down to efficiency. Do the mission critical stuff on fully replicated subnets and do the hard data processing (non-mission critical) in the cheapest and fastest way.
HTTP outcalls currently go through consensus so they arent great for fast communication with the outside world. So any data procesing would be better inside the IC.
I give an example here -ă Data Processing Subnet
Great topic - there are big overlaps with the post I raised on a data processing subnet. Iâll not go over it all again but in short to really replace AWS / full web stack we canât replicate EVERYTHING⌠thatâs just wasteful and frankly pointless.
Do the sensitive/ critical things securely and the non-critical things fast and cheap!
The question for Dfinity - is your whole business webstack on chain? Why not?
I know the answer⌠no - because you cannot process all the data for the dashboard (and probably other services) fast enough fully on chain.
Itâs why Saorsa labs has 3 Heroku servers and trad database on top of multiple ICP canisters (frontend and bavkend). I would much prefer to have all on the IC, written in rust.
I love the fully-on-chain thing but being honest⌠you canât run the world fully on chain. Maybe the term should be Fully sovereign/ independent.
This is a tough choice for me cause while I believe the network should be less omogeneous and offer more flexibility to suit everyoneâs specific needs, I donât think it should be tailored for specific projects in a âhardcodedâ way, especially if these changes come with protocol modifications that Dfinity has to work on with their limited manpower and the project asking for it hasnât proved the effort will be justified, so if the title of the proposal were âCreate subnets with lower replicationâ it would have been less troubling for me.
Personally I think moving from subnets to a per canister/canister group consensus model would benefit everyone way more than creating specific subnets and have talked about this in the past but the discussion didnât catch on: Question about ICP's subnet design
Furthermore I donât believe your specific use case is currently worth asking Dfinity to shift their internal priorities, Iâve been gaming for over 15 years and modding is what got me into coding so I take this stuff to heart.
Iâve seen you mentioned some big franchises like Half Life, ArmA and Warcraft as examples of what modding is capable of and why this is a worth endeavour, thing is those games are on their own without any user made content already amazing games, on top of it they facilitate content creation by offering dev tools, tons of assets, built in functionalities, etcâŚ
So I ask where is all of that with Plethora? Cause Iâve seen some pretty big claims like fully on chain games 10xing how humanity creates value and interact, but when I look at what youâve actually built itâs nothing to write home about, it is very underwhelming as in âI played games made for Ludum Dare that were more entertainingâ level of underwhelming, so when I read about this grand plan to improve gaming that has never been done before and possibly canât even be done cause a 3 node subnet will have considerable latency too and your product doesnât even come close to what the industry offered us 20 years ago I canât help being skeptical.
I know it may sound harsh but I deeply care about this stuff and have grown a bit impatient about web3 games selling grandiose ideas when 99% of them are less fun than flash games from 2012, all I see is NFT this and onchain that, buzzwords that investors like or at least used to like but actual gamers despise, meanwhile big players in the industry like Epic are actively and silently working towards a goal similar to what you envision without encumbering themselves by getting caught in the âeverything must be onchain memeâ, which for this specific use case brings more issues than benefits, instead they chose to focus on the stuff that is really needed: easy access to code, game logic and assets, very flexible tools anyone can use, a brand new programming language to write extensible and easily scalable game logic, frameworks to spread simulations on different servers and way way more.
I highly suggest to watch this yearâs Epic GDC presentations as Tim Sweeney goes deep into what he envisions the future of the Metaverse will be and one key aspect of it is the fact it isnât owned by anyone, but not cause it is decentralized or run by a DAO, but because (in his opinion) it will be an aggregate of content built using open standards, just like the web, and therefore the engine/clients used will be mere implementations of those standards.
I agree with you very much, and this is exactly the point I want to express as a game practitioner. None of the games that are currently on IC are good enough to apply for the sub-net. Please optimize your game first, or at least make its front-end page less laggy.
I would like to see the idea of low-replication subnets / untrusted subnets generalized and come to life in the form of âprivate subnetsâ.
The concept of âprivate subnetâ means that anyone can just deploy a subnet on any hardware they like with any number of nodes they like (one or more) and connect it to the IC in a permissionless way. The NNS does not need to create or approve private subnets. Of course, being untrusted, there are some limitations such as a private subnet cannot create cycles, calls from the IC to a private subnet are limited to one-way calls (unless timeouts are introduced), etc. A âprivate subnetâ can of course be made as public or decentralized as one wishes but it remains untrusted from the ICâs perspective.
I have heard of the idea as early as 2017 that besides the one public IC there could be many private ICâs just like there are intranets vs the internet. They are connected but with some limitations. But it shouldnât be required to get permission or approval to deploy one. The key point is that the same code can run on a private IC and on the public IC and to have the same development experience. The idea even went so far that one could move a deployed canister with state from a private IC to the public IC when it feels âreadyâ.
I would also like to throw out an additional idea inspired by some conversations with @rckprtr and perhaps some others.
Imagine an area of memory similar to stable memory but more volatile, i.e. volatile memory. This memory would not go through the same rigorous BFT process, but might have a lesser and much cheaper and faster process that is still fault tolerant to some extent.
Or imagine if queries could be cached more aggressively, and perhaps gossiped to other nodes, allowing a large volatile RAM area to work with.
This is already possible with query calls currently, as you can store anything on the heap, do any calculation within the limits, and it is free (currently) and wiped after the call. If this could somehow be extended and shared across nodes I wonder if it could provide similar capabilities.
Basically, cheaper storage areas like stable memory, volatile memory.
Hi Timo!
I really like this idea. Private subnets could prevent the issue of having to outsource computation to AWS. Low-latency, cheap storage, and geographic positioning could all be uses cases of private subnets.
And as a result, the IC benefits in many ways:
- Node providers make money instead of AWS
- Streamlined developer experience
- Permissionless deployment
- One programming language
- Composability with mainnet IC
Hi Jordan! Thanks for chiming in.
This is an interesting idea, Iâll definitely be thinking about it more. Iâm wondering how this would work though in low-latency applications where one user changes volatile memory and another user needs to fetch it instantly. If itâs a 13-node subnet, nodes might not have the same volatile memory at all times.
Although I suppose when the user updates volatile memory, they could send their update to all 13 nodes at the same time. That would cut down the latency of nodes having to share the new data with each other.