Canister Cycle Limits and Burning Cycles 😬?

Hazel · March 2, 2021, 2:26pm

Hey all! Can anyone shed some more-official light onto how many cycles a canister can hold? I’ve been experimenting it looks like 10^14.

I’m working on a goofy recreation of the “Million Dollar Homepage”, and my plan was to let “users” buy pixels by sending Cycles along with their request. It all works, but since the canister the full once you deploy to your local replica, all the cycles I send just get refunded.

Is there a way to burn cycles that isn’t just executing a big for loop? Maybe a way to extract cycles from a canister? Or, maybe just a way to configure how many cycles the canister is deployed with?

claudio · March 2, 2021, 9:14pm

Have you seen this documentation Managing cycles :: Internet Computer?

I suspect your code needs to add a call to ExperimentalCycles.accept(amount : Nat) : Nat to actually accept the funds sent on the call - unless explicitly accepted, the funds will be refunded.

To transfer funds with an intercanister call, call ExperimentalCycles.add(amount : Nat) : () before making the call.

I’m not sure how to arrange for a JS call to transfer funds from the user wallet to your service, but hopefully someone else can answer that one (and your other questions).

Best,
Claudio

Hazel · March 3, 2021, 12:32am

Hey @claudio !

I have! The issue I’m having is the canister refunds most of the cycles I send, because I believe I’m at the canister’s cycle capacity already.

claudio · March 3, 2021, 2:16pm

Ah, sorry, I didn’t read your question carefully enough.

I’m not aware of any way for dfx to specify the initial cycle allocation for a local install.

As a workaround, which is kinda slow and expensive, you can get your actor to dynamically install a dummy canister using an actor class that you either discard or let hang around. Any cycles you put on the actor class instantiation will be transferred to the fresh canister and die if and when that canister is deleted, freeing up capacity in the main canister.

This repo provides two methods, burn and burnFast, One is slow because it creates and destroys the other canister, requiring more rounds of concensus. The other is fast, because it just leaks the fresh canister after transferring the cycles.

Clearly, this is a hack.

Hazel · March 3, 2021, 3:00pm

@claudio thank you so much - This Perfect!’

Also,

github.com

crusso/burn/blob/main/src/burn/Canisters.mo

import Principal "mo:base/Principal";

module {

   // Bind select methods from the
   // system ManagementCanister at the well-known address 
   let ic00 = actor "aaaaa-aa" : actor {
     stop : Principal -> async ();
     delete : Principal -> async ();
   };
    
   // Destroy a canister (and burn its cycles)
   public func destroy(a : actor {}) : async () {
     let p = Principal.fromActor(a);
     ignore ic00.stop(p);
     ignore ic00.delete(p);
   };

}

Didn’t know about these management canister functions. Woo!

claudio · March 3, 2021, 3:17pm

I’ve cleaned up the examples a bit and added a third method:

burn just creates a new actor, passing cycles to it, but doesn’t cleanup the new actor;
burnBetter uses the system’s management canister to additionally delete the temporary actor.
burnBest uses the system’s management canister to just create and delete an empty canister, without even installing a Motoko actor (or requiring a dummy Motoko actor class).

github.com

crusso/burn/blob/main/src/burn/main.mo

import Principal "mo:base/Principal";
import Cycles "mo:base/ExperimentalCycles";

import Lib "Burner";

actor {

    public query func balance() : async Nat {
        Cycles.balance();
    };

    public func burn(amount : Nat) : async (Nat,Nat) {
        let pre = Cycles.balance();
        // instantiate an dummy actor, passing cycles
        Cycles.add(amount);
        ignore Lib.Burner();
        // works, but leaks the Burner instance on the network
        return (pre, Cycles.balance());
    };

This file has been truncated. show original

claudio · March 3, 2021, 4:47pm

I’ve been told that dfx 0.6.24 will let you specify cycles on dfx canister create and dfx deploy, so you can avoid the hack.

paulyoung · May 16, 2021, 7:01am

Is there any documentation for the limits on cycle allocations of canisters on the Mercury network?

Topic		Replies	Views
Lost all my cycles when deploying to the network Developers	5	604	June 30, 2021
Terminal says I don't have enough cycles, but I do. Help? Developers	5	1085	October 19, 2023
How do cycles work with asset canisters Developers	5	967	May 21, 2021
Canister burning through cycles Developers	43	1980	August 4, 2022
What is the Cycle Burn Rate capacity as of today? DFINITY	2	67	December 20, 2024

Canister Cycle Limits and Burning Cycles 😬?

Related topics