This topic is intended to capture Subnet Management activities over time for the pjljw 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:
DFINITY will submit an NNS proposal today to reduce the notarization delay on the subnet, pjljw, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).
Voted to adopt proposal 134282. 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 unchanged. The relevant context is provided by this forum post and associated discussion. However, I voted before this reply was posted. The subsequent posts indicate that this proposal was submitted in error, so I would therefore now recommend a reject vote.
Voted to reject proposal 134282. This result was submitted in error as pointed out by @timk11 which we can verify through this confirmation by DFINITY in a forum post.
A new proposal with id 134619 has been submitted, please take a look.
Click here to open proposal details
Replace a node in subnet pjljw
Motivation:
replacing z6jp6 as per user request: Requested by the node operator in order to redeploy all nodes in the DC after 48 months, and switch to a new node operator ID.
The proposal replaces healthy Active status node z6jp6 from Dallas, with unassigned healthy Awaiting status node k67we from Florida, without any change to the decentralization of the subnet.
The motivation is that this was requested by the NP 87m Neuron in order to be redeployed with a new node operator ID.
Contact info.
This proposal is intended to replace node z6jp6 for the stated reason that the removal was requested by the node operator in order to redeploy all nodes under a new node operator ID, but no forum link to or other evidence of this request is provided in the proposal details.
The proposal replaces the node z6jp6 with node k67we with no impact on the decentralization.
This type of proposal was discussed before and was agreed with @SvenF that the best way to move forward was to have a forum post from the NP confirming the intent to remove the node from the subnet.
This was not done and in order to enforce a standard on this type of proposal I think it’s important to reject specially since the issue was discussed before.
Hey @LaCosta and @timk11, I like your reviews and I’m planning to vote the same way. Given that 2 of CodeGov’s 3 reviewers rejected, and only @ZackDS voted to adopt, I’m confused to see that CodeGov has voted to adopt overall.
Querying the NNS canister using the list_neurons method shows that the CodeGov neuron also has a hotkey. @wpb did you use this to override consensus on this proposal for some reason, or has something else occurred here that caused CodeGov to adopt?
TLDR: I’ve voted to reject, because the proposal does not follow procedure. There’s no reference to a public declaration from the node operator, with which to verify their request.
Motivation:
replacing z6jp6 as per user request: Requested by the node operator in order to redeploy all nodes in the DC after 48 months, and switch to a new node operator ID.
1 removed online US node replaced with an unassigned node in the US
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7325.541 km
16759.085 km
PROPOSED
0 km
7270.354 km (-0.8%)
16759.085 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
Node Operator
EXISTING
5
11
13
13
13
13
PROPOSED
5
11
13
13
13
13
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
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)
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
You may wish to follow D-QUORUM if you found this analysis helpful.
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.
Additional good neurons to follow:
D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
Synapse (currently 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)
Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
Thankfully Synapse is no longer solely following CodeGov (as mentioned in the known neurons part of my review). I’ve just voted, following @timk11 and @LaCosta’s lead, which has triggered the Synapse vote, which has helped to balance that non-consentual vote slightly. See here for more info.
The CodeGov team has a group chat in which we keep each other informed of different aspects of our decisions. I voted manually on proposal 134619 before @LaCosta cast his vote. At the time, @ZackDS had already voted to adopt and @timk11 had already voted to reject. Both posted their reviews and commented in our chat group. I was working with @hpeebles on testing of the WaterNeuron vote relay app and needed a vote to be cast since he and I were actively troubleshooting. Tim had commented in our chat that he was ok with either adopt or reject on this proposal. Zack indicated he thought it was ok to vote manually on a few proposals since it is the holidays and it might be difficult for all the votes to be cast in a timely manner. I voted to adopt, but failed to inform Henrique of my vote. I would have been ok with either adopt or reject on this one, but chose what seemed like the more reasonable option at the time. I stand by this manually cast vote. It was well informed. I can understand your confusion since you are no longer part of the CodeGov team and don’t have access to our internal discussions.
Thanks for clarifying the situation Wenzel. I understand triggering the vote early (as a convinience for testing the relay dapp in the production environment). I find the divergence from the public reviews and formal votes confusing/unsettling though (1 adopt + 1 reject = reject). I’m not sure why the rejection wasn’t respected.
I think it is though, isn’t it? That what the reviews are for, and it’s why they need to be public.
