TL;DR: We present the high level design for phase 2 of the subnet rental feature, that allows to
- turn rental requests into rental agreements by creating a new subnet and
- enables regular payments for the subnet
Hi all,
as some of you might have noticed, by the recent release of the subnet rental canister, we have picked up work again on the subnet rental feature.
This second phase contains the following main parts:
- establish a rental agreement by creating a new subnet that is rented
- introduce regular billing for a continued rental agreement
In this post, we share the high level design for the two parts after a quick recap of what already happened in phase 1.
Background Phase 1
The subnet rental canister already allows a user to make an initial rental request, including a payment that covers the first rental period. The request can be made by submitting an NNS proposal.
If this is successful, the subnet rental canister stores a rental request and some portion of the ICP initial payment is regularly locked by converting the ICP to cycles.
Phase 2
Once there are enough nodes for the creation of the subnet, the user who has a valid rental request from phase 1, can ask the NNS to turn this rental request into a rental agreement. This will create the subnet and allow the user to install canisters on the new subnet exclusively.
The original payments from phase 1 cover the first months of the rental agreement. After that, to keep using the subnet, the user then needs to regularly provide more ICP.
Create a new subnet to be rented
- There is a new proposal to create a new subnet for rental
- Upon proposal adoption,
- the subnet is created and this information is stored in the registry.
- To reflect that this subnet is rented, the registry records a flag with the subnet indicating that this subnet does not need to pay cycles.
- the subnet rental canister checks that there is a rental request and turns this into a rental agreement
- the subnet rental canister converts all of the ICP remaining from the initial payment into cycles (refunds are no longer possible)
- it is ensured that only the user who made the payment can deploy canisters to the newly created subnet (this is done by setting the permissions accordingly in the cycles minting canister).
- After the rental agreement is established, the subnet rental canister regularly burns the remaining cycles.
Subnet rental payments beyond initial period
To keep using a subnet beyond the initial rental period that is covered by the rental request, a user has to regularly pay for the rented subnet.
To do so,
- A user can send ICP to the subnet rental canister and inform the subnet rental canister that a payment was made by a dedicated API.
- Upon this call, the subnet rental canister will convert all ICP on the user’s account to cycles.
Conclusion and next steps
We have started working on phase 2, which includes work on:
- subnet rental canister (initial subnet creation, regular payment)
- governance (new proposal)
- registry (new flag for subnets to indicate they don’t use cycles)
- cycles minting canister (give the renter exclusive access to the subnet)
- execution layer (making sure that when a subnet has this flag, canisters don’t use cycles).
As we proceed with a more detailed design and implementation, we will update the community on this thread. For example, we will soon share the details of the new NNS proposal so that all frontends can prepare to show this proposal.
Let us know if you have any questions or feedback and have a great day!