We are a few years into the Internet Computer’s life and Motoko’s base library still has a warning for ExperimentalCycles.
Do I really need to be worried about this going away entirely or changing dramatically? I understand that DFINITY is working on a cycles ledger; but, this experimental library is all we’ve had for the longest time and I find it hard to believe this could be removed without breaking a bunch of apps.
I’m also concerned about losing the ability to simply send and receive cycles between canisters. I’d really hate to have to send an async request to and from a ledger like we do to transfer ICP.
Thank you for addressing my question @claudio. I’m still confused on the difference between deprecating something and it disappearing entirely.
In my case, I’m building a dapp that will archive all of its transactions in ICRC3 blocks. These blocks will be stored in blackholed canisters to prevent tampering. I’ve developed a Motoko library that allows the parent canister to monitor and distribute cycles to its children. Both the parent canister and the children will rely on the ExperimentalCycles lib.
Do I need to be worried about my archive canisters breaking because the underlying replica no longer supports the methods that make ExperimentalCycles work?
Edit: For context, this is the warning that causes me anxiety. I could be overthinking it, but the fact that it refers to a “low-level API” disappearing is what has me worried about my immutable canisters.
As far as I know, there’s no plans to remove the ability to send cycles with canister calls in the protocol. All we might change is how we surface this in the Motoko language.
Cycles.add(1000);
receiver.send();
might become (just a sketch}
receiver.send() with [#cycles 1000];
coupling the cycle addition more closely with the call instead of using a side-effect some distance before the call.
This actually looks really convenient and coupling cycles addition to the call like this seems safer.
Is it your hope that you can do something similar for accepting cycles and checking the canister’s balance as well? It seems like this would remove the need for a separate library altogether.
