Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On-chain Domain Resolution #187

Merged
merged 4 commits into from
Jun 25, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions dips/dip-182.md
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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any recommendations on how a VASP should pick a domain name? For example, should company ABC that already has abc.com use that as a domain name? Or perhaps just abc?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is appropriate scope within a DIP.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to say this is something the Diem Association will provide rules on, however, I think some guidance somewhere is important. Where will that guidance exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe on VASP onboarding guide? I agree it shouldn't be on this DIP

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there were some hiccups on the guide that are being worked on. There is some content in the operators-runbook repo.

* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the number of VASPs is not too large, it should be fine for the Diem Association to handle registration, expiration, uniqueness, re-use, and other characteristics. Before this DIP can move to Accepted, I think we will need to have commitment from the Diem Association that these responsibilities can be taken on.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who do we need to talk to ? @aching @davidiw

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be pretty quick conversation with @pdhamdhere .


## 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,
}
```

* 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