Updating the list of public subnets on January 24 2025

Updating the list of authorized subnets to:

Subnet id Subnet Type Public Description
2fq7c-slacv-26cgz-vzbx2-2jrcs-5edph-i5s2j-tck77-c3rlz-iobzx-mqe Application false Subnet has more than 60000 canisters
3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe Application false Subnet has more than 400 GiB state size
4ecnw-byqwz-dtgss-ua2mh-pfvs7-c3lct-gtf4e-hnu75-j7eek-iifqm-sqe Application true
4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe Verified Application true
5kdm2-62fc6-fwnja-hutkz-ycsnm-4z33i-woh43-4cenu-ev7mi-gii6t-4ae Verified Application true
6pbhf-qzpdk-kuqbr-pklfa-5ehhf-jfjps-zsj6q-57nrl-kzhpd-mu7hc-vae Application true ⇒ false Subnet has more than 400 GiB state size
bkfrj-6k62g-dycql-7h53p-atvkj-zg4to-gaogh-netha-ptybj-ntsgw-rqe Application false Explicitly marked as non-public (European subnet)
brlsh-zidhj-3yy3e-6vqbz-7xnih-xeq2l-as5oc-g32c4-i5pdn-2wwof-oae Application true
csyj4-zmann-ys6ge-3kzi6-onexi-obayx-2fvak-zersm-euci4-6pslt-lae Verified Application false Other verified subnets opened up in this run
cv73p-6v7zi-u67oy-7jc3h-qspsz-g5lrj-4fn7k-xrax3-thek2-sl46v-jae Application true ⇒ false Subnet has more than 400 GiB state size
e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe Application true ⇒ false Subnet has more than 400 GiB state size
ejbmu-grnam-gk6ol-6irwa-htwoj-7ihfl-goimw-hlnvh-abms4-47v2e-zqe Verified Application true
eq6en-6jqla-fbu5s-daskr-h6hx2-376n5-iqabl-qgrng-gfqmv-n3yjr-mqe Verified Application false Subnet has more than 60000 canisters
fuqsr-in2lc-zbcjj-ydmcw-pzq7h-4xm2z-pto4i-dcyee-5z4rz-x63ji-nae Application true
gmq5v-hbozq-uui6y-o55wc-ihop3-562wb-3qspg-nnijg-npqp5-he3cj-3ae Application true ⇒ false Subnet has more than 400 GiB state size
io67a-2jmkw-zup3h-snbwi-g6a5n-rm5dn-b6png-lvdpl-nqnto-yih6l-gqe Verified Application true
jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe Application true ⇒ false Subnet has more than 400 GiB state size
k44fs-gm4pv-afozh-rs7zw-cg32n-u7xov-xqyx3-2pw5q-eucnu-cosd4-uqe Application false Subnet has more than 400 GiB state size
lhg73-sax6z-2zank-6oer2-575lz-zgbxx-ptudx-5korm-fy7we-kh4hl-pqe Application false Subnet has more than 400 GiB state size
lspz2-jx4pu-k3e7p-znm7j-q4yum-ork6e-6w4q6-pijwq-znehu-4jabe-kqe Application true
mpubz-g52jc-grhjo-5oze5-qcj74-sex34-omprz-ivnsm-qvvhr-rfzpv-vae Application true ⇒ false Subnet has more than 400 GiB state size
nl6hn-ja4yw-wvmpy-3z2jx-ymc34-pisx3-3cp5z-3oj4a-qzzny-jbsv3-4qe Application true ⇒ false Subnet has more than 400 GiB state size
o3ow2-2ipam-6fcjo-3j5vt-fzbge-2g7my-5fz2m-p4o2t-dwlc4-gt2q7-5ae Application true ⇒ false Subnet has more than 400 GiB state size
opn46-zyspe-hhmyp-4zu6u-7sbrh-dok77-m7dch-im62f-vyimr-a3n2c-4ae Application true ⇒ false Subnet has more than 400 GiB state size
pae4o-o6dxf-xki7q-ezclx-znyd6-fnk6w-vkv5z-5lfwh-xym2i-otrrw-fqe Verified Application false Other verified subnets opened up in this run
pjljw-kztyl-46ud4-ofrj6-nzkhm-3n4nt-wi3jt-ypmav-ijqkt-gjf66-uae Application true
pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae Application false Explicitly marked as non-public (Fiduciary subnet)
qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe Application true
qxesv-zoxpm-vc64m-zxguk-5sj74-35vrb-tbgwg-pcird-5gr26-62oxl-cae Verified Application false Other verified subnets opened up in this run
shefu-t3kr5-t5q3w-mqmdq-jabyv-vyvtf-cyyey-3kmo4-toyln-emubw-4qe Verified Application false Explicitly marked as non-public (Distrikt subnet cannot be public before migrating away from ICQC)
snjp4-xlbw4-mnbog-ddwy6-6ckfd-2w5a2-eipqo-7l436-pxqkh-l6fuv-vae Verified Application false ⇒ true
tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe System false System subnets should not have public access
uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe System false System subnets should not have public access
w4asl-4nmyj-qnr7c-6cqq4-tkwmt-o26di-iupkq-vx4kt-asbrx-jzuxh-4ae Verified Application false Other verified subnets opened up in this run
w4rem-dv5e3-widiz-wbpea-kbttk-mnzfm-tzrc7-svcj3-kbxyb-zamch-hqe System false System subnets should not have public access
x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae Application false Explicitly marked as non-public (SNS subnet)
yinp6-35cfo-wgcd2-oc4ty-2kqpf-t4dul-rfk33-fsq3r-mfmua-m2ngh-jqe Application true

