- Verifiable canisters
The concrete work currently being done relates to reproducibility of canisters, i.e., a developer wants to make it verifiable that a canister has been compiled from a particular source code, where we want to update the instructions to remedy some cases where they fail and make reproducibility more robust over time.
We are also working on how to more conveniently display information about canisters on the IC (e.g. controllers, perhaps ownership history, etc.).
Finally, there is an exploratory dimension, we want to think more broadly about what guarantees the IC can provide about canisters. Example: perhaps one could have an option to specify a call must only be executed if a particular wasm instance is running on the canister (to prevent execution against a changed smart contract). For the latter part I may reach out on the forum to solicit some brainstorming. - One-shot messaging.
The motivation for this is the same as this thread, non-responses is a risk and could happen due to attack or faults, guaranteed responses also create a risk of cycles in the call graph, and by introducing one-shot messaging you can eliminate that risk. This feature is not currently being worked on though and I’m guessing it will be quite a lot of work, hence my question of how big a concern it is. The problem is that it happens at the platform layer, so even if your canister ignores the response, under the hood the part of the IC that manages your canister will still expect a response (and e.g. get unspent cycles back). - Ensure canisters can always be upgraded.
The internal description is short, it essentially says governance canisters should be upgradeable and application canisters should be upgradeable. The feature is not active right now, but for the first goal I know some of my colleagues are working on improving upgradeability of the ledger.
2 Likes