Subnet Management - qxesv (Application)

This topic is intended to capture Subnet Management activities over time for the qxesv 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": 44461,
  "records": [
    {
      "key": "subnet_record_qxesv-zoxpm-vc64m-zxguk-5sj74-35vrb-tbgwg-pcird-5gr26-62oxl-cae",
      "version": 44461,
      "value": {
        "membership": [
          "j7mu5-sfjx5-rflso-aqhd5-ymijf-glw4a-ovi6i-f3blz-o54sg-a2rfk-bae",
          "sspbf-fne25-z7m5y-imq3z-ihf3v-qbyhd-ohrqp-zzfk3-dbuu3-zs7se-pqe",
          "sbiuh-cg2ut-pmrik-jit6d-t5szz-4fp7i-pqodm-llgxp-ooht3-d3txm-bqe",
          "5v6bx-3443d-zvacu-gas5w-uopbm-yxnob-i6rsh-rlxqh-hna7u-sy2aj-yae",
          "fvy7i-ux7is-cuvfm-2n2zh-5lpb4-oe2vz-bfnhz-oi5s5-jkzhk-phlj2-gqe",
          "uk6n5-nw7vs-zeydi-qdmgp-xbevs-fnhce-35je2-3m5fu-l2wzj-wrcxb-5ae",
          "w5nh3-v5yix-fnwcd-6iema-sj7yc-hprcf-5xju7-nj7iu-o5p4y-aq5pc-6ae",
          "x5wch-pmfrw-336to-dfhft-qz752-ncbbt-d67os-vmlqf-3je3g-cgzri-nae",
          "ctwsk-mtlet-rcsk6-p44am-6yabc-psi27-den2q-gaeg4-lk5zi-hr23q-6ae",
          "y5y6o-v23la-k26ed-rdyxv-nhyfz-rmeqg-cg5hi-vvc55-xhrcu-5szgb-xqe",
          "ii5t4-bvjp2-sypuy-pqz6v-v44yf-lzox2-ja3tp-m7gtj-7pszo-fk66d-cqe",
          "ys5ct-b73ij-z33xq-y4tej-vby6a-pwzjk-t7ob5-y5nub-oe4vo-alrjn-oae",
          "kzlfn-xeqoz-zcrlc-no4r5-pfjdw-flzfm-cq7zw-bbipw-fw3u7-bsoa6-4qe"
        ],
        "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": "verified_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
      }
    }
  ]
}

There’s an open proposal for changing subnet membership - https://dashboard.internetcomputer.org/proposal/131422. 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 y5y6o-v23la-k26ed-rdyxv-nhyfz-rmeqg-cg5hi-vvc55-xhrcu-5szgb-xqe
+++ India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 cxuqe-ou4rp-y6vot-zzuar-x3qwp-3jj5s-abhs4-yxacr-nxl4p-2cgb5-jae
Belgium Brussels (br1) Digital Realty Allusion ctwsk-mtlet-rcsk6-p44am-6yabc-psi27-den2q-gaeg4-lk5zi-hr23q-6ae
Canada Toronto (to1) Cyxtera Blockchain Development Labs 5v6bx-3443d-zvacu-gas5w-uopbm-yxnob-i6rsh-rlxqh-hna7u-sy2aj-yae
Switzerland Zurich 2 (zh2) Everyware DFINITY Operations SA uk6n5-nw7vs-zeydi-qdmgp-xbevs-fnhce-35je2-3m5fu-l2wzj-wrcxb-5ae
Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC fvy7i-ux7is-cuvfm-2n2zh-5lpb4-oe2vz-bfnhz-oi5s5-jkzhk-phlj2-gqe
Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone sspbf-fne25-z7m5y-imq3z-ihf3v-qbyhd-ohrqp-zzfk3-dbuu3-zs7se-pqe
Japan Tokyo 2 (ty2) Equinix Starbase kzlfn-xeqoz-zcrlc-no4r5-pfjdw-flzfm-cq7zw-bbipw-fw3u7-bsoa6-4qe
Portugal Lisbon 1 (li1) Dotsi Ivanov Oleksandr j7mu5-sfjx5-rflso-aqhd5-ymijf-glw4a-ovi6i-f3blz-o54sg-a2rfk-bae
Romania Bucharest (bu1) M247 Iancu Aurel ys5ct-b73ij-z33xq-y4tej-vby6a-pwzjk-t7ob5-y5nub-oe4vo-alrjn-oae
Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital ii5t4-bvjp2-sypuy-pqz6v-v44yf-lzox2-ja3tp-m7gtj-7pszo-fk66d-cqe
Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG sbiuh-cg2ut-pmrik-jit6d-t5szz-4fp7i-pqodm-llgxp-ooht3-d3txm-bqe
United States of America (the) Allentown (aw1) Tierpoint Bigger Capital w5nh3-v5yix-fnwcd-6iema-sj7yc-hprcf-5xju7-nj7iu-o5p4y-aq5pc-6ae
United States of America (the) Tampa (tp1) Flexential Mika Properties, LLC x5wch-pmfrw-336to-dfhft-qz752-ncbbt-d67os-vmlqf-3je3g-cgzri-nae

