Question about ICP's subnet design

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.

3 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.

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.

1 Like

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.