Subnet Management - mpubz (Application)

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:

Expand
{
  "version": 44495,
  "records": [
    {
      "key": "subnet_record_mpubz-g52jc-grhjo-5oze5-qcj74-sex34-omprz-ivnsm-qvvhr-rfzpv-vae",
      "version": 44495,
      "value": {
        "membership": [
          "dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe",
          "4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe",
          "g4eis-jmdlu-iiivf-75n73-uto6l-miezg-kluob-ogj6z-2llqc-pomjl-jae",
          "ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe",
          "d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe",
          "epwlh-zpyza-66uqs-7zrr5-hvtpz-srxfs-acqqj-or2oy-zvky3-3eo2q-6ae",
          "yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe",
          "cwb7w-kd3lm-4jzgx-mljqg-ptquz-665kh-w2svb-22eca-fab6l-jelhv-3ae",
          "rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe",
          "yeark-e7nqu-ovf7r-vrjm3-zh7yz-kg6f6-6rlhc-o5kgs-lkriq-5d2hi-zqe",
          "i5xgw-uzqkn-xrfkd-7nqdz-3yvas-lujhr-mvs5w-sxv5u-m7zrn-hrd2k-pqe",
          "ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe",
          "b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 1000,
        "initial_notary_delay_millis": 600,
        "replica_version_id": "2c0b76cfc7e596d5c4304cff5222a2619294c8c1",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "application",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [
          ""
        ],
        "ssh_backup_access": [],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}
2 Likes

There’s an open proposal for changing subnet membership - https://dashboard.internetcomputer.org/proposal/131425. This information is presented below:

  • red marker represents a removed node
  • green marker represents an added node
  • highlighted patches represent the country a node sits within

Table
Country Data Center Owner Node Provider Node
--- Germany Munich (mu1) q.beyond Staking Facilities yeark-e7nqu-ovf7r-vrjm3-zh7yz-kg6f6-6rlhc-o5kgs-lkriq-5d2hi-zqe
+++ Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners kegk5-wu5c5-xpe2p-athmd-4dzq6-4gucp-n4ne3-uj2zk-e2jjl-3253l-6qe
Belgium Brussels 2 (br2) AtlasEdge Allusion rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe
Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe
Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe
Japan Tokyo 2 (ty2) Equinix Starbase cwb7w-kd3lm-4jzgx-mljqg-ptquz-665kh-w2svb-22eca-fab6l-jelhv-3ae
Romania Bucharest (bu1) M247 Iancu Aurel b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe
Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital i5xgw-uzqkn-xrfkd-7nqdz-3yvas-lujhr-mvs5w-sxv5u-m7zrn-hrd2k-pqe
Slovenia Maribor (mb1) Posita.si Fractal Labs AG yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe
Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA 4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe
United States of America (the) Allentown (aw1) Tierpoint Bigger Capital g4eis-jmdlu-iiivf-75n73-uto6l-miezg-kluob-ogj6z-2llqc-pomjl-jae
United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe
United States of America (the) San Jose (sj2) Digital Realty BlockTech Ventures, LLC epwlh-zpyza-66uqs-7zrr5-hvtpz-srxfs-acqqj-or2oy-zvky3-3eo2q-6ae
United States of America (the) Tampa (tp1) Flexential Giant Leaf, LLC ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe

The removed node is replaced with a node based in South Korea. I’ve verified that this node is currently unassigned.

The proposal mentions that his change is needed due to the Munich (mu1) data centre being due for decommissioning. See here for more discussion and references.

1 Like

Proposal 132144

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). :-1:

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. :+1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

Continent Country Data Center Owner Node Provider
EXISTING 6 4 1 2 1
PROPOSED 7 (+16.64%) 3 (-25%) 1 1 (-50%) 1

See here for acceptable limits → Motion 125549 (note that these are due for a slight revision)

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)

Table
Continent Country Data Center Owner Node Provider Node Status
--- Asia Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital i5xgw-uzqkn-xrfkd-7nqdz-3yvas-lujhr-mvs5w-sxv5u-m7zrn-hrd2k-pqe DEGRADED
--- Americas United States of America (the) San Jose (sj2) Digital Realty BlockTech Ventures, LLC epwlh-zpyza-66uqs-7zrr5-hvtpz-srxfs-acqqj-or2oy-zvky3-3eo2q-6ae UP
+++ Europe Spain Barcelona 1 (es1) Adam Carbon Twelve uao44-6xaz7-xmjyv-wxzqn-fawuf-hpz34-d7ea4-2ft3d-znzye-k246e-cqe UNASSIGNED
+++ Asia Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital i5xgw-uzqkn-xrfkd-7nqdz-3yvas-lujhr-mvs5w-sxv5u-m7zrn-hrd2k-pqe DEGRADED
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe UP
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase cwb7w-kd3lm-4jzgx-mljqg-ptquz-665kh-w2svb-22eca-fab6l-jelhv-3ae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners kegk5-wu5c5-xpe2p-athmd-4dzq6-4gucp-n4ne3-uj2zk-e2jjl-3253l-6qe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA 4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe UP
Americas United States of America (the) Allentown (aw1) Tierpoint Bigger Capital g4eis-jmdlu-iiivf-75n73-uto6l-miezg-kluob-ogj6z-2llqc-pomjl-jae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe UP
Americas United States of America (the) Tampa (tp1) Flexential Giant Leaf, LLC ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe UP

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)

1 Like

Proposal 132181

TLDR: I’ve voted to adopt this proposal.

  • One degraded node replaced with an up node :+1:
  • 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). :+1:

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. :+1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

