Solidity – Understanding Cryptic Part at the End of Contract Bytecode

assemblyevmremixsolcsolidity

Given the following contract:

pragma solidity ^0.4.11;

contract Simple {
    bytes32 public v;
    function set(bytes32 _v) {
        v = _v;
    }
}

When disassembling, neither remix, solc or evm can properly intepret the trailing end of the code. Additionally, the code seems unreachable (it follows a JUMP instruction), and what it seems to do doesn't make much sense.

Similar trailing code is produced when compiling with solc and remix, prefixed and suffixed similarly but contents are slightly different:

 00a165627a7a72305820...0029

In disassembly, the prefixing bytecode is intepreted by all as:

 stop
 log1
 push6 0x627a7a723058 
 sha3
 ...

When compiled with remix, the "assembly" field in the web GUI describes the part as a ".data" tag:

[...]
 SSTORE             v = _v
      POP           v = _v
    tag 10          function set(bytes32 _v) {\n        ...
      JUMPDEST          function set(bytes32 _v) {\n        ...
      POP           function set(bytes32 _v) {\n        ...
      JUMP [out]            function set(bytes32 _v) {\n        ...
    .data

Thus hinting that this is not code at all, but some form of data field. If so, what is this used for?, generally and in this specific example?

  • remix: 0.4.14+commit.c2215d46.Emscripten.clang
  • evm: 1.7.0-unstable (git commit 3d32690b)
  • solc: 0.4.14-develop.2017.7.27+commit.16ca1eea.Linux.g++

Runtime bytecode (from remix):

60606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680637c2efcba146047578063db80813f146075575b600080fd5b3415605157600080fd5b60576099565b60405180826000191660001916815260200191505060405180910390f35b3415607f57600080fd5b6097600480803560001916906020019091905050609f565b005b60005481565b80600081600019169055505b505600a165627a7a72305820e62ffd25aaa1132d83ae4470e9f3991cb237178c38401db1857b9417b74603560029

Best Answer

This is the Swarm hash. It is documented at https://solidity.readthedocs.io/en/develop/metadata.html

Extract follows

Contract Metadata

The Solidity compiler automatically generates a JSON file, the contract metadata, that contains information about the current contract. It can be used to query the compiler version, the sources used, the ABI and NatSpec documentation in order to more safely interact with the contract and to verify its source code.

The compiler appends a Swarm hash of the metadata file to the end of the bytecode (for details, see below) of each contract, so that you can retrieve the file in an authenticated way without having to resort to a centralized data provider.

The format looks like this:

enter image description here

If you were to separately upload the metadata file to Swarm then future users of your contract could find it via this reference in the contract code.

Update Aug 2019

Since solidity 0.5.9, the metadata format looks like this:

solidity 0.5.9

And also a word of caution:

The compiler currently uses the “swarm version 0” hash of the metadata, but this might change in the future, so do not rely on this sequence to start with 0xa2 0x65 'b' 'z' 'z' 'r' '0'. We might also add additional data to this CBOR structure, so the best option is to use a proper CBOR parser.

Related Topic