FR: partial canister immutability

[infu]

Consider the following scenario:

• actor body
• module_1 (motoko module)
  • submodule_1
    • subsubmodule_1
• module_2

Is it possible to develop a canister function accepting wasm and returning hashes of different wasm parts. [ actor body : 244eac011af63a9080fb074eeab519f04e2de2686035ae4911982d376d32beb8, module_1 : 0d739316ac6a1f112048b42e06977f5ebcae499fa12bfa4e51b191ae596aef93 submodule_1 : 508ba6a7210aceb9f73852580a2bd7ae81999c4e022504c41b996aa6c9b4fe1e subsubmodule_1 : e7193d567d63bc0c4b465d51fee2be784da8a64be05f20c6144496f45e3392d7 module_2: 61f2433b62dd947eb332e5cec33914abc011e39057785a541d64b39a859b987f ] Changes in the source code of each part will not result in modified hashes of other parts. This way we can implement partial canister immutability.

[skilesare]

+1 This would be fantastic to have for composability and interoperability. It would allow us to better build open zeppelin style modules.

[rossberg]

It's not clear how this could be implemented on the IC as is. AFAICS, the IC would need to support on-chain linking, i.e., the ability to install a dapp consisting of multiple Wasm modules, each having its own hash, and each upgradable individually. Currently, multiple modules need to be munched together by the compiler, and that isn't possible without changes in one source module affecting all final functions, since their index spaces have to be merged and shifted.

[domwoe]

That is an interesting discussion!

@infu @skilesare Can we discuss why you wouldn't want to split the actor into multiple actors?

• Loss of atomicity?
• Access to common state?
• Complexity of management (cycles etc..) ?

[skilesare]

A lot of the reasons are in this lite paper we did: https://forum.dfinity.org/t/neutron-modular-rolling-governed-applications-system/20295

@infu has a demo where you build your web/motoko into a single package and then users can "install" the motoko and web app into their own personal canister. They access everything through their wallet. I think the test canister is still up at: https://widm7-oiaaa-aaaam-abpba-cai.icp0.io/. You can create your own neuron and then install a test hello module.

He had a demo compiler that could compile the code(I think currently node.js, but we were thinking you could get around some of this subpackage hashing if you could build a canister-based compiler for motoko).

As an aside....this would really benefit from derived canister IDs so we can give each app its own set of IDs...like an internal II for the wallet https://forum.dfinity.org/t/derived-canister-ids/17434.

I think it has moved to the background for both infu and I as far as what we are working on, but I still think about it just about every day, especially as a I start to think about a proper enterprise environment built on the IC.

[infu]

@domwoe Some real world use cases:

• A developer adds immutable modules in their canisters. Perhaps starts with a ledger, makes it immutable and then adds other functionality, but can't change the ledger module and its memory anymore. The new functionality doesn't have to call an external ledger with inter-canister calls
• Multiple entities control one canister - each controls different modules. Their modules communicate with each other without async calls
• A user adds modules in their 'wallet' canister, each new module can only talk to other modules via their public functions and can't touch their memory - working like an operating system. The user can't install anything other inside the canister except the os they started with. This could work with multiple canisters, but it will be probably slower and cost more and add the async complexity.

@rossberg If we had a Motoko compiler on-chain that would also work. Is that easier to do?

[rossberg]

@infu, your request was about computing hashes on Wasm binaries. Where you produce those binaries makes no difference for the problem.

If, however, you are fine with hashes of the Motoko source (e.g. produced by the compiler and embedded into the Wasm binary somehow), then that could already be done off-chain. Such a hash could even take the compiler version into account, so that only same source + same compiler yield the same hash. But of course, such hashes are not reliable if you cannot guarantee that they were actually produced by the real compiler – i.e., some other tool could forge them and inject fakes into a binary.

[infu]

@rossberg Yes. Either way will work for these use cases - support on-chain linking or have a Motoko compiler on-chain (canister maybe).

"But of course, such hashes are not reliable if you cannot guarantee that they were actually produced by the real compiler" That is exactly why off-chain compiler won't do. Doing that inside a secure enclave or using zkwasm and doing attestation & verification could also provide the guarantee, but they wont be as reliable.