Thanks @dsharifi. This subnet is processing 0 transactions per second, with 0 instructions executed per second. Yet blocks are being produced (at a rate of 1.28 per second). Please could you clarify how there can be new blocks without instructions being executed or transactions being processed?
These metrics don’t make sense to me. Please would you be able to offer some clarity before raising this proposal?
@Manu, sorry to keep poking you and @dsharifi. Please let me know if I should be directing my question above elsewhere. Does this just come down to a rounding issue or something (i.e. there are instruction and transactions, hence the blocks, it’s just there’s too few for the dashboard to display)?
Blocks are created irrespective of whether there are messages to be included. This makes sense because at the time of block making, we don’t even actually know if there is stuff to execute, because not everything comes in via blocks, canisters can also do work on their own via heartbeat or timers. We need to regularly have a new block to trigger a new execution round which then may execute those heartbeat/timer messages.
Wrt why this subnet has essentially no load: not all subnets are made available by the CMC, and this is one where you cannot install canisters without an NNS proposal allowing you to do so. This is some legacy thing where around launch time, some projects had designated subnets. I hope we can get rid of that, but before we can do that, we need to make sure that all these subnets are equivalent, and currently these weird subnets allow for some legacy features which other subnets don’t.
Thanks @Manu, this is very helpful info.
Is this related to which principals are allowed to deploy canisters to the subnet, or some other aspect? I’d be interested to know more. It would be good to be able to detect which subnets are affected. Are you saying that there is load on the subnet, but it’s invisible to the dashboard?
Voted to adopt proposal 134178, as the reasoning is sound and the description matches the payload. This proposal replaces 2 healthy nodes, both of which appear as “Active” on the IC dashboard. The proposed change improves decentralisation with respect to country and brings the target topology parameters to within the requirements.
TLDR: I’m planning to adopt. This proposal brings the subnet inline with the IC Target Topology, by reducing the max number of nodes per country from 3 to 2.
It does however increase the max number of nodes per continent from 7 to 8 (but continents are not a formal part of the IC Target Topology).
Motivation:
- replacing node v7xli-jnnol-am5py-5stvp-ucmul-5y4kn-yy4tu-34xee-mgfnu-y3hfg-xae to optimize network topology
- replacing node uvyny-tt2f2-rb743-fk6ia-qn6ut-c3qyb-ob3aw-6qcvm-qbktr-pco7n-2ae to optimize network topology
A German and US node replaced with 2 nodes in Poland and Czechia.
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 300.075 km | 6388.743 km | 16464.988 km |
| PROPOSED | 449.292 km (+49.7%) | 5894.874 km (-7.7%) | 16464.988 km |
| Continents | Countries | Data Centers | Owners | Node Providers | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 3 | 11 | 13 | 13 | 13 | 13 |
| PROPOSED | 3 | 12 (+8.3%) | 13 | 13 | 13 | 13 |
This proposal slightly improves decentralisation in terms of jurisdiction diversity. 
| Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 7 | 3 | 1 | 1 | 1 | 1 |
| PROPOSED | 8 (+14.29%) | 2 (-33.34%) | 1 | 1 | 1 | 1 |
See here for acceptable limits → Motion 132136
The above subnet information is illustrated below, followed by a node reference table:
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.
Another good neuron to follow is 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)
Voted to adopt proposal #134178.
The proposal replaces 2 healthy Active status nodes form Portland, US and Geneva 2, CH in order to optimize network topology.
@ZackDS has just pointed out to me that the removed node may actually be in Switzerland (not Germany). Thanks for pointing this out Zack 
Looks like another case of IP address geolocation being inaccurate for certain providers.
@SvenF are you able to provide any further clarity on this one? If it weren’t for the WHOIS lookup, I’d expect that Switzerland is the correct country, but given the WHOIS lookup and api.ip2location.io, I’m not so sure.
Well there are many ways to skin a cat so we could agree this could be either way.
Regarding update of records specially from the IC Dashboard the provider is listed as Archery Blockchain SCSp located in Switzerland as well as all his 46 nodes but their listed website seems to be MIA, and a Google search places them in Luxembourg.
Voted to adopt proposal 134178. The proposal replaces two nodes from subnet 4zbus:
Removed Nodes: v7xli, uvyny.
Added Nodes: qzvif and kwict.
The proposal was verified using the DRE tool to verify the metrics stated. All nodes replaced are healthy but this replacements improve the network topology on the country metric.
Proposal #134382 to enable the HTTPS outcalls feature is live.
Voted to adopt proposal #134382.
The proposal is set to enable the HTTPS outcalls feature by setting http_request to true, as we can see it is currently disabled.
Voted to reject proposal 134382 as insufficient information is supplied in the proposal text. The proposal is to enable the HTTPS outcalls feature on subnet 4zbus but no further explanation or reasoning is given and no forum post link is provided. An explanation might include whether this feature should usually be enabled on all subnets and if so, why it wasn’t enabled on this one, or other relevant considerations. There is an opportunity to discuss this in the forum now, but the proposal itself should serve as a record of the considerations involved in making the proposal and this will not be possible given that no link has been included.
I’m with @timk11. Great points, and I’m only echoing them below.
What happened to the established workflow, proposer 48? This isn’t the first time for subnet management proposals →
I don’t think proposals like this are conducive to effective decentralisation, and responsible voting behaviour, so I’ll be rejecting this proposal.
There are currently only 4 subnets that have the HTTPS outcalls feature disabled.
If this proposal executes (and the other open one), the NNS and SNS subnets will be the only subnets with HTTP outcalls disabled.
Some important context for these proposals are, why are HTTP outcalls currently disabled on the two application subnets and why is this feature now being enabled? (and how should voters know where to turn for an explanation when they see this proposal in the NNS dapp?)
Just posting this for reference, this subnet was recently made public.
@Lorimer @timk11 There was no particular reason that HTTP outcalls were not enabled on application subnets 4zbus and 2fq7c, it was just oversight that it was never enabled. This only recently became apparent because 4zbus became public and users noticed that outcalls were disabled.
I agree that the description of the proposal is rather succinct, and we could add more context in the future.
Since we definitely want HTTP outcalls available on all application subnets, DFINITY will vote to adopt 134382 and 134383.
Voted to reject proposal 134382. Completely agree with @timk11 stance on this and would like further clarification on this. It seems that the proposal Failed even though it was adopted so I think this might be a good opportunity for DFINITY to better expand on this topic.
Thanks for pointing this out @LaCosta. Curious that the error message indicates that sev_enabled was being changed by the proposal when in fact the property was NULL in the payload (which should be a no op).
Error executing ExecuteNnsFunction proposal. Error Code: 5. Rejection message: IC0503: Error from Canister rwlgt-iiaaa-aaaaa-aaaaa-cai: Canister called
ic0.trapwith message: Panicked at ‘[Registry] Proposal attempts to change sev_enabled for Subnet ‘4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe’, but sev_enabled can only be set during subnet creation.’, rs/registry/canister/src/mutations/do_update_subnet.rs:269:9. Consider gracefully handling failures from this canister or altering the canister to handle exceptions. See documentation: Execution errors | Internet Computer
The proposal for 2fq7c succeeded, despite the same conditons. Both subnets have sev_enabled set to false, and both proposals had this property nulled out.
@Manu, do you have any insight into this discrepancy?
It looks like this is a bug in the registry. On subnet 4zbus, the features struct was null, and in that case somehow the registry incorrectly does not let you update the subnet features. On subnet 2fq7c, the features field was set. So the registry would need to be updated and then we need to resubmit the proposal to enable outcalls.
As far as I can tell and can be seen in the screen capture from 5 days ago the features was set to false and was not null ?
