Proposal 132145
TLDR: Offline node in Israel replaced with one in Georgia. This looks good, however a few points I’d like some clarity on before voting:
- I’ve noticed that the unassigned nodes are currently on GuestOS version
3d0b3f10417fc6708e8b5d844a0bac5e86f3e17dwhile the subnet is running GuestOS version6968299131311c836917f0d16d0b1b963526c9b1. I’m unclear how this is handled. Is the GuestOS version automatically updated for the unassigned node as part of joining the subnet? If so, what’s the point of deploying GuestOS versions to unassigned nodes in the first place (e.g. Proposal: 131712)? - I’m aware of cases where other types of proposals have failed due to the GuestOS version on unassigned nodes, such as when unelecting versions from the registry (e.g. below)
@Luka do you know if GuestOS version inconsistencies can be an issue during ‘Change Subnet Membership’ proposals (or is the unassigned node’s GuestOS version updated automatically to reflect the subnet)?
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 117.442 km | 6831.051 km | 17277.995 km |
| PROPOSED | 117.442 km | 6777.392 km (-0.8%) | 17277.995 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 | 4 | 13 | 13 | 13 | 13 |
| PROPOSED | 4 | 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 | 7 | 1 | 1 | 1 | 1 |
| PROPOSED | 7 | 1 | 1 | 1 | 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
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)