dType Alias Extension - Decentralized Type System
ERC-2193 proposes a system for providing human-readable resource identifiers to on-chain content called dType Alias. This system is based on the type of data and the data content and supports any type of data. The motivation behind this proposal is to address the need for attaching human-readable identifiers to Ethereum accounts in a more intuitive and widely used approach, which is a root->leaf format. With the help of 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. Multiple aliases can be assigned to a single resource, and each separator can have a specific standard for displaying and processing data based on its semantic meaning. The proposal includes an in-work implementation, and it will be updated with an appropriate implementation when consensus is reached on the specifications.
Video
Original
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.
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: 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. 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); }
dtypeIdentifier
: Type identifier from the dType registry, needed to ensure uniqueness ofname
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 theidentifier
is checked.name
: user-defined human-readable name for the resource referenced byidentifier
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
oralice@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 dTypesignature
: Alias owner signature ondtypeIdentifier
,identifier
,name
,separator
,nonce
,aliasAddress
,chainId
.nonce
: monotonically increasing counter, used to prevent replay attacksaliasAddress
: Ethereum address ofAlias
contractchainId
: chain on which theAlias
contract is deployed, as detailed in EIP-155, used to prevent replay attacks when updating theidentifier
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.
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.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all