From 1529796d3a141a2e1b23911d291407d6eeb39c2d Mon Sep 17 00:00:00 2001 From: Loredana Cirstea Date: Thu, 18 Jul 2019 22:14:06 +0300 Subject: [PATCH] Add ERC: dType Alias Extension - Decentralized Type System (#2193) * Add ERC: dType Alias Extension - Decentralized Type System * Add EIP number 2193, fix links As suggested in https://github.com/ethereum/EIPs/pull/2193#discussion_r304121479, https://github.com/ethereum/EIPs/pull/2193#discussion_r304121615 * EIP-2193 - add separator semantics, address PR review - add separator semantic explanations - add EIP-155 as requirement, as per https://github.com/ethereum/EIPs/pull/2193#discussion_r304139427 - address https://github.com/ethereum/EIPs/pull/2193#discussion_r304139590 -- use `external` instead of public -- clarify who can set aliases -- chainId explanation -- use `bytes1 separator` instead of `string separator` --- EIPS/eip-2193.md | 92 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 EIPS/eip-2193.md diff --git a/EIPS/eip-2193.md b/EIPS/eip-2193.md new file mode 100644 index 00000000..fdab1455 --- /dev/null +++ b/EIPS/eip-2193.md @@ -0,0 +1,92 @@ +--- +eip: 2193 +title: dType Alias Extension - Decentralized Type System +author: Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu) +discussions-to: https://github.com/ethereum/EIPs/issues/2192 +status: Draft +type: Standards Track +category: ERC +created: 2019-07-16 +requires: 1900, 2157, 155 +--- + +## Simple Summary + +We are proposing Alias - a semantic standard for identifying on-chain resources by human-readable qualifiers, supporting any type of data. + +## Abstract + +The dType Alias is a system for providing human-readable resource identifiers to on-chain content. A resource identifier is based on the type of data (identifier provided by dType, [EIP-1900](http://eips.ethereum.org/EIPS/eip-1900)) and the data content (identifier provided by a dType Storage Contract, [EIP-2157](http://eips.ethereum.org/EIPS/eip-2157)). It is a universal way of addressing content, supporting any type of data. + +## Motivation + +There are standards that currently address the need for attaching human-readable identifiers to Ethereum accounts, such as [EIP-137](http://eips.ethereum.org/EIPS/eip-137). These standards are an attempt to bring domain names to Ethereum, following the same format as DNS: `subdomain.domain.tld`. This leaf -> root format is unintuitive and contradicts the semantic meaning that `.` has in programming languages, which is a root -> leaf connection (e.g. in OOP, when accessing an object's property). A more intuitive and widely used approach is a root->leaf format, used in file browsers, hierarchical menus, and even in other decentralized systems, which give unique identifiers to resources (e.g. `0x56.Currency.TCoin` in [Libra](https://medium.com/r/?url=https%3A%2F%2Fdevelopers.libra.org). + +Moreover, [EIP-137](http://eips.ethereum.org/EIPS/eip-137) is not flexible enough to address smart contract content, which can contain heterogeneous data that belongs to various accounts. For example, a `PaymentChannel` smart contract can have an domain name. However, the `Alice-Bob` channel data from inside the smart contract, cannot have a subdomain name. Having uniquely identified, granular resources opens the way to creating both human and machine-readable protocols on top of Ethereum. It also provides a basis for protocols based on functional programming. + +This ERC proposes a set of separators which maintain their semantic meaning and provides a way to address any type of resource - from Ethereum addresses, to individual `struct` instances inside smart contracts. + +Imagine the following dType types: `SocialNetwork` and `Profile`, with related storage data about user profiles. One could access such a profile using an alias for the data content: `alice@socialnetwork.profile`. For a `PaymentChannel` type, Alice can refer to her channel with Bob with `alice-bob.paymentchannel`. +This alias system can be used off-chain, to replace the old DNS system with a deterministic and machine-readable way of displaying content, based on the dType type's metadata. + +## Specification + +The dType registry will provide domain and subdomain names for the resource type. Subdomains can be attributed recursively, to dType types which contain other complex types in their composition. + +We define an `Alias` registry contract, that keeps track of the human-readable identifiers for data resources, which exist in dType storage contracts. +Anyone can set an alias in the `Alias` registry, as long as the Ethereum address that signs the alias data has ownership on the resource, in the dType storage contract. Storage contract data ownership will be detailed in [EIP-2157](http://eips.ethereum.org/EIPS/eip-2157). An owner can update or delete an alias at any time. + +```solidity +interface Alias { + + event AliasSet(bytes32 dtypeIdentifier, bytes1 separator, string name, bytes32 indexed identifier); + + function setAlias(bytes32 dtypeIdentifier, bytes1 separator, string memory name, bytes32 identifier, bytes memory signature) external; + + function getAliased(bytes1 separator, string memory name) view external returns (bytes32 identifier); +} +``` + +- `dtypeIdentifier`: Type identifier from the dType registry, needed to ensure uniqueness of `name` for a dType type. `dtypeIdentifier` is checked to see if it exists in the dType registry. The dType registry also links the type's data storage contract, where the existence and ownership of the `identifier` is checked. +- `name`: user-defined human-readable name for the resource referenced by `identifier` +- `separator`: Character acting as a separator between the name and the rest of the alias. Allowed values: + - `.`: general domain separation, using root->leaf semantics. E.g. `domain.subdomain.leafsubdomain.resource` + - `@`: identifying actor-related data, such as user profiles, using leaf->root semantics. E.g. `alice@socialnetwork.profile` or `alice@dao@eth` + - `#`: identifying concepts, using root->leaf semantics. E.g. `topicX#postY` + - `/`: general resource path definition, using root->leaf semantics. E.g. `resourceRoot/resource` +- `identifier`: Resource identifier from a smart contract linked with dType +- `signature`: Alias owner signature on `dtypeIdentifier`, `identifier`, `name`, `separator`, `nonce`, `aliasAddress`, `chainId`. + - `nonce`: monotonically increasing counter, used to prevent replay attacks + - `aliasAddress`: Ethereum address of `Alias` contract + - `chainId`: chain on which the `Alias` contract is deployed, as detailed in [EIP-155](http://eips.ethereum.org/EIPS/eip-155), used to prevent replay attacks when updating the `identifier` for an alias. + +Content addressability can be done: +- using the `bytes32` identifiers directly, e.g. `0x0b5e76559822448f6243a6f76ac7864eba89c810084471bdee2a63429c92d2e7@0x9dbb9abe0c47484c5707699b3ceea23b1c2cca2ac72681256ab42ae01bd347da` +- using the human identifiers, e.g. `alice@socialnetwork` + +Both of the above examples will resolve to the same content. + + +## Rationale + +Current attempts to solve content addressability, such as [EIP-137](http://eips.ethereum.org/EIPS/eip-137), only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly. + +With [EIP-1900](http://eips.ethereum.org/EIPS/eip-1900) and [EIP-2157](http://eips.ethereum.org/EIPS/eip-2157), general content addressability can be achieved. dType provides type information and a reference to the smart contract where the type instances are stored. Additionally, Alias uses the semantic meaning of subdomain separators to have a [intuitive order rule](https://github.com/loredanacirstea/articles/blob/master/articles/Flexible_Alias_or_Why_ENS_is_Obsolete.md). + +Multiple aliases can be assigned to a single resource. Either by using a different `name` or by using a different `separator`. Each `separator` can have a specific standard for displaying and processing data, based on its semantic meaning. + +## Backwards Compatibility + +Will be added. + +## Test Cases + +Will be added. + +## Implementation + +An in-work implementation can be found at https://github.com/pipeos-one/dType/blob/master/contracts/contracts/Alias.sol. +This proposal will be updated with an appropriate implementation when consensus is reached on the specifications. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).