Categories
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:

Constructor

60806040526001600055348015601457600080fd5b5060358060226000396000f3fe

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

Runtime

6080604052600080fdfe

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

Metadata

a165627a7a723058204e048d6cab20eb0d9f95671510277b55a61a582250e04db7f6587a1bebc134d20029

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:

4e048d6cab20eb0d9f95671510277b55a61a582250e04db7f6587a1bebc134d2

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 *