Docs / On-chain builds / Verifying a build

Verifying a buildalpha

Check what the compiler canister built, from which files, and with which compiler.

moxzi verify reads a build record from the compiler canister and checks it. It needs no identity and costs nothing.

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai --job 1

job             1
entry           /src/hello.mo
files           1
sourcesDigest   bd1434f9c83abd6f0c21843a1a3ebba433a63bff2026fe0a5efd1bf8573a3341
optionsDigest   db700b01e8f9e20ce5ad629775f7529a924826df19c8f95c86cdf7b02d9ef649
compilerVersion 1.14.1
cacheVersion    (unset)
artifact        da33c8358aa785232eeb93c51b695ee24599839cbaf80ef80940ff9b4abee9a1  (61650 B, unlinked)

ok    sourcesDigest recomputed from 1 files and matches
ok    canister module hash (from the IC) 21daca9881aa024f89091b104591440325ea92e6a0fb22c4e9fa5f153d29207b

*** 1 check(s) passed ***

Field	Meaning
`entry`, `files`	The entry file and the number of files in the build
`sourcesDigest`	A hash of every source file's path and hash. `verify` downloads the file list and recomputes it
`optionsDigest`	A hash of the build options. The same source built with different options is a different build
`compilerVersion`	The Motoko version the compiler reports
`artifact`	The hash of the compiled module, before linking
canister module hash	The compiler canister's module hash, read from the Internet Computer itself rather than from the canister

Omit --job to check the most recent build, or run with --list instead of --job to see recent builds and their ids.

Check your source#

--entry compares each recorded file hash with the files on your machine:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai \
  --job 42 --entry src/main.mo

A file that differs is reported by name.

Check a wasm#

--artifact compares a wasm file's hash with the recorded artifact hash:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai \
  --job 42 --artifact main-unlinked.wasm

The recorded hash is for the module before linking. Linking is deterministic, so the same unlinked module always produces the same deployable module.

Check the compiler#

--expect-module checks that the canister is running a particular wasm. Pass the compiler you have locally:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai --job 1 \
  --expect-module ~/.local/lib/moxzi/compiler.wasm

job             1
entry           /src/hello.mo
files           1
sourcesDigest   bd1434f9c83abd6f0c21843a1a3ebba433a63bff2026fe0a5efd1bf8573a3341
optionsDigest   db700b01e8f9e20ce5ad629775f7529a924826df19c8f95c86cdf7b02d9ef649
compilerVersion 1.14.1
cacheVersion    (unset)
artifact        da33c8358aa785232eeb93c51b695ee24599839cbaf80ef80940ff9b4abee9a1  (61650 B, unlinked)

ok    sourcesDigest recomputed from 1 files and matches
ok    canister module hash (from the IC) 21daca9881aa024f89091b104591440325ea92e6a0fb22c4e9fa5f153d29207b
ok    the canister is running ~/.local/lib/moxzi/compiler.wasm

*** 2 check(s) passed ***

The check passes: the canister runs the same compiler.wasm that ships with this release. That's why a local build and an on-chain build of the same source produce the same bytes, and why you can check an on-chain build by building locally. moxzi info shows the hashes of your local compiler and linker:

moxzi info | grep -E '^(compiler|linker|sha256) '

compiler : ~/.local/lib/moxzi/compiler.wasm
sha256   : 21daca9881aa024f89091b104591440325ea92e6a0fb22c4e9fa5f153d29207b
linker   : ~/.local/lib/moxzi/linker.wasm
sha256   : 674a9ada189b6983715b9e6d8b33864af3eafee56cd9323f5b134c6c926b877e

A canister's controllers can upgrade it. Check the module hash, not only the canister id, each time you rely on a build.

Next steps#

Publishing to a registry: attach the build record to a published wasm.
Trust.