mirror of https://github.com/status-im/EIPs.git
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`
This commit is contained in:
Loredana Cirstea
Nick Johnson
parent
fc9dad1f82
commit
1529796d3a
|
|
@ -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/).
|
||||
Loading…
Reference in New Issue