Subnet Management - General Discussion

[Lorimer]

Subnet Management - pzp6e (Fiduciary)

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

[Lorimer]

@SvenF

we have another 3 nodes degraded on the lhg73 subnet, we’re looking into the cause of this, and why it does not occur on other subnets. For now, we think it might be related to a kernel bug that is triggered by the large replica state of this subnet

Thanks for the heads up @SvenF. I’ll be interested to learn about what the root cause is once it’s found.

[dsharifi]

I created a subnet management thread dedicated to the x33ed (sns) subnet. Subnet Management - x33ed (Application SNS)

[Lorimer]

@dsharifi

I created a subnet management thread for the subnet eq6en:

@dsharifi

I created a subnet management thread dedicated to the x33ed (sns) subnet

Thanks @dsharifi! @diegop, is there any chance that you would add these two to the list at the top of this thread (given that the post is so old I’m no longer able to edit it myself). These are now the last two subnets to be added (of the existing subnets), so hopefully there’ll be no need to bother you with this again until some new subnets get created

[Severin]

Subnets are added to the list

[Lorimer]

Subnet Management - tdb26 (NNS)

DFINITY will submit an NNS proposal today to reduce the notarization delay on the NNS subnet, tdb26, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread ). The NNS subnet is the last subnet left as part of the latency milestone to reduce its notarisation delay.

once executed, all subnets will have a notarisation delay of 300ms

[Lorimer]

134038 - Replace nodes in subnet 5kdm2
134039 - Replace nodes in subnet e66qm
134040 - Replace a node in subnet io67a
134041 - Replace a node in subnet brlsh

134042 - Replace nodes in subnet uzr34

[sat]

We just extended DRE tooling to allows it to automatically create forum posts for subnet management proposals.
Here are a few new automatically created forum threads/posts:

Replacing nodes in subnet tdb26

Replace a node in subnet tdb26 Motivation: replacing dead node onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe Calculated potential impact on subnet decentralization if replacing: 1 additional node would result in: (gets better) the average log2 of Nakamoto Coefficients across all features increases from 3.2999 to 3.3303 (solution penalty: 30) 2 additional nodes would result in: (gets better) the average log2 of Nakamoto Coefficients across all features increases from 3.3303…

Replacing nodes in subnet snjp4

Replace a node in subnet snjp4 Motivation: replacing dead node wzr5d-7qa2x-tduot-6mkkq-ou4sc-5ktje-4hxqa-a75d5-gunkc-3xhyt-6qe Calculated potential impact on subnet decentralization if replacing: 1 additional node would result in: equal decentralization across all features Based on the calculated potential impact, not replacing additional nodes to improve optimization. Note: the information below is provided for your convenience. Please independently verify the decentralization changes ra…

Replacing nodes in subnet yinp6

Replace nodes in subnet yinp6 Motivation: replacing node s52il-lowsg-eip4y-pt5lv-sbdpb-vg4gg-4iasu-egajp-yluji-znfz3-2qe to optimize network topology replacing node cjiry-m7wev-s6adg-3oqev-2g74r-wmtlj-ttdbj-abwts-rtwlj-6lxts-dqe to optimize network topology Calculated potential impact on subnet decentralization if replacing: 1 additional node would result in: (gets better) the average log2 of Nakamoto Coefficients across all features increases from 1.9932 to 2.0575 (solution penalty: 10) 2 …

This functionality was requested by @cryptoschindler and @marc0olo as a part of the proposal review process improvements.

[ZackDS]

Ok, at least thanks for sharing.

[Lorimer]

Thanks for this announcement @sat. @cryptoschindler, @marc0olo, would you be able to comment on what the motivation for this was?

@Lorimer

What’s gained by each SM proposal having a dedicated forum topic? I think there are certain things that are lost with this approach, such as an easy to view chronology of changes that have been applied to a specific subnet (this alone has helped me to catch certain issues in the past)

[sat]

I thought that this was discussed with the community members already. It seems like I was wrong.

[Lorimer]

It was brought up, and I raised concerns that maintaining an easy to see chronology of reviews for each subnet was valuable.

My understanding is that the two motivations for having separate forum topics would be to:

1. improve the experience for reviewers of reviewers (the grant committee). Given that this task is comparatively simpler (compared to actually generating the review), I think it’s a mistake to optimise for it.
2. for consistency with other types of proposals. I’m not sure why this should be important. Subnet Management topics have clear deployment targets, but with variable types of proposals that can be applied. So far I’ve found the chronology that the existing forum threads provide extremely valuable. I’m not sure if other reviewers agree. What do you think @ZackDS, @timk11, @LaCosta

