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.
We can split up the bytecode shown above into three pieces:
Constructor
60806040526001600055348015601457600080fd5b5060358060226000396000f3fe
Runtime
6080604052600080fdfe
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.