RFC: Pure SC-based DNS system

[damip]

RFC: Pure SC-based DNS system

Rationale

Instead of hardcoding DNS into the layer 1, this RFC proposes fully implementing it in smart contract terms.

Initially we wanted to integrate DNS at layer 1 because we observed that ENS was only used in frontends and smart contracts that were not thought through to use it in the first place were not using it. Also because we want to ship the decentralized web as a native feature.

But I see multiple reasons to do it in SC:

• our L1 DNS concept is still not mature enough to be implemented "last second"
• the L1 does not need to know about DNS just like it doesn't need to know about on-chain websites => simplifies the L1
• we can heavily incentivize the use of the DNS by default by having Massa SC SDK, Massa Web3 and Massa Station expose a transparent Address type that supports both domain names and native addresses under the hood, and automatically resolves names to native addresses when required

Domain name format

Domain names are valid UTF-8 made of a prefix between 2 (included) characters and 100 (included) bytes long.

Allowed characters in the domain (inspired by DNS):

• anything alphanumeric https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric
• hyphen "-"

DNS smart contract standard

A DNS smart contract follows a standard and exposes the following functions:

• dns_resolve(domain: string) -> Result<NativeAddress> resolves a domain name string into a NativeAddress or fails with an error. Also works in read-only.
• dns_alloc_cost(domain: string, address: NativeAddress) -> Result<Amount> returns the simulated cost of allocating the domain. Also works in read-only.
• dns_alloc(domain, target_address, owner_address) -> Result<()> allocates a domain, expected to fail if the domain is already allocated.
• dns_free(domain) -> Result<()> frees an allocated domain, expected to fail if the domain is not allocated.
• dns_transfer(domain, target_address, owner_address) -> Result<()> transfers a domain.

The Root DNS smart contract instance is used natively by Massa SC SDK, Massa Web3 and Massa Station.
Anyone can deploy their own DNS for managing subdomains using the same standard.

Root DNS smart contract instance

Storage

The DNS smart contract stores a table domain_name -> (target_address, owner_address).
It manages domains without the .massa suffix which is stripped away by the tooling.
Multiple domains can point to the same address, but a given domain only points to one address.

Allocation

For example to allocate mydomain.massa to point to target_addr:

• the tooling strips the .massa and callsdns_alloc("mydomain", target_address, owner_address) on the root DNS SC which does the following:
  • check if mydomain is already allocated, fail if it is
  • check if there are enough coins in the call (see below) otherwise fail
  • create the entry mydomain -> (target_address, owner_address) in the datastore of the root DNS SC

The root DNS also exposes the dns_alloc_cost function that returns how expensive the allocation would be in coins.

The deposits are (does not include storage fees!):

• 2 characters: 10000 coins
• 3 characters: 1000 coins
• 4 characters: 100 coins
• 5 characters: 10 coins
• 6 or more characters: 1 coin

Liberation

The Root DNS implements the dns_free function.

It must be called from the owner address, transferring 50% of the coin deposit back to the caller. The function fails with an error if the domain does not exist.

Transfer

The Root DNS implements dns_transfer(domain, target_address, owner_address).

It must be called from the owner address, and transfers the domain to point to a new address with a potentially new owner.

Assumptions on mutability

Domain names are mutable by the owner address. If it is a smart contract, code-is-law applies: if the code does not allow mutability, then mutability cannot happen. On externally owned accounts, mutability is assumed.

Note that domain names can be "frozen" by transferring their ownership to address 00000000000000000000000.
From there they become de-facto immutable but remain allocated forever.

Tooling

L1

Nothing changes in the L1.

Massa Web3

The Massa Web3 lib provides domain name resolution facilities allowing transparent use of domains.
Domain resolution happens automatically in read-only.

Massa Station

Massa station transparently supports domain resolution (or normal addresses) in the browser URLs the same way as the SDK and massa web3. The same applies when transferring coins from the wallet towards a domain.

A name allocation plugin can be added to simplify the process of reserving domain names.

[leoloco]

In my opinion, simplicity should be a top priority for L1s. I'm convinced that Bitcoin's success has a lot to do with the willingness of the developers and the community to keep the system simple and understandable. Thus, I agree that a clear separation between the protocol layer and the applicative layer is a good idea.
Concerning the specification of the DNS, your proposal allows for both mutable and immutable storage. Thus it covers the use case targeted by this proposal, while allowing for broader use cases. One potential flaw of the previous proposal was that, if some vulnerability is discovered in some frontend/smart contract, there was no way for the application owner to prevent users from using it. If I understand rightly, your proposal allows for "free" even if the domain is immutable. Thus I think your proposal is superior, in the sense that it would allow the domain owners to stop their service if a vulnerability is discovered.
For security reasons, I would suggest that we show the user whether the domain he is accessing is mutable or not. This could take the form of a specific marker in the URL. Something similar to the green lock you can see in the address bar when you access a domain through HTTPS. Maybe this marker could be implemented by Massa station.

Overall I support this proposal.

[leoloco]

I was unsure of my understanding of this feature. But you are right indeed. The blacklist system you propose should be enough and respect the protocol/app separation.
Would it be conceivable to add a storage_free function so that immutable domain owners of vulnerable frontend/sc can erase their content? The domain would remain allocated but the corresponding storage would be freed. Thus node runners won't have to store data "for nothing".

[damip]

For that case, as always Code is Law so if the domain is mutable but the SC owning it has only code to transfer property towards the address 00000000000000000, then it can only ever "burn" the domain.

Immutability actually mostly makes a difference for externally owned accounts: you have control over them unless they are immutable. In that sense we could even remove the immutability bit completely. In that case we would apply "code is law" for SCs and assume that EOWs can always freely modify their aliases

[damip]

Yes that would actually simplify things. I'm gonna remove the immutability bit

[damip]

Done

[sofiyasokolova]

very nice!

[AurelienFT]

https://github.com/AurelienFT/massa-dns little draft implementation. Not working with subcalls yet and need tests + a interface

[peterjah]

I will add another feature to this, Dns entries should respect the nft standard to allow trading secondary market like nft marketplaces