The code allows you to either upload
cont.wasm files or a
The difference between the files is as follows:
Just the WebAssembly bytecode. You can look at this in a somehow human readable form by executing
wasm2wat hello-world.wasm > hello-world.wat and viewing the file in an editor.
This file will be stored on-chain.
Contains the contracts metadata. You might also know this under the term "ABI" from other blockchain projects. This file contains a multitude of information about the contract ‒ none which is stored in the
You can execute
cat metadata.json | jq . to get a pretty print of the file. You'll see that it contains information such as: which functions can be invoked on the contract, which compiler was used for it (important for reproducible builds), the storage layout of the contract, etc..
It's important that this file is not stored on the blockchain.
This file is needed if you build e.g. a user interface, a Dapp, a client, something along those lines. Than that application would read the metadata to find out how to interact with the contract. For example, each function on the contract has a selector. This selector is a unique sequence of bytes that can be used to identify the function which is called. So in order to interact with the contract you need to know how the selectors are defined.
This file is just the
metadata.json with an additional field
.source.wasm. This field contains the Wasm bytecode in hex encoding. You can pretty print this file and look at it by executing
cat hello-world.contract | jq .. It really only has this one field more.
This file is used if you upload a contract to a chain, e.g. via Contracts UI or polkadot-js. It's Wasm bytecode part will be stored on-chain, it's metadata part will be used by the UI to display information and interaction possibilities for the contract.
And then for your second question:
What is the difference between the usage of a
.wasm file and a
.contract file for instantiation?
It's still in the UI's for two reasons:
- For legacy reasons, we only introduced the
.contract format later on.
- If you want to work with upgradeable contracts you need an option to set a different
metadata.json for a contract that already exists on-chain. This is because the originally uploaded
.contract file might have been updated and now you want to interact with it using the metadata format from the contract to which it was upgraded. You can find more details on this in our readme for an example of such an upgradeable contract (here).