Merge remote-tracking branch 'etherchina/develop' into develop

Author: riversyang

README.md

@@ -33,7 +33,15 @@ toyab, 侯伯薇, 姜信宝（bobjiang）, 左洪斌（hongbinzuo）, 李捷（o
 
 
 ## 术语表
-参见glossaries.md
+参见`glossaries.md`和`glossaries.rst`
 
 ## 参考资料
-参见references.md
+参见`references.md`
+
+## 感谢  
+支持 [HiBlock区块链社区](http://hiblock.net/)  
+赞助 [OlympusLabs](https://olympuslabs.io/)
+
+## 捐助
+欢迎使用以太捐助我们的翻译工作，以太坊地址：
+`0xa36c3EFC7dd21db612490B5B1BF8734c8EDBCd00`

metadata.rst

@@ -2,145 +2,122 @@
 合约的元数据
 #################
 
+.. include:: glossaries.rst
 .. index:: metadata, contract verification
 
-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.
+Solidity编译器自动生成JSON文件，即合约的元数据，其中包含了当前合约的相关信息。
+它可以用于查询编译器版本，所使用的源代码，|ABI| 和 |natspec| 文档，以便更安全地与合约进行交互并验证其源代码。
+
+编译器会将元数据文件的 Swarm 哈希值附加到每个合约的字节码末尾（详情请参阅下文），
+以便你可以以认证的方式获取该文件，而不必求助于中心化的数据提供者。
+
+当然，你必须将元数据文件发布到 Swarm （或其他服务），以便其他人可以访问它。
+该文件可以通过使用 ``solc --metadata`` 来生成，并被命名为 ``ContractName_meta.json`` 。
+它将包含源代码的在 Swarm 上的引用，因此你必须上传所有源文件和元数据文件。
+
+元数据文件具有以下格式。 下面的例子将以人类可读的方式呈现。
+正确格式化的元数据应正确使用引号，将空白减少到最小，并对所有对象的键值进行排序以得到唯一的格式。
+代码注释当然也是不允许的，这里仅用于解释目的。
 
 .. 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
+        // 对 Solidity 来说是必须的：编译器的版本
         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 哈希值
           "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
+          // 必选（除非定义了“content”，详见下文）：
+          // 已排序的源文件的URL，URL的协议可以是任意的，但建议使用 Swarm 的URL
           "urls": [ "bzzr://56ab..." ]
         },
         "mortal": {
-          // Required: keccak256 hash of the source file
+          // 必选：源文件的 keccak256 哈希值
           "keccak256": "0x234...",
-          // Required (unless "url" is used): literal contents of the source file
+          // 必选（除非定义了“urls”）： 源文件的字面内容
           "content": "contract mortal is owned { function kill() { if (msg.sender == owner) selfdestruct(owner); } }"
         }
       },
-      // Required: Compiler settings
+      // 必选：编译器的设置
       settings:
       {
-        // Required for Solidity: Sorted list of remappings
+        // 对 Solidity 来说是必须的： 已排序的重定向列表
         remappings: [ ":g/dir" ],
-        // Optional: Optimizer settings (enabled defaults to false)
+        // 可选： 优化器的设置（ enabled 默认设为 false ）
         optimizer: {
           enabled: true,
           runs: 500
         },
-        // Required for Solidity: File and name of the contract or library this
-        // metadata is created for.
+        // 对 Solidity 来说是必须的：用以生成该元数据的文件名和合约名或库名
         compilationTarget: {
           "myFile.sol": "MyContract"
         },
-        // Required for Solidity: Addresses for libraries used
+        // 对 Solidity 来说是必须的：所使用的库的地址
         libraries: {
           "MyLib": "0x123123..."
         }
       },
-      // Required: Generated information about the contract.
+      // 必选：合约的生成信息
       output:
       {
-        // Required: ABI definition of the contract
+        // 必选：合约的 ABI 定义
         abi: [ ... ],
-        // Required: NatSpec user documentation of the contract
+        // 必选：合约的 NatSpec 用户文档
         userdoc: [ ... ],
-        // Required: NatSpec developer documentation of the contract
+        // 必选：合约的 NatSpec 开发者文档
         devdoc: [ ... ],
       }
     }
 
 .. note::
-    Note the ABI definition above has no fixed order. It can change with compiler versions.
+    需注意，上面的 ABI 没有固定的顺序，随编译器的版本而不同。
 
 .. 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.
+    由于生成的合约的字节码包含元数据的哈希值，因此对元数据的任何更改都会导致字节码的更改。
+    此外，由于元数据包含所有使用的源代码的哈希值，所以任何源代码中的，
+    哪怕是一个空格的变化都将导致不同的元数据，并随后产生不同的字节代码。
 
 元数据哈希字节码的编码
 =============================================
 
-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::
+由于在将来我们可能会支持其他方式来获取元数据文件，
+类似 ``{"bzzr0"：<Swarm hash>}`` 的键值对，将会以 `CBOR <https://tools.ietf.org/html/rfc7049>`_ 编码来存储。
+由于这种编码的起始位不容易找到，因此添加两个字节来表述其长度，以大端方式编码。
+所以，当前版本的Solidity编译器，将以下内容添加到部署的字节码的末尾::
 
     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.
+因此，为了获取数据，可以检查部署的字节码的末尾以匹配该模式，并使用 Swarm 哈希来获取元数据文件。
 
-自动化接口生成和NatSpec的使用方法
+自动化接口生成和 |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.
+元数据以下列方式被使用：想要与合约交互的组件（例如，Mist）读取合约的字节码，
+从中获取元数据文件的 Swarm 哈希，然后从 Swarm 获取该文件。该文件被解码为上面的 JSON 结构。
 
-The component can then use the ABI to automatically generate a rudimentary
-user interface for the contract.
+然后该组件可以使用ABI自动生成合约的基本用户接口。
 
-Furthermore, Mist can use the userdoc to display a confirmation message to the user
-whenever they interact with the contract.
+此外，Mist可以使用 userdoc 在用户与合约进行交互时向用户显示确认消息。
 
-Additional information about Ethereum Natural Specification (NatSpec) can be found `here <https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format>`_. 
+有关 |natspec| 的其他信息可以在 `这里 <https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format>`_ 找到。
 
 源代码验证的使用方法
 ==================================
 
-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.
+为了验证编译，可以通过元数据文件中的链接从 Swarm 中获取源代码。
+获取到的源码，会根据元数据中指定的设置，被正确版本的编译器（应该为“官方”编译器之一）所处理。
+处理得到的字节码会与创建交易的数据或者 ``CREATE`` 操作码使用的数据进行比较。
+这会自动验证元数据，因为它的哈希值是字节码的一部分。
+而额外的数据，则是与基于接口进行编码并展示给用户的构造输入数据相符的。