I’m a bit surprised that principals aren’t allowed to deploy canisters themselves and wondering if anyone knows the reasons and maybe the possible benefits for this.
Also, curious if a
wallet canister cycles wallet runs out of cycles if it’s possible to lose access to all the canisters it controls? Can the principal which is the controller of that wallet canister revived it and regain access to their canisters?
Edit: A trivial reason that comes to mind is having more complex access control for a canister ie. upgrade under certain conditions etc
I think there’s some name confusion… Are you talking about the cycles wallet? I don’t know of anything called canister wallet. Assuming you are talking about the cycles wallet:
The cycles wallet is not required, and you are allowed to create/deploy canisters without having one. You can do so using
dfx ledger create-canister, which will take ICP and create a fresh canister by converting the ICP into cycles.
Having a cycles wallet is, however, the default way to work on the IC because…
- Only canisters can hold cycles, principals cannot. If you want to delete a canister and not lose existing cycles, you have to withdraw them somewhere. This is where the wallet is used.
- Without a wallet, sending cycles around is technically possible, but in practice too cumbersome to do.
- When you create canisters from your wallet, these canisters are created on the same subnet as the wallet is. This makes it faster to call functions on your other canisters because the messages don’t have to go through the XNet protocol.
- Since principals cannot hold cycles, only canisters can initiate function calls that contain cycles. While this is not an extremely common scenario, it is still common enough that most developers will end up doing so at some point. The wallet makes this very easy.
There’s also some more information on the cycles wallet here: Default Cycles Wallet | Internet Computer Home
He might be referring to the capability of canisters to hold ICP (ie “Canister Wallet”).
It also sounds like he’s under the impression that each wallet = 1 canister. (Would this assumption be true? I can think of reasons why it could be and couldn’t be true ahah!)
If we’re talking about the cycles wallet, then yes, this is true. A cycles wallet can, however, have multiple controllers (or authorised users) at the same time. So you could use the same wallet for multiple people or multiple identities at the same time.
If we’re thinking of what you call “Canister wallet”, so canisters holding ICP, then no. Calls to Ledger (the canister that does ICP accounting) always contain a principal plus a subaccount. The subaccount can be an arbitrary string and is meant so that anyone/anything can hold multiple separate accounts at the same time.
@Severin I was indeed talking about the cycles wallet.
I’d appreciate any insights about the second part of the question above about what happens if the cycles wallet runs out of cycles.
Have a look at the Interface Spec here: The Internet Computer Interface Specification | Internet Computer Home
Afterwards the canister is empty. It can be reinstalled after topping up its balance.
Once the IC frees the resources of a canister, its id, cycles balance, and controllers are preserved on the IC for a minimum of 10 years. What happens to the canister after this period is currently unspecified.
Cheers! I haven’t seen that part of the spec yet.
There’s one last question about this.
What about the case where a canister is the “controller” of another canister? Does this means that the child canister won’t be able to start again or it’s possible to reinstall the WASM module from the parent canister directly?
If the wallet is the sole controller of a canister, then yes, access to the child canister stands and falls with access to the wallet. But it is also really easy to set a new list of controllers (or already set the list when creating the canister) so that not only the wallet but also your personal principal are both controllers.
In case you decide to work with dfx to add/remove controllers, make sure you understand the difference between
dfx canister update-settings --controller and
dfx canister update-settings --add-controller. We’ve had some (almost?) accidents with some people confusing these commands this week.