Subnet Management - pzp6e (Fiduciary)

This topic is intended to capture Subnet Management activities over time for the pzp6e 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": 44399,
  "records": [
    {
      "key": "subnet_record_pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae",
      "version": 44399,
      "value": {
        "membership": [
          "eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe",
          "7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe",
          "wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae",
          "ebih2-65fto-thxfj-knxfn-xxdmq-z42dj-oty4c-n3fbj-qry6f-g3oe2-nqe",
          "tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe",
          "wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe",
          "ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae",
          "snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae",
          "5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae",
          "6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae",
          "e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae",
          "3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe",
          "c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae",
          "afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae",
          "fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae",
          "sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae",
          "flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae",
          "lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae",
          "3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae",
          "fsqi5-jxy3h-7enjy-d3734-zqvvu-s6nmh-o7xyk-6ahom-ecorw-o4oro-mae",
          "irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae",
          "hc3ft-rhmb5-yhogg-3xdlz-vmwhv-zkm52-gj6ln-3zvn7-d5qie-nynj3-fqe",
          "bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae",
          "mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe",
          "xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae",
          "w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe",
          "xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe",
          "gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 3000,
        "initial_notary_delay_millis": 1000,
        "replica_version_id": "a3831c87440df4821b435050c8a8fcb3745d86f6",
        "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": [
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEVcbYyW9CASaIa8wh07Dvm5dCeh0P/YgRP9Kwr38gB5 consensus@10.31.0.141",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICsO2IEV96tOVfjoOj450TZr4MD8PauHqhcLYvrmRRue pfops@sf1-spm12",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMz75Tyjsl6gxOJz0zHIvcQcMquIm7DHBB62ReJbRkk9 op@pyr07"
        ],
        "ecdsa_config": {
          "quadruples_to_create_in_advance": 5,
          "key_ids": [
            {
              "curve": "secp256k1",
              "name": "key_1"
            }
          ],
          "max_queue_size": 20,
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 1209600000
        },
        "chain_key_config": {
          "key_configs": [
            {
              "key_id": {
                "Ecdsa": {
                  "curve": "secp256k1",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 5,
              "max_queue_size": 20
            }
          ],
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 1209600000
        }
      }
    }
  ]
}
3 Likes

There’s an open proposal for changing subnet membership - Proposal: 131400 - ICP Dashboard (internetcomputer.org). 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 hc3ft-rhmb5-yhogg-3xdlz-vmwhv-zkm52-gj6ln-3zvn7-d5qie-nynj3-fqe
+++ Romania Bucharest (bu1) M247 Iancu Aurel j6uir-h4bk3-chdqr-hxnkr-3jp7o-yb3el-skdsd-7oejj-eubk5-5onvy-zae
Australia Queensland 1 (sc1) NEXTDC Karel Frank 3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe
Austria South Moravian Region 1 (bn1) Master Internet Lukas Helebrandt afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae
Belgium Brussels 2 (br2) AtlasEdge Allusion wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae
Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae
Switzerland Geneva 2 (ge2) SafeHost Archery Blockchain SCSp w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe
Switzerland Zurich 3 (zh3) Nine.Ch Tomahawk.vc fsqi5-jxy3h-7enjy-d3734-zqvvu-s6nmh-o7xyk-6ahom-ecorw-o4oro-mae
China HongKong 4 (hk4) hkntt Origin Game 6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae
Costa Rica Bogota 1 (bg1) EdgeUno Geeta Kalwani tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe
Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe
Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae
India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd ebih2-65fto-thxfj-knxfn-xxdmq-z42dj-oty4c-n3fbj-qry6f-g3oe2-nqe
India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae
India Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae
India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae
Japan Tokyo 2 (ty2) Equinix Starbase gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae
Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe
Lithuania Vilnius 1 (bt1) Baltneta MB Patrankos šūvis c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae
Latvia Riga 1 (rg1) DEAC Ivanov Oleksandr eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe
Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe
Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae
Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae
United States of America (the) Atlanta (at1) Flexential Goat, LLC lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae
United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae
United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe
United States of America (the) San Jose (sj1) INAP Shelburne Ventures, LLC xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae
South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae
South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae

The removed node is replaced with a node based in Romania. 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. I have some questions about this which I’ve asked on another topic.

3 Likes

Open proposal for the creation of the Schnorr production keys: https://dashboard.internetcomputer.org/proposal/131474. See also this other topic for related discussions: Generation of Schnorr production keys and II subnet downtime

3 Likes

Thanks for the announcement @andrea :slight_smile:

I noticed that the idkg_key_rotation_period_ms value is different to that used on the test key subnets (1209600000 instead of 604800000). Can I ask why this is?

Similarly pre_signatures_to_create_in_advance is 5 (whereas this is set to 7 on test key subnets). Are you able to explain the reason for these differences?

2 Likes

This interval determines how frequently each node in the subnet is expected to rotate its encryption key. Nodes do not rotate their keys at the same time, but these are scattered at regular intervals that depend on the subnet size, i.e. the idkg_key_rotation_period_ms is also the time the entire subnet will have all the encryption keys rotated. The intervals in the different proposals correspond to 14 and 7 days, for subnets of size 28 and 13, respectively. This will result in the two subnets to rotate keys at a similar frequency (one key every ~10 hours).

Note that the current proposal is not changing this parameter, as this is a global parameter affecting all chain key configs, and the value is the same as currently used by the subnet.

Similarly pre_signatures_to_create_in_advance is 5

This is the same amount of presignatures that the subnet precomputes for ECDSA. This value can affect both signature throughput and finalization rate of the subnet, and can be likely increased at a later stage. Our suggestion is to start with some moderate value and then progressively increase this, depending on demands and protocol optimizations.

3 Likes

Thanks for the explanation @andrea, it’s much appreciated. All makes sense and sounds good :+1:

1 Like

Thanks for the new proposal DFINITY. Can we expect these proposals to be announced on these forum topics in the future?

Proposal: 131696 - ICP Dashboard (internetcomputer.org)

I see that this proposal enables pzp6e for signing with the new Bip340Secp256K1 key (“key_1”) now that this key has been backed up on uzr34.

The proposal config payload looks consistent with the summary.

Presumably this proposal will soon be followed by another one that enables Ed25519 on pzp6e? (the other key that was recently generated on pzp6e and backed up on uzr34, using the same proposals as for the Bip340Secp256K1 key)

1 Like

An intention to propose a change to IC target topology that will affect this subnet has been announced in this post.

2 Likes

There’s currently an open ‘Remove Node from Subnet’ proposal for this subnet → Proposal: 131977 - ICP Dashboard (internetcomputer.org)

I have rejected this proposal. My suggestion is that this proposal should be resubmitted as a ‘Change Subnet Membership’ proposal instead.

Justifications
  • This proposal summary indicates that the node will be removed in order to be ‘redeployed’ (to the same subnet…?). This subnet is already over-represented by Indian nodes (there should be no more than 3 per country for a 28 node subnet).
  • I consider this proposal summary to be extremely poor. It does not make the context nor the intentions clear. It does not clearly identify to voters the subnet that it applies to, nor why the proposal is needed (offline node). Almost all other ‘Remove Node from Subnet’ proposal summary’s historically have been much more informative.

This proposal is illustrated by this map for voter convenience.

Map Description
  • Red marker represents a removed node (transparent center for overlap visibility)
  • Blue marker represents an unchanged node
  • Highlighted patches represent the country the above nodes sit within
  • 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 - there are plenty of nodes that could be swap in)
Node Lookup Table
Continent Country Data Center Owner Node Provider Node Status
--- Asia India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd ebih2-65fto-thxfj-knxfn-xxdmq-z42dj-oty4c-n3fbj-qry6f-g3oe2-nqe DOWN
Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank 3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe UP
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae UP
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae UP
Europe Switzerland Geneva 2 (ge2) SafeHost Archery Blockchain SCSp w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe UP
Europe Switzerland Zurich 3 (zh3) Nine.Ch Tomahawk.vc fsqi5-jxy3h-7enjy-d3734-zqvvu-s6nmh-o7xyk-6ahom-ecorw-o4oro-mae UP
Asia China HongKong 4 (hk4) hkntt Origin Game 6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae UP
Americas Costa Rica Bogota 1 (bg1) EdgeUno Geeta Kalwani tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe UP
Americas Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe UP
Europe Czechia South Moravian Region 1 (bn1) Master Internet Lukas Helebrandt afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae UP
Asia Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae UP
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae UP
Asia India Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae UP
Asia India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe UP
Europe Lithuania Vilnius 1 (bt1) Baltneta MB Patrankos šūvis c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae UP
Europe Latvia Riga 1 (rg1) DEAC Ivanov Oleksandr eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel j6uir-h4bk3-chdqr-hxnkr-3jp7o-yb3el-skdsd-7oejj-eubk5-5onvy-zae UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae UP
Americas United States of America (the) Atlanta (at1) Flexential Goat, LLC lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae UP
Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe UP
Americas United States of America (the) San Jose (sj1) INAP Shelburne Ventures, LLC xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae UP
Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae UP

You may wish to consider following my known LORIMER neuron for future Subnet Management proposals. CodeGov is another great neuron to follow for Subnet management (along with other technical topics).

2 Likes

I saw that too. I see the node is offline but I also took it that there should be a proposal to replace the node rather than just remove it. This proposal appears to have come from the data centre and/or node provider owner. Note that the data centre is located in Sri Lanka, not India.

2 Likes

Thanks @timk11. Great point, we can be sure that the IC dashboard shows this node as residing in Sri Lanka. A couple of questions though, do we know,

  • how this information is obtained on the IC and verified?
  • how this information has been kept up-to-date beyond the formal node provider onboarding process?
  • that the responses coming from this node are insulated from tampering by the Indian authorities (who at the very least have access to nodes performing the same compute as this node, and a signal that is at least routed from this node though an Indian IP address)? (sounds paranoid, but it’s the sort of thing the country coefficient is supposed to be in place to protect against)

The external IP address for this node is 2400:a240:0:2:6801:63ff:fe71:6299. The public record for this IP address locates it in India.

1 Like

@SvenF are you able to provide an answer to any of the above questions?

@Lorimer @timk11 , I can provide clarity on this since we are the node provider.

  1. ISP Details: Our ISP is Tata Communications, and the IP assigned to us is an anycast IP. This means it can be broadcasted from Sri Lanka, even though the IP address is originally issued from an Indian subnet. The IP latency remains as of local IP of srilanka. We selected Tata Communications due to their Tier 1 status and have already raised the issue regarding the IP location on some Geodatabase
  2. Corrective Measures: Due to the ISP’s failure to provide us with the appropriate local IP address. We have implemented changes by using local provider IPs. As a result, some nodes are temporarily down during this transition.

The following nodes have already been migrated:

This Geo location of IP is now originating from Sri Lanka.

For reference, here is the IP info from Tata Communications prior to our adjustments:

If there’s any concern regarding the Sri Lankan allocation, you can contact Tata Communications Lanka Ltd directly at noc.lanka@tatacommunications.com for verification.

Does this answer your question about the IPs previously provided by TATA communication for us? I will be more than happy to provide transparent information

3 Likes

I appreciate your effort to make ICP better. This must be something ICP must have missed during the onboarding process. I would suggest everyone use up-to-date Geo IP location databases for accurate information.

For example, the node eybf4 with IP address 2400:a240:0:2:6801:98ff:fe32:71eb is correctly identified as coming from Sri Lanka in the following databases:

Additionally, the IPv6 subnet 2400:a240::/32 is entirely owned by Tata Communications Lanka, verified by APNIC. You can see the ownership details on IPinfo.io.

Lastly, APNIC (APNIC Whois Search | APNIC), the internet organization responsible for allocating IP addresses in Asia, clearly states that these IPs are issued to GEODD (PVT) LTD in Sri Lanka via Tata Communications Lanka, which owns the IPs. See below search result

ICP’s node provider onboarding process is a rigorous one that needs substantial investments and makes sure all the requested specifications are met as a node provider, we have made sure to meet all the expected specifications with the respect we have for DFINITY and for the investment we have made. If you need further clarification on this, we would be more than willing to provide you with the transparency you require.

3 Likes

Thanks for your detailed responses @MalithHatananchchige, I plan to take a closer look at this the next time I get a chance - particularly regarding the use of regularly updated IP location databases.

In the meantime I have a proposal to adopt :stuck_out_tongue_winking_eye:

p.s. your input regarding the nodes with the same geolocation below would be useful if you get a chance :blush:


Proposal 132178

TLDR: I’ve voted to adopt this proposal. Replaces one down node with an up node :+1: Replaces another node to improve decentralisation :+1:(note that this subnet is still violating the country limit though :cry:)

Interestingly, while reviewing this proposal...

I noticed that two nodes that already belong to this subnet (and which belong to different data centers, owners, and node providers), actually have the exact same geolocation based on their IP address (something to ponder :thinking:) →

Country Data Center Owner Node Provider Node Status
India (19.1412, 73.0087) Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae UP
India (19.1412, 73.0087) New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae UP

Using another IP location provider indicates these are both actually in Sri Lanka. I gather this provider keeps a more up-to-date database, so will use this one in the future (thanks for the tip @MalithHatananchchige). In any case, both nodes still resolve to the same location (yet are regarded as completely separate entities that would be uninclined to collude)…


Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

Smallest Distance Average Distance Largest Distance
EXISTING 0 km 8007.1 km 18490.237 km
PROPOSED 0 km 8073.407 km (+0.8%) 18490.237 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). :+1:

