Add system API endpoints for cycle cost calculation

[michael-weigelt]

Design Doc

[github-actions]

🤖 Here's your preview: https://c4y23-xqaaa-aaaam-abayq-cai.icp0.io

[mraszyk]

Could you please also add functions into the formal semantics: the actual return value can be abstracted over as arbitrary(), but the rest should follow, e.g., ic0.canister_cycles_balance128.

[michael-weigelt]

is this benchmark using serde_bytes for decoding Vec?

I measured the instructions on a canister that turns a Vec into a struct using candid::Decode!(). Whether candid uses serde_bytes itself, idk.

this complexity can't be avoided, it can only be pushed to the CDKs

Yes. But there, the precise call type is already known without inspecting a blob.

[mraszyk]

I measured the instructions on a canister that turns a Vec into a struct using candid::Decode!(). Whether candid uses serde_bytes itself, idk.

serde_bytes are used if the type you want to decode contains corresponding serde_bytes annotation. Could you please share the type definition you're decoding to?

[oggy-dfin]

So we would buy extensibility with 1) more complexity in the impl and 2) more costs to the caller. But is extensibility really worth that? I would consider adding a new system API endpoint of an existing type is a small effort already. Although granted, it is less pleasant than an API that just covers it by design.

I think what rubs me the wrong way about the current proposal and the problem of possible future extensions is that the couples the System API (which is currently oblivious to the existence of the management canister and all other functionality) with these other special aspects of the system. Obviously my proposal would also couple them, just at the implementation level (by having to understand the payload) instead of the API level, and in some sense it's inevitable if we want to provide a synchronous API.

[michael-weigelt]

While I agree with your analysis, I'd make a different trade-off. Having an API that is agnostic to the details has these disadvantages:

• The system API impl gets a blob -> the logic of understanding mgmt canister payloads is now in the system API impl too. Note that if we push this to the caller, i.e., the CDK, it does not add more coupling, because the CDK already needs to understand these payloads anyway. But having a set of switch statements that fans out all the possible blob types in the system API impl is not pretty, especially considering the caller had the precise information available in the first place.
• The difference in cost of passing a blob versus passing a few u64s is significant, both in terms of cycles and actual work performed by the replica.
• Asking the user to provide a well-formed payload when they potentially just want to make a decision based on some sizes and lengths is not that ergonomic.