Subnet Management - pzp6e (Fiduciary)

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) :slight_smile:

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 :slight_smile: 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. :sweat_smile:

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 :slight_smile:


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). :+1:

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. :+1:

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 :+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
Continent Country Data Center Owner Node Provider Node Status
--- Americas United States of America (the) San Jose (sj1) INAP Shelburne Ventures, LLC xsntz-cuxb5-c3xmg-vuzwb-2wsb6-jbfpj-jh6du-ynics-ziore-t7bpp-4ae UP
+++ Oceania Australia New South Wales 1 (ns1) Latitude.sh Conic Ventures w7v5s-nethv-crfsc-zzq5e-gibjz-dmmyp-mrl6e-vkvid-g56eh-iilcm-eqe UNASSIGNED
+++ Europe Belgium Seoul 3 (kr1) KT Pindar Technology Limited mhfef-zbxsl-rocpc-ovqeh-jg3ct-7nvmi-gzpnm-xjmm4-uekgj-rquls-uqe UNASSIGNED
+++ Europe Portugal Lisbon 1 (li1) Dotsi Artem Horodyskyi u3ahx-ft3kq-pzlkr-imzus-aeqxm-cirqv-ymehh-xzctz-os4ud-3a74m-vae UNASSIGNED
+++ Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd jlifv-mddo3-zfwdc-x2wmu-xklbj-dai3i-3pvjy-j4hqm-sarqr-fhkq6-zae UNASSIGNED
Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank 3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe UP
Europe Austria South Moravian Region 1 (bn1) Master Internet Lukas Helebrandt afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae UP
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae UP
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae UP
Asia China HongKong 4 (hk4) hkntt Origin Game 6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae UP
Americas Costa Rica Bogota 1 (bg1) EdgeUno Geeta Kalwani tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe UP
Americas Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe UP
Europe Germany Geneva 2 (ge2) SafeHost Archery Blockchain SCSp w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe UP
Europe Spain Barcelona 1 (es1) Adam Carbon Twelve rq2bj-ek3yy-mjj6s-zewtq-zzke4-u4zix-tz2xd-xigpz-s5hih-4wpmt-iqe UP
Asia Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae UP
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae UP
Asia India Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae UP
Asia India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe UP
Asia Sri Lanka Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd shtwt-kuy74-afhyd-sivzp-nj3vl-vh2zl-hdsvv-yunlj-k3asp-zsigu-cae UP
Europe Lithuania Vilnius 1 (bt1) Baltneta MB Patrankos ĆĄĆ«vis c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae UP
Europe Latvia Riga 1 (rg1) DEAC Ivanov Oleksandr eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel j6uir-h4bk3-chdqr-hxnkr-3jp7o-yb3el-skdsd-7oejj-eubk5-5onvy-zae UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae UP
Americas United States of America (the) Atlanta (at1) Flexential Goat, LLC lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae UP
Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe UP
Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae UP

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 :+1:

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). :-1:

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. :+1:

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
Continent Country Data Center Owner Node Provider Node Status
+++ Europe Switzerland Zurich 6 (zh6) Green.ch Sygnum Bank yzi7p-lnf22-u2wot-tgxzn-v3ubs-4yuqq-fywh7-4tkk7-ly2xh-r5byg-mqe UNASSIGNED
+++ Asia China HongKong 3 (hk3) hkcolo Power Meta Corporation zzuq4-xiygt-ypkox-2tgdr-yvpzp-optye-xazeq-vnpw5-pata3-4jlle-wqe UNASSIGNED
+++ Europe Portugal Barreiro 1 (ba1) Online Bitmoon g765q-rteh7-xio4e-vtyea-ww46p-beylc-3e3s3-yhvuy-in6jd-hj5qo-3qe UNASSIGNED
Oceania Australia New South Wales 1 (ns1) Latitude.sh Conic Ventures w7v5s-nethv-crfsc-zzq5e-gibjz-dmmyp-mrl6e-vkvid-g56eh-iilcm-eqe UP
Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank 3ojqg-v6jhs-frq5l-a3l7k-7xvhc-kolvz-2e4to-pdf4l-xiuem-h72b3-bqe UP
Europe Austria South Moravian Region 1 (bn1) Master Internet Lukas Helebrandt afu64-x2met-w2vxb-4lzus-z4fhf-divej-q46gf-wvpek-dj67h-fptsd-aae UP
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion wgxbt-4e5xm-lsyc6-kazar-7kvzj-7biff-vzt52-2hddx-h3ddg-pfd3n-iae UP
Europe Belgium Seoul 3 (kr1) KT Pindar Technology Limited mhfef-zbxsl-rocpc-ovqeh-jg3ct-7nvmi-gzpnm-xjmm4-uekgj-rquls-uqe UP
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs flzwv-lslut-uvzxu-nrlrj-64b4q-om4c6-amsu4-nswej-io3nd-4gkkg-6ae UP
Asia China HongKong 4 (hk4) hkntt Origin Game 6ricl-vwbej-yk73y-6ttjb-oefyv-cpjta-7ttqk-e4ucl-5rxsq-v2bag-zae UP
Americas Costa Rica Bogota 1 (bg1) EdgeUno Geeta Kalwani tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe UP
Americas Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe UP
Europe Germany Geneva 2 (ge2) SafeHost Archery Blockchain SCSp w2zci-bq5jo-vzrng-42mks-hvytn-she3z-52pej-vmigw-tic67-4prc6-qqe UP
Europe Spain Barcelona 1 (es1) Adam Carbon Twelve rq2bj-ek3yy-mjj6s-zewtq-zzke4-u4zix-tz2xd-xigpz-s5hih-4wpmt-iqe UP
Asia Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone fi2eu-lgaic-n73rv-dsfr6-52z3t-7eto7-pmdg7-r7o7n-agotm-zw6o5-tae UP
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS snwzs-jy7bs-y6t3i-kegus-3s5xm-ob7yz-bcje6-qjb2m-jgndt-5dvbl-oae UP
Asia India Navi Mumbai 1 (nm1) Rivram Rivram Inc 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae UP
Asia India New Delhi 1 (nd1) Marvelous Web3 DC Marvelous Web3 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase gbavy-dj3ok-jnmaa-pnbhh-sgxlp-gzcap-mt5ox-v5cml-eivtx-sodxc-vae UP
Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe UP
Asia Sri Lanka Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd shtwt-kuy74-afhyd-sivzp-nj3vl-vh2zl-hdsvv-yunlj-k3asp-zsigu-cae DEGRADED
Europe Lithuania Vilnius 1 (bt1) Baltneta MB Patrankos ĆĄĆ«vis c2ewt-wic55-asi27-6eoeu-rn7bq-xjzmz-dzxg2-pxrfw-qeinw-yrj52-7ae UP
Europe Latvia Riga 1 (rg1) DEAC Ivanov Oleksandr eqe4v-xnyd5-sqimm-7qxav-sxmuf-c5jjj-bpqq3-ccpso-g6jqf-2a4yo-bqe UP
Europe Portugal Lisbon 1 (li1) Dotsi Artem Horodyskyi u3ahx-ft3kq-pzlkr-imzus-aeqxm-cirqv-ymehh-xzctz-os4ud-3a74m-vae UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel j6uir-h4bk3-chdqr-hxnkr-3jp7o-yb3el-skdsd-7oejj-eubk5-5onvy-zae UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital mh6ne-3zycb-z4p45-lcfrf-lh6of-zelj3-7nuii-mzg7b-zi2ic-s67kx-6qe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG bkult-ic75e-xfviw-iyidh-tivyz-r7fvw-7r4xt-aawip-cp7vm-4iu2v-rae UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA irpwa-t65vg-ellmb-rg37m-ge5or-g3crz-3vbri-m4spq-eldkq-v2vs7-pae UP
Americas United States of America (the) Atlanta (at1) Flexential Goat, LLC lzveb-mlka7-ectcs-cqg44-him3y-vh6yf-q4vdo-7z45l-3o46m-64awc-5ae UP
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers sua4d-2yomd-7lnkd-6kumk-tzsqm-mv5dm-prpte-zjtqr-x3d63-bapf4-6ae UP
Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC xelcd-pogkb-lrtry-hfe4m-maxod-fwebb-3fvh7-6sb5b-vs2n2-fkaxz-yqe UP
Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd ntk4m-3jwml-24enm-akwhr-gps2m-xe36d-qlkd2-scgcu-qmjik-nrk3b-wae UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd e6334-h54qb-rfmfa-kktez-s5tjs-q2ihe-fazyk-ybuo5-leln6-v3cfi-dae UP
Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd jlifv-mddo3-zfwdc-x2wmu-xklbj-dai3i-3pvjy-j4hqm-sarqr-fhkq6-zae UP

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.

1 Like