Find the full proposal text at https://dashboard.internetcomputer.org/proposal/134971 .

3 Likes

Proposal 134971 | Tim - CodeGov

Vote: Adopt

This proposal changes 9 subnets from public to private due to having a state size greater than 400 GiB and 1 subnet from private to public. The payload matches the list in the proposal text and the changes are in keeping with previous similar changes.

About CodeGov…

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

2 Likes

The context/justification for part of this proposal is here (the part that makes a private subnet public) →

The previous proposal in this series is this one, 16d ago → proposal 134924

Proposal 134971 Review | LORIMER Known Neuron

VOTE: …pending an answer to the question below… YES

TLDR: I’ve checked the claims in the proposal against CMC data and proposal history, and have produced the table below. From what I can see the majority of claims in the proposal are inaccurate.

@timk11, can I ask where you verified this? →

@dmanu, where have you got those canister stats from? They’re not consistent with what I can see. Only one of those subnets has exceeded the 400 GB memory usage threshold. Given this I’m planning on rejecting this proposal, as the actions appears to be based on faulty claims.

Subnet id Subnet Type Public Authorised Principals Last Changed Canisters Memory Usage Proposal Action and Claims
6pbhf Application true false EVERYONE 2025-01-09 by 134674 35,266 400.001 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size
cv73p Application true false EVERYONE 2022-03-11 by 49048 51,383 243.312 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
e66qm Application true false EVERYONE 2022-03-11 by 49048 35,845 204.522 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
gmq5v Application true false EVERYONE 2024-09-13 by 132409 33,748 177.005 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
pr42y 2024-09-13 by 132409
jtdsg Application true false EVERYONE 2024-09-13 by 132409 27,158 236.158 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
pr42y 2024-09-13 by 132409
mpubz Application true false EVERYONE 2025-01-09 by 134674 55,296 305.29 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
pr42y 2025-01-09 by 134674
nl6hn Application true false EVERYONE 2025-01-09 by 134674 31,743 271.373 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
o3ow2 Application true false EVERYONE 2025-01-09 by 134674 56,584 270.292 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
opn46 Application true false EVERYONE 2025-01-09 by 134674 39,880 311.648 GB Subnet Type: Application, Public: true ⇒ false Subnet has more than 400 GiB state size :face_with_monocle::slightly_smiling_face:‍↔
pr42y 2025-01-09 by 134674
snjp4 Verified Application false true bl7vf + EVERYONE 157 4.457 GB Subnet Type: Verified Application, Public: false ⇒ true
hepun + EVERYONE
ilqei + EVERYONE
kr2dh + EVERYONE
m3m6n + EVERYONE
mcoor + EVERYONE
pr42y + EVERYONE
y5mgz + EVERYONE
zcmil + EVERYONE

Other than the subnets that are being made private, this proposal would make snjp4 public (for anyone to deploy canisters to). It’s currently private, with explicit deployment privileges available to a select few principals. Context for this is pointed to in the post above.

I did a quick spot check on the dashboard of several of these subnets and all of them exceeded the 400 GiB limit at the time the proposal was created and at the time that @timk11 posted his comments. Did you check the State history @Lorimer and do you think it should be relevant to the adoption or rejection of this proposal?

2 Likes

Thanks Wenzel. I didn’t check the history. I think an explanation for what happened here is needed (it’s very irregular). I wonder if it’s related to the IC OS version these subnets were running or something. If I have a chance I’ll take a look. In the meantime I’ll hold off rejecting.

1 Like

I agree it looks odd, but perhaps not the first time. Here is the full State history (approx 2 years) of another subnet and it has several step changes above the 400 GiB limit. I have no idea what causes it or why is comes back down below 400 GiB.