Subnet characteristic counts →

Continents Countries Data Centers Owners Node Providers
EXISTING 5 19 28 28 28
PROPOSED 5 21 (+9.5%) 28 28 28

This proposal slightly 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 9 4 1 1 1
PROPOSED 9 4 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
--- Europe Switzerland Zurich 3 (zh3) Nine.Ch Tomahawk.vc fsqi5-jxy3h-7enjy-d3734-zqvvu-s6nmh-o7xyk-6ahom-ecorw-o4oro-mae UP
--- Asia India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd ebih2-65fto-thxfj-knxfn-xxdmq-z42dj-oty4c-n3fbj-qry6f-g3oe2-nqe DOWN
+++ Europe Spain Barcelona 1 (es1) Adam Carbon Twelve rq2bj-ek3yy-mjj6s-zewtq-zzke4-u4zix-tz2xd-xigpz-s5hih-4wpmt-iqe UNASSIGNED
+++ Asia Sri Lanka Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd shtwt-kuy74-afhyd-sivzp-nj3vl-vh2zl-hdsvv-yunlj-k3asp-zsigu-cae UNASSIGNED
Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank 3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe UP
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae UP
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae UP
Europe Switzerland Geneva 2 (ge2) SafeHost Archery Blockchain SCSp w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe UP
Asia China HongKong 4 (hk4) hkntt Origin Game 6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae UP
Americas Costa Rica Bogota 1 (bg1) EdgeUno Geeta Kalwani tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe UP
Americas Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe UP
Europe Czechia South Moravian Region 1 (bn1) Master Internet Lukas Helebrandt afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae UP
Asia Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae UP
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae UP
Asia India Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae UP
Asia India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe UP
Europe Lithuania Vilnius 1 (bt1) Baltneta MB Patrankos šūvis c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae UP
Europe Latvia Riga 1 (rg1) DEAC Ivanov Oleksandr eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel j6uir-h4bk3-chdqr-hxnkr-3jp7o-yb3el-skdsd-7oejj-eubk5-5onvy-zae UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae UP
Americas United States of America (the) Atlanta (at1) Flexential Goat, LLC lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae UP
Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe UP
Americas United States of America (the) San Jose (sj1) INAP Shelburne Ventures, LLC xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae UP
Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae 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

