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.
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.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
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
Subnet characteristic counts →
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.
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
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)
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.
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)
IC records consider this node to be in Switzerland (note that this record is not kept up-to-date, and reflects the original location)
@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.
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.
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.
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?)
@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.trap with 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.