aboutsummaryrefslogtreecommitdiffstats
path: root/docs/miscellaneous.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/miscellaneous.rst')
-rw-r--r--docs/miscellaneous.rst144
1 files changed, 0 insertions, 144 deletions
diff --git a/docs/miscellaneous.rst b/docs/miscellaneous.rst
index e9b01340..6d6c25ac 100644
--- a/docs/miscellaneous.rst
+++ b/docs/miscellaneous.rst
@@ -221,150 +221,6 @@ This means the following source mappings represent the same information:
``1:2:1;:9;2::2;;``
-*****************
-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.
-
-Of course, you have to publish the metadata file to Swarm (or some other service)
-so that others can access it. The file can be output by using ``solc --metadata``
-and the file will be called ``ContractName_meta.json``.
-It will contain Swarm references to the source code, so you have to upload
-all source files and the metadata file.
-
-The metadata file has the following format. The example below is presented in a
-human-readable way. Properly formatted metadata should use quotes correctly,
-reduce whitespace to a minimum and sort the keys of all objects to arrive at a
-unique formatting.
-Comments are of course also not permitted and used here only for explanatory purposes.
-
-.. code-block:: none
-
- {
- // Required: The version of the metadata format
- version: "1",
- // Required: Source code language, basically selects a "sub-version"
- // of the specification
- language: "Solidity",
- // Required: Details about the compiler, contents are specific
- // to the language.
- compiler: {
- // Required for Solidity: Version of the compiler
- version: "0.4.6+commit.2dabbdf0.Emscripten.clang",
- // Optional: Hash of the compiler binary which produced this output
- keccak256: "0x123..."
- },
- // Required: Compilation source files/source units, keys are file names
- sources:
- {
- "myFile.sol": {
- // Required: keccak256 hash of the source file
- "keccak256": "0x123...",
- // Required (unless "content" is used, see below): Sorted URL(s)
- // to the source file, protocol is more or less arbitrary, but a
- // Swarm URL is recommended
- "urls": [ "bzzr://56ab..." ]
- },
- "mortal": {
- // Required: keccak256 hash of the source file
- "keccak256": "0x234...",
- // Required (unless "url" is used): literal contents of the source file
- "content": "contract mortal is owned { function kill() { if (msg.sender == owner) selfdestruct(owner); } }"
- }
- },
- // Required: Compiler settings
- settings:
- {
- // Required for Solidity: Sorted list of remappings
- remappings: [ ":g/dir" ],
- // Optional: Optimizer settings (enabled defaults to false)
- optimizer: {
- enabled: true,
- runs: 500
- },
- // Required for Solidity: File and name of the contract or library this
- // metadata is created for.
- compilationTarget: {
- "myFile.sol": "MyContract"
- },
- // Required for Solidity: Addresses for libraries used
- libraries: {
- "MyLib": "0x123123..."
- }
- },
- // Required: Generated information about the contract.
- output:
- {
- // Required: ABI definition of the contract
- abi: [ ... ],
- // Required: NatSpec user documentation of the contract
- userdoc: [ ... ],
- // Required: NatSpec developer documentation of the contract
- devdoc: [ ... ],
- }
- }
-
-.. note::
- Note the ABI definition above has no fixed order. It can change with compiler versions.
-
-.. note::
- Since the bytecode of the resulting contract contains the metadata hash, any change to
- the metadata will result in a change of the bytecode. Furthermore, since the metadata
- includes a hash of all the sources used, a single whitespace change in any of the source
- codes will result in a different metadata, and subsequently a different bytecode.
-
-Encoding of the Metadata Hash in the Bytecode
-=============================================
-
-Because we might support other ways to retrieve the metadata file in the future,
-the mapping ``{"bzzr0": <Swarm hash>}`` is stored
-`CBOR <https://tools.ietf.org/html/rfc7049>`_-encoded. Since the beginning of that
-encoding is not easy to find, its length is added in a two-byte big-endian
-encoding. The current version of the Solidity compiler thus adds the following
-to the end of the deployed bytecode::
-
- 0xa1 0x65 'b' 'z' 'z' 'r' '0' 0x58 0x20 <32 bytes swarm hash> 0x00 0x29
-
-So in order to retrieve the data, the end of the deployed bytecode can be checked
-to match that pattern and use the Swarm hash to retrieve the file.
-
-Usage for Automatic Interface Generation and NatSpec
-====================================================
-
-The metadata is used in the following way: A component that wants to interact
-with a contract (e.g. Mist) retrieves the code of the contract, from that
-the Swarm hash of a file which is then retrieved.
-That file is JSON-decoded into a structure like above.
-
-The component can then use the ABI to automatically generate a rudimentary
-user interface for the contract.
-
-Furthermore, Mist can use the userdoc to display a confirmation message to the user
-whenever they interact with the contract.
-
-Usage for Source Code Verification
-==================================
-
-In order to verify the compilation, sources can be retrieved from Swarm
-via the link in the metadata file.
-The compiler of the correct version (which is checked to be part of the "official" compilers)
-is invoked on that input with the specified settings. The resulting
-bytecode is compared to the data of the creation transaction or ``CREATE`` opcode data.
-This automatically verifies the metadata since its hash is part of the bytecode.
-Excess data corresponds to the constructor input data, which should be decoded
-according to the interface and presented to the user.
-
-
***************
Tips and Tricks
***************