Merge branch 'master' into master

EIPS/eip-1046.md

@@ -0,0 +1,87 @@
+---
+eip: 1046
+title: ERC20 Metadata Extension
+author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs)
+discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfh1g/erc20_metadata_extension_eip_1046/
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-04-13
+requires: 20
+---
+
+## Simple Summary
+Optionally extend ERC20 token interface to support the same metadata standard as ERC721 tokens.
+
+## Abstract
+The ERC721 standard introduced the `tokenURI` parameter for non-fungible tokens to handle metadata such as:
+
+- thumbnail image
+- title
+- description
+- special asset properties
+- etc.
+
+Metadata is critical for assets such as crypto-collectibles and video game assets to have real utility and value. However, not all crypto-collectibles and gaming assets will be non-fungible. It is critical for fungible ERC20 tokens to have a metadata standard like that of ERC721 tokens. Standardization of metadata between ERC20 and ERC721 will simplify development of dApps and infrastructure that must support both fungible and non-fungible assets.
+
+## Motivation
+The ERC721 standard was created to support the creation of perfectly unique, 1-of-1, non-divisible tokens known as "non-fungible tokens".
+
+The initial use case for the ERC721 standard was to support the creation of crypto-collectibles and gaming assets, initially for the ["Crypto Kitties"](https://www.cryptokitties.co/) collectibles game. The success of Crypto Kitties catalyzed significant application development to support the display of ERC721 assets using the `tokenURI` metadata parameter.
+
+However, not all crypto-collectibles and gaming assets need to be unique and non-fungible. Gaming assets (items, weapons, characters), crypto-artworks with non-unique "prints", and more will function more like traditional ERC20 tokens with a fungible `supply`. Many applications such as wallets, exchanges, games, etc. will want to support both fungible and non-fungible assets containing similar metadata. This proposal will extend the ERC20 standard to optionally include a nearly identical `tokenURI` parameter supporting the same JSON metadata schema as the ERC721 standard.
+
+## Specification
+
+The **metadata extension** will be OPTIONAL for ERC20 contracts. This allows your smart contract to be interrogated for its name and for details about the assets which your tokens represent.
+
+```solidity
+/// @title ERC-20 optional metadata extension
+interface TokenMetaData /* is ERC20 */ {
+
+    /// @notice A distinct Uniform Resource Identifier (URI) for a given token.
+    function tokenURI() external view returns (string);
+}
+```
+
+This is the "Token Metadata JSON Schema" referenced above.
+
+```json
+{
+    "title": "Asset Metadata",
+    "type": "object",
+    "properties": {
+        "name": {
+            "type": "string",
+            "description": "Identifies the asset to which this token represents",
+        },
+        "description": {
+            "type": "string",
+            "description": "Describes the asset to which this token represents",
+        },
+        "image": {
+            "type": "string",
+            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
+        }
+    }
+}
+```
+
+The token's name() and symbol() getters should be preferred over the name and/or symbol properties in the tokenURI JSON. 
+
+## Rationale
+This proposal will make adding metadata to ERC20 tokens straightforward for developers with minimal-to-no disruption to the overall ecosystem. By using the same parameter name and by consolidating the underlying Token JSON Metadata Standard, developers will confidently understand how to add and interpret token metadata between ERC20 and ERC721 tokens.
+
+## Backwards Compatibility
+This EIP is fully backwards compatible as its implementation simply extends the functionality of ERC20 tokens and is optional.
+
+## Test Cases
+TO-DO
+
+## Implementation
+
+- [Rare Art Labs](https://rareart.io) (WIP)
+- [Open Zeppelin](https://github.com/OpenZeppelin/zeppelin-solidity) (WIP)
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1047.md

@@ -0,0 +1,72 @@
+---
+eip: 1047
+title: Token Metadata JSON Schema
+author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler)
+discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfk2a/token_metadata_json_schema_eip_1047/
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-04-13
+---
+
+## Simple Summary
+A standard interface for token metadata
+
+## Abstract
+The ERC721 standard introduced the "tokenURI" parameter for non-fungible tokens to handle metadata such as:
+
+- thumbnail image
+- title
+- description
+- properties
+- etc.
+
+This is particularly critical for crypto-collectibles and gaming assets.
+
+This standard includes a reference to a metadata standard named "ERC721 Metadata JSON Schema". This schema is actually equally relevant to ERC20 tokens and therefore should be its own standard, separate from the ERC721 standard.
+
+## Motivation
+Metadata is critical for both ERC721 and ERC20 tokens representing things like crypto-collectibles, gaming assets, etc. Not all crypto-collectibles and gaming assets will be non-fungible. It is critical for fungible ERC20 tokens to have a metadata standard similar to that of ERC721 tokens. Standardization of metadata between ERC20 and ERC721 will simplify development of dApps and infrastructure that must support both fungible and non-fungible assets.
+
+It is more logical and easier to maintain one Token Metadata JSON Schema rather than multiple schemas contained in their own EIPs.
+
+This should result in no code changes to the ERC721 standard or ERC20 standard and will serve only to simplify the process of maintaining a standard JSON Schema for token metadata.
+
+## Specification
+
+This "Token Metadata JSON Schema" mimics the structure of the ERC721 standard. Only grammatical changes are being recommended at this time.
+
+```json
+{
+    "title": "Asset Metadata",
+    "type": "object",
+    "properties": {
+        "name": {
+            "type": "string",
+            "description": "Identifies the asset to which this token represents",
+        },
+        "description": {
+            "type": "string",
+            "description": "Describes the asset to which this token represents",
+        },
+        "image": {
+            "type": "string",
+            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
+        }
+    }
+}
+```
+## Rationale
+One JSON schema standard will allow for simpler maintenance of this critical schema.
+
+## Backwards Compatibility
+Fully backwards compatible requiring no code changes at this time
+
+## Test Cases
+TO-DO
+
+## Implementation
+TO-DO
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1062.md

@@ -0,0 +1,84 @@
+---
+eip: 1062
+title: Formalize IPFS hash into ENS(Ethereum Name Service) resolver
+author: Phyrex Tsai <phyrex@portal.network>, Portal Network Team
+discussions-to: https://ethereum-magicians.org/t/eip-1062-formalize-ipfs-hash-into-ens-ethereum-name-service-resolver/281
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-05-02
+---
+
+## Simple Summary
+To specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service).
+
+## Abstract
+The following standard details the implementation of how to combine the IPFS cryptographic hash unique fingerprint with ENS public resolver. This standard provides a functionality to get and set IPFS online resources to ENS resolver.
+
+We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ENS resolver mapping standard a cornerstone for building future Web3.0 service.
+
+## Motivation
+To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
+- Address large amounts of data, and has unique cryptographic hash for every record.
+- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.
+- IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network.
+
+Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser.
+
+
+## Specification
+The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum uses hex in API to encode the binary data. So that need a way to process the condition requires not only we need to transfer from IPFS to Ethereum, but also need to convert it back.
+
+To solve these requirements, we can use binary buffer bridging that gap.  
+When mapping the IPFS base58 string to ENS resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ENS, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string.
+
+
+## Rationale
+To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below :
+
+```
+function setMultihash(bytes32 node, bytes hash) public only_owner(node);
+```
+
+Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.
+
+```
+function multihash(bytes32 node) public view returns (bytes);
+```
+
+## Test Cases
+
+To implement the way to transfer from base58 to hex format and the reverse one, using the ‘multihashes’ library to deal with the problem.  
+The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes)  
+To implement the method transfer from IPFS(Base58) to hex format :
+
+```
+import multihash from 'multihashes'
+
+export const toHex = function(ipfsHash) {
+  let buf = multihash.fromB58String(ipfsHash);
+  return '0x' + multihash.toHexString(buf);
+}
+```
+
+To implement the method transfer from hex format to IPFS(Base58) :
+
+```
+import multihash from 'multihashes'
+
+export const toBase58 = function(contentHash) {
+  let hex = contentHash.substring(2)
+  let buf = multihash.fromHexString(hex);
+  return multihash.toB58String(buf);
+}
+```
+
+## Implementation
+The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ENS just like we normally type the DNS to browser the website. Solve the current pain for normal people can not easily visit the total decentralized website.
+
+The workable implementation repository : [https://github.com/PortalNetwork/portal-network-browser-extension](https://github.com/PortalNetwork/portal-network-browser-extension)
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+