My takeaway from previous discussions was that this would be something to revisit (so here we are I guess ).

[marc0olo]

@Lorimer

improve the experience for reviewers of reviewers (the grant committee). Given that this task is comparatively simpler (compared to actually generating the review), I think it’s a mistake to optimise for it.

it isn’t only that. while we 100% agree that it is good to have the whole subnet history in one thread, it also makes sense to split out a separate thread for each proposal of a subnet.

the “global” subnet thread history becomes very hard to track if you just want to look for comments on a specific proposal.

our suggestion in that regard is, that somebody (maybe you? ), just references the respective proposal thread within the subnet thread. so we can have both, a nice subnet history and a good discussion overview for each proposal.

@cryptoschindler feel free to add your opinion or just hit a like on my post. this was mainly driven by you, right?

[Lorimer]

@marc0olo

the thread history becomes very hard to track if you just want to look for comments on a specific proposal.

Thanks @marc0olo , I think this point of view does sound reasonable, but all proposals sit within a context. I strongly believe that context is key to effective decision-making on complex topics.

I agree that it’s simpler for each SM proposal to have their own forum topic, but in my opinion the hidden complexity is actually value lost. The assumption is that segregation allows all comments that are relevant to a proposal to be contained on a dedicated topic, but in practice the recent history of a subnet is valuable context for evaluating the appropriateness of a current proposal.

My motivation for debating this is to try to ensure we’re optimising for whatever makes the job of performing subnet management reviews easier, and more likely to be diligent and on the ball (for the benefit of the IC, now and in the future).

I’m just one person with an opinion on this. I think it would be worth checking the opinion of other Subnet Management reviewers (I’m happy to be alone in my opinion, so please don’t let my stance on this sway you if you don’t actually agree, fellow reviewers).

[Lorimer]

@marc0olo

our suggestion in that regard is, that somebody (maybe you? ), just references the respective proposal thread within the subnet thread. so we can have both, a nice subnet history and a good discussion overview for each proposal.

I’m happy to do this, but realistically I’d forget some of the time (there are already lots of things to do when reviewing a proposal). My main concern is making it easier for voters to make informed decisions about SM proposals. Should the history thread link to the proposal thread, as well as the proposal thread linking to the history thread? That’s a lot of cross-posting.

Here are the two user stories that I’m envisaging:

---

Full-History-Topic Scenario

1. An SM proposal is submitted with a proposal summary that links to a forum topic that contains a running history of changes to the subnet
2. A voter sees the proposal and would like to make an informed decision with their vote, so they follow the link to the forum topic
3. The user arrives on the forum and has two options
   A. the user chooses to scroll up to get a feel for what has happened recently
   B. the user chooses to scroll down to understand what has been said since the proposal was submitted
4. The user has the best chance of understanding the proposal and the context that it sits within.

---

Dedicated-Topic Scenario

1. An SM proposal is submitted with a proposal summary that links to a dedicated forum topic
2. A voter sees the proposal and would like to make an informed decision with their vote, so they follow the link to the forum topic
3. The user arrives on the forum and has one option, scroll down to understand what has been said since the proposal was submitted. Ideally others will have posted anything that’s relevant, but those people are just voters too (I think it’s better to maximise the chances of relevant history getting spotted, by anyone and everyone)
4. The user may understand the proposal but is less likely to understand the context that it sits within

[marc0olo]

@Lorimer

Should the history thread link to the proposal thread, as well as the proposal thread linking to the history thread?

it is enough if the proposal thread is linked in the history thread. if we consequently achieve this, it will look like this in the proposal thread:

these highlighted links will lead the user directly to the position in the history thread where it was linked.

I definitely understand your concerns. I would like to get more opinions from other reviewers. what I am wondering mostly as we discuss is, whether there is much discussion going on between several proposals (except proposal reviews and comments on proposal reviews)

by separating into explicit threads (as done now), you would at least be able to always read messages in the right context and the history thread would be “more clean”.

@Lorimer

but in my opinion the hidden complexity is actually value lost.

not sure if that is really the case. maybe we can just explore how it goes with the recent changes as the team already put the effort in this (thanks @sat) before taking a decision to revert all of this.

@Lorimer

My motivation for debating this is to try to ensure we’re optimising for whatever makes the job of performing subnet management reviews easier, and more likely to be diligent and on the ball (for the benefit of the IC, now and in the future).

I totally understand this. but at the same time reviewers also want the community being able to easily follow those discussions and have the right context to make their own decision in the NNS or decide to follow the Neurons they value most. we should consider both sides, the reviewers and the general community which follows their Neurons and thus increase the reviewers voting power.

