Is calling install_code with an untrusted blob wasm_module safe for the calling canister?
Canister initialization can’t contain await, therefore the newly created canister cannot run an infinite loop for a long time, but at worst will spend 30B cycles quickly and trap. So, unlike calling an unsafe method, it can’t make the calling canister stuck in its infinite loop and become unupgradeable.
Is the previous paragraph correct?
Is the previous paragraph correct?
Not entirely. If you assume no malicious subnet or temporarily unavailable subnet, then it would be correct. But with a malicious subnet you could have a similar situation where the response to the install_code is never delivered or rather withheld “forever”.
Correction on the amount of cycles that can be spent: there’s a 200B instruction limit for install_code messages, which at the current cycles fee for instructions, would result in 80B cycles that can be spent.
But won’t a malicious subnet found and deleted?
Doesn’t it lead to eventual trap?
Subnet deletion is not implemented yet in the protocol. We can detect a malicious subnet given some metrics that exist but it would need manual work to isolate it.
Doesn’t it lead to eventual trap?
No it won’t. Unless some upgrade of the protocol delivers a (synthetic) reject response for all outstanding requests to a malicious subnet.
And what about IC.create_canister? Is it safe in presence of malicious subnets?
It is also a call to the management canister, so it suffers from the same problems as install_code wrt malicious subnets.
@Severin seems to disagree with you:
He wrote “Now, with locally timing out canister requests, you will (after 5 min IIRC) get an error because the request failed.”
I don’t think there’s any disagreement. This timeout is simply referring to another case.
This timeout will only happen if the receiving subnet is too busy and never accepts your request in the first place. However, a malicious subnet can accept the request (pretending it will process it) but never send the response back (or rather withhold it “forever”).
IC.update_settings is too unsafe in presence of malicious subnets, isn’t it?