This topic is intended to capture Subnet Management activities over time for the mpubz subnet, providing a place to ask questions and make observations about the management of this subnet.
At the time of creating this topic the current subnet configuration is as follows:
TLDR: I’ve rejected this proposal as it does not solve the degraded node issue, and the payload parameters appear to contain errors.
Note that node i5xgw is included in both the nodes removed and nodes added parameters of the payload. Swapping nodes is supposed to be a transactional operation (I wouldn’t be surprised if this would fail to execute).
The other node swap in this proposal is taking the opportunity to improve subnet decentralisation (given there’s already a need for a proposal). 1 of the 4 nodes in the USA is proposed to be replaced with one node in Spain. This brings the owner coefficient into the acceptable range (the subnet was previously violating it), however, this proposal still leaves the subnet in a state that is in violation of the formally voted in IC Target Topology. There is supposed to be no more than 2 nodes in the same country (not 3 nodes in one country).
My suggestion would be to reject this proposal and resubmit one that solves the degraded node problem, and gets this subnet back into a state that conforms to the IC target topology (else clearly explain in the proposal summary why this latter point is not feasible).
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
3.534 km
6951.098 km
15939.448 km
PROPOSED
3.534 km
6513.004 km (-6.3%)
15939.448 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
EXISTING
3
9
13
12
13
PROPOSED
3
10 (+10%)
13
13 (+7.7%)
13
This proposal significantly improves decentralisation in terms of jurisdiction and data center ownership diversity.
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)
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.
Other good neurons to follow:
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
One node that’s currently contributing to the violation of the data center nakamoto coefficient replaced with a diversified node👍
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
3.534 km
6951.098 km
15939.448 km
PROPOSED
3.534 km
7783.34 km (+12%)
16347.516 km (+2.6%)
This proposal increases decentralisation in terms of geographic distance (and therefore there’s a potential increase in localised disaster resilience).
Subnet characteristic counts →
Continents
Countries
Data Centers
Owners
Node Providers
EXISTING
3
9
13
12
13
PROPOSED
4 (+25%)
10 (+10%)
13
13 (+7.7%)
13
This proposal improves decentralisation in terms of jurisdiction and data center ownership diversity. Note that this subnet is currently violating the IC target topology regarding the data center nakamoto coefficient, and this proposal brings it back into the acceptable limits.
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)
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.
Other good neurons to follow:
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
DFINITY will submit an NNS proposal today to reduce the notarization delay on the subnet, mpubz, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).
This proposal proposes replacing one degraded node, and also replacing an up node in order to improve decentralisation. As detailed and illustrated below, the most number of nodes in the same country is reduced by this proposal from 3 to 2. This proposal therefore brings this subnet back in line with the IC Target Topology. I’ve voted to adopt
The most number of nodes in the same continent is actually increased by this proposal (decreasing decentralisation in these terms), however this metric isn’t currently considered by the formal IC Target Topology.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7703.64 km
16759.085 km
PROPOSED
0 km
7158.186 km (-7.1%)
16759.085 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
EXISTING
4
10
13
13
13
PROPOSED
4
11 (+9.1%)
13
13
13
This proposal improves decentralisation in terms of jurisdiction diversity.
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)
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.
Other good neurons to follow:
Synapse (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)
This proposal replaces 2 nodes in subnet mpubz: cwb7w, which appears as “Status: Degraded” in the IC dashboard, and an additional node for the sake of lowering the number of nodes in this subnet in the US from 3 to 2 in order to comply with the per-country limit as specified in the target topology. As seen in the proposal (which I verified using the DRE tool), the overall effect of these changes is to increase the log average Nakamoto coefficient while still keeping the number of nodes per node provider, data centre and data centre owner within the limits specified in the target topology and improving decentralisation with respect to country.
Voted to adopt proposal 134191, as the reasoning is sound and the description matches the payload. This proposal replaces 1 healthy node, which appears as “Active” on the IC dashboard, for the purpose of making it available for another subnet where it could improve decentralisation parameters. The proposed change leaves the Nakamoto coefficients unchanged and the target topology parameters within the requirements.
Motivation: The node operator h6fpp currently has all nodes assigned to subnets. We propose to remove one of the operator’s nodes from subnet mpubz to optimize overall network topology, since subnet decentralization does not worsen upon node removal. This way the same node can be assigned to subnet where it would improve decentralization.
1 removed Australian h6fpp node replaced with a z6cfb node in China. According to the IC-APIh6fpp currently have two nodes assigned to subnets, and after this proposal passes they will only have one (the other node will be unassigned).
This node replacement is performed without negatively affecting decentralisation coefficients that are a formal part of the IC Target Topology. However, decentralisation is reduced by this proposal in terms of continent diversity and average geographic distance between nodes (neither of which are formal parts of the IC Target Topology, so should not be prioritised over helping to improve formal targets for other subnets). The motivation (to make it easier to optimise other subnets) seems reasonable.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7158.186 km
16759.085 km
PROPOSED
0 km
6286.308 km (-12.2%)
15939.092 km (-4.9%)
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
4
11
13
13
13
13
PROPOSED
3 (-33.3%)
11
13
13
13
13
This proposal slightly reduces decentralisation in terms of jurisdiction diversity.
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)
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.
Another good neuron to follow is Synapse (follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
The proposal replaces healthy Active status node form New South Wales 1, AU with Awaiting node from HongKong 1, HK in order to optimize network topology and to assign set removed node to other subnet where it will improve decentralization. Kinda strange motivation but ok since it does not affect current decentralization.
Voted to adopt proposal 134191. The proposal replaces one node from subnet mpubz:
Removed Node: j3pcf.
Added Node: ked4e.
The proposal was verified using the DRE tool to verify the metrics stated. The motivation from the proposal states that node operator h6fpp currently has all his nodes assigned to subnets and in order to optimize overall network topology they want to remove one of it’s nodes.
This is rather abstract and since no changes to decentralization were seen due to this replacement I don’t see how this is achieved.
The second reason where the same node could be assigned to a different subnet where it would improve decentralization sounds better but then again I would appreciate more clarification on this like why the node from Hong Kong couldn’t be used with same objective. I’m adopting this proposal since there is no change in decentralization but I’m hoping for better clarifications in future proposals.
Do you mean why are there numerous similar looking posts? If you look closely at the maps you’ll see that they’re all slightly different, and they depict the changes that are being made to the mpubz subnet. This thread tracks the history and discussion of those changes. Does that answer your question?
Voted to adopt proposal 134280. The proposal seeks to remove a cordoned node from the subnet and specifies that the associated data centre is being offboarded “after 48 months”. Decentralisation parameters are improved with respect to country. The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.