This is just a placeholder for the official announcement, sort of.
A new proposal is out 133320 to replace degraded node and dead node.
2 Likes
Voted to adopt proposal 133320.
This proposal replaces 2 nodes in subnet lhg73: cilsw, which appears in the dashboard as āStatus: Degradedā, and jfryc, which appears on the dashboard as āStatus: Offlineā. The overall effect of these changes is to leave the log average Nakamoto coefficient unchanged while keeping the number of nodes per node provider, data centre, data centre owner and country to one each in every case, well within the limits specified in the target topology.
2 Likes
Voted to adopt proposal 133320. The proposal replaces two nodes, cilsw: degraded and jfryc: offline with two healthy nodes ffsue and 7jjmd. The nodes are operational but havenāt been alocated to a subnet in a long time as itās possible to see here but the respective data centers have healthy nodes in various subnets. The Nakamoto coefficient remains unchanged as verified with the Dre tool.
1 Like
What happened to the established workflow, proposer 61?
Proposal: 133320 - ICP Dashboard (internetcomputer.org)
The above proposal doesnāt contain a reference to a forum post where voters can go see critical discussion about the proposal (to inform their vote, or share their insight). There was no forum post to reference, because the proposal wasnāt announced. I donāt think proposals like this are conducive to effective decentralisation, and responsible voting behaviour, so Iāll be rejecting this proposal. Iād be happy to adopt a replacement proposal that follows established procedure.
Proposal 133320
2 removed down/degraded nodes replaced with unassigned node in the US and Switzerland.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) ā
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 317.676 km | 8678.125 km | 18505.029 km |
| PROPOSED | 300.075 km (-5.5%) | 8719.449 km (+0.5%) | 18505.029 km |
Subnet characteristic counts ā
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 13 | 13 | 13 | 13 |
| PROPOSED | 5 | 13 | 13 | 13 | 13 |
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) ā
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 4 | 1 | 1 | 1 | 1 |
| PROPOSED | 4 | 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
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)
1 Like
Voted to adopt proposal 133320 the ids and reasons for the two removed notes check out and the addition of two new healthy ones check out as well while the decentralization stays the same.
About the proposal workflow I would have to agree with @Lorimer by adding that it shouldnāt be JUST for proposals that have voting grants. Since we have been doing this for a while now we do know where to find the forum thread to post. Also it wouldnāt be a problem for us to post each proposal to the affected subnet management thread on a first saw the new proposal first to post it basis.
I just think that using the Subnet Management threads (again we have to thank @Lorimer for the great job he did with these) is a great place to encourage others (outside of the current voting grants) to join and participate in the discussions relevant to each proposal and changes they bring to each subnet. Could raise more awareness on how decentralization is achieved and the
current target topology of the IC.
3 Likes
Hello there! Proposer 61 here. Iāll share some of the background of why that took place.
We had to make an emergency hotfix a few days ago.
The release automation tool ā itās a fairly recent innovation, ordinarily in charge of making proposals, and weāre very happy it exists ā normally in charge of making the forum post then creating the proposal with a link to the forum post, had what we might call āa moment of confusionā. It started posting āin a few minutes there will be a new proposalā, several times spaced apart by a few minutes. So we suspended it. Of course, this meant no proposal was going to be produced.
Facing the situation as release manager for this week, I manually created the proposal using ic-admin (something we havenāt done in probably months). I composed the title, the content of the proposal, verified the SHA256 sum of the package, and collated the URLs for it to go complete. Sadly, the forum post link went missing in that process.
Thatās the lowdown on how the proposal came to be without a forum post link. While itās technically not necessary to have a forum post link in a proposal ā itās not a field part of the formal machine-readable payload, only the commentary ā we pride ourselves in fostering an environment where people can discuss the IC, its operation and all issues surrounding its evolution. The oversight is on me, and I apologize for that.
Iām happy to answer any further questions regarding this issue!
Edited to add: the forum post where the automation was slated to post an update was the same forum post for this weekās original release. I think the original release automation hiccups are still in that thread.
Edit #2: the automation hiccups are gone. I manually posted the notes for the hotfix here.
5 Likes
Hi @Lorimer as the proposal was accidentally missing the forum post link, which has been corrected and weāre making sure that this does not happen in the future again, the Foundation has decided to adopt the proposal. Thanks for your sharp review on the process to be followed, very much appreciated!
5 Likes
Hello, folks. Weāre experiencing some issues with three different nodes in lhg73. Please stand by for more information on how we plan to proceed in order to restore lhg73 to full operation. Thanks.
2 Likes
Weāll shortly submit a proposal to replace three dead / degraded nodes.
Please disregard proposal 133400 ā this proposal was submitted in error.
EDIT: proposal has been submitted:
Forum post link: https://forum.dfinity.org/t/subnet-management-lhg73-application/34055/30
Payload: ChangeSubnetMembershipPayload {
subnet_id: lhg73-sax6z-2zank-6oer2-575lz-zgbxx-ptudx-5korm-fy7we-kh4hl-pqe,
node_ids_add: [
vlbpb-szwgu-jqul3-kpfje-ozgkp-jdwz4-f2hhq-6w6tf-e2lrl-4bmad-xae,
r4642-fjh73-ltnlt-qhdcr-kfujl-v3up4-5pnci-o7zqi-set7a-pvi3p-5qe,
rs26k-ldffa-z7lqu-rhjps-tumxa-arwvb-mdyye-mhevv-4dpjm-xo72t-mae,
],
node_ids_remove: [
7jjmd-p43kv-2h3bp-yrcuv-gc3ia-zaess-2rj6p-p4xgr-f43xy-6hk55-xqe,
ognrk-q4exl-3wf25-yrrsy-mtezk-e3qww-k6s5v-2pikz-gto6z-dyl2y-eae,
rsp26-d2hko-kvacs-6mdca-dumka-qxiyw-4yzkp-cuwgr-lj7je-v7e6z-4qe,
],
}
proposal 133404
5 Likes
Based on this I rejected the proposal 133400 with only 2 replacements.
1 Like
Thank you very much, Zack.
@ZackDS @Lorimer @timk11 @LaCosta can we have your review of proposal 133404? The lhg73 subnet has three degraded nodes now, which would be good to replace as fast as possible. Thanks again for your efforts!
6 Likes
Proposal 133404
TLDR: Iām voting to adopt.
3 removed nodes (in Switzerland - degraded, Germany - up, Georgia - down) replaced with unassigned nodes in Germany, China, Japan.
I took at look at the node provider rewards dashboard to see what the situation was with the Germany node, given that it currently appears to be up. Looks like itās been having some degradation recently, but not as bad as some other nodes on that subnet. Oddly enough there are no stats for the last few days:
For comparison, 56ovz is an example of an up node thatās not being swapped, yet itās stats look even worse.
In any case, this proposal improves network decentralisation and addresses a clearly degraded and down node. Looks good, Iām voting to adopt
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) ā
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 300.075 km | 8719.449 km | 18505.029 km |
| PROPOSED | 317.676 km (+5.9%) | 9071.275 km (+4%) | 18505.029 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 | |
|---|---|---|---|---|---|
| EXISTING | 5 | 13 | 13 | 13 | 13 |
| PROPOSED | 5 | 13 | 13 | 13 | 13 |
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) ā
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 4 | 1 | 1 | 1 | 1 |
| PROPOSED | 5 (+25%) | 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
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)
133400
Rejected (proposed by neuron 61 - @dmanu, who has declared the proposal as submitted in error)
3 Likes
Sry for the late response I was away. Voted to adopt proposal 133404.
All the 3 listed nodes are consistent with the proposals motivation as being offline and degraded (even though the one from Dfinity " rsp26" is currently showing as active in the dashboard while NPR shows that is offline for last 3 days)
The proposed new nodes all are healthy and adding them does not hurt but in fact improves decentralisation.
2 Likes
Voted to reject proposal 133400 based on the information provided.
2 Likes
Voted to adopt proposal 133404. The proposal replaces three nodes on the lhg73 subnet: node 7jjmd (Degraded), node ognrk (Offline) and node rsp26 (Active) with the nodes: vlbpb, r4642 and rs26k.
The Nakamoto Coefficient remains the same and although node rsp26 shows up in the dashboard as active it has been degraded since the 10th of October as seen in the image from the Node Provider Rewards.
4 Likes
I voted earlier to adopt proposal 133404. This proposal replaces three dead or degraded nodes in the lhg73 subnet and does so without any negative impacts on Nakamoto coefficients or the target topology. I havenāt yet had the opportunity to verify all the details independently but I appreciate thereās some urgency to get this change underway in order to uphold the safety of the network.
4 Likes
Iāve also voted to reject proposal 133400 given that it was submitted in error and then superceded by the more recent proposal.
4 Likes
Thank you so much for your help getting lhg73 to top performance again.
3 Likes