EIPs/eip-2193.md at master

Force usage of included LICENSE file (#5055 )

* Include LICENCE in the Jekyll build

* Replace old licence link with new and improved licence link

* Add note to EIP-1 mandating the new link

* Maybe this fixes it?

* Rename LICENCE so that jekyll picks it up

* Add original LICENCE file back

* Delete the markdown file

* Add Jekyll header

Hopefully the tooling still detects it as CC0

* Remove Jekyll header

* Maybe this will trick Jekyll and satisfy github?

* Remove config changes

* Enable incremental build

* Will it work if I rename it?

* I'll just paste the content of the licence into the file...

* Perhaps this will work

* Replace the licence file

* Fix false positive

Co-authored-by: Micah Zoltu <micah@zoltu.net>

* Resolve feedback

* Perhaps this might work

* It didn't work

This reverts commit 55116e15168fb20ae57dea97388bb260c0941465.

* Will licencee still detect this correctly?

* Jekyll Preamble in licence file

* Include it?

* Licence -> License, get rid of CC0.md

* Force wording of copyright waiver

* Formatting consistent with the rest of the list

* Spelling

* Escape

* Task failed successfully

* Fix two more links

* Will this render it?

* Perhaps this will work too

* .md essential

* Fix the issues Micah noted

Co-authored-by: Micah Zoltu <micah@zoltu.net>

2022-05-06 00:29:09 -07:00

6.9 KiB

Raw Permalink Blame History

eip	title	author	discussions-to	status	type	category	created	requires
2193	dType Alias Extension - Decentralized Type System	Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu)	https://github.com/ethereum/EIPs/issues/2192	Stagnant	Standards Track	ERC	2019-07-16	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) 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 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, 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.

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