Subnet Rental & Swiss Subnet

[Forreal]

The foundation should do a write up of this is.

[LightningLad91]

I scrolled down to the bottom and didn’t see it; going to look again.

In the meantime though; @diegop it might be worth speaking to your legal team about the use of “Skunk Works” at the bottom of the webpage that David linked.

Maybe there’s some legal loophole (or it’s genuinely acceptable usage) but figured I’d share the legal notice from Lockheed’s website for awareness sake.

Skunk Works® Legal Notice

Edit: On a brighter note; just wanted to say I think the subnet rental idea is great. Been seeing a lot of promising developments recently.

[oggy]

@skilesare

How do other subnets interoperate with these subnets with assurances that no funny business is going on as these subnets will likely have different security and risk configurations.

The DFINITY R&D team conducted a security assessment focused on the first use case of subnet rental, the Swiss subnet. We assess the risk of the rented subnet posing a threat to other subnets, canisters on other subnets, and the governance infrastructure as very low, basically comparable to all other 13 nodes application subnets given that:

1. it still consists of 13 nodes
2. the nodes are to be run by reputable, independent organizations, following the same node provider onboarding process as for all other nodes, and
3. their legal jurisdiction is Switzerland, where DFINITY can effectively sue for infringement of node provider self-declarations.

Therefore, we propose not to delay the project by adding proactive technical measures right now. It’s worth pointing out that the will be a subnet suspension mechanism in place for the NNS to activate. Any community member can use the existing monitoring infrastructure and submit such a proposal. The DFINITY foundation will monitor the situation and react should anomalies be detected. However, down the line, if subnet rental takes off and more subnets with different characteristics are added, we would like to see additional, proactive measures in place. In particular, we would like to address the biggest risk, a subnet fabricating cycles.

In terms of threshold ECDSA and other services that require cycles, these would run as usual. Subnet rental canisters who want to use tECDSA need to purchase cycles (on top of the subnet rent) that they can then use to make tECDSA management canister calls. This is no different to any other subnet and is in line with the rental model; tECDSA incurs load on other subnets, so it’s not included in the rent. HTTP outcalls would be free to the subnet’s canisters. There isn’t much risk to other subnets from this, and if anything goes wrong the NNS can disable HTTP outcalls dynamically, through a proposal.

[skilesare]

@oggy

. Any community member can use the existing monitoring infrastructure and submit such a proposal. The DFINITY foundation will monitor the situation and react should anomalies be detected.

Thanks for the detailed write up! For clarity, fabricating cycles would take a set of nodes colluding to install an alternative replica that fabricated the cycles?

[oggy]

@skilesare

For clarity, fabricating cycles would take a set of nodes colluding to install an alternative replica that fabricated the cycles?

Yep. The subnet would need to violate the main IC trust assumption, which is that there are less than 1/3rd of comrpomised (i.e., having the alternative, malicious replica installed) nodes in a subnet. In theory the subnet could double spend cycles already with >=1/3 of the subnet nodes compromised , but the attack is still difficult until 2/3rds of the subnet nodes are compromised, at which point they can start doing basically whatever they want easily.

[ic.aitubi]

@dieter.sommer

The Internet Computer at large benefits from rented subnets in that the rent paid corresponds to a 100% utilization of the subnet. This would increase the cycle burn rate for the IC considerably.

Does this mean that rent is constant and independent of the tenant’s actual consumption of storage and compute power?

[ic.aitubi]

@dieter.sommer

Node providers of such subnets are chosen by the NNS using the NNS-adopted node optimization framework (Proposal 125367 ). Special properties for such subnets are defined in terms of a target topology update for optimal fit for the intended use case, e.g., banks, NGO organizations like ISO or ITU, or universities, in order to obtain a more proof-of-authority-like consensus property in this subnet. As always, such target topology updates are proposed to the NNS for a vote.

Given that the tenant will be named and known, and it might be an entity safeguarding highly sensittive data, such as for example an NGO holding personal data of political refugees, how is the risk mitigated that a powerful nation state might exercise pressure on the tenant, or even DFINITY Foundation, to grant acccess to such data on the subnet?

[ruslanhuman]

Really Good news on New Yeras

[roel-storms]

@Severin

ICP shouldn’t need to be run like a for-profit business, but as a whole it should try to cover its total cost.

Over time, development cost is something that should also be compensated for. Not only NNS governance and subnet idle time. But atm, it would be a step in the right direction to have 100% utilization. It feels rather unfair to have a markup on these subnets where this is not the case for normal subnets.

[dfisher]

I disagree. A subnet rental is a different proposition to a public subnet. The public subnets exist as a public resource and are subsidized to get the network going. The subnet rentals are in essence semi private and should be profitable from the get go.

The projects always have the option to use a public subnet. They should pay a premium to be compliant and have full rental control over a subnet.

[michael-weigelt]

The rent is independent of the actual compute and memory consumption.
You may wonder why the tenant is expected to pay for the whole subnet then. One reason is that a Swiss subnet does not fulfill the decentralization goals, so regular canisters of regular users of the protocol should not be assigned this special subnet. Therefore, the tenant effectively gets exclusive access to this subnet (even if that may not be a strict requirement on their side), and should pay for all of the incurred costs.

[dieter.sommer]

@Sormarler

Why 13 nodes and not 6 or 30?why have these restrictions on optionality?

The proposal is to use a 13-node subnet as this is the same size as all the app subnets. The choice for app subnets is that it’s a sweet spot in terms of efficiency and security. Subnets should always have a number of nodes that is some 3*k+1 due to how consensus and the security model works. Not following this also works, but essentially is more wasteful.

Having any other size than 13 would work also in practice, but has not been the choice for the above proposal.

[osman]