Thanks again for all the detailed info @MalithHatananchchige, you’ve been more than helpful!

I still have some remaining questions about how the IC dashboard obtains and keeps its location information up-to-date (it doesn’t appear to update when the geolocation attached to an IP address changes) - I’m hoping @sat, @Dylan or @SvenF will be able to answer this.

I believe that the latitude, longitude, and region of a data center (the location information displayed by the ICP Dashboard) is controlled exclusively via NNS proposals, as I indicated in a different thread.

You seem to be asking if there is (ongoing) validation performed that the locations of nodes and data centers specified in executed NNS proposals are accurate. That would be outside of my area, so I’m not aware if something like that is being done or if there are plans to do so in the future.

As far as the latitude and longitude goes, I recall that in the past this has sometimes been an approximate location, for example coordinates within the same city. For node provider remuneration, that is fine, but I understand your point about accurately differentiating data centers by using the geolocation of its nodes for purposes of determining subnet decentralization.

IP Location Verification Suggestion using BGP

BGP (Border Gateway Protocol) is what controls how data moves across the internet. Every network is part of an Autonomous System (AS), which has a unique ASN (Autonomous System Number). By looking at BGP routes and ASN details, you can track where data is going and confirm the real location of an IP address, even if it seems to come from another country.

  • ASN Ownership: Each IP block is tied to an ASN, which is linked to a specific organization and country. So, even if an IP subnet is originally from a different country (like India)
  • BGP Routing Path: BGP routes show the path data takes across the internet. By looking at the AS Path, you can see the sequence of networks (ASNs) the data passes through, which helps confirm where the IP is being routed. If the last ASN in the path is based in Sri Lanka, you know that the IP is being used there, even if it was originally from somewhere else.
  • Geolocation Verification: Combining BGP data with IP geolocation services lets you double-check the physical location of the IP. Tools like the Hurricane Electric BGP Toolkit let you search for an IP address, see its ASN, and verify that it’s being used in the correct location.

