I know that queries called from outside the IC are currently free. What about when called from another canister? If my canister calls icrc1_balance_of to an ICRC1 token, is that token being charged since it is being called ‘in update mode’? I suspect the answer is no, but would like confirmation.
2 Likes
It will be charged as it happens in replicated mode.
Is there any way to detect and revoke queries from other canisters? (Principal ID length?)
I’m wondering if there should be some kind of ingress-only query where you know you can revoke with an inspect message…this way other canisters just wouldn’t be able to call the methods which would drastically reduce the exposure to cycle drain attacks for certain types of endpoints.
Is there any way to detect and revoke queries from other canisters? (Principal ID length?)
I don’t think the principal ID length would do it but you can (as a proxy) check for the last byte. If you read the spec, you’ll see that byte 0x01 should signal system generated ids (that includes canister ids) while byte 0x02 signals self-authenticating ids (i.e. user ids).
I’m wondering if there should be some kind of ingress-only query where you know you can revoke with an inspect message…this way other canisters just wouldn’t be able to call the methods which would drastically reduce the exposure to cycle drain attacks for certain types of endpoints.
Yeah certainly that would be helpful and we know it’s a gap between ingress messages and inter-canister messages – it’s something that we might get to at some point as it has been brought up before.
The upside is that for these messages the caller pays for the fees of transmitting the request/response and your canister pays for the local execution only (unlike ingress where the canister bears the cost for everything). So, if you combine the above check with a quick reject of any such message before any heavy processing needs to happen, the cycles spent by your canister should be minimal.
1 Like
Good to know…My biggest concerns are byte bombs where someone includes an ICRC1 account with a 2MB account ID…sounds like the attacker would have to pay. If you check the size straight away you’d likely have very little execution costs(maybe local memory?). @claudio, maybe a dumb question, but is checking the size of a blob in motoko a constant operation? Or does it count up the bytes linearly? I know there was some inefficiencies in blob at one point.
It’s constant time (checking blob size, that is)
1 Like