This topic is intended to capture Subnet Management activities over time for the bkfrj 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:
This proposal sets the notarisation delay of the subnet to 300ms, down from 600ms. The change will increase the block rate of the subnet, aimed to reduce latency of update calls.
Here are the current metrics for this subnet. A question I’ll be asking on the Subnet Management General thread (see reference below this post) is why this update is being rolled out to so many subnets at once, each with different finalisation rate profiles (i.e. peaks and troughs, whereas the canary subnet was always steady, even prior to the update). I’m wondering if this limits the representativeness of the results on that canary subnet.
Voted to adopt proposal 134192, 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.
TLDR: I’m planning to adopt. Replaces a node in this subnet without negatively affecting decentralisation coefficients. The motivation (to make it easier to optimise other subnets) seems reasonable.
Motivation: The node operator raiov currently has all nodes assigned to subnets. We propose to remove one of the operator’s nodes from subnet bkfrj 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 UK raiov node replaced with a gyzti node in Spain. According to the IC-APIraiov currently have two nodes assigned to subnets, and after this proposal passes they will only have one (the other node will be unassigned).
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
27.369 km
1237.64 km
3485.353 km
PROPOSED
27.369 km
1318.881 km (+6.6%)
3485.353 km
This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).
Subnet characteristic counts →
Continents
Countries
Data Centers
Owners
Node Providers
Node Operator
EXISTING
1
11
13
13
13
13
PROPOSED
1
11
13
13
13
13
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 London 1, UK with Awaiting node from Barcelona 1, ES 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.
According to wikipedia “The United Kingdom, made up of England, Scotland, Wales and Northern Ireland, is an island nation in northwestern Europe”. So fingers crossed this will not be a Brexit from the EU subnet
Voted to adopt proposal 134192. The proposal replaces one node from subnet bkfrj:
Removed Node: 3jol6.
Added Node: pekym.
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 proposal as the same motivation as proposal 134191 where I elevated some questions regarding it in my previous review that you can checkout here. Then again I will adopt this proposal but would like better explanation in future proposals.
TLDR: I’ll adopt. Prior to this proposal this subnet was in violation of the IC Target Topology, with 3 nodes in the same country. With this proposal this number drops down to 2, which is within the specified limits.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
27.369 km
1318.881 km
3485.353 km
PROPOSED
95.554 km (+249.1%)
1390.099 km (+5.4%)
3485.353 km
This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).
Subnet characteristic counts →
Continents
Countries
Data Centers
Owners
Node Providers
Node Operator
EXISTING
1
11
13
13
13
13
PROPOSED
1
12 (+8.3%)
13
13
13
13
This proposal slightly 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)
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
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.
The proposal replaces cordoned healthy Active status node lj6xb from the ZH5 Data Center in Zurich 5, Switzerland with unassigned healthy Awaiting status node yf2ct from Latvia, with slight improvement change to the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info, also it can be checked here.
An update on this proposal. @SvenF pointed out that in ZH5 DC there is more than one node operator, which is something that apparently all of us missed earlier. In ZH5 there is Sygnum - that we want to remove, and also Zondax - a regular gen2 node provider, unrelated to the cordoning.
In this proposal 134542 we are actually removing one Zondax node which is not planned. However, since the decentralization of the subnet actually improves with the replacement, plus we free up a valuable node from a node provider with only a few nodes, my recommendation would be that we proceed with the adoption of the proposal. The summary text of the proposal is slightly misleading, but the advantages of adopting seem high enough to justify the honest mistake.
The cordoning rules in the DRE tool have already been corrected for the future proposals:
This proposal replaces 1 node, due to offboarding ZH5 data centre. Data centre details are consistent with the links provided in the proposal but the node being removed belongs to a different node provider from the one who is offboarding nodes. However, decentralisation parameters are improved with respect to country and brought to within the requirements of the target topology, so in this respect the proposal is beneficial.
Replaces the node lj6xb with the node yf2ct on subnet bkfrj.
Although the proposal states that this replacement was to offboard a node from the ZH5 DC, this node does not belong to the Node Provider which made the post to offboard the nodes. Even so the decentralization coefficients are improved with this proposal by improving the country metric.
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)
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
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)
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.
This proposal replaces node c2dnc which appears in the dashboard as “Status: Active” for the stated reason “offboarding the second rack of nodes in the GE1 DC after 48 months”. This node is listed to be handed over in this post. As shown in the proposal, decentralisation parameters are improved with respect to country and remain within the requirements of the target topology.
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.
Vote: Adopted Reason:
The proposal replaces cordoned healthy Active status node c2dnc from Geneva, with
unassigned healthy Awaiting status node c4xi6 from Zagreb, Croatia. This improves the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info.
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.
Replaces cordoned node c2dnc with node c4xi6 on subnet bkfrj.
The reason for this proposal is to offboard the GE1 DC consistent with forum posts made on the forum thread used for posts regarding the renovation/sell of Gen-1 node machines by NPs.
Both the NP and DC stated in the forum post match the ones from the node being removed in the proposal.
The node being removed was also stated here.
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.
