The IC lacks the ability to deterministically calculate canister IDs. This functionality is useful in a handful of scenarios as proven in other chains such as ETH and TON.
I therefore propose a way to deterministically generate canister IDs in the following manner.
According to the Internet Computer Specification, I propose to add another category of principals: “deterministic ids” with the format
blob · 0x05.
The canister principal shall be calculated as
H( H(bytecode) · H(init params) · H(controller) · subnet id · salt) · 0x05 (29 bytes).
This allows anyone to derive the pricipal of a canister deployed with a particular bytecode to a specific controller (i.e. in a deterministic state), without actually deploying the canister.
Those deterministic canister principals are mapped to the real canister IDs in the IC when used.
Anyone can deploy the canister by paying the cycles required for deployment, calling a special IC API function
When a canister ID exists in the deterministic canister ID map, the
caller shall resolve to the deterministic canister ID instead.