-
Notifications
You must be signed in to change notification settings - Fork 55
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* On-chain Domain Resolution * Comments * nits * Rename to remove diemID
- Loading branch information
Showing
1 changed file
with
71 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,71 @@ | ||
--- | ||
dip: 182 | ||
title: On-Chain Domain Resolution | ||
authors: Sunmi Lee (@sunmilee), David Wolinsky (@davidiw) | ||
status: Draft | ||
type: Informational | ||
created: 06/08/2021 | ||
last_updated: 06/015/2021 | ||
issue: https://github.com/diem/dip/issues/182 | ||
--- | ||
|
||
# Summary | ||
|
||
This DIP proposes adding VASP domain names on-chain and describes the domain name resolution process. | ||
|
||
On-chain domain name resolution allows organizations to define their product names, and for VASPs to look up other VASPs using the product names. | ||
Having a human-readable VASP identifier means we can enumerate all VASPs by their names, which is useful for merchant purposes as well as p2p transactions. | ||
For example, given a VASP domain name in a payment transaction, VASPs can look up where to route the payment correctly using an approved mapping of VASP identifiers to on-chain addresses. | ||
|
||
# On-chain data | ||
|
||
## Domain Format | ||
A VASP domain name is a unique string that is mapped to a VASP. Specification: | ||
* Case insensitive | ||
* Valid regular expression: `^[a-zA-Z0-9][a-zA-Z0-9.]*$` | ||
* Maximum length: 63 characters | ||
|
||
## VASP Domain | ||
|
||
``` | ||
resource struct VaspDomains { | ||
domains: vector<VaspDomain>, | ||
} | ||
struct VaspDomain { | ||
domain: vector<u8>, // Utf-8 encoded | ||
} | ||
``` | ||
* Field definitions: | ||
* `domain` - name of a VASP domain | ||
* The `VaspDomains` resource can only be published into an account with `Role == PARENT_VASP_ROLE_ID` | ||
* The `VaspDomains` contains a list of `VaspDomain` structs that are associated with a VASP. It is possible to register more than one VaspDomain for a given VASP | ||
* Only the Treasury Compliance (TC) account (address `0xB1E55ED`) can manipulate a `VaspDomains` resource: | ||
* Only TC account can create and publish a `VaspDomains` resource | ||
* Only TC account can add, remove or update a `VaspDomain` within `VaspDomains` resource | ||
* `VaspDomains` resource will be created in an empty state as part of creating a `ParentVASP` account resource, and existing `ParentVASP` accounts without `VaspDomains` will have the resource instantiated by the DiemRoot account | ||
* In order to register a VASP domain, a VASP needs to submit a request to Diem Association. After approval, Diem Association will use TC account to issue an on-chain transaction to register a VaspDomain. Diem Association will ensure uniqueness of domain names across all VASPs. | ||
|
||
## VASP Domain Events | ||
|
||
The Move contract that manages domains must emit an event every time VaspDomain is created, removed or updated. Those events are critical for applications to be able to efficiently index existing VaspDomains. | ||
An application can be built to listen for these events to construct a mapping of domains to VASP accounts for lookup of onchain addresses given a VaspDomain. | ||
While the domains are published into VASP account resources, domain events are published under the TC account. We consolidate events under a single account to allow indexers to follow a single event stream. | ||
|
||
To store events, `VaspDomainManager` resource is published under the TC account. | ||
|
||
``` | ||
resource struct VaspDomainManager { | ||
/// Events are emmitted | ||
vasp_domain_events: Event::EventHandle<Self::VaspDomainEvent>, | ||
} | ||
struct VaspDomainEvent { | ||
removed: bool, | ||
domain: VaspDomain, | ||
address: address, | ||
} | ||
``` | ||
|
||
This comment has been minimized.
Sorry, something went wrong. |
||
* Fields definition: | ||
* `removed` - `true`, if VaspDomain was removed, `false` if it was created or updated | ||
* `domain` - exact copy of `VaspDomain` that was added/removed from `VaspDomains` resource of a VASP account | ||
* `address` - address of a VASP account where `VaspDomain` was added or removed |
I think it is worth summarizing that publishing a new domain has two parts: 1. publish a VaspDomain resource to the ParentVasp address by T&C role, 2. update a VaspDomainManager resource within the T&C address (with what?).