Allow canister to query its own cumulative cycle consumption

Developers
1

I’m building out a protocol called Open Value Sharing (previously called Cycle Compensation or Cycle Sharing).

You can read more about the foundations of the idea here: Cycle Compensation

To get an MVP working, the idea is for Azle to set a timer off on init/post_upgrade of a canister. Keep in mind that this needs to be a general-purpose solution. Azle will be providing this functionality automatically for all Azle canisters.

The timer will go off on some period, like every day. When the timer callback executes, it will loop through the dependencies of the canister (obtained during a build step from node_modules/package(lock).json) and send some cycles to the registered principal of those dependencies.

I think this will work okay as an MVP without protocol changes, at first…but one major limitation is measuring cycle consumption. I really think it would be great to have the payouts be based on the amount of cycles burned between timer callback executions. But there is no way to accurately get this in a general manner, as top ups can’t be easily accounted for as far as I know.

I propose that the IC APIs be extended to allow a canister to query its own cycle consumption over a period of time. This would allow the payout amounts to be easily calculated based on actual cycle usage of the canister.

@ulan @Severin

6 Likes
2

I think if you put something that aggregates the performance counter in a place like #[update] before the result is returned you could get a pretty decent estimate. It wouldn’t cover storage cost, but that could also be handled in the timer where you can read how many memory pages are currently reserved

3

Perfect timing!

The Execution team is working on its roadmap for the next few months and one of the items we’re planning to work on is what we’re calling “better insights for cycles and instructions consumed”.

We will be adding the ability for a canister to get a breakdown of cycles consumed by use case (e.g. for executing code, storage, making inter-canister calls, https outcalls, signing with tECDSA, etc). With this you can also compute the total cycle consumption that you seem to be interested in for your use case.

5 Likes
4

Perfect! I’m excited for this. Would you mind posting the thread or other central place to discuss this once you have it?

2 Likes
5

We have not begun the work of scoping yet but I will definitely make sure we discuss this in a public place (others have also expressed interest from the community to participate).

2 Likes