Repository files navigation

This is a Docker build with a locked set of dependencies to producereproducible builds of cosmwasm smart contracts. It also does heavyoptimization on the build size, using binary stripping andwasm-opt.

Image	Description	x86_64 images (default)	ARM images (experimental1)
optimizer	Combines rust-optimizer and workspace-optimizer in a single image	cosmwasm/optimizer	cosmwasm/optimizer-arm64
rust-optimizerdeprecated	Single contract builds	cosmwasm/rust-optimizer	cosmwasm/rust-optimizer-arm64
workspace-optimizerdeprecated	Multi-contract workspaces (e.g. cosmwasm-plus)	cosmwasm/workspace-optimizer	cosmwasm/workspace-optimizer-arm64

¹ ARM images do not produce the same output as the default images and are discouraged for production use. SeeNotice below.

This works for most cases, for monorepo builds see advanced

The easiest way is to simply use thepublished docker image.You must set the local path to the smart contract you wish to compile andit will produce anartifacts directory with<crate_name>.wasmandchecksums.txt containing the hashes. This is just one file.

Run it a few times on different computersand usesha256sum to prove to yourself that this is consistent. I challengeyou to produce a smaller build that works with the cosmwasm integration tests(and if you do, please make an issue/PR):

docker run --rm -v"$(pwd)":/code \  --mount type=volume,source="$(basename"$(pwd)")_cache",target=/target \  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \  cosmwasm/optimizer:0.16.0

Demo this withcosmwasm-examples (going into eg.erc20 subdir before running),withcosmwasm-plus, or with a sample app fromcosmwasm-template.

Note that we use one registry cache (to avoid excessive downloads), but the target cache is a different volume percontract that we compile. This means no interference between contracts, but very fast recompile times when makingminor adjustments to a contract you had previously created an optimized build for.

This is designed for cosmwasm-plus samples. We use a separate docker image

Sometime you want many contracts to be related and import common functionality. This isexactly the case ofcosmwasm-plus.In such a case, we can often not just compile from root, as the compile order isnot deterministic and there are feature flags shared among the repos.This has lead toissues in the past.

For this use-case we made a second docker image, which will compile all thecontracts/* folders inside the workspace and do so one-by-one in alphabetical order.It will then add all the generated wasm files to anartifacts directory with a checksum,just like the basic docker image (same output format).

To compile all contracts in the workspace deterministically, you can run:

docker run --rm -v"$(pwd)":/code \  --mount type=volume,source="$(basename"$(pwd)")_cache",target=/target \  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \  cosmwasm/optimizer:0.16.0

The downside is that to verify one contract in the workspace, you need to compile themall, but the majority of the build time is in dependencies, which are shared and cachedbetween the various contracts and thus the time is sub-linear with respect to numberof contracts.

This is designed for cosmwasm samples. You cannot provide automatic verification for these

If you have a more complex build environment, you need to pass a few morearguments to define how to run the build process.

cosmwasm has a root workspaceand many contracts under./contracts/*, which areexcluded in thetop-levelCargo.toml. In this case, we compile each contract separatelywith it's own cache. However, since they may refer to packages via path(../../packages/std), we need to run the script in the repo root. In thiscase, we can use the optimize.sh command:

docker run --rm -v"$(pwd)":/code \  --mount type=volume,source="devcontract_cache_burner",target=/code/contracts/burner/target \  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \  cosmwasm/optimizer:0.16.0 ./contracts/burner

The build system uses the folder/target in its local file system for all Rust compilation results.This ensures there is no conflict with the target folder of the source repository.It also means that for each compilation, Cargo will have an empty target folder and have to re-compileall contracts and all dependencies. In order to avoid this, you can optionally mount a Docker volumeinto the file system, as highlighted here:

 docker run --rm -v "$(pwd)":/code \+  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/target \   --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \   cosmwasm/rust-optimizer:0.15.0

Using this cache is considered best practice and included in all our example call snippets.

Before version 0.13.0, the target folder was located at/code/target. Thiscaused situations in whichrust-optimizer/workspace-optimizer wrote to the target folder of the hostin an unintended way. By ensuring the target location is not a subfolder of the mountedsource code we can avoid those sort of problems.

Take a look at theMakefileYou can edit the Dockerfile (in a fork), and runmake build to compile it.

This has been tested on Linux (Ubuntu / Debian). There are currently versions of both optimizers for two processorarchitectures: Intel/Amd 64-bits, and Arm 64-bits (these run natively on Mac M1 machines).

However, the native Arm version produces different wasm artifacts than the Intel version. Given that that impactsreproducibility, non-Intel images contain a "-arm64" suffix to differentiate them.

Arm images are released to ease development and testing on Mac M1 machines.For release / production use,only contracts built with the Intel optimizers must be used.