1 Like

I’ve taken a look and their synchronised huge memory usage spike doesn’t seem to be related to the IC OS version (or at least not that alone). Based on IC-OS election proposal history, there currently appear to be 4 blessed replica versions registered. I’ve listed these below, ordered by elected date

  • 76a634c, elected 2025-01-06 (proposal 134663), running on 0 subnets
  • 4367024, elected 2025-01-07 (proposal 134684), running on 0 subnets
  • aa705aa, elected 2025-01-13 (proposal 134773), running on 1 subnets
  • 233c1ee, elected 2025-01-20 (proposal 134900), running on 36 subnets

All of the subnets that spiked (and are proposed to be made private) have been running the lastest IC OS version for days, and are still running it (233c1ee).

  • 6pbhf, has been running 233c1ee since 2025-01-23 (3 days)
  • cv73p, has been running 233c1ee since 2025-01-22 (4 days)
  • e66qm, has been running 233c1ee since 2025-01-23 (3 days)
  • gmq5v, has been running 233c1ee since 2025-01-23 (3 days)
  • jtdsg, has been running 233c1ee since 2025-01-23 (3 days)
  • mpubz, has been running 233c1ee since 2025-01-23 (3 days)
  • nl6hn, has been running 233c1ee since 2025-01-23 (3 days)
  • o3ow2, has been running 233c1ee since 2025-01-22 (4 days)
  • opn46, has been running 233c1ee since 2025-01-22 (4 days)

If these subnets were private, their current memory usage would warrant them being made public again (except for 6pbhf). I’ll hold off voting until DFINITY provide some commentary. Perhaps the spikes are expected to continue on these subnets.

1 Like

I checked the payload against the proposal text but I was otherwise relying on the information in the proposal text and did not verify the states separately. I obviously need to increase my level of diligence so thanks for pointing this out! From checking now I can see that this entire group of subnets abruptly increased their state size beyond 400 GiB for the same period of about 36 hours and then dropped back to their previous levels. This is indeed peculiar and warrants some explanation. At this point I would recommend a reject vote.

2 Likes

Proposal #134971 — Zack | CodeGov

Vote: Adopted

Reason:
The proposal is correct, and updates the list of public subnet setting 9 from public to private and 1 to public. A lot can happen in 4 days, we had nodes go offline and come back up right before the proposal deadline, not knowing what the issue was with the state size increase if they investigate and find that it is no longer an issue they can update the list again.

About CodeGov (click to expand).

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.


Learn more about CodeGov and its mission at codegov.org.

1 Like

Just posting a quick comment on my lunch break.

I’m not convinced that this proposal represents proper usage of the public/private feature. The surge didn’t coincide with a surge in the number of canisters. All setting the subnet to private does is mean no new principals can deploy there. All existing principals can continue to deploy more canisters. My understanding is that setting a subnet to private should be more about the sustained long-term memory usage of a subnet.

Otherwise there’s a large incentive for any existing principal who would like to keep their subnet private to just temporarily use up a lot of memory, then raise a proposal to make the subnet private. If they only need to do that here and there for a short period of time, I don’t think it would be a costly strategy.

@Severin, do you have any thoughts on this situation?

1 Like

hey @Lorimer, I think this proposal was submitted at an unlucky time where there was a surge in storage use on many subnets which later went down again (I don’t think there was any problem in the system, this was just usage on the application layer).

I don’t think your attack is super concerning. If you temporarily boost usage on your subnet, you may indeed get it to be marked as private in a proposal like this. However, these are done regularly, so unless the usage remains high, the subnet would be made public again.

Overall, I agree that using the public/private feature like this is not ideal. The intent is of course that new canisters are not accidentally deployed to high load subnets. Ideally, at some point we can put that logic into the CMC canister, and then all app subnets can be public. We’re looking into that but I don’t have an eta.

3 Likes

Hey @Manu, thanks for explaining

Would it be worth adjusting the policy regarding when to make a subnet public/private? Instead of being based on memory usage now, maybe it would be better to base it on an average over the last week or something? Presumably this proposal will be followed up shortly by one that makes the subnets public again (given that there’s an overarching agenda to make more subnets public at the moment).

This would be great!

1 Like

We could, but I personally think it’s not worth the effort, because it happened only once that such a usage spike influenced things, so I’d rather put the effort into the structural fix and have the CMC send new canisters to quieter subnets.

2 Likes

Proposal 134971 – LaCosta | CodeGov

Vote: ADOPT

The proposal changes 9 subnets from public to private since their state size is greater than 400 GiB and one subnet from private to public. The payload matches the subnets in the proposal summary.

About CodeGov…

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

1 Like