The DFINITY Foundation would like to propose expanding the ICP application subnets to 60 by adding 30 new subnets, each comprising 13 nodes to support the growth of the Caffeine AI, the self-writing apps platform.
Additionally, we propose adding a US-based subnet to the topology.
Background:
Caffeine.ai is a self-writing apps platform: the first complete tech stack designed for AI, where humans build through conversation only. This expansion is intended to accommodate increased demand for compute capacity of ICP, as well as scaling out in anticipation of Caffeine.ai release. With the proposed addition, the number of application subnets would increase to 60, ensuring ICP is well-positioned to meet both current and projected demand.
We will gradually add the new subnets and open them up to the public during the next several weeks. Our preliminary analysis suggests that the network’s spare capacity is sufficient to handle additional subnets (See Graph 1)
I don’t agree, there is no need to expand the ICP application subnets at all now, you can’t predict how many people will use caffeine ai in case there are very few, it would be a waste of resources
How much will be the token inflation from node providers. It was last month about 445k, does new number will be 1.34mil ICP. There is no way that users burn that much ICP from building stuff. If price will be pushed up, they will get less, but problem remains, too much token inflation.
Isnt 60 too much? 60x25k canisters is 1.5mil canisters, but 1 subnet can hold 100k canisters, thats 60x100k 6mil canisters.
Too much subnets.
I’m not sure if you are aware, but there is an excess of nodes that are sitting in standby mode and getting paid node provider rewards at this time. This change to add the 60 new application subnets has no impact on ICP inflation and does not add any new node providers or nodes to the network. It simply puts idle nodes to work. It has an additional benefit of enabling performance based node provider rewards that is based on a higher population of active nodes for each node provider. That means there is an increased probability that inflation could go down for any node provider who cannot keep a higher percentage of their nodes in operation reliably.
This will not impact inflation since we have a large excess of nodes in standby mode and getting paid node provider rewards already. Notice that @alexu referenced using the networks spare capacity to handle the additional subnets. That means he is not proposing to add new nodes or node providers or inflation.
I think thats the plan, to support 60 subnets the current nodes are enough. The announcement does not ask for new nodes instead it implies increase of alocation of subnets.
No new nodes are required for this proposal - we are simply utilizing spare capacity that already exists within the network.
Subnets are created as demand grows. Not utilizing all the nodes at once allows flexibility and a more optimal network topology, including capacity planning and maintenance.
We propose a US-based subnet to maintain regional balance. Ever since the EU-based subnet was launched, the community has been asking for something similar in the US. This proposal addresses that interest and will provide developers with more diverse deployment options.
Thanks for the announcement and explanation @alexu. Could you clarify if the NNS subnet special case regarding DFINITY-owned nodes is still intended to be in force?
If so I think this will need to be included in the summary table when a motion proposal is raised
I’m on my lunch break at the mo, but planning to take a closer look at this later.
This is indeed included in the prepared motion proposal text already. Please let us know if you have any comments - we’d like to submit the proposal this evening!
Thanks @alexu. The current standing IC Target Topology Motion Proposal makes it easy to spot from a distance by including it in the table.
In terms of there being spare capacity for 60 application subnets, I would not be surprised if (in practice) this makes it hard to achieve the IC Target Topology consistently, due to greater potential for getting stuck in local optima (requiring a lot of shuffling to meet the target topology, rather than a simple swap).
However I’m definitely in favour of this. I think the network should be striving to get the most out of the nodes that are available (I’ve posted some thoughts on this before, with respect to an elastic target topology).
I also think the presence of node provider clusters with a total node count surpassing the number of subnets (37 at the moment), necessitates the presence of additional subnets if those nodes are to become actively useful.
Thanks @alexu, before I vote on this I’d like to make sure I understand the situation completely. I think there are aspects that haven’t been made as clear as they could be.
I’ve diffed the proposed IC Target Topology table with the existing one (red deletions and green additions highlighted below).
Subnet Type
# Subnets
# Nodes in subnet
Total
SEV
Subnet limit NP, DC, DC Provider*
Subnet limit country
NNS
1
43
43
no
1 (with exception for DFINITY nodes)
3
SNS
1
34
34
no
1
3
Fiduciary
1
3428
3428
no
1
3
Internet Identity
1
3428
3428
yes
1
3
ECDSA signing
1
28
28
yes
1
3
ECDSA backup
1
28
28
yes
1
3
Bitcoin canister
1
13
13
no
1
2
European subnet
1
13
13
yes
1
2
Swiss subnet
1
13
13
yes
1
13
US subnet (NEW)
1
13
13
yes
1
13
Application subnet (NEW)
5160
13
663780
no
1
2
Reserve Nodes Gen1
–
–
100
–
–
–
Reserve Nodes Gen2
–
–
20
–
–
–
Total
10231021
A point that is not made clear is that the number of nodes in the Fiduciary and Internet Identity subnets are proposed to be reduced. This hasn’t been mentioned (other than by the figures in the table). Could you elaborate on this aspect?
This proposal proposes to shrink them back to 28 nodes. I think this deserves some discussion.
I also noticed that the total count of nodes is 2 less than last time.
My understanding is that there are 1425 replica nodes currently onboarded on the IC (or 1445 if you include boundary nodes). Am I correct in understanding this means there are 404 ‘reserve nodes’ (if you just count replica nodes)?
Can I ask why reserve nodes were omitted from the table this time around? Have I misunderstood the purpose that those two removed rows served?
You may wish to follow the LORIMER known neuron if you found this post helpful.
You are absolutely right! This is an oversight on our side. We’ll get this corrected, triple-check it this time and submit a new proposal. Thank you for being vigilant, as usual!
Indeed, we have decided to remove the reserve columns and treat all remaining spare servers as reserves.
Another reason for removing ‘reserve’ nodes is that this number can be somewhat misleading: the spare capacity should be well-distributed across the network for it to be utilized effectively. Currently, some large providers in countries like Switzerland and the US aren’t being heavily used due to country-level restrictions on subnet participation. So even with plenty of spare nodes, we’re limited in how many new subnets we can spin up until we optimize the current setup. The team is already working on it.
Thanks @alexu, LGTM. I’ve updated the diff below based on the new proposal summary.
Subnet Type
# Subnets
# Nodes in subnet
Total
SEV
Subnet limit NP, DC, DC Provider*
Subnet limit country
NNS
1
43
43
no
1 (with exception for DFINITY nodes)
3
SNS
1
34
34
no
1
3
Fiduciary
1
34
34
no
1
3
Internet Identity
1
34
34
yes
1
3
ECDSA signing
1
28
28
yes
1
3
ECDSA backup
1
28
28
yes
1
3
Bitcoin canister
1
13
13
no
1
2
European subnet
1
13
13
yes
1
2
Swiss subnet
1
13
13
yes
1
13
US subnet (NEW)
1
13
13
yes
1
13
Application subnet (NEW)
5160
13
663780
no
1
2
Reserve Nodes Gen1
–
–
100
–
–
–
Reserve Nodes Gen2
–
–
20
–
–
–
Total
10231033
I’ve rejected the prior proposal. I would recommend that other voters do the same. We need a robust NNS that doesn’t adopt stuff unless the outcome should be considered desired. The yes votes are still rolling in though. I suspect everyone is just excited about Caffeine - me too!
I’ve updated my SM proposal review tooling to point to this motion as the new IC Target Topology mandate (assuming this one is adopted).
You may wish to follow the LORIMER known neuron if you found this post helpful.
Note that I am no longer a member of Synapse, and I would strongly advise following others if you believe that known neurons should be held to account for their claims about transparency and decentralisation.
In fact, it just occurred to me while reviewing the vetkeys proposals that these two rows (above) appear to be out of date. The Fiduciary and II subnets are the signing and backup subnets for the various production keys, and the test subnets have 13 nodes.
I think this was pre-existing stale data in the IC Target Topology specification (rather than something introduced by this proposal). In any case, if my understanding is correct a follow up may be useful to amend this to avoid any future confusion.
