Subnet Management - 4zbus (Application)

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.

4 Likes

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.

2 Likes

Proposal 134178

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

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

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:

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 Operator Node Status Performance
--- Europe Germany Geneva 2 (ge2) SafeHost Archery Blockchain SCSp 5atxd uvyny-tt2f2-rb743-fk6ia-qn6ut-c3qyb-ob3aw-6qcvm-qbktr-pco7n-2ae UP :bar_chart:
--- Americas United States of America (the) Portland (pl1) Flexential 87m Neuron, LLC lz4fy v7xli-jnnol-am5py-5stvp-ucmul-5y4kn-yy4tu-34xee-mgfnu-y3hfg-xae UP :bar_chart:
+++ Europe Czechia South Moravian Region 1 (bn1) Master Internet Bohatyrov Volodymyr sjstt kwict-ujiu6-u4ss3-nlwqq-dchsd-2h5lh-nzkke-24ij3-3otqq-rswre-vqe UNASSIGNED :bar_chart:
+++ Europe Poland Warszawa 3 (wa3) DataHouse Artem Horodyskyi ngpk7 qzvif-vpece-l4rga-6l6v7-tdegr-ycnty-p3zgo-qzghb-v5hmq-edjbv-lqe UNASSIGNED :bar_chart:
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion oorkg najnj-to3ju-pl6pl-5yjlc-6vdqi-f7tht-qd7tt-fenyr-f3tjc-tfj37-uae UP :bar_chart:
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i 2h6dm-k5h3n-nmqek-m5gty-yy3xq-a3atf-54its-biy25-ijh3c-xvit4-mae UP :bar_chart:
Europe Switzerland Zurich 5 (zh5) Green.ch Sygnum Bank 4ohfd c2vrr-ynjrh-xturt-s77ah-a5efo-b726x-dgq4a-m7zdc-wvsa5-7ogz5-mqe UP :bar_chart:
Europe Spain Madrid 3 (ma3) IPCore Vladyslav Popov f4rto oiso5-hxkkc-elqlo-iyoqg-7oux4-5mscl-zkvoh-b2432-ohrir-b5fcm-gae UP :bar_chart:
Asia Japan Tokyo (ty1) Equinix Starbase cqjev ktqjk-r6yho-cqgxd-qaqqn-yhxvl-ez6ax-jk3n4-bfa2f-vprkh-eigf5-5qe UP :bar_chart:
Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg 7agd5-pfc4g-rdozn-zajij-aax72-7jft2-rzw36-y3flc-xwt77-pjg5w-7qe UP :bar_chart:
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin jvqnq-6jnty-tr3ml-izvma-e5w6e-s3rfx-w4wir-mwcsf-x5yok-nc4uz-6ae UP :bar_chart:
Europe Slovenia Ljubljana 2 (lj2) Anonstake Anonstake eu5wc 5zqhj-66qn7-he3p5-76gnj-hlsvl-ajlt5-k356i-fgm4m-5it4c-6m5ag-7qe UP :bar_chart:
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA lgp6d ozim4-dez5l-gk24c-m7phw-e6i32-c7vxe-m6you-mkprj-moxq2-fhtyw-uae UP :bar_chart:
Americas United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC 5syyj cvic3-6mmjj-2zszr-mr727-im4l5-skwod-gzrg2-avd4i-bahw3-xyx3l-2ae UP :bar_chart:
Americas United States of America (the) Jacksonville (jv1) Tierpoint 9Yards Capital wmrev 7ak5q-ev3ur-nmmup-rocyw-z2kxo-bqppk-vkj22-gicfw-6h37b-cpvmc-uae UP :bar_chart:

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)

2 Likes

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.

2 Likes

@ZackDS has just pointed out to me that the removed node may actually be in Switzerland (not Germany). Thanks for pointing this out Zack :slightly_smiling_face:

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.

2 Likes

Well there are many ways to skin a cat so we could agree this could be either way.


A bit off topic for this subnet

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.

2 Likes

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.

1 Like

Proposal #134382 to enable the HTTPS outcalls feature is live.

2 Likes

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.

2 Likes

:point_up:
I’m with @timk11. Great points, and I’m only echoing them below.


Proposal 134382

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?)

1 Like

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.

2 Likes

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.

3 Likes

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.

3 Likes

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 ?

1 Like