@Lorimer, all information for the decentralization calculations that you see in the NNS proposals and in the DRE tooling is coming from the NNS registry, it’s coming from the Node Provider proposal, Data Center proposal and Node Operator proposal, and also any update proposals such as proposals for update of Node Operator record, which of course are also stored in the NNS registry.
2 Likes
Let me just add that this is the primary reason the DRE tooling is written in Rust. Talking with the registry directly from other programming languages is… harder.
2 Likes
I just submitted a proposal to bring the NNS decentralization closer to the target topology objectives: https://dashboard.internetcomputer.org/proposal/132228
node_provider: 11.00 -> 11.00 (+0%)
data_center: 13.00 -> 13.00 (+0%)
data_center_owner: 11.00 -> 12.00 (+9%)
city: 9.00 -> 9.00 (+0%)
country: 5.00 -> 6.00 (+20%)
continent: 2.00 -> 1.00 (-50%)
Here is the command I ran (in case someone wonders):
dre subnet replace --id tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe --motivation “optimizing subnet decentralization” --forum Subnet Management - tdb26 (NNS) -o 3
After discussing with the networking team, we agreed to replace only 3 nodes at a time in the NNS subnet, to reduce risk.
We will likely need a few more proposals like this one to align the subnet with the target topology objectives. But we’re getting there.
2 Likes
Thanks @Sat, nice work!
Proposal 132228
TLDR: I’ve adopted this proposal 
it brings this subnet closer to the IC target topology! 3 removed nodes replaced with nodes in France, Estonia, Switzerland to improve decentralisation.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 8022.816 km | 19448.574 km |
| PROPOSED | 0 km (NaN%) | 7578.945 km (-5.5%) | 19448.574 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).
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 25 | 39 | 37 | 37 |
| PROPOSED | 5 | 27 (+7.4%) | 39 | 38 (+2.6%) | 37 |
This proposal improves decentralisation in terms of jurisdiction diversity and data center ownership diversity. 
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 14 | 6 | 2 | 2 | 2 |
| PROPOSED | 17 (+21.429%) | 3 (-50%) | 2 | 2 | 2 |
See here for acceptable limits → Motion 132136. This proposal is a big step in bringing this subnet closer the IC target topology (it will now meet it regarding the country limit, which is great).
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 (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 (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews, 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)
3 Likes
I just submitted a proposal to replace an unhealthy node and optimize subnet a bit:
Since there may be questions, the DRE tool analyzed replacing anywhere from 1 to 6 nodes, and concluded that replacing 3 nodes results in identical Nakamoto Coefficient (decentralization) as the replacement of 6 nodes, so it picked to replace only 3 nodes since that’s lower risk
2024-09-20T10:09:51.697Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 1 (+0 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:51.808Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 2 (+1 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:52.032Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 3 (+2 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:52.369Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 4 (+3 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:52.817Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 5 (+4 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:53.370Z INFO decentralization::network > Resizing subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe by removing 6 (+5 unhealthy) nodes and adding 1 nodes. Available 809 healthy nodes.
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 1 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7500 #crit nodes [14, 15] # crit uniq [37, 26] #crit coeff 1 avg linear 8.6667
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 2 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7753 #crit nodes [14, 15] # crit uniq [38, 27] #crit coeff 1 avg linear 8.8333
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 3 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7982 #crit nodes [14, 15] # crit uniq [38, 27] #crit coeff 1 avg linear 9.0000
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 4 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7914 #crit nodes [14, 15] # crit uniq [36, 28] #crit coeff 1 avg linear 8.8333
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 5 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7914 #crit nodes [14, 15] # crit uniq [36, 28] #crit coeff 1 avg linear 8.8333
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 6 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7982 #crit nodes [14, 15] # crit uniq [38, 27] #crit coeff 1 avg linear 9.0000
2024-09-20T10:09:54.022Z INFO decentralization::network > Max score: NakamotoScore: min 1.00 avg log2 2.7982 #crit nodes [14, 15] # crit uniq [38, 27] #crit coeff 1 avg linear 9.0000
2024-09-20T10:09:54.022Z INFO decentralization::network > Replacing 3 nodes in subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe gives Nakamoto coefficient: NakamotoScore: min 1.00 avg log2 2.7982 #crit nodes [14, 15] # crit uniq [38, 27] #crit coeff 1 avg linear 9.0000
Also, not all business rules (target topology) could be satisfied in this replacement cycle. But we’re getting closer.
4 Likes
Voted to reject proposal 133078.
This proposal replaces a dead node (2tk2h, which appears as “Status: Offline” on the dashboard) and additionally replaces two other nodes for the purpose of improving network decentralisation. As seen in the proposal (which I verified using the DRE tool), the overall effect of these additions is to increase the log average Nakamoto coefficient. However, the status with respect to the target topology is worsened, as one of the data centre owners goes from controlling 1 node to controlling 2 nodes. There are also some other instances (mostly unchanged by this proposal) of a node provider, data centre or data centre owner controlling 2 nodes, which is contrary to the target topology, but I do appeciate that for such a large subnet it would be very difficult or perhaps impossible to achieve all of the target parameters at once. In the case of this proposal, the improvement in the Nakamoto coefficient is due primarily to in an increase in the number of cities (from 9 to 11) that would need to collude in order to perform a malicious action on the subnet, which in my estimation represents a very unlikely scenario. I also note that nodes per city is not a parameter in the adopted target topology.
Using the DRE tool, I tested two other scenarios in which only the dead node is replaced, using either one of the two suggested replacement nodes that does not already share a data centre owner with a node already in this subnet. In both cases the Nakamoto coefficients all remained the same and there was no worsening with respect to any of the target topology parameters. In my opinion, either of these would have been preferred options, so I have voted to reject the proposal for this reason. I note that there is always some urgency to replace dead nodes, and my comments are made with full appreciation and respect for the team’s work in keeping the network running, but in this case there are still 39 healthy nodes a potential opportunity to submit an alternative proposal if required.
4 Likes
Proposal 133078
3 removed nodes replaced with nodes in the US, India and Germany.
The reason for one of the replaced nodes is because it’s offline (1 out of 40 nodes, so nothing imminently serious). The other two node replacements are to try and take advantage of the opportunity presented by this proposal, and have a go at further optimising subnet topology to bring it closer to the IC target topology.
I don’t believe this proposal actually achieves its secondary goal, and I respect @timk11’s decision to reject this proposal. Also it sounds like he did a great job in evaluating the other options.
This subnet is already meeting the 3 nodes per country limit, and it’s currently violating all other characteristic limits (2 nodes per every other characteristic). These ‘2 nodes per characteristic’ stats are not actually affected by this proposal. However it does bring the subnet closer a ‘node provider characteristic’ of 1. On the other hand, it also takes the ‘owner’ characteristic even further away from reaching 1.
I would have preferred to see a simple proposal that just solves the problem at hand, which is the offline node. I’ve also rejected this proposal.
Context and Further Explanation
The fact that we’re bumping up against these seemingly unimprovable IC Target Topology metrics is in direct contradiction with the statement made (and adopted) in the latest motion proposal.
There are evidently not enough spare node machine (with sufficient diversity) to meet the IC Target Topology that the above statement refers to. I called for that motion to be rejected. I’ve also called for it to be replaced or suspended if DFINITY would like the community to vote in favour of proposals like this one.
The latest discussion on this that I recall was →
This was more than 3 weeks ago, and I haven’t seen any more on this issue.
I want to make it clear that I respect and appreciate everything DFINITY does to improve the Internet Computer. I’m acting in a way that I believe is in the best interests of the IC. We need a discerning community that takes proposals very seriously (if the idea of the NNS is to make any sense).
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 7578.945 km | 19448.574 km |
| PROPOSED | 0 km | 7269.941 km (-4.1%) | 19448.574 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). 
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 27 | 39 | 38 | 37 |
| PROPOSED | 5 | 28 (+3.6%) | 39 | 37 (-2.7%) | 38 (+2.6%) |
This proposal slightly improves decentralisation in terms of jurisdiction and node provider diversity , but diversity of data centre owners is reduced
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 17 | 3 | 2 | 2 | 2 |
| PROPOSED | 18 (+5.9%) | 3 | 2 | 2 | 2 |
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)
4 Likes
Voted to reject proposal 133078.
This proposal main reason is to replace the offline node 2tk2h. In addition to this replacement two other replacements are sugested to increase the Nakamoto Coefficient. Using the DRE tool to analyse the proposed changes the coefficients for the node_provider and city are increased while the data_center_owner metric worsens. The debate over this metrics has been talked about in other forum posts and I have to agree with @timk11 and @Lorimer. The importance of the IC Target Topology only stands if it’s followed thoroughly. If other metrics should be considered, like the city, that’s a debate needed for further proposals on the target topology. As of now, the city parameter is not relevant from the view point of the target topology so this metric shouldn’t be focused on this type of proposals. In comparison, having the coefficient of the data_center_owner metric worsened is much more relevant. With the suggested nodes I think replacing the dead node with the node zxt3p would be a much better choice since the problem of the dead node is solved and we don’t go further from the target topology.
I would like to hear opinions on this, but I think that if it happens the case where a dead node must be rapidly replaced in a subnet, the best solution might be to just make a proposal for the replacement of this node so there’s no friction in it’s approval. Of course, if it’s possible to increase the coefficients and come closer to the target topology, meaning not sacrificing important metrics, I would certainly vote in favor of such a change.
Thanks for the work and hope we can continue this discussion
3 Likes
Thanks for the very thorough proposal review.
You are absolutely right that we could have replaced only a single node.
dre subnet whatif tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe --remove-nodes 2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe --add-nodes zxt3p-naibu-wlon6-w2h5f-ur74w-wxde7-x4zxc-ghfgs-dgbpr-65lnr-wqe
[…]
Decentralization Nakamoto coefficient changes for subnet tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe:
node_provider: 11.00 -> 11.00 (+0%)
data_center: 13.00 -> 13.00 (+0%)
data_center_owner: 12.00 -> 12.00 (+0%)
city: 9.00 -> 9.00 (+0%)
country: 6.00 -> 6.00 (+0%)
continent: 1.00 -> 1.00 (+0%)
Mean Nakamoto comparison: 8.67 → 8.67 (+0%)
Overall replacement impact: equal decentralization across all features
Details
Nodes removed:
2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe[health: dead, impact on decentralization: (gets better) the number of nodes controlled by dominant Country actors decreases from 15 to 14]
Nodes added:
zxt3p-naibu-wlon6-w2h5f-ur74w-wxde7-x4zxc-ghfgs-dgbpr-65lnr-wqe[health: healthy, impact on decentralization: (gets worse) the number of nodes controlled by dominant Country actors increases from 14 to 15]
We could do that.
HOWEVER…
If we do that then the decentralization of the NPs stays the same. That is, some NPs still have >1 node and the resulting Nakamoto Coefficient is 11.
If we replace more nodes, we do reduce by 1 the number of NPs with >1 nodes in the subnet.
And the NP Nakamoto goes up
node_provider: 11.00 -> 12.00 (+9%)
I see that just as valuable as the decrease in the DC owner by 1. So that part is break even from my point of view.
I agree that the City decentralization does not add much value. The challenge is that in the Registry we use this field inconsistently. In the US that’s a state (check out at2 DC), and in other parts of the world that’s a City. So removing the City altogether from the analysis means that in the US we won’t be decentralizing based on State, which isn’t good IMO.
Overall, the proposal:
- Takes the ‘node provider’ feature closer to 1 node per NP
- Takes the ‘DC owner’ feature further from 1 node per DC owner, in the same amount as the above
- replaces one unhealthy node
- there is no obvious bug in the tooling or a mistake in the proposal to warrant a REJECT.
So from my point of view this proposal would be worth ADOPTing, since it solves one operational problem at hand (unhealthy node) and the rest of subnet decentralization arguably stays approximately the same.
That said, I do want the community members to feel heard and valuable. I would be interested in hearing from @timk11 and @Lorimer how strongly you feel about REJECTing this proposal? Because I don’t feel strongly about ADOPTing it. Just I don’t see value in rejecting it (as explained above), but I’d be okay if we drop it if you feel we should absolutely do this?
2 Likes
It is also important to understand how the DRE tooling handles the business rules requirements.
If any business rule is not satisfied, the code adds a penalty.
Later on, when comparing candidate nodes, it first compares the penalties and then compares anything else.
If there was any candidate node that improves business rules, it would be picked.
Anything else (including City Nakamoto, etc) is considered after comparing penalties. So, unless there are bugs in the code, there is no better candidate to pick for this replacement. And by better I mean one that gets us even closer to the target topology.
UPDATE: I’ve clarified this in the docs: docs: Update decentralization.md by sasa-tomic · Pull Request #953 · dfinity/dre · GitHub
4 Likes
Voted to adopt, and looking forward about the direction this takes us. Looks like more clear documentation is needed for DRE tooling as well as some optimization on how to agree on rules, target topology and so forth.
2 Likes
Thanks @sat for the further discussion points.
So how strongly do I feel about rejecting this proposal? On a scale of meh → tough call → slightly → moderately → rather strongly indeed → very strongly → extremely → fanatical → cmbd, I’d probably go with slightly, so just strongly enough that I’d still favour rejecting it but would still be amenable to alternative viewpoints.
What I think would be really good would be to work towards aligning the decision tools and target topology more closely, which I think is what you had in mind anyway. Given that there’s a longer term plan to expand the larger subnets to 41 nodes, I gather there will be another target topology proposal in the not-too-distant future. I’d suggest raising it in the forum quite some time ahead of submitting the proposal. That would give a chance for discussing whether to add cities, continents, etc to the framework, whether to add some requirements based on Nakamoto coefficients and so forth. There’s a fair bit to weigh up there, such as the possible scenarios we’re aiming to prevent. In the case of cities, a city-wide power outage could potentially impact the network. For continents, it’s hard to think of anything much that could happen, except perhaps in the case of Europe if there is some EU-related action that impacts, but I don’t know if even that is theoretically possible. If there’s an interest in pursuing this sort of discussion sooner, it might be worth carrying it over to the general subnet management topic, or even to a new topic.
1 Like
@timk11 @Lorimer the foundation has decided to reject the proposal based on your feedback. I think the idea of TimK is a good one and there should be a discussion on how the decentralization metrics in the DRE tooling and the metrics on for the optimization tooling can be used best. I suggest we follow up on that discussion in the general subnet management thread.
It’s important to keep in mind that adjusting the tooling takes time, so in all discussions we should not only look for end-state solutions but also for ways in which it can be implemented in a pragmatic, step-by-step way. You’re input in this is very much valued!
As a second comment, DRE will now submit only proposals that improve decentralization on all individual metrics (instead of the total decentralization score that is used in the current DRE tooling), but dead node machines still need to be replaced so there might situations from operational perspective that proposals need to be submitted that slightly decrease decentralization, as we need to limit the risk of a subnet losing too many active nodes.
5 Likes
Here is a change in our tooling that further restricts the subnet membership changes based on the discussions in this thread:
5 Likes
Thanks @Sat, @timk11 and @SvenF, the proposed way forward sounds good. I also think the change to the tooling sounds like a good move. Thanks for turning that around so quickly @Sat!
On a related note, I’ve posted some progress that I’ve made in exploring alternative means of optimising the IC topology. I may not have time to make progress on this for a while, so I wanted to share what I have so far in case anyone else fancies pushing this forward, or is able to provide some early feedback.
2 Likes
Proposal 133148
Thanks for this proposal @sat. I’ve voted to adopt. 2 nodes which are degraded or down
replaced with other nearby nodes. No effect on decentralisation coefficients. Just a slight reduction in the average distance between nodes. Looks good
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 7578.945 km | 19448.574 km |
| PROPOSED | 0 km (NaN%) | 7559.677 km (-0.3%) | 19448.574 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).
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 27 | 39 | 38 | 37 |
| PROPOSED | 5 | 27 | 39 | 38 | 37 |
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 17 | 3 | 2 | 2 | 2 |
| PROPOSED | 17 | 3 | 2 | 2 | 2 |
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)
2 Likes
Hi @sat . Regarding proposal 133148, one of the nodes proposed for removal, bv2x3, shows up as “Degraded” on the dashboard but appears to be working very well on the Node Provider Rewards tool. Is there any other information that should be taken into account here?
2 Likes
Voted to adopt Proposal 133148.
This proposal replaces two nodes in subnet tdb26: 2tk2h, which appears as “Status: Offline” in the IC dashboard, and bv2x3, shows up as “Status: Degraded” on the dashboard but appears to be working very well on the Node Provider Rewards tool. However, one of the replacement nodes, lxgqb, is from the same node provider and data centre as the replaced node.
As seen in the proposal (which I verified using the DRE tool), the overall effect of these additions is to leave the log average Nakamoto coefficient and target topology parameters unchanged. Note that there are some instances of a node provider, data centre or data centre owner having more than one node in the subnet, in contravention of the target topology, but none of these parameters are worsened by this proposal.
2 Likes
Voted to adopt proposal 133148. The updated Decentralization in the DRE Codebase - DRE team docs is awesome.
Yes, the node is having problems to sync time (NTP client does not work correctly). Based on the discussion with the node provider and the analysis so far, it’s an issue on the node provider side (actually on their ISP side), and they are already taking corrective action for this
I’m looking forward to the nodes becoming healthy again and to bringing them back into operation.
1 Like