Example with Old IP and ASN:

  • IP Block: 2400:A240:0:2::/64
  • ASN: AS4755
  • Announced By: Tata Communications Lanka Ltd

In this example, even though the IP block might originate from India, BGP data shows that it’s being announced by Tata Communications Lanka in Sri Lanka. This confirms that the IP is being used in Sri Lanka, even if the subnet’s origin is elsewhere.

https://bgp.he.net/ip/2400:a240:0:2:6801:63ff:fe71:6299#_whois

We can use this to verify each 64 block ICP requires Nodeproviders during the ICOS installation. My two cents are using ASN and BGP. The problem is it will not give you LAT or Long but it will give you the country or even state. Sometimes even Datacenter of BGP is announced in DC infra

2 Likes

Thanks @MalithHatananchchige, this is really useful information. It’s awesome to see that you’ve built a verification tool for this as well - I respect that a lot. I’ll take a look when I get a chance.

In the meantime, I’ll switch to using the location info provided by the relevant proposals. It sounds like diligent node providers such as yourself are doing a great job of keeping each other in check.

It just occurred to me that ISP is probably something that should feature its own Nakamoto coefficient. i.e. even if there are nodes at different data centers, but they use the same ISP, that ISP is a potential central point of failure. Maybe I’ll look into this in a future review :thinking:

@lorimer ISP is definitely a possible candidate for an additional decentralization coefficient, to add in the future.

1 Like