93 lines
6.9 KiB
Markdown
93 lines
6.9 KiB
Markdown
|
---
|
|||
|
|
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: Stagnant
|
|||
|
|
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](../LICENSE.md).
|