What is the difference between renting a subnet and deploying a decentralized application on the ICP? My understanding is, By renting a subnet; In this subnet, the tenant can deploy any number of decentralized applications on this network by creating parameters according to his/her wishes.
However, the person or company running a decentralized application on ICP has accepted the existing parameters.

[dieter.sommer]

Indeed, renting a subnet gives you control over the resources of the subnet. You can deploy as many dapps on your rented subnet as you wish (and as the subnet can handle).

The rented subnet has been created by the NNS following the accepted IC topology. E.g., a subnet can comprise only nodes from one country, e.g., Switzerland, i.e., may be created according to different rules than a regular IC subnet. Is this what you meant with “creating parameters”?

[osman]

yes, that’s what I meant. Of course, the parameters that the tenant establishes in the rented network should not contradict NNS, the management layer of ICP.

[CoolPineapple]

So in general tailored subnets seem like a reasonable extension of the GDPR compliant subnet idea. There are just more criteria. Rental seems like a reasonable extension of a service guarantee pricing model.

I have no strong opinion but I would like to flag up a couple of narrative / philosophical points to ponder.

1. If I want to set up a proof of authority system with known parties then why not just contact those parties and run (a fork of) the software directly on those nodes bypassing the NNS and wider ICP ecosystem?

   The answer is I guess:

   (1) The software licence doesn’t allow it.
   (2) There are likely benefits from interoperating with the rest of the system.

   But note that “1” is going to play very badly on crypto twitter and it would be better if there was a strong security or technical argument, and this underscores the need for shared security to be on the roadmap.)

2. If I want to rent a subnet then it is likely that I want more control. So the NNS being all powerful with respect to individual applications on my subnet seems odd. Consider a federated NNS model where power and liability lie with the renter.

3. There may be legal issues regarding suspension and other NN activities which interfere with operation if the rental agreement is considered to be a legal service agreement.

4. Their may be other ways of give applications guaranteed performance and service quality e.g. being able to reserve a portion of an existing subnet rather than rent a whole one. (Polkadot have recently moved in that direction with parathreads. or perhaps simply being able to pay for priority in case of congestion might fulfil a lot of this user requirement. BTW there is a lot of prior art on cloud pricing).

   Going a little off topic: I think pricing, service level guarantees and demand management in general should be looked at more holistically. It would be a large project but everything from correctly pricing individual instructions/operations (See Ethereum project here) to demand management (e.g. priority & reservation), capacity management (including both when to expand overall capacity and flexing capacity with standby subnets/nodes, to capturing value from desired trade execution order (MEV in Ethereum terms).

[PCeID]

All firms in Switzerland are navigating the time and human capital required for compliance with the new Swiss Data Protection Law enacted in September 2023. Future Swiss tenants will soon realize the cost savings of renting a Subnet to comply with both GDPR and the nFADP.

According to the EU Commission, GDPR applies only to the processing of personal data of natural persons in the EEA and EFTA by individuals, businesses, or organizations. Chapter 3 of GDPR (Art. 12-23) ensures European residents have the right to control their personally identifiable information online—explicitly limiting solely automated data processing by smart contracts without prior consent.

A Canister virtual instance hosted on a Swiss Subnet may fulfil Art. 22 by complying with the ePrivacy directive and the “right to be forgotten” obligations outlined in Art. 17. That would also provide Art. 16, 20, 25 and 26 compliance, automating the ‘Purpose Limitation’ under Art. 6(4).

Per Art. 42/43 of GDPR, the Swiss service provider’s boundary nodes would (then) be interoperable with the EBSI distributed-node hardware. This is a prerequisite for applying for the EU Cybersecurity Act Framework certification and aligns with the Swiss Confederation’s 2023 revision of the E-ID Law for a national digital ID adoption by 2026.

[georgi]

If I want to set up a proof of authority system with known parties then why not just contact those parties and run (a fork of) the software directly on those nodes bypassing the NNS and wider ICP ecosystem?

The idea to be able to creat private ICP instances or as Dom calls them private Cloud 3.0, is out there. It is under the codename Utopia and is mentioned in the deck on slide 60. I don’t have the details how that would work but from what I’ve heard from Dom it is close to what you’re describing.

If I want to rent a subnet then it is likely that I want more control. So the NNS being all powerful with respect to individual applications on my subnet seems odd.

With subnet rental one gets more control (e.g. control which canisters are being installed on the subnet) but not full control. It is a model that may work for some applications, yet turns to be too restrictive because one needs to play according to the rules imposed by the NNS. The private clouds idea is probably better suited for entities that wants a 100% control over the network, including where it runs.

[BANG]

This all sounds really amazing. It appears that their is a need for digital land/territories and the representation of tenant and leases lexicon in subnet rental governance can be considered such.

I am excited for the following features;

• 100% utilization of the subnet is awesome. 100% occupancy is rare in commercial real estate. The benefits of 100% occupancy cannot be understated for deflation and developers that can create financial models thereof.

• Localization is a non threatening compliance model that has huge benefits for adoption.

• “Multiple community members have expressed interest in renting an entire ICP subnet.” Great way to begin a discussion of a proposal.

I do have a few questions:

Could their possibly be a master lease holder of a subnet?
How long is the termination proposal process?
Can you disclose if the “community members” interested include industry?

[michael-weigelt]

Could there possibly be a master lease holder of a subnet?

A rental agreement is officially between a tenant principal and the NNS. That principal is provided in the request proposal and only that principal will be whitelisted to install canisters on the rental subnet. It is then up to the tenant to manage access to other principals.

How long is the termination proposal process?

If termination becomes necessary, the community can choose what measures are appropriate for the specific situation. Ideally, the subnet is not in suspension longer than a few days or weeks.

Can you disclose if the “community members” interested include industry?

At least one business entity is interested in renting a subnet located in Switzerland.