How can i deploy a canister that is verifiably running public code?

General DFINITY
1

Since canisters generally don’t run like smart contracts on a public chain that everyone can inspect, how can you run a canister that is running code which is publicly verifiable?

2

I imagine some sort of canister registry that lets developers upload source code, which is compiled (by a compiler canister) so the resulting binary can be compared. An additional service can be offered that notifies users when canisters are upgraded.

Who is building this?

5 Likes
3

Working on it! A few things to iron out for that particular feature but it’s on the roadmap.

5 Likes
4

Is there technical roadmap available somewhere?

5

Not as such, but it is for the community so input on features going forward is definitely open—we want this to evolve with everyone’s needs.
(I should stress this is a third party endeavour btw!)

6

@Ori - If we could just get the module hash via a publicly available method that would be a nice stopgap.

7
4 Likes
8

:tada: :tada: :tada: Thanks for sharing this! I was shown

https://sdk.dfinity.org/docs/interface-spec/index.html#ic-canister_status

Only the controllers of the canister can request its status.

and was under the impression the module_has wasn’t accessible at all to anyone except the owner.

1 Like
9

The aaaaa-aa.canister_stats() method is indeed restricted, but some information is also exposed via the state tree, as @wang’s code shows.

10

So – to summarize – is it correct that a third party is able to get the module hash of a canister (e.g., using Wang’s code above), and if the canister owner published their source code, they could then verify the code by basically just hashing it? Obviously this process would be improved/easier with a registry as discussed.

11

You can also get the module hash and the controller of any canister by doing
dfx canister --no-wallet --network ic info <canister_id>

3 Likes
12

@dave, the summary is almost correct. the module hash is the hash of the compiled code. So if the module author is publishing the source code, they should also publish instructions how to build that bit-for-bit reproducibly, which is not that easy (as, for example, local file paths end up in the .wasm, changing the hash).

This is why, for example, the Internet Identity project ships a Dockerfile and instructions to build the .wasm in a way that should allow anyone to reproduce the deployed .wasm.

Try it! According to https://github.com/ic-association/nns-proposals/blob/main/proposals/network_canister_management/20210527T2203Z.md the latest deployed git revision is bd51eab, so you should be able to check out the internet-identity repository at that revision, follow the build steps, and get a .wasm file that matches the module hash as reported by dfx canister ic info.

See https://reproducible-builds.org/ for more on why reproducible builds are hard and what people to do get them.

7 Likes
13

Here is a more detailed walk-through: Walkthrough: Verifying the code of the Internet Identity service

5 Likes
14

Excellent walk-through! Thanks, this is exactly what I was looking for. Awesome stuff. On a different but somewhat related note, with regards to canister ownership – if a canister owner can update the code anytime, then am I correct that dapps will likely have their original owners/deployers revoke their ownership after deployment? (Obviously there are also some other models that could be used). Is revoking ownership straightforward?

2 Likes
15

Yes, it’s straight forward, see Non-revokable APIs - #5 by nomeata

2 Likes