I was digging into subnets, and had a few questions about subnet types, specializations, and authorization. This questions are all in response to playing around with the v3/subnets API.
The subnet documentation talks about Application, System, Fiduciary, and European subnets. However, the v3/subnets endpoint further breaks this down into subnet type & specialization.
The different subnet types are:
application
verified application
system
What is a verified application subnet, and how does it differ from a normal application subnet? Are any other subnet types in the works?
The different subnet specializations are:
“” (empty, no specialization - most application subnets, and all system subnets)
fiduciary
european
Is it in the plans to have a subnet that is both fiduciary and european? Are there any other subnet specializations in the works?
There’s also an authorization_type field for access to these subnets that is one of
private
authorized_only
public
All publicly used subnets seem to have have an authorization_type of either public or authorized_only.
There are a few other posts on this forum, including this one that talks about authorized_only being used to limit canister creation on certain subnets based on how full (memory wise) the subnet is, but I’d be curious to learn more about the specifics of authorized_only.
Does authorized_only just block ingress canister creation, or does it also block creation from other canisters? Are there different levels of authorized_only restriction? For example, could authorized_only start by blocking non-canister (ingress) creation, and then moving to block creation of all canisters that are not on a designated principal allowlist?
I’ll let someone else answer your other questions, but I can provide some clarity on subnet_authorization, since this is just a term we decided to use for the ICP Dashboard, not something from the ICP codebase.
Based on how we’ve defined this term for the ICP Dashboard, get_default_subnets of the CMC returns the list of subnets that are subnet_authorizationpublic. Any subnets not in the list are subnet_authorizationauthorized_only.
This is set via NNS Set Authorized Subnets proposals such as this.
Application = ordinary subnet.
System subnet = no cycles need to be paid for running canisters, some more generous execution limits. Used for NNS and II subnet
Verified application = leftover idea from ~launch time. Conceptually it would have been similar to subnet rental. Today it is the same as an application subnet
I have not heard anyone talk about concrete plans about other subnet types. The future could hold e.g. storage subnets or GPU subnets as new types.
I haven’t heard of any specific plans. If you have a good reason to make a subnet of a new specialization feel free to start a discussion. I suppose the swiss subnet is similar, but since that one will go through the subnet rental canister (at least according to this post, not sure if that’s still the plan) I’m not sure access to it will go the usual CMC-managed access control route.
This post explains how authorization works at the moment. There is no other access control/authorization mechanism in place.
Where do you pull data for the other subnets from that aren’t public or specially typed as european or fiduciairy? Wondering if there’s an on-chain API for this info, or if the best place to get it all is through the v3 api.