Subnet Rental & Swiss Subnet
Dear ICP community!
Multiple community members have expressed interest in renting an entire ICP subnet. There seem to be sufficient use cases that justify the introduction of subnet rental on the Internet Computer. Subnet rental means that a whole subnet can be rented by a tenant (a person or company). The tenant gets exclusive access to the subnet and its resources and has to pay the full expenses incurred by running the subnet, i.e., the full node provider rewards incurred by the operation of the subnet.
Subnet rental is particularly interesting to allow for subnets that are tailored to the needs of the tenant, e.g., in terms of decentralization, security properties, and countries where the data processing is performed. Subnets tailored to the needs of a tenant can help realize beneficial properties for their tenant, as for example:
- All subnet nodes are located in one specific country or region, e.g., Switzerland. This can be important to reach regulatory compliance or cater to the reputation of a specific country, Switzerland in the example, as a highly stable and reliable country.
- 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.
- All together, such a subnet can realize specific high-security or compliance requirements thanks to the combination of factors determining their setup.
It is important to note that the selection of node providers, data centers, and nodes for the subnet is done by the NNS and not the tenant, thereby following all the basic rules of ICP.
Note that such tailored subnets currently do not fit into the overall ICP decentralization strategy which decentralizes every subnet as aggressively as possible on a global scale. Thus, they make only sense in the context of subnet rental.
More general advantages of rented subnets are discussed next:
- Guaranteed performance and service quality for the tenant as the general public cannot deploy canisters on this subnet and thus subnet resources such as ingress capacity, compute, and storage do not need to be shared with others.
- 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.
- The Internet Computer becomes a platform that can host a wider variety of applications, namely such that would not be eligible to run on the typical subnet of the IC, e.g., due to the countries nodes are located in. This argument is mainly regulatory driven.
- Help grow ICP overall by admitting new classes of use cases and create positive traction for the whole ecosystem.
Using Web 2 for an analogy, one can see subnet rental as analog to having a dedicated machine in the Web 2 setting instead of using cloud computing with collocation of random clients on the same machine. Similar advantages apply in Web 2 as do on the Internet Computer, namely security and guaranteed performance and resource availability for the tenant. The same drivers that motivate dedicated machines in Web 2 motivate subnet rental in Web 3 on the Internet Computer. Following this line of argumentation, there is a clear use case for subnet rental.
How can subnet rental be realized?
A main tenet of subnet rental is that rent is paid by the tenant, giving the tenant exclusive access to the subnet and that canisters deployed on a rented subnet do not need to pay cycles for their operation. The subnet is let to a tenant principal corresponding to an entity (person or business) that wants to use the subnet for their projects.
Prerequisite: Availability of a subnet to rent
As a prerequisite, a subnet for rent must be available. This is achieved via the ICP topology model which strives to establish a target node topology for the Internet Computer, thereby also including the subnets that are for rent. The currently adopted target topology already contains a 13-node Swiss subnet, for example. Note that the Swiss subnetâs âSubnet limit countryâ parameter, i.e., the maximum number of nodes in a single country, has been wrongly set to 2 and needs to be set to 13 in a future proposal to make a single-country subnet work.
In the general case, a prospective tenant would make an NNS proposal to update the ICP topology model to contain the subnet they would like to rent later.
If such a topology proposal gets accepted, the subnet needs to be established, be it by means of nodes of existing node providers or new node providers bringing in new nodes to the network according to special requirements of the to-be-established subnet, e.g., nodes in a specific country or region. All of this fully follows the regular NNS-driven processes of node provider onboarding, data center onboarding, and onboarding of new nodes, and finally the creation of a new subnet, in this case flagged as a for-rent subnet.
The above is orthogonal and necessary, but not part of the actual proposal for subnet renting. In the remainder of the discussions, we assume that the subnet to be rented has been made available as outlined above.
Required technical components
A simple and non-invasive way for implementing subnet rental on ICP is to realize the required logic as part of a Subnet Rental Canister (SRC) that is running under the control of the NNS on the NNS subnet. This canister must handle the conclusion of a subnet rental agreement, the initial and periodic billing, the offboarding in case a tenant wants to move off the subnet, and possible service suspension in case of rent not being paid.
Process of renting a subnet
The process for a tenant to rent a subnet that has been made available with an ICP topology change and node provider, data center, node onboarding, and subnet creation is described next.
Deposit by the tenant
A prospective tenant makes an ICP deposit to a publicly known address controlled by the SRC, specifically to a subaccount derived from the tenantâs principal and the id of the subnet in question. The amount of ICP transferred must cover the subnet cost for an initial rent duration (e.g., 6 months) and is calculated from the current ICP/SDR exchange rate and a set price per day. Due to exchange rate fluctuations, the real duration of the initial period may be shorter or longer.
Note: Subnet rental must be economically viable for the Internet Computer, including that it must be guaranteed that a subnet that is specifically created for the intention to be rented, with specific properties regarding node providers, data centers, and decentralization, generates rent for the defined initial duration and is not abandoned by the tenant a short time after being rented out. For this reason, the proposal above mandates a prepayment of the rent for the subnet upfront to cover the subnet cost for this initial period.
NNS proposal for renting the subnet
The following steps include the tenant making an NNS proposal for renting the subnet and the actions triggered by this proposal as outlined next.
- The prospective tenant makes a payment to the subaccount derived from their principal and the subnet id.
- They create a subnet rental request NNS proposal (this is a new proposal type), containing their principal, a list of other principals to be whitelisted and the subnet id of the subnet to be rented.
- The governance canister validates the proposal by checking that no other proposal of this type exists.
- The proposal is opened up for a community vote.
- After the community vote, the proposal executes code on the SRC:
- If the community rejects the proposal or the proposal is invalid due to a bad subnet ID or insufficient funds, the request is archived as rejected and the rejected tenant can call a refund method on the SRC.
- If the community adopts the proposal, the SRC performs the following actions:
- The SRC calls an existing method on the CMC (Cycles Minting Canister) to whitelist the tenant principal to be allowed to deploy canisters on the rented subnet.
- The SRC creates and persists the rental agreement, and starts the billing process.
From this point on, the tenant principal has the sole authority to deploy, run, and manage canisters on the subnet.
Billing
Billing for the initial rental period
At the start of the billing phase for the rental agreement, the initial deposit is transferred to another subaccount, derived from the subnet id only. It is now no longer refundable and will start to be burned.
Billing after the initial rental period
A subnet that can be rented is assigned some additional parameters related to subnet renting during its creation; examples for those parameters are given next:
daily_cost
: 1000 XDRinitial_rental_period
: 183 daysbilling_period
: 30 dayswarning_threshold
: 60 days
After the initial deposit is used up (this should be approximately after the initial rental period, but may happen sooner or later due to exchange rate fluctuations), the tenant is expected to regularly transfer ICP to their subaccount on the SRC. It should be ensured that the rent for the next period, e.g., month, is covered to avoid service interruption. There should always be enough ICP available in the rent account to cover the subnet cost for the warning_threshold
time period to avoid warnings. The warning status can be queried via API, so warnings are pull-based.
The SRC runs the following billing process periodically:
- This process withdraws an amount of ICP from the rent address every billing period, e.g., every month, to cover the rent for the upcoming period. In the above subnet configuration example it would withdraw ICP worth 1000 SDR from the rent account every month. The withdrawn ICP are converted to cycles and burned. In this success case, the output of the billing process is
active
, meaning that the subnet state is active and the subnet should continue normal operation. - In case of insufficient funds being available on the rent account, the output of the billing process is
suspended
, meaning that the subnet is in suspended state.
Service suspension
If insufficient ICP is available on the rent account to cover the subnet operation, services are suspended. This state is reversible and can be lifted by the tenant by paying. If the services are suspended for too long, a community member may create a rental termination proposal. Service suspension means that update calls and / or query calls are blocked on the whole subnet.
Termination of a rental agreement
After the prepaid initial period, a tenant can terminate a running rental agreement by creating a rental termination proposal. During the execution of this proposal, the subnet is purged and brought into a state where it is ready for rental again.
Details to the processes of service suspension and termination of rental agreements still need to be worked out in detail, but should follow best economic principles and the best interests of the Internet Computer.
Swiss subnet
A Swiss subnet, henceforth also referred to as S2, comprising 13 nodes is intended to be constructed and rented as a first use case of subnet rental. The community has already accepted the âSwiss subnetâ in Proposal 125549, note, however, that the âSubnet limit countryâ parameter is wrong and needs to be set to 13 in a future proposal as all nodes will be in a single country. Node provider (NP), data center (DC), and node operator onboarding shall be done as per the NNS-approved node optimization model (Proposal 125367).
There are already concrete plans about which projects to host on the subnet. Details on the projects can not yet be presented to the public, but what can be said is that the Swiss subnet helps reach regulatory, security, and trust constraints for those use cases. Also, a fully Swiss subnet is appealing to some of the projects intended to be hosted due to the excellent reputation Switzerland has.
Conclusion
In this post, we have outlined how subnet rental can be introduced to ICP. We have several next steps on our mind to progress the work on subnet rental:
- We would like to ask the community for feedback and ideas on this proposal. The request for feedback comprises both the general concept of subnet rental as well as the concrete proposed realization.
- Based on the feedback, we will consolidate the proposal and converge it to have (at least) rough consensus in our community.
- Once (rough) consensus has been achieved, we would proceed with a motion proposal with the following goals:
- Asking the community whether subnet rental should be implemented;
- Modifying the target topology for the Swiss subnet to change the âSubnet limit countryâ from 2 to 13.
We are looking forward to your valuable inputs and to having a lively discussion on the topic of subnet rental!