EIPs/EIPS/eip-2193.md

---
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: 155, 1900, 2157
---

## 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](./eip-1900.md)) and the data content (identifier provided by a dType Storage Contract, [EIP-2157](./eip-2157.md)). 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](./eip-137.md). 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](./eip-137.md) 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](./eip-2157.md). 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](./eip-155.md), 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](./eip-137.md), only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly.

With [EIP-1900](./eip-1900.md) and [EIP-2157](./eip-2157.md), 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/).