Continent Country Data Center Owner Node Provider
EXISTING 6 4 1 2 1
PROPOSED 6 3 (-25%) 1 1 (-50%) 1

See here for acceptable limits → Motion 132136

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)

Table
Continent Country Data Center Owner Node Provider Node Status
--- Asia Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital i5xgw-uzqkn-xrfkd-7nqdz-3yvas-lujhr-mvs5w-sxv5u-m7zrn-hrd2k-pqe DEGRADED
--- Americas United States of America (the) San Jose (sj2) Digital Realty BlockTech Ventures, LLC epwlh-zpyza-66uqs-7zrr5-hvtpz-srxfs-acqqj-or2oy-zvky3-3eo2q-6ae UP
+++ Oceania Australia New South Wales 1 (ns1) Latitude.sh Conic Ventures j3pcf-ielts-wwr24-73hhq-flvsq-d7yh3-ly5li-r6csx-5tczk-wkpc3-5ae UNASSIGNED
+++ Asia Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital rgacz-r4m53-3mwgy-63dqd-txx4i-o6aw6-5wwdt-eizs3-6lh2z-hxzlv-3ae UNASSIGNED
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe UP
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase cwb7w-kd3lm-4jzgx-mljqg-ptquz-665kh-w2svb-22eca-fab6l-jelhv-3ae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners kegk5-wu5c5-xpe2p-athmd-4dzq6-4gucp-n4ne3-uj2zk-e2jjl-3253l-6qe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA 4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe UP
Americas United States of America (the) Allentown (aw1) Tierpoint Bigger Capital g4eis-jmdlu-iiivf-75n73-uto6l-miezg-kluob-ogj6z-2llqc-pomjl-jae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe UP
Americas United States of America (the) Tampa (tp1) Flexential Giant Leaf, LLC ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe UP

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)

1 Like

Subnet mpubz is being made public by → Expanding the list of Public Subnets on the Internet Computer - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)

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).

2 Likes

Voted to adopt proposal 133066. The initial_notary_delay_millis is set to 300 and the subnet_id is correct.

1 Like

Proposal 133152

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 :+1:

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). :-1:

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. :+1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

Continent Country Data Center Owner Node Provider
EXISTING 6 3 1 1 1
PROPOSED 7 (+16.67%) 2 (-33.34%) 1 1 1

See here for acceptable limits → Motion 132136

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)

Table
Continent Country Data Center Owner Node Provider Node Status
--- Asia Japan Tokyo 2 (ty2) Equinix Starbase cwb7w-kd3lm-4jzgx-mljqg-ptquz-665kh-w2svb-22eca-fab6l-jelhv-3ae DEGRADED
--- Americas United States of America (the) Allentown (aw1) Tierpoint Bigger Capital g4eis-jmdlu-iiivf-75n73-uto6l-miezg-kluob-ogj6z-2llqc-pomjl-jae UP
+++ Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 7r7kx-pfeyy-apl6r-7m3mi-nhuan-zy5rd-l4bxq-6x5ak-a4632-sqoof-qqe UNASSIGNED
+++ Europe Germany Frankfurt 2 (fr2) Equinix Virtual Hive Ltd 4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe UNASSIGNED
Oceania Australia New South Wales 1 (ns1) Latitude.sh Conic Ventures j3pcf-ielts-wwr24-73hhq-flvsq-d7yh3-ly5li-r6csx-5tczk-wkpc3-5ae UP
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe UP
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners kegk5-wu5c5-xpe2p-athmd-4dzq6-4gucp-n4ne3-uj2zk-e2jjl-3253l-6qe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe UP
Asia Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital rgacz-r4m53-3mwgy-63dqd-txx4i-o6aw6-5wwdt-eizs3-6lh2z-hxzlv-3ae UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA 4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe UP
Americas United States of America (the) Tampa (tp1) Flexential Giant Leaf, LLC ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe UP

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)

