2. Ethereum virtual machine

Deploying a smart contract

When deploying a smart contract, a regular transaction is created, without a to address. Additionally, some bytecode is added as input data. This bytecode acts as a constructor, which is needed to write initial variables to storage before copying the runtime bytecode to the contract’s code. During deployment, creation bytecode will only run once, while runtime bytecode will run on every contract call.

Another example Solidity contract, along with its bytecode needed to deploy

We can split up the bytecode shown above into three pieces:



The constructor writes all initial values to storage and copies the runtime bytecode to the contracts memory



This is the piece of bytecode which is written to memory during the contract creation



At the end of this bytecode, a Swarm hash of a metadata file created by Solidity gets appended. Swarm is a distributed storage platform and content distribution service, or, more simply stated: a decentralized file storage. Although the Swarm hash will also be included in the runtime bytecode, it will never be interpreted as opcodes by the EVM, because its location can never be reached. Currently, Solidity utilizes the following format:

0xa1 0x65 'b' 'z' 'z' 'r' '0' 0x58 0x20 [32 bytes swarm hash] 0x00 0x29

Therefore, in this case, we can extract the following Swarm hash:


The metadata file contains various information about the contract, such as the compiler version or the contract’s functions. Unfortunately, this is an experimental feature, and not many contracts have publicly uploaded their metadata to the Swarm network.

Leave a Reply

Your email address will not be published. Required fields are marked *