We have just added NNS root as controller of the two canisters and removed the BN principal as controller. Now, the two empty canisters are fully NNS controlled.
@Lorimer Thanks a lot for your thorough work and pointing out this oversight. I also learned something new
I disagree with the statement that the proposal summary was incorrect: a principal can be authorized for a subnet. The proposal removed that authorization.
I agree that the principal still had possibilities to setup canisters through the other canisters. That was an oversight on my part and is a âfeatureâ of controlling the canister instead of being authorized on a specific subnet.
Thanks @rbirkner, no problem. This is information that I gleaned from reviewing a prior proposal, where it was highlighted by @Severin.
Iâve only said that the proposal summary should not be taken literally Taking it literally would mean that deploying new canisters to the subnet would be unauthorized, which would be a misleading / unhelpful classification (some system subnets depend on this feature).
This proposal replaces node z5a4h which appears in the dashboard as âStatus: Activeâ, for the purpose of examining the stability of another node operatorâs nodes. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.
Thanks @ZackDS for pointing out this distinction, which I had in fact missed. The two nodes are in different data centres, hence having different node operator IDs even though they are owned by the same node provider. Does this help to clear it up or was your point more that the proposal should have explained this detail for the benefit of newcomers?
Well itâs clear for me/us, I meant it could be confusing to new users who look at the dashboard only. I doubt anyone new will search for operator idâs (specially as they are not an active link) and seeing the same NP (in case they go as far as at least opening the node on the dashboard, can get confusing). Just a thought that crossed my mind, if itâs not worth addressing will ask @LaCosta to vote yes and we will have majority consensus.
While on this Rabbit whole, ofc one NP can have nodes in different Data Centers that obv can behave very differently the âinsights into the stability of the nodes of this node operatorâ seems a bit confusing.
Thatâs a fair point and I see what you mean now. I think thereâs a fair argument either way in this case, so Iâd just wait and see what he decides.
The proposal replaces one node from subnet uzr34:
Removed Node: z5a4h: Dashboard Status Active
Added Node: vqucp: Dashboard Status Awaiting
The proposal was verified using the DRE tool to verify the metrics stated which are not affected by this replacement.
Both nodes are from the same NP and the replacement was done to gain insights into the the added node which is operated by a different Node Operator which means itâs in a different DC and currently no nodes from this Node Operator are active as can be seen here.
I my opinion proposals should be easy to understand as in providing all the information necessary for reviewing the proposals but still requiring some kind of knowledge. I donât want to see people not aware of what the IC is voting for the sake of it. I would like this to come with some degree of curisosity from the users who want to participate, which requires gaining basic insights on what the proposal is doing so they can vote consciously. We can measure this by the difficulty in which users can gain this basic knowledge, and making a 5 second search on google on what is a Node Operator, I found this, which very clearly states the differences. This makes the difficulty of obtaining the necessary knowledge to vote consciously very easy. I also donât want to see proposals with large summarys with 50 lines of references on what every keyword means
Iâve vote to adopt proposal 134400. The decentralisation coefficients were unchanged by the proposal. As can be observed using the IC-API, the bmlhw node operator has 14 nodes (as stated in the proposal summary). Now that this proposal has executed, one of those nodes is assigned (vqucp).
Note that the IC-API is not open source, since learning this, Iâm in the process of switching over verifiable sources of this sort of information (rejecting because Iâve not had time to do this yet would be too harsh - even for me ).
Yes, this is a fair point. One could consider making the extrapolation more granular by applying it at the level of (node provider, data center). However, this approach will lead to further fragmentation of the nodes of the node provider, increasing the volatility of the extrapolation, as some node providers have very few, or even a single, node in a data center.
So yes, the node operator gives us appropriate granularity because the same NP would often (albeit not necessarily always) buy a set of machines with the same specs and from the same supplier, and put these machines into the same rack, in a DC. These machines would also share the power supply and the ISP, so they would be in the same failure domain.
In another DC, we could expect that the NP would use another supplier and another ISP, so it would be a different failure domain.
What is likely wrong in the whole thing is the terminology we use. But someone thought the above naming is âgood enoughâ and now itâs pretty hard to change. Naming is hard.
That said, we can surely start with the NP-based extrapolation (rather than node operator based), and check if that NP-based extrapolation approach would catch the current performance offenders. And if that (NP-based) doesnât work - switch over to the node operator based extrapolation.
Thank you @bjoernek and @sat for the valuable feedback and in detail breakdown. It all makes sense and confirms what we already know and think so far as in it is not intentionally over complicated but rather logical that follows sets of rules put together in order to simplify the understanding of how the IC works. My point wasnât about good enough which everything so far falls under, but rather a sort of âmaking all of this understandable for regular folks, specially new usersâ coming from other ecosystems. The whole IC is lightyears away from other chains right now, and this was just a thought regarding only one proposal from many, where the same existing Node Provider with different node operator IDâs was put in a sort of letâs test it situation, without a bit of more info. Again and I canât stress this enough that IMHO not many users would go and check in detail but at a first glance checking Node Providers on the dashboard that is the main source of info for regular users doesnât have any info on Node Operator. Hope this makes sense ?
The proposal replaces healthy Active status but cordoned node gtfa3 from CH3 DC in Illinois, with currently Offline status node 6hqi5 from Portugal, while this would be a slight improvement for the decentralization of the subnet and the motivation makes sense and the provided Forum link included in the summary provides further info, also it can be checked here.
This proposal replaces cordoned node gtfa3 which appears in the dashboard as âStatus: Activeâ for the stated reason âoffboarding CH3 DC after 48 monthsâ. This is consistent with the information in this post, and the CH3 data centre record and node provider record for MI Servers on the IC dashboard. As shown in the proposal, decentralisation parameters are improved with respect to country and remain within the requirements of the target topology.
However, as @ZackDS noted the replacement node, 6hqi5, currently appears on the dashboard as âStatus: Offlineâ. It also appears as âDOWNâ using the decentralization tool. If the node is indeed consistently offline then this would be a basis on which to reject this proposal.
TLDR: The node thatâs proposed to be added to this subnet is DOWN, while the node that is proposed to be removed is UP (well spotted @ZackDS). This would reduce the number of functional nodes in the subnet, so I have rejected this proposal.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) â
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7497.062 km
19448.574 km
PROPOSED
0 km
7317.281 km (-2.4%)
19448.574 km
This proposal slightly reduces decentralisation, considered purely in terms of geographic distance (and therefore thereâs a slight theoretical reduction in localised disaster resilience).
Subnet characteristic counts â
Continents
Countries
Data Centers
Owners
Node Providers
Node Operator
EXISTING
5
26
31
31
31
31
PROPOSED
5
27 (+3.7%)
31
31
31
31
This proposal slightly improves decentralisation in terms of jurisdiction diversity (if the new node were actually up, but itâs not).
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) â
The above subnet information is illustrated below, followed by a node reference table:
Map Description
Red marker represents a removed node (transparent center for overlap visibility)
Green marker represents an added node
Blue marker represents an unchanged node
Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)
You may wish to follow D-QUORUM if you found this analysis helpful.
Known Neurons to follow if you're too busy to keep on top of things like this
If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.
Additional good neurons to follow:
D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
Synapse (currently follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
CodeGov (actively reviews and votes on Subnet Management proposals, and is well informed on numerous other technical topics)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
Note that this analysis involved data provided by the IC-API, which is not open source. Iâm in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
Replaces cordoned node gtfa3, status Active with node 6hqi5, status Offline on subnet uzr34.
The reason for this proposal is to offboard CH3 DC consistent with forum posts made on the forum thread used for posts regarding the renovation/sell of Gen-1 node machines by NPs specifically here.
Both the NP and DC stated in the forum post match the ones from the node being removed in the proposal.
Unfortunately, since the proposal the node proposed has become Offline and NP hasnât provided any clear indication on why this happened at the moment. Iâll be awaiting for a response by @bitmoon for another 12 hours otherwise Iâll be rejecting the proposal.
Thank you for the update @bitmoon looks like the node is back online. Could you share what was the issue, now that Dfinity decided to stall and not vote for only this one proposal makes me wonder.
Taking it literally would mean that deploying new canisters to the subnet would be unauthorized, which would be a misleading / unhelpful classification (some system subnets depend on this feature).
).