@Lorimer

The user may understand the proposal but is less likely to understand the context that it sits within

I kind of disagree with that. usually the context is made clear in the proposal itself. isn’t that the case?

@Lorimer

I’m happy to do this, but realistically I’d forget some of the time (there are already lots of things to do when reviewing a proposal).

this is definitely kind of crucial to keep the history of the main subnet thread consistent and transparent. maybe this could also be automated (cc @sat ), but if you or somebody else could make sure to cross-post this at least initially, that would be great.

I wouldn’t want to put more effort into this if we still discuss and explore the best path.

[Lorimer]

@marc0olo

I definitely understand your concerns. I would like to get more opinions from other reviewers.

Thanks @marc0olo, I think I also understand where you’re coming from. I’d also like to see other peoples’ take on this.

---

@marc0olo

what I am wondering mostly as we discuss is, whether there is much discussion going on between several proposals (except proposal reviews and comments on proposal reviews)

There are cases where discussion takes places that’s independent of any one proposal (but which potentially relates to the history of the subnet in general). Here’s a fairly recent example.

---

@marc0olo

by separating into explicit threads (as done now), you would at least be able to always read messages in the right context and the history thread would be “more clean”.

My point is that the right context is always the history of the subnet (if you’re interested in voting on the proposal). Here are just a few examples that demonstrate this:

• Set subnet notarisation delay to 300ms on subnet ejbmu ← You can spot what’s wrong with that proposal simply by scrolling up to the previous post
• Replace a node in subnet 6pbhf ← Another example where scrolling up to the previous post provides valuable insight into the new proposal (see here for an explanation)
• The mysterious situation with the Bitcoin subnet may well be valuable context for the next proposal. Similarly the history for lhg73 is valuable context.
• There are also numerous examples where a sequence of proposals are required on a specific subnets to action a desired change. Other examples include temporarily worsening decentralisation coefficients in order to perform a task on some nodes, followed by another proposal to address the decentralisation issue caused by the prior proposal.

@marc0olo

usually the context is made clear in the proposal itself. isn’t that the case?

I don’t think we can or should depend on information that has been provided by the proposer to support their proposal (they want the proposal to pass or they wouldn’t have submitted it). The reviewer’s job is to challenge that perspective, not make any assumptions about the integrity of the proposer, and fact check the details.

---

The only real benefit I can see to segregating discussions for specific proposals is that it becomes easier to quickly see that every elected reviewer has fulfilled their role on that specific proposal.

Are there any examples that demonstrate the potential utility of this segregation from the point of view of a voter?

---

@marc0olo

before taking a decision to revert all of this

I don’t think recent efforts would need reverting. Instead of creating a new topic, the tool could just post to an existing topic. If this is done, I think it would be good if the details of the post could be contained in a collapsible section (expandable if the user wants to see it).

[timk11]

I think I’m with @Lorimer on this one. When reviewing these proposals it’s sometimes been handy to see what other proposals have previously been accepted or rejected for the same subnet. If each proposal had a separate forum topic it would take a lot more jumping around between forum topics to find this information.

I recall there was some discussion around how best to organise reviews within the forum. Since then things seem to have evolved organically and the flexibility has been appreciated.

My overall preference would be for every proposal in the funded review topics (and probably most of the others) to make use of the URL field in the proposal overview like so:

and maybe even to have this coded in as a requirement for submitting a proposal.

For Subnet Management proposals my personal preference would be for a link to be given to a specific post (rather than just a forum topic) that just gives essential details of the proposal. Reproducing the entire text of the proposal works well for IC-OS proposals because a lot more things change with each proposal, but for SM proposals I think just a brief summary keeps the overall thread more readable. This would mean a manual process of starting a forum post, submitting the proposal and then going back to the forum post to edit in the proposal link, but this has worked really well whenever it’s been done before and should make things easier for reviewers, other voters and reviewers of reviewers alike, hopefully without adding much work for proposers.

[timk11]

@marc0olo

what I am wondering mostly as we discuss is, whether there is much discussion going on between several proposals

Indeed there has at times. Similarly with node provider proposals, various discussions have come up that have been helpful for voting on subsequent proposals, and having the vast bulk of these proposals all in the one thread has been very helpful in this respect.

[sat]

One very easy thing we could do to potentially satisfy all sides is to add another tag per subnet. For instance tdb26 for the nns subnet. Then one could simply click on the tag in any proposal thread and get all previos topics and discussions on that particular subnet. Would that work, and would that be actually enough?