Expanding the list of Public Subnets on the Internet Computer

Governance NNS proposal discussions
1

Hello IC Community,

I’m excited to share some recent developments and propose an update of the list of public subnets on the IC Mainnet. As many of you may have noticed, with the recent introduction of bob.fun, there has been a substantial increase in cycle consumption, surging from approximately 20 TC/s in the last week to over 300 TC/s today. This surge is primarily due to the proof-of-work algorithm as per bob.fun implementation. Subnets are still performing with only a minor impact, and non-CPU-intensive message executions are largely unaffected.

In light of this, we believe it’s the right time to propose an expansion of the pool of public subnets. Historically, the IC had several underutilized subnets that were not made public due to a lack of demand. However, with the current developments, opening these subnets could greatly benefit the community.

We propose to make the following subnets public, allowing all principals to install canisters and take advantage of the available resources:

Proposed public Subnets:

  • 3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe
  • 4ecnw-byqwz-dtgss-ua2mh-pfvs7-c3lct-gtf4e-hnu75-j7eek-iifqm-sqe
  • 6pbhf-qzpdk-kuqbr-pklfa-5ehhf-jfjps-zsj6q-57nrl-kzhpd-mu7hc-vae
  • brlsh-zidhj-3yy3e-6vqbz-7xnih-xeq2l-as5oc-g32c4-i5pdn-2wwof-oae
  • cv73p-6v7zi-u67oy-7jc3h-qspsz-g5lrj-4fn7k-xrax3-thek2-sl46v-jae
  • e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe
  • fuqsr-in2lc-zbcjj-ydmcw-pzq7h-4xm2z-pto4i-dcyee-5z4rz-x63ji-nae
  • gmq5v-hbozq-uui6y-o55wc-ihop3-562wb-3qspg-nnijg-npqp5-he3cj-3ae
  • jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe
  • lspz2-jx4pu-k3e7p-znm7j-q4yum-ork6e-6w4q6-pijwq-znehu-4jabe-kqe
  • mpubz-g52jc-grhjo-5oze5-qcj74-sex34-omprz-ivnsm-qvvhr-rfzpv-vae
  • nl6hn-ja4yw-wvmpy-3z2jx-ymc34-pisx3-3cp5z-3oj4a-qzzny-jbsv3-4qe
  • o3ow2-2ipam-6fcjo-3j5vt-fzbge-2g7my-5fz2m-p4o2t-dwlc4-gt2q7-5ae
  • opn46-zyspe-hhmyp-4zu6u-7sbrh-dok77-m7dch-im62f-vyimr-a3n2c-4ae
  • pjljw-kztyl-46ud4-ofrj6-nzkhm-3n4nt-wi3jt-ypmav-ijqkt-gjf66-uae
  • qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe
  • yinp6-35cfo-wgcd2-oc4ty-2kqpf-t4dul-rfk33-fsq3r-mfmua-m2ngh-jqe

As a change from proposal 130724, we believe this upcoming new proposal will a) allow the IC community to better utilize existing IC resources, and b) allow bob.fun to be even more fun!

To be clear, this proposal does not create any new subnets. It only allows any principal to create new canisters on the subnets listed above. That is expected to increase the utilization of these subnets.

We welcome your feedback and support on this proposal. Let’s work together to make the Internet Computer even more vibrant and versatile!

Best regards,
Sasha

6 Likes
3

Thanks @Sat, this sounds exciting! I have a few questions to make sure I understand the context.

Is this the only reason these subnets have not previously been made public? I’m trying to understand why there would be a need to prevent the use of these subnets, just because the demand wasn’t there for them at the time.

Is this sort of subnet configuration visible somewhere (e.g. via IC-Admin)? I’ll be sure to check, but wont have time until later today after work.

Thanks again for this announcement :slight_smile:

1 Like
4

Here is the diff of the subnets.

image
image1313×342 87.4 KB

  • brlsh was a fleek-only subnet
  • fuqsr is a test key tECDSA backup subnet
  • gmq5v was a fleek-only subnet
  • jtdsg was a public subnet but was removed to balance load across other subnets
  • mpubz was a fleek-only subnet
  • o3ow2 used to be a public subnet but was removed to balance load across other subnets
  • pjljw used to be a public subnet but was removed to balance load across other subnets
  • qdvhd used to be a public subnet but was removed to balance load across other subnets
  • yinp6 used to be a public subnet but was removed to balance load across other subnets
2 Likes
5

Sadly no, the information is present in the CMC canister but there is no public interface to get it out. At the moment we can only use previous NNS proposals to conclude what is the current state. @nikola-milosa wanted to try to tackle this by extending the CMC canister to expose this information. Let’s hope that works out.

