This topic came back on the ICP.Lab 5 - Gaming Lab, and after the presentation, wanted to write here some feedback for the future.
On the presentation, it’s clear that low replication subnets breaks several assumptions of the protocol. Being the main break that “subnets are all equal”. Breaking them increases complexity and with it costs of development/maintenance. I like consistency, so we should really try to solve this (and any other discussed problems) in an alternative (and less riskier) change.
Something it became apparent from the QA, is that:
Main problem is latency and cost of writing (that for gaming position is critical). Another issue is region / geography control.
We could use AWS, Unity Services, and other third party providers, but they are not “easily” integrated, like payments or canister controlling.
So I thought of 2 alternative solutions:
The same way we have boundary nodes, we could also have other specialised nodes. That are not “inside” the blockchain, but controlled by the blockchain (NNS or SNS). A canister/user could start/stop a Wasm VM/Node and pay for it’s cycles.
Another alternative, probably faster to implement, would be for a DAO to provide “Cloud as a Service”. Someone requests a canister, and through HTTP Outcalls it spins up the desired VM/Lambda/Fargate, with the required configs.
The ICP cycles need to be pre-paid, and when running out, it would stop / delete the VMs. Unfortunately the billing would need to be trusted to the core developers of that DAO. But they would also have strong incentives to keep the system running, as a business / service.
Maybe Boom DAO would be a good provider for this service.
Rooms for a subnet
Already today we are faced with the need to create a subnet for processing streaming data. The security level of such a subnet will be an order of magnitude lower. This is a necessary sacrifice for seamless operation. The most convenient tool for this is WebSocket. This technology allows you to send a message to a user without receiving a request from him. I intentionally exclude WebRTC technology because it doesn’t work after the router. Safety:
Use only certain types of data in the subnet that are not critical for applications and users.
Exclude the possibility of processing personal data and user assets Data standardization:
It is necessary to create a common registry of variables that will be processed by the subnet. This registry can be adjusted by the community. For example, for games, variables such as coordinates, speed, damage value, and so on are needed. Messengers and streaming services need other types of variables. Saving resources:
The subnet sends all received changes to its users. But as the ecosystem grows, the amount of data will grow all the time. I don’t think an OpenChat user needs to receive data about changes in the Eimolad game. And vice versa. Therefore, it is logical to sort data for users. Principle of operation:
Application developers create a room in a subnet and configure an array of variables for their community. Also, it configures the frequency of recording streaming data from the subnet to the Kernel Canister of the main network for reliable data storage. They should probably deposit a certain number of cycles for this. Such a requirement will reduce the risk of fraud and hacker attacks. Users of this application, when logging into a game or messenger, use Internet Identity and connect to a specific subnet room. Thus, the subnet recognizes the user and sends certain types of data to him. For example, in the form of JSON. The main important data is always stored in the main IC network, and the streaming data is processed in the subnet and periodically written to the main IC network as well.
Apparently, the BoomDAO structure can be used to base the architecture of such a subnet.