feat: [EXC-1768] Add system API to get costs of management canister calls. #3584
Conversation
| .get_subnet_size(&subnet_id.into()) | ||
| .map(|x| x as u32) | ||
| .ok_or(HypervisorError::SubnetNotFound) | ||
| } |
There was a problem hiding this comment.
Need to trace these new syscalls
| /// This system call indicates the cycle cost of signing with schnorr, | ||
| /// i.e., the management canister's `sign_with_schnorr` for the key | ||
| /// with name given by `src` + `size`. | ||
| /// | ||
| /// Traps if `src`/`size` cannot be decoded to a valid key name. | ||
| /// | ||
| /// The amount of cycles is represented by a 128-bit value and is copied | ||
| /// to the canister memory starting at the location `dst`. | ||
| fn ic0_cost_schnorr( |
There was a problem hiding this comment.
Instead of the key name, should the argument be the key ID (as in sign_with_schnorr and schnorr_public_key)? Since we currently support two different schnorr algorithms, there are also two "Schnorr" keys with the same name. You could imagine that they may be deployed to two different subnets with different replication factors, or perhaps that the Ed25519 variant could be more expensive/cheaper than Bip340. IIUC the current implementation would return the same cost for both keys.
To be future proof, I would say the same argument applies for ECDSA and VetKD
There was a problem hiding this comment.
Thanks for pointing this out. I checked for Ecdsa, but did not take another closer look at Schnorr.
Yes, in this case, we need to disambiguate keys of the same name even within a given signing scheme.
I tried to avoid encoding KeyId, because initially most of the information therein seemed redundant for this endpoint. But it looks like I have to use it in some form. Would the (scheme, key_name, curve)-tuple be unique, conceptually? Or are you implying that 'algorithm' and 'curve' are also distinct choices?
There was a problem hiding this comment.
Schnorr key IDs have an "algorithm" variant, whereas ECDSA and VetKD use "curve". So assuming the scheme is derived from the function name I think the tuples (key_name, curve) for VetKD and ECDSA, and (key_name, algorithm) for Schnorr should be enough.
There was a problem hiding this comment.
Thanks. I'll ping you when I have the next iteration ready.
| heap: &mut [u8], | ||
| ) -> HypervisorResult<()>; | ||
|
|
||
| /// This system call indicates the cycle cost of signing with ecdsa, |
There was a problem hiding this comment.
| /// This system call indicates the cycle cost of signing with ecdsa, | |
| /// This system call indicates the cycle cost of threshold key derivation, |
| ) -> HypervisorResult<()>; | ||
|
|
||
| /// This system call indicates the cycle cost of signing with ecdsa, | ||
| /// i.e., the management canister's `vetkd_encrypted_key` for the key |
There was a problem hiding this comment.
| /// i.e., the management canister's `vetkd_encrypted_key` for the key | |
| /// i.e., the management canister's `vetkd_derive_encrypted_key` for the key |
| /// | ||
| /// The amount of cycles is represented by a 128-bit value and is copied | ||
| /// to the canister memory starting at the location `dst`. | ||
| fn ic0_cost_vetkey( |
There was a problem hiding this comment.
Would it be cleaner if the name was ic0_cost_vetkd_derive_encrypted_key?
Also ic0_cost_sign_with_ecdsa and ic0_cost_sign_with_schnorr above
Design Doc
Spec PR
This is the base of a stack of PRs. Before merging this one, I'll merge the stack into this after each part has been reviewed.