Subnet Management - General Discussion

[0rions]

I also support quint and alex on this!

[Manu]

@0rions @quint @Lorimer thanks for raising this. So today, there’s one method for update_subnet proposals which takes an UpdateSubnetPayload, which consists of many optional fields of things that can be changed. This payload is what is displayed on the NNS FE and the dashboard. Are you proposing to change how the dashboard / nns dapp display things, or would you want to change some of the types / function signatures? If the latter, what would you propose?

[Lorimer]

Thanks Manu, my understanding was that optional fields do not need to be specified in the serialised object representation. I think the default behaviour of protobuf is to deserialise the object without complaint (leaving the optional fields with None values - which should be the same result as explicitly declaring the None values).

I’m not clear on what’s actually depending on None and/or NULL fields being specified in the payload.

[quint]

Based on the code comment that setting a field to None means the value shouldn’t be changed, could we adjust the frontend to reflect this? We could filter out None fields from the display, making it clear what’s actually being updated without touching the function signatures.

Additionally, it would help to not display the original fields that aren’t related to the specific change being made. This way, the focus is on the relevant fields, reducing noise and making it easier to spot changes. I’d lean towards updating the frontend, as it’s a much smaller and more practical change than overhauling the function.

[Lorimer]

@andrea had some further comments about this sort of thing, but I’m not really clear on why this doesn’t seem feasible (I’d be happy with any approach that avoids the noisy proposal payload)

@andrea

To achieve what you are asking there are probably two options: only display mandatory fields and optional fields set to Some in the dashboard, or have dedicated proposals for each of those fields. Both these options seems worse to me than what we have today: for the former the dashboard wouldn’t display the full payload, which makes it harder to detect that something was sneaked in; for the latter, we may end up a with a large number of proposal types, which will probably increase the complexity of the governance canister as well.

[Manu]

Yeah so it seems like we all agree that looking into improving how we display the proposals (so without changing any proposal types) is the most promising path. I brought it up to the team.

[Lorimer]

Thanks for the announcements @dsharifi. I’ve collated them here just for reference.

• shefu 133059
• nl6hn 133064
• jtdsg 133065
• mpubz 133066
• pjljw 133067
• yinp6 133068
• 3hhby 133069
• 4ecnw 133070
• 5kdm2 133072
• cv73p 133073
• lhg73 133074
• snjp4 133060
• opn46 133076
• lspz2 133075
• o3ow2 133077

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

---

Update: All of the above proposals are for 13 node application subnets, reducing the notorisation delay to 300ms (from 600ms). The only caveat I can think of is that lhg73 currently only has 12 nodes operational (which will be addressed by 133081). DFINITY have tested for turbulent network and topology conditions, and in theory a subnet with fewer operational nodes should require less time to disseminate artifacts anyway

I’ve voted to adopt all of the above proposals.

[dsharifi]

I created subnet management threads for the following subnets:

• snjp4
• lspz2
• opn46

[Lorimer]

Thanks @dsharifi. @diegop is there any chance you could use your admin priviledges again to add these to this topic’s introductory post? (as editability has timed out for me)

[diegop]

Added to: Subnet Management - General Discussion

[Lorimer]

• 133071 Resize subnet uzr34 forum post, adopted
• 133078 Replace nodes in subnet tdb26, forum post, rejected
• 133079 Replace a node in subnet 2fq7c, forum post, adopted
• 133080 Replace a node in subnet 6pbhf, forum post, adopted
• 133081 Replace nodes in subnet lhg73, forum post, adopted

[dsharifi]

I created a subnet management thread for the subnet eq6en:

Subnet Management - eq6en (Application)

This topic is intended to capture Subnet Management activities over time for the eq6en subnet, providing a place to ask questions and make observations about the management of this subnet.

[Lorimer]

3 application subnets with 13 nodes to have their notarisation delay reduced to 300ms, which is consistent with all the other 13 nodes subnets on the IC. I’ve voted to adopt all three

• gmq5v announcement for proposal 133140
• k44fs announcement for proposal 133141
• eq6en announcement for proposal 133139

This proposal sets the notarisation delay of the … subnet to 300ms, down from 600ms. The change will increase the block rate of the subnet, aimed to reduce latency of update calls.

---

The remaining four subnets (fiduciary, II, NNS, and SNS) are all much larger subnets that currently have a notarisation delay of 1000ms. It’ll be interesting to see what the notarisation delay can be safely reduced to for these subnets (in future proposals).

[Lorimer]

133152 - Replace nodes in subnet mpubz
133151 - Replace nodes in subnet lspz2
133150 - Replace a node in subnet lhg73 ← (I had a question about this one, but it’s not critical and I have now adopted the proposal)
133149 - Replace a node in subnet uzr34
133148 - Replace nodes in subnet tdb26
133147 - Resize subnet pzp6e

[sat]

FYI, I’m preparing a change in the DRE tooling that will:

1. remove the continent from the Nakamoto calculation
2. add the EU (European Union) as the entity)
   After the change is merged, all Nakamoto coefficients will go down, but IMHO the results will be more useful.

Please DO comment on the PR:

Add EU and remove Continent from calculation of Nakamoto

[sat]

Unfortunately moving EU countries in the previous PR resulted in some complicated replacement suggestions for large subnets, such as the NNS, where we couldn’t possibly reach the adopted target topology. So I will likely have to temporarily revert part of the changes, until we run additional analysis about what the current set of nodes can give us wrt decentralization coefficients.

Revert EU country handling in decentralization code

[ZackDS]

Maybe dividing EU into larger parts like few smaller neighbour countries together ?

[sat]

Possibly, yes. Although the idea was to somehow include the EU as a single jurisdiction into the calculation. But seems like we’re not there yet with the set of nodes that we have at the moment.

[ZackDS]

Got it was just thinking out loud. Also this could be worth taking into consideration for future NP’s onboarding.