3 Likes
6

Thanks @Sat, an element of this proposal that could do with being highlighted and made more explicit for voters is that k44fs is being removed from the list of public subnets, and made private (due to ‘Subnet has more than 300 GiB state size’). This is stated in the proposal, but it’s buried in a table.

Presumably when a subnet is removed from the list of NULL ‘who’ principals, it defaults to being restricted to the root NNS canister principal (exclusively requiring NNS proposals to deploy canisters)?

I’ve not had much time to review this proposal, and I’m planning to take a closer look this evening.

7

No, not even NNS root can then create new canisters on that subnet unless it is explicitly allowlisted as every other principal.

If a principal already controls a canister on that subnet, then that principal can still a) upgrade the existing canisters and b) use the existing canisters to create new canisters on that subnet using the management canister.

2 Likes
8

This!
So if you already have a wallet canister on that subnet, you can still create new canisters, up to the canister limit on the subnet.

9

Thanks @Severin, in this case could you clarify what the whitelist will be for k44fs once this proposal executes? As far as I can gather from analysing SetAuthorizedSubnetworks proposal history, this subnet has never being assigned an explicit ‘who’ principal for whitelisting.

Presumably all subnets start out with whitelist principal(s)? This appears to be the case, given proposal 129398, which claims to have removed rd2df from the CMC’s whitelist (would be interesting to know why), even though rd2df was never explicitly whitelisted for the CMC.

Thanks for clarifying, this explains why public subnets switch to private when they’re considered full (the public/private terminology confused me). Why not reduce the max allowed canisters for the subnet instead (presumably there’s also a max memory limit)?

10
Subnet id Public Description
bkfrj-6k62g-dycql-7h53p-atvkj-zg4to-gaogh-netha-ptybj-ntsgw-rqe false [Explicitly removed] European subnet

In the proposal summary, can I ask what’s meant by ‘[Explicitly Removed]’? It doesn’t look like there’s ever been a SetAuthorizedSubnetworks proposal for bkfrj.

I gather for pzp6e and x33ed (both also declared as ‘[Explicitly Removed]’) this refers to proposal 97470 and 110323. What about uzr34 and w4rem (98066 and 129399)?

I’m only asking to get a better sense of things :slight_smile:

11

For anybody searching for the NNS proposal related to expanding the pool of public subnets, this is proposal 132409.

1 Like
12

I don’t have the list handy, but you can compute it with the output from get_principals_authorized_to_create_canisters_to_subnets.

AFAIK no, the whitelist starts empty, but this could be a leftover from Genesis where things were configured before Governance started recording proposals

Because of bad UX. If you reduce the max canister limit but still keep the subnet public then both existing users of the subnet the CMC will hit ‘canister limit hit’ errors when attempting to create new canisters. If you switch the subnet to private the CMC will never hit those errors as it doesn’t attempt to create new canisters there, and existing users won’t hit the error for a longer time

3 Likes
13

It looks like principal pr42y-f6vp7-lbhgk-qt4oq-524yv-yabkq-6bhr7-nludh-bbbpj-aiuhu-xqe will still have explicit permission to deploy to subnet k44fs after it’s made private by this proposal. Thanks for pointing out the get_principals_authorized_to_create_canisters_to_subnets endpoint @Severin.

This has made me curious of a few other things. But I’ll ask those questions on the general subnet discussion topic as they’re not directly related to this proposal (which I’ll vote for when I get home shortly) :+1:

As a side note, mpubz and o3ow2 are already fairly close to 300GB, and o3ow2 and qdvhd are already close to 60000 canisters, so worth keeping an eye on after this proposal executes and these subnets are made public (I’m surprised they’re being made public given that these thresholds have been used for justifying other subnets being private). Anyway, I’ve now voted to adopt.

1 Like
14

@Lorimer it basically says that the subnet has neither >60k canisters or >300GB data so we added an explicit rule in the code to not make subnet public. The reason for not making it public is given right after that.
Does that make sense?

1 Like
15

Thanks @Sat, this makes sense now. I was trying to reproduce the same sort of table based on information in proposal history (and subnet state), but looks like that’s not possible. I see that there’s a blacklist of subnets that should not be made public, for the reasons you provided :slight_smile:

Thanks for helping me understand! :sweat_smile: I’ll be more prepared for this sort of proposal in the future.

1 Like
16

Quick update: @nikola-milosa and @Luka made a change in the CMC canister to fetch a list of all public (default) subnets. Such heros! Thank you boys!

4 Likes