One of the design principles is the asynchronous environment all canisters operate in. My question regards why DFINITY chose the subnet model where a set of canisters are hosted on a single blockchain instead of assigning a blockchain to every single canister and assigning nodes on a per canister basis? Was this approach just technically infeasible? In theory it would make node shuffling much easier and would allow canisters to decide their own level of security/speed tradeoff.
3 Likes
Consensus comes with a lot of overhead if you want to achieve Byzantine Fault Tolerance. The number of messages per canister can vary a lot between different canisters and over time. Therefore we decided to batch messages for sets of canisters hosted on the same subnet and let them share the overhead.
You are right, different canisters have different requirements wrt replication, storage etc, …
At the moment, developers cannot choose between different subnet types, however we are working on bringing more types of subnets to the IC, as outlined here A Technical Overview of the Internet Computer | DFINITY | The Internet Computer Review. It will not happen over night though, there are technical hurdles to overcome.
4 Likes
It’s a mistake to create subnets based on what dfinity or even the community thinks is most useful to developers instead of letting them choose themselves, like what avalanche does. Having cannisters be their own blockchains is the simplest way sidestep this error regardless of whatever overhead it creates, but alas your response makes it seem like dfinity is unable to make this kind of architecture change so we’ll just have to see if it pans out in the future
2 Likes
I don’t see why you are making this assumption. If we get n=1 subnets you would be able to write your own code to have a blockchain and wire them up in what event swarm you desired. In fact today, if you wanted to improve your redundancy or security you could write a consensus layer on top of the existing subnets. You’d get some latency, but it all depends on your trade offs.
1 Like
I don’t see why you are making this assumption.
Because the longer you think about it the less it makes sense to group cannisters into subnets when cannisters communicate asynchronously, each cannister has a specific speed/security requirement that the developer, not dfinity or the community knows beforehand. Plus for node switching to occur with the current architecture a node must download the entire subnet state before they are able to join it (it’s also kind of crazy dfinity are pushing defi without node switching on subnets). If each cannister was it’s own separate subnet/blockchain a node would simply have to download an individual cannisters state to become a validator for it.
If we get n=1 subnets
Dfinity or the NNS shouldn’t be in control of what type of subnets are and aren’t allowed, central planning is silly. This may seem like a trivial difference but consider the possibility the Avalanche team adds a configurable node requirement spec for their subnet system such that you could configure a subnet that only allows high end hardware. The IC would literally become redundant in that case.
1 Like
I agree with this only if
- Resource constraints are not a problem for the system as a whole
- No possible kind of subnet poses a risk to the system as a whole
which are some very big assumptions for which I’d like to see a proper proof for if I were to vote about allowing arbitrary subnets.
1 Like
You cite Avalanche subnets but that is a completely different concept than what subnets are on the internet computer. The IC is a homogenous system, the fact that there are subnets is hidden to the developers and users as much as possible, canisters can talk to each other regardless of which subnet they are hosted on, there are system guarantees around inter-canister messaging, etc. Dfinity took great care to come up with a name (“subnets”) that removes confusion and makes it clear that the technology is different than what other blockchains do (shards, parachains, etc.)
Unfortunately, Avalanche came around, copied the name and used it for its own, different technology which is why there is now this confusion that you bring up. Avalanche calls itself a “heterogenous network of blockchains” (source). Their subnets are completely independent and there is currently no messaging between their different blockchains.
So for the IC, in order to provide messaging guarantees and simplification for users/devs, I think it makes sense that it is working the way it is now, in particular that it is homogeneous in terms of security and that developers cannot choose their own level of security.
However, in the future it is entirely possible to have subnets with specialized hardware for special types of execution (GPUs, AI, etc.) but still a homogenous level of security.
It is also possible for a single canister to occupy an entire subnet. If that happens then you basically have what you asked for in your original post: a single blockchain per canister. The fact that a subnet can host multiple canisters can be seen as an optimization to share overhead.
9 Likes
You raised a couple points but ultimately the only meaningful argument is that the IC is homogenous and it should stay that way, which is just wrong. It currently isn’t a homogenous system and nobody wants/plans for it to be a homogenous system, the NNS subnet has a higher node count than any other subnet because Dfinity realized their application requires a higher level of security than what a typical subnet provides. Do you see how that works? There is also talks about storage subnets. Badlands etc.
The vibe I get from dfinity and the community is that nobody really knows what the IC is or should be. IMO at it’s base level the IC should be a protocol and incentive structure for layering blockchain functionality on top of thousands of servers around the world so developers can easily access compute power by paying for computation cycles in a completely decentralized way. This is contrast to other blockchains where they’re basically just consensus machines, not computing platforms. When you look at it this way the current setup of the NNS controlling every aspect of the network like the creation of different subnets seems really weird and is mostly just a proxy for Dfinity controlling every aspect of the network.
tl:dr my suggestion makes the IC much much more extensible and lessens the involvement in any kind of centralized party but I have significant doubts that Dfinity is competent enough to change the architecture at this point so this discussion is probably moot anyway.
3 Likes
I think you make good points. There does seem to be confusion over what the IC is trying to be/become.
Unfortunately, I don’t think there is an alternative to the NNS? Ethereum etc can get away with no on chain governance because like you say, it is just a consensus mechanism.
The NNS is necessary, but the protocol should be designed such as to minimize it’s role in the network. My suggestion to do away with subnets in favour of single canister blockchains gets rid of the NNS’ current job of prescribing the subnets developers can deploy to.
Not only that it opens up the possibility of cycles being used as gas and the node rewards, instead of nodes being payed the same amount of ICP regardless of the amount of computation they do. And also facilitates my main point in that developers are the ones who know how many nodes they need for their application, many applications may not need any node replication at all, while some may need 1000+ node replication.
1 Like
But wasn’t that promised and already kind of happening with different subnet types and restrictions based on subnet type, e.g Storage subnet’s won’t be able to trigger updates on standard subnets.
They might share the consensus overhead but they also share the subnet’s ingress message capacity. With that being limited to 1000 ingress messages shared between users and canisters scaling might prove difficult even when a multi subnet approach is used.
Per canister blockchain would allow:
- Arbitrary replication factor set by the dev, widening the decentralization spectrum offered by the IC: from something more akin to standard cloud with a canister running on just 1 node all the way to greater decentralization with high node count.
- Per canister and not per subnet ingress queue.
- More frequent node rotation and possibly even some protocol level load balancer cause canisters can be quickly moved around to other nodes without the necessity of syncing the entire subnet’s state, providing greater safety for the network and a better use of IC’s computational capability.
The 2 downsides I can foresee are:
- higher overhead, as you mention, which might result in longer time to finality but higher throughput and easier scaling approaches
- all cross canister messages having the latency of cross subnets calls, which might be alleviated with protocol level functionality like canister groups.
2 Likes
This design would likely also remove the requirement for high-end server hardware to participate in the network, your hardware and internet throughput would simply dictate the amount of cannisters/blockchains you are able to validate at once
Didn’t he already answer your guy’s question?
That isn’t a viable solution and far from the idea @Kurtis0108 proposed.
-
Devs can’t arbitrarily choose the desired replication factor.
-
Occuping an entire subnet has a not negligible cost.
-
It’s hard to find a fresh subnets with no other canisters on it, let alone n subnets for multi canister dApps.
-
Single canister subnets potentially waste the IC’s computational capacity, as @yvonneanne said: “he number of messages per canister can vary a lot between different canisters and over time”, so when the canister isn’t being used the entire subnet just sits there doing nothing, which makes it harder if not impossible for the IC to become deflationary, see: Question regarding RE EXC-1168: add non-subsidised storage cost on 20+ node subnets (behind the flag) - #17 by Zane
-
Frequent node rotation and load balancing are harder to implement due to the amount of state which needs to be synced when the subnet membership changes
His proposal looks like the app chain thesis like avalanche and cosmos. If not what are the differences?
I am not convinced it solved a big enough problem to scrap the entire internet computer architecture for.
I don’t know much about cosmos but avalanche is similar except a subnet on avalanche runs a single virtual machine, cannot host data, and has some weird rules around subnet membership, i’m not sure that the avalanche protocol handles node membership for user created subnets
here is a simple diagram i’ve made of the current vs proposed architecture
2 Likes
They aren’t the same thing, appchains allow to spin up a custom blockchain with as less friction as possible, they are much more similar to the “subnet rental” feature proposed by Dfinity, main difference being appchain can completely customize the chain: VM, network parameters, base token, fees, etc… but they don’t provide nodes by default, those have to be hosted by the chain owner or obtained with financial incentives. Subnet rentals lack the customization aspect, other than maybe setting cycle cost to 0 cause the subnet is paid for in advance, but the nodes are provided by default, this could be seen as a pro and a con based on individual’s needs.
The idea proposed by kurtis just makes the current system more fluid and perhaps more scalable.
I think allowing nodes to filter the canisters they want to host is a slippery slope, the boundary nodes as censors proposal is a better approach.
1 Like
One con I’ve read about AVAX’ design is that their version of subnets don’t need to use the AVAX token. And since ICP requires deflationary effects to become healthy, it’s not something that should be overlooked. And also, it’s a new consensus design that has yet to be tested fully in the real world.
It’s not a con, it is by design and regardless avax subnet model has nothing to do with what is proposed here.