The state tree of the Internet Computer contains information about the topology of the Internet Computer, including the set of canister IDs assigned to each subnet.
How often does this change, and if, in the future canister subnet migrations were a thing, how might this affect the stability of subnet-to-canister id ranges?
Right now, there isn’t a way for a canister to be aware of another canister’s subnet on the Internet Computer without making an http outcall to the ic-api, so knowing these subnet canister ranges is a nice “hack” around needing asynchronous calls.
If canister subnet migrations are implemented, will it still be possible to know what subnet a canister is currently on simply based off of the canister id without needing to make an asynchronous call from outside the Internet Computer. If not, could an endpoint be added to the management canister, or a field to canister_status that returns the subnet that the canister is currently on?
Why do I care about this?
Because I’d like to build a service that is subnet aware (deployed to multiple subnets), and functions without cross subnet calls.
This is very helpful! But is there a way for me to determine the subnet without making a call all the way to the NNS subnet? I’m developing an sdk and would like to provide canisters themselves with a way to be subnet aware without having to make an inter-canister call.
For example, a system API that tells a canister what subnet that it is currently on (self aware).
There is no system API that tells a canister on which subnet it is.
Historically, the goal was to hide the fact that canisters run on different subnets (as much as possible), which is likely the reason why no such API exists, but it clearly matters in practice.
Is making a call to the NNS subnet really not a workable solution for you? Canisters cannot migrate at the moment and I’m not aware of any intention to split a subnet in the foreseeable future, so it may be sufficient for each canister to query the information where it is hosted once in a while.
It matters because it requires an asynchronous cross-subnet call (6+ seconds), when likely that call could be made synchronously within a canister.
I believe the replica internals are aware of the subnet id that a specific canister is executing on, so if that information can be retrieved directly from the replica the canister is on via a system API, that would improve the cycles cost & speed/performance of being subnet-aware.
We’d like to implement an canister client sdk that makes use of this information. So developers put this code into their canister to find out what subnet they’re on, and then based on what subnet they’re on they know which of our service canister(s) to talk to. The developers we’re talking to have 1000s of canisters, so this does make a difference.
This is important because cross-subnet messaging has ingress limits of 2-4MB per block, so we want to keep the inter-canister messaging local to a specific subnet for speed and performance reasons, and to reduce the inter-subnet messaging load on the IC.
Right now it doesn’t change. The only canister that ever changed subnets is II, and that was a very manual surgery. And even if we had automated subnet splitting, I would expect a canister to change subnets at most every O(weeks)
Is it enough for you to know if two canisters belong to the same subnet? If so, this information can be derived from the binary representation of their canister IDs (ignoring subnet splitting for now).
That could work. We’d essentially check an all pairs of canister ids to see if there was a match between the calling canister and any of the service canisters to see if they were on the same subnet.
It would be ideal if canisters were subnet aware and if there was a synchronous system API for exposing this, but a synchronous is_on_same_subnet() could also work, it would just be a different abstraction that provides less information by hiding the canister’s current subnet.
Just to be very clear, when you say “subnet aware”, you mean that a canister can figure out on which subnet it is hosted, that is, a synchronous system call is required that returns the subnet ID, correct?
Or do you see an advantage in having a synchronous is_on_same_subnet call?
As you observed correctly, the two functions are not equivalent.
I’m curious why you’re proposing is_on_same_subnet - is it to abstract away the notion of a subnet? Wouldn’t the is_on_same_subnet need access to the same subnet to canister mapping information?
