Is ther any plan to increase node count of subnet commonly?

As we have known, commonly a subnet is consisted of only 13 nodes. Comparing with the other layer 1 public chain, that is nearly nothing. And it is also cited as a proof to complain that IC is too centralized. Although, Dfinity does not agree with them, I personally do.

IC has created a new type of subnet that consisted of more nodes (28 for now). My question is,
is there any plan to increase the other subnet’s node count to at least 21?

I don’t know of any plans.

Since the 34 node subnet has linearly scaled cost, I would assume that moving to 21 nodes would mean that cost in general would raise by 50 percent, which would be a pretty big change to already existing services. Because of that I’d be surprised if all subnets would change to 21 nodes

2 Likes

Do note that the Internet Computer uses deterministic decentralization, i.e. the composition of a subnet is deterministically selected so it maximizes decentralization, in terms of operators, geography and jurisdiction. Compared with classic blockchains, who rely on anonymous validators, this means that a lot fewer replicas/validators are required in order to achieve the same level of decentralization.

E.g. given a standard proof-of-work or proof-of-stake blockchain, there will be a handful (on the order of 3-5; this is very, very common) of mining pools that control the majority (1/2 or 2/3) of the validators. Meaning that even though there may be a long tail of independent validators, running on their desktops at home, the network is actually controlled by only that handful of mining pools.

Which is the same level of tamper resistance that you get with a 13 node IC subnet, even if you allow for quite a bit of behind-the-scenes collusion between node operators.

3 Likes

Thank you for your reply.

Why only 13 nodes? What does this number 13 mean?
Don’t you think only 13 is too less?

13 doesn’t mean anything. Except that it’s 3f+1 (with f=4), meaning that it’s just as resilient (in terms of how many replicas can misbehave, 4) as a subnet with 14 or 15 nodes. And more resilient than a subnet with 12 replicas.

I don’t think 13 is too low, no.

One way of looking at it is the above “how many replicas can fail without causing the subnet to stall”. And the answer for a 13 node replica is 4. For context, I used to work at Google and the rule of thumb there was to have 3 replicas of everything, so you could afford 2 of them going down (or, equivalently, you still had one backup if one of them went down). So allowing for 4 replicas to fail at any given time while maintaining liveness is way more than what Google thinks is necessary for the vast majority of their services. (For more context, just before Genesis we thought subnets should have 7 replicas, which would have given us the same or better resilience as 3 replicas in a non-Byzantine distributed system.)

The other way to look at it is decentralization: how many parties must collude to tamper with the state of the blockchain (aka Nakamoto coefficient). With your average proof-of-work or proof-of-stake network, that number is usually in the single digits: a handful of large mining pools control the majority (51% or 67%) of validators. So even if there are thousands and thousands of validator nodes (as opposed to 13 on the IC) it literally only takes something like 3-5 people (controlling thousands and thousands of nodes) to collude to take over a network. And while the network’s native tokens may not be permanently affected (a handful of honest validators can still decide that the blocks proposed by the malicious majority are invalid; and eventually restore the network to its last valid state); it’s still likely that exchanges or bridges have already acted on the invalid transactions; and such actions are generally not reversible (e.g. you may still have your wrapped Bitcoin, but the actual Bitcoin behind it is already in my wallet).

On a regular IC application subnet consisting of 13 replicas, you’d need 9 replicas to collude in order to tamper with the state of the subnet. Even if you consider significant behind-the-scenes collusion between node operators (e.g. $random_big_company being secretly behind 1/3 of the node providers), you still likely require at least a handful of parties that need to collude to make it happen. Which is the same as the above.

2 Likes

Partly, I agree with you. About count of validators, the big difference between ICP and the other chain is that the count of individual. Although the other chain may be running on clouds and by joining mining pool actually they are under the control of ONE entity, but as a validator of individual, they all have choice of doing or not. For example, even over 13 validators can choose to exit, that does not hurt the chain.
And if this happens on IC, that would be critical. I mean, the exact count of validator is important too.

We all know that bitcoin integration has been deployed on IC, nobody would send big value of bitcoins to IC that controlled by only 13 nodes. That is not safe, trustless.