EIP2193 - dType Alias Extension - Decentralized Type System

# 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) and the data content (identifier provided by a dType Storage Contract, 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. 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 (opens new window).

Moreover, 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: [email protected]. 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. An owner can update or delete an alias at any time.

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);
}

1
2
3
4
5
6
7
8

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. [email protected] 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, 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, only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly.

With EIP-1900 and 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 (opens new window).

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