DFINITY submitted a proposal to enable subnet pzp6e to sign with the key Ed25519:key_1: https://dashboard.internetcomputer.org/proposal/132383.
1 Like
Thanks @andrea, this proposal has been eagerly anticipated.
I do have a question though. Why does the payload of this proposal contain the following fields?
max_instructions_per_install_code:NULL
max_instructions_per_message:NULL
max_instructions_per_round:NULL
These arenât valid âupdate subnetâ config fields are they? â ic/rs/registry/admin/src/update_subnet.rs at master · dfinity/ic · GitHub
Similarly, if optional fields donât need specifying, why specify them at all (the payload would be much easier to read if NULL/default value fields were ommitted).
As a side note, would you consider providing a link to the forum conversation in the proposal in the future? This is so that voters in the NNS dapp have an accessible means of reviewing critical discussion, in order to cast a more informed vote (and/or more easily join in with the conversation) 
This is an update subnet config proposal. I think that all the fields visible in the payload are the things you can propose to change with such proposal. As this proposal is not proposing to modify any of those fields, apart from enabling the ed25519 key, those fields are empty in the submitted payload. This is the payload that was submitted:
Payload: UpdateSubnetPayload {
subnet_id: pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae,
max_ingress_bytes_per_message: None,
max_ingress_messages_per_block: None,
max_block_payload_size: None,
unit_delay_millis: None,
initial_notary_delay_millis: None,
dkg_interval_length: None,
dkg_dealings_per_block: None,
start_as_nns: None,
subnet_type: None,
is_halted: None,
halt_at_cup_height: None,
max_instructions_per_message: None,
max_instructions_per_round: None,
max_instructions_per_install_code: None,
features: None,
ecdsa_config: None,
ecdsa_key_signing_enable: None,
ecdsa_key_signing_disable: None,
chain_key_config: None,
chain_key_signing_enable: Some(
[
Schnorr(
SchnorrKeyId {
algorithm: Ed25519,
name: "key_1",
},
),
],
),
chain_key_signing_disable: None,
max_number_of_canisters: None,
ssh_readonly_access: None,
ssh_backup_access: None,
max_artifact_streams_per_peer: None,
max_chunk_wait_ms: None,
max_duplicity: None,
max_chunk_size: None,
receive_check_cache_size: None,
pfn_evaluation_period_ms: None,
registry_poll_period_ms: None,
retransmission_request_ms: None,
set_gossip_config_to_default: false,
}
1 Like
Thanks @andrea, was this payload auto-generated by tooling? Iâm curious why those 3 fields are included in this case, but werenât in prior update subnet config proposals. Itâs also curious that those three fields do not appear to have a binding for deserialization. The NNS function that this proposal executes is UpdateConfigOfSubnet, which deserializes the payload to UpdateSubnetPayload (unless Iâm mistaken)
Iâve adopted because superfluous fields will just be ignored during payload deserialisation. But it would be good to know more about how these payloads are constructed. It would be great if in future proposals the only fields specified are the ones that are being modified (for clarity).
was this payload auto-generated by tooling?
Yes, it was generated using ic-admin.
Itâs also curious that those three fields do not appear to have a binding for deserialization.
Ah, I understand whatâs going on now. This was due some recent change that removed those 3 unused fields, see here. The version of ic-admin used was probably older than the above commit and thus created those fields (and included in the payload I pasted above), but they are then ignored during deserialization.
It would be great if in future proposals the only fields specified are the ones that are being modified
I donât think it is possible given how things work currently. I.e. the argument of this governance function is the payload UpdateSubnetPayload which includes several optional fields. When the dashboard decodes the payload it has to set all the fields, and some of them may be set to None if those entries should not be modified.
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.
Do you have concrete suggestions on how would you improve this?
2 Likes
Are you sure? Canât the payload be deserialised without specifying the optional fields (which will end up with a default None value)? Why would they need to be explicitly set?
Related to this subnet:
2 Likes
Thanks for announcing this @Sat Are you able to point to a public reference regarding the âuser requestâ?
removing xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae as per user request
User request here means a human, that is, not the automation, and not any other condition. It could be a wrong term to use here. Better suggestions are welcome! Or a PR. That would be even better of course. 
1 Like
I guess it was requested by the node provider in a private message then? If it was via a public forum then a link would be great.
Oh now I understand the question. So youâre asking why this particular note was removed from the subnet. The reason is that this subject had four nodes in the US and we needed to remove one so the algorithm picked one based on the user (mine) request to remove one node. Hope that makes sense.
1 Like
Thanks @Sat, this makes sense (I think I just got the wrong end of the stick). Iâve voted to adopt the proposal now
Proposal 132483
1 American node removed (to meet the 3 nodes per country limit), and 4 nodes added (in Australia, South Africa, Portugal, Belgium). This proposal brings this subnet closer to the new target topology (aiming for an eventual subnet size of 34 nodes). After this proposal there subnet will jump from 28 to 31 nodes.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) â
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 8103.495 km | 18505.029 km |
| PROPOSED | 0 km (NaN%) | 8162.808 km (+0.7%) | 18505.029 km |
This proposal slightly increases decentralisation, considered in terms of geographic distance (and therefore thereâs a slight theoretical increase in localised disaster resilience). 
Subnet characteristic counts â
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 21 | 28 | 28 | 28 |
| PROPOSED | 5 | 22 (+4.5%) | 31 (+9.7%) | 31 (+9.7%) | 31 (+9.7%) |
This proposal improves decentralisation in terms of jurisdiction diversity.
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) â
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 9 | 4 | 1 | 1 | 1 |
| PROPOSED | 11 (+22.2%) | 3 (-25%) | 1 | 1 | 1 |
Continents do not feature in the IC target topology, but countries do. This proposal brings the country count down within the acceptable limits
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
Proposal 133147
Adds 3 additional nodes to this subnet (in Switzerland, China and Portugal). After this proposal executes the subnet will be meeting the new IC Target Topology (where it was proposed to grow this subnet from 28 nodes to 34 nodes). Looks good. Iâve adopted
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) â
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 8162.808 km | 18505.029 km |
| PROPOSED | 0 km | 7972.045 km (-2.3%) | 18505.029 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 | 22 | 31 | 31 | 31 |
| PROPOSED | 5 | 23 (+4.3%) | 34 (+8.8%) | 34 (+8.8%) | 34 (+8.8%) |
This proposal improves decentralisation in terms of characteristic diversity.
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) â
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 11 | 3 | 1 | 1 | 1 |
| PROPOSED | 13 (+18.18%) | 3 | 1 | 1 | 1 |
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 adopt the addition of the 3 healthy nodes in order to align it with the Target Topology. Looks like improving decentralization is getting harder to meet as the number of nodes grow on any given subnet.
3 Likes
Voted to adopt proposal 133147, even tough the Nakamoto coefficient across all features gets worse, in order to get closer to the number of nodes needed according to the Target Topology.
2 Likes
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 ).
3 Likes
Voted to adopt proposal 133395. This proposal reduces the notarisation delay for subnet pzp6e from 1000ms to 300ms with the aim of improving network latency.
3 Likes
Adopted proposal 133395. The summary and both subnet id and the delay value in the payload are correct.
1 Like