The removed node is replaced with a node based in India. 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.

DFINITY will submit a proposal today to reduce the notarization delay on the subnet, qxesv , similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).

1 Like

Voted to adopt proposal 134285. 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 134285. 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.

Voted to adopt proposal 134285. This proposal is part of a sequence of steps to remove cordoned nodes from subnets as the associated data centeres are being offboarded after 48 months of their respective DC contracts that are still private and were signed up before the Genesis. There is a great and detailed explanation of this changes in this forum post and the forum thread it is in. In the wiki there is a series of Steps for Gen-1 Node onboarding after 48 months that need to be followed in order for the nodes to continue earning rewards which starts by making a forum post in the following thread. As we can verify no one as come forward with nodes from the DCs in this proposals so I don’t see any issues with the removal of this nodes.

~Note, @Lorimer , that in our view, the ownership of the data center is not inconsistent with the records in the IC registry, as the registry does not hold information on the ownership of hardware. It holds records stating who runs the nodes. ie: has access to them and is fully responsible for them. As I have said, DFINITY owned the hardware but has had zero access to these servers or responsibility for keeping them running. We also have not held the DC contracts (which is why we have had sero access to them.) We have therefore NOT been the node provider.~

~There is no way of knowing how many other nodes out there might be running on leased servers… both for ICP and for many other blockchains… as this is not something that is currently asked or verified.~

Edit: I didn’t write this post. I have no idea where it came from.

1 Like

Except when the crux of the proposal rests on that ownership (which I agree was nuanced). If it can’t be verified, then we can’t (and haven’t) performed verification of the primary claims of the proposal. Remember clarification does not replace verification (particularly when that clarification comes from the entity that submitted the proposal).

If a reviewer is happy to take a proposer’s word for it, then this whole system makes no sense at all.

@Lorimer That doesn’t look like a comment that I made. I don’t know where that came from. My gut feeling is that it’s a glitch rather than a hack.

@sat @dsharifi @katiep Does the post above that’s attributed to me look familiar to you?

Hello!
So two questions…
If a Node Provider does not have the financial means to PURCHASE servers, but they obtain a lease on servers, which they then put in the DC contract that they own and 100% control…
Do you think that this presents a security issue with the network?

If so, why would this be a security risk?

That leads to the second question: Do you think that Node Providers should be required to purchase hardware and provide invoices showing proof of that purchase (which could be faked rather easily, so we’d have to ask retailers to somehow confirm that Yes, indeed, those servers were purchased from them).

1 Like

Not necessarily, but it wouldn’t be ideal, for similar reasons that subletting a property that you’re renting usually isn’t permitted by the landlord. The extra level of indirection causes complications. Who should be screened during the onboarding process? The node provider, the lender, and/or any future node provider the lender chooses to replace the prior node provider? What happens if the node provider defaults on repayments for the servers that they don’t actually own?

Unless there’s are supply/demand issue (i.e. enough NPs capable and willing), then yes I think this would be good. Regarding this being faked, there are lots of things that a node provider could fake if they were motivated enough (such as location, and other decentralisation metrics), but that’s why the rewards system is there to encourage good behaviour. They’re required to sign a declaration of intent regarding the best interests of the IC. That can be faked too (a pinky promise) but that doesn’t mean it’s not a useful layer of protection that can be used to hold a node provider to account.


In any case, in my opinion, all that would have been required as a sufficient source of verification of those recent proposals is for the DC owners and/or node providers to publicly state their alignment with the claims made in the proposals (given that their nodes were the ones that were targeted). The proposal summary should then have pointed to these statements (the relevant one for each proposal). I’m not sure why this wasn’t done.

If a lender repossessed the server, that would naturally result in the nodes going offline and rewards stopping.

One of the challenges that NPs face at the moment is that the number of people who have the funds to purchase expensive servers AND have the technical ability to be a good node provider is quite limited. I foresee that in the future, there will need to be some method where the two groups can collaborate. Therefore, it seems to me to work against the long-term interests of the IC (in terms of hosting nodes being open to anyone) if we require NPs to have the cash funds to purchase servers outright.

It will be interesting to see where the IC goes, concerning this problem, and what the consensus is with the community.

1 Like

:exclamation: @sat @dsharifi @katiep Please see my query above re the post that was incorrectly attributed to me.

2 Likes

Those are quotes of a post I made on a different thread. Someone must have copied them and got mixed up regarding who wrote it. No worries!

No, there’s a post attributed to me that I didn’t write. Please scroll back further and you’ll see what I mean.

1 Like

@katiep It’s this post here in this same thread. Someone else has posted it under my name. Presumably it was done inadvertently but it’s very unusual.

@sat @SvenF Any ideas?

1 Like

It seems like the only reasonable explanation is that @katiep has admin privileges, and for some reason she was impersonating your account, forgot she was doing it, and then posted thinking she was operating under her own account.

Does that sound conceivable @katiep?

@timk11 I am not sure how that is possible, I will ask the forum moderators.

Yes, that’s possible, as I’m new to being a forum moderator, so I might have done something like that without realizing it. That seems more likely than any other possibility I can think of, in fact!

1 Like