2 Likes

Voted to adopt Proposal 133152.

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.

2 Likes
US       3 -> 2

Good job, adopted.

1 Like

Voted to adopt proposal 133152. Replaces a degraded node and a healthy node to increase the nakamoto coefficient on the country metric.

2 Likes

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.

3 Likes

Proposal 134191

TLDR: I’m planning to adopt.

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-API h6fpp 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). :-1:

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. :-1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

Continent Country Data Center Owner Node Provider Node Operator
EXISTING 7 2 1 1 1 1
PROPOSED 7 2 1 1 1 1

See here for acceptable limits → Motion 132136

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)

Table
Continent Country Data Center Owner Node Provider Node Operator Node Status Performance
--- Oceania Australia New South Wales 1 (ns1) Latitude.sh Conic Ventures h6fpp j3pcf-ielts-wwr24-73hhq-flvsq-d7yh3-ly5li-r6csx-5tczk-wkpc3-5ae UP :bar_chart:
+++ Asia China HongKong 1 (hk1) Unicom Wancloud limited z6cfb ked4e-syml2-ao2ub-xgtxi-awdfd-2vkf6-lbol5-prycv-2vpb5-ws5jp-oae UNASSIGNED :bar_chart:
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion oorkg rhy7d-pjsmu-5ljz7-vuaio-ihiaq-iysyk-np226-tirem-kuw7n-v2i2w-iqe UP :bar_chart:
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i 7r7kx-pfeyy-apl6r-7m3mi-nhuan-zy5rd-l4bxq-6x5ak-a4632-sqoof-qqe UP :bar_chart:
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp yngfj ag3bm-tdrfp-kki7m-yfwop-aoc4g-f4sjz-grd33-7zy3x-xq3tr-hpbuh-zqe UP :bar_chart:
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc paxme d2ffc-r2mqq-yx3u5-f5j47-davp4-lske5-57oal-ilwph-o2hex-tqaz2-7qe UP :bar_chart:
Europe Germany Frankfurt 2 (fr2) Equinix Virtual Hive Ltd 3nu7r 4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe UP :bar_chart:
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners ukji3 kegk5-wu5c5-xpe2p-athmd-4dzq6-4gucp-n4ne3-uj2zk-e2jjl-3253l-6qe UP :bar_chart:
Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg b3knf-xg5xg-p3oyq-dgpdw-xjz2l-n35mj-pdoyl-4dgas-u2t5l-bndrp-hqe UP :bar_chart:
Asia Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital 5mhxl rgacz-r4m53-3mwgy-63dqd-txx4i-o6aw6-5wwdt-eizs3-6lh2z-hxzlv-3ae UP :bar_chart:
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG 3xiew yttmc-lxazf-6ctyr-aqchl-g5est-gut4i-qltuy-gds2b-7vhfu-43xey-2qe UP :bar_chart:
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA lgp6d 4xhpj-gsmak-akpfh-z7rro-63yfp-5ewvu-i4o6g-yyrix-yd7xj-cus4y-hqe UP :bar_chart:
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers t37p3 dafyf-uvzhi-ypecj-c6ujq-e7aae-m6y2m-5f4pp-v64pz-lfebd-awmre-cqe UP :bar_chart:
Americas United States of America (the) Tampa (tp1) Flexential Giant Leaf, LLC 7fnoo ey524-belml-leby7-hvt63-znr5b-xwkgp-5epra-kdmez-ynelx-2m4ys-hqe UP :bar_chart:

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)

3 Likes

Voted to adopt proposal #134191.

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.

2 Likes

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.

2 Likes

Why is this thread repeating itself?

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?

2 Likes

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.

I’ve voted to reject proposal 134280. It makes claims that I see no clear way of verifying, and supporting statements regarding the ownership of the data centre are inconsistent with records held in the IC registry. The proposal was announced here.