Contest Proposal: Decentralized Name Service (DeNS)

Ever TON Dev Experience Sub-Governance
#1

Decentralized Name Service (DeNS)

Motivation

There is a clear and urgent need to provide human readable names to Free TON addresses.

Current solutions (for example a TON DNS, proposed here) are either a large smart contracts which maintains a full list of records, or a tree-like solutions which shards the list based on some parameters. Neither of these solutions are satisfactory due to a lack of scalability, high costs of maintenance, long search time, single point of failure and so on.

This contest participants will create a set of smart contracts as a completely distributed system, facilitate distributed, decentralized and fair name management system which does not require centralized record, nor a tree of domains or records with almost zero latency.

Current Contest Proposal is based upon TIP-2 proposal.

Architecture

Let’s consider a DeNS Root is a smart contract which contains a Code of the Name Identity Certificate (NIC) smart contract. The Root may has methods for Identity Registering, NIC Code Retrieval, Root PubKey retrieval, Version history, Change Owner and so on.

When a User wishes to register an Identity it is calling a “RegName” method in DeNS Root with the signed message of UTF-8 encoded string (Name) together with a Registration Bid (a hash of a Bid Value in TONs with some salt) with value attached 1 TON.

DeNS Root is taking its Public Key and a NIC Code inserts a Name, calculates the NIC address and checks if the address already has a NIC Code deployed by sending a bounced true message calling method “getName”. Return to User a Whois Information.

If it bounces or a registration period in Whois is less than 28 days DeNS Root will send the name into an Auction Smart Contract together with a Registration Bid Hash and a number of years before expiration. First bidder determines the duration of the auctioned name. Other users will be able to Bid for the same name but only for same duration with their Bids following exactly the same process. Auction duration is minimum 7 days per year of name duration but no more than 28 days. At the end of the Auction all participants will submit to the Auction contract a message signed from the address of the original bid together with their original bid price and salt. The winner of the auction will be determined by the highest bid per day and will pay the second higher price for the Name Certificate.

Once DeNS Root knows the Auction result it will wait (meaning of course waiting for someone to call it until registration period ends if the name certificate has existed before, else immediately deploy the NIC smart contract into the address calculated as a NIC Contract Code with a Name inserted into initial data and PubKey of the Owner passed in its constructor.

To resolve the Name any User can now call Get method “Resolve” of DeNS Root locally to obtain an Address. DeNS Root will use Code of NIC smart contract, a DeNS Root PubKey, insert any name they are wishing to resolve into NIC Code and calculate the address.

Since most of the time a user application will just cash the Code of NIC smart contract and DeNS PubKey, resolving any name is achieved locally with a simple address calculation, with no need for network connection at all.

Reserved names

DeNS should support a possibility to reserve some names if community decides so. The interface to the SMV Voting system should therefore be provided for reserved names allocation. Of course community should not be able to reserve names that has already been issued.

Proposed Reserved DeNS Root Names at start:

tonos, os — for names of system smart contracts
gov — for governance contract names
debot, bot — for top level debot names
dev — for development resources
defi — for defi resources
proxy — for proxy, vpn addresses
site — for TON sites
…

Example of NIC smart contract methods

Whois — sends all certificate data: a name, date of registration, owner PubKey

GetWhois is a whois getter

GetAddress by Type, for example — ADNL, Wallet,

RegName
GetResolve
ChangeAddress
ChangeOwnership

Free TON Name Identity Certificate convention

  • Format: any UTF-8 encoded string except for a dot (.) and slash (/) which are prohibited.

  • Only top level names are provided by DeNS Root, but any NIC smart contract can point into a next level of hierarchy which is divided by /

  • top-name/sub-name/

  • Each next hierarchy level can choose its own rules on how sub-name certificates are granted

  • The dot (.) is specifically prohibited as to not create confusions with a current internet domain system.

Terms

Contest participants should implement the above architecture using either Solidity or C++ languages. The contract system must be cost effective. All elements of the described above architecture should be provided, but participants are welcome to add, revise and modify it as long as it does not introduce additional points of centralization (such as registry smart contracts for instance) and provides a clear description and motivation of the proposed modification.

Any implementation must provide a DeBot interface to all system User interactions.
Contracts must have tests, deploy and make scripts and should be deployed into any working network with publishes addresses.

Reward Structure, Contest dates

  • Contest duration: 4 weeks
  • number of prizes – 5
  • the winners will receive the following prizes:
  • 1-st place - :gem: 50 000
  • 2-nd place - :gem: 40 000
  • 3-th place - :gem: 30 000
  • 4-th place - :gem: 20 000
  • 5-th place - :gem: 10 000
  • participants who place below 5th, receive points and do not have “rejected” votes will receive a consolation prize of :gem: 1 500
17 Likes
Decentralized Name Service (DeNS) — Part II
#2

What about name prolongation? I buy name on 2 years. Name expired. Someone buy name on auction. Me and my users after 2 years: O_o. Maybe i not understand something?

1 Like
#3

At the meetup dated 28 Jan 2021, the following decision was made on awarding the contest participants:

  • development time should be 4 weeks
  • number of prizes – 5
  • the winners will receive the following prizes:
    * 1-st place - :gem: 50 000
    * 2-nd place - :gem: 40 000
    * 3-th place - :gem: 30 000
    * 4-th place - :gem: 20 000
    * 5-th place - :gem: 10 000
  • participants who place below 5th, receive points and do not have “rejected” votes will receive a consolation prize of :gem: 1 500
1 Like
#4

I’ll add that it’s a potential attack vector on users:

  • Buy an expiring DeNS name of some contract/debot/site dealing with money on Auction for a sum that a previous owner can’t afford
  • Make a fishing contract/debot/site with same UI and DeNS name as a previous one
  • Profit!

On the other side, what prevents me to buy a name for 99999 years for a 1 TON bid while noone else is interested in this name?

In traditional domains it will cost me a lot, but here it seems that there is no point to bid for short durations (as duration has no influence on bid) or take part in Auctions at all, because why should I pay a price for a DeNS name that has a short duration and will cost me something and will expire with no guarantee of retaining it? It’s much better to take a name from someone who bought it for 99999 years and pay him off-chain for ownership keys.

I mean that Auctions in this schema are attributed to durations and giving that short durations are very uncomfortable (you are constantly at risk of loosing name), it will be a better strategy to stick to long durations only and never do expiring Auctions.

#5

Totally agree. I think this is contest not only about coding. Design also needs improvement.

#6

What is the problem of buying a Name for a long duration? If nobody is bidding means nobody is interested in this domain. Yes it is beneficiary for you to buy a Name for as longer period as possible.
Let’s consider the opposite. If it would be very easy to extend a Name period for the same amount of money it would be not beneficiary to have a long term registration at all. Everyone would just buy a Name for 3 months and by that ensuring the prolongation forever.
I do agree that we need to have a prolongation mechanism for the current Name owners but we can not just allow a prolongation for the same price. One of the ways to do that is having a non liner (say, quadratic function) of the increase in Name price on the next renewal, whenever this point is. This way you will still be interested in buying for as long as possible (since the longer you buy the less price will increase) but will also allow you to renew the Name just for a larger price. On certain point therefore the price will be increased so much it would be beneficiary for you to have the Name auctioned again (unless you bought it for a really long time).
And lastly, whats the problem of secondary market for Names? Why that would not be good if you would buy a Name from somebody else?

#7

Added Reward Structure, Contest dates

#8

What is the problem of buying a Name for a long duration? If nobody is bidding means nobody is interested in this domain.

Not interested or not yet interested or not yet know about this feature at all. The problem is not with long durations. It’s with a simplicity that removes importance from this decision.

I have an example.
Just open any existing MMO game and try to enter any sane name for a new game char. That will be quite a challenge.
And unlike traditional DNS domains, those “already in use” names are mostly inactive.
And best of them were locked in the first week of this game’s existence.

I see the same flaw here.

If you can get a name for eternity without paying enough price, then you will try to get a name for every idea that comes in your mind, instead of making a thoughtful decision. Just in case. Or as a joke. Or a sabotage. And in the end, that will be a net full of names that are locked and unused or even with totally forgot accesses.

Everyone would just buy a Name for 3 months and by that ensuring the prolongation forever.

And it’ still better than cheap long durations, because at least initial owner is ready to pay for prolongation and have access. In long durations it can’t be guaranteed.

And lastly, whats the problem of secondary market for Names? Why that would not be good if you would buy a Name from somebody else?

No, I didn’t mean that secondary market is bad. Just said that that it will be a preferrable way (long duration + secodary exchange) than (short duration + expiration auction) rendering expiration auctions mostly unneeded.

I do agree that we need to have a prolongation mechanism for the current Name owners but we can not just allow a prolongation for the same price. One of the ways to do that is having a non liner (say, quadratic function)

Will it be part of a contest? :thinking: If so, I’ll hold my alternative solutions until the contest.

1 Like
#9

Do I correctly understand that contest participant shall write the following SCs?

  • Root (certainly)
  • NIC (of course)
  • DeBot (well, yes)
  • Auction ← not sure about this one

And where the SMV contract or specification to be interacted with can be found?

Also I would kindly like to inquiry some clarifications about the requirements:

That means that if domain remaining registration period is < 28 days?

That means that number of years before expiration can be only integer? No fractions such as

or 1.5 years are possible?

So there is no ceiling on max period of registration? So that you can

and the auction period would be 28 days the same as for 4 years registration.

Is there any specifics on this procedure or is it at discertion of the contestant? There are several edge cases and auction participants behaviour is quite unobvious judging by the Game Theory.

The voting should be used for both adjusting reserved names list and deploying a NIC for the reserved name bypassing the auction?

This is super confusing. Alfa-numeric string already allows only a to z and 0 to 9 and does not allow dot and slash. In the example I can see that the dash (-) is allowed. Could you please clarify the requirements on this matter? Which non-alfa-numeric characters are allowed?

Is there any requirements on how addition of new NIC smart contract version should be done to the root? Having an technical owner (operator) would be convenient but it would be an additional point of centralization. Doing that through SMV voting (is it already ready yet?) would be fair to community but may slow down the development. A hard choice.

Addition: Should there be a central registry of ongoing auctions that could be listed by DeBot? Or you should find auctions by yourself using events / other ways?

#10

Indeed, that is confusing since in different definitions some chars may belong to alphanumeric and in some - not. The question is - do we want to sanitize the charset only in the top domain name or that rules are relevant for the whole URL, like it happens in PHP e.g. when FILTER_SANITIZE_URL is applied…

#11

guys, all token income from proposed platform will go back to subgov.

this means we can postpone discussions about “ideal and fair rules” etc., all “bad actors” will pay)

lets make the core implementation, and see how it works.
it’s unique and viable use-case which anyone never did before and which we are capable to make real^ so lets do it first. then improve after we do it)

#12

the problem of name squatting is solved by game theory btw, and the proposed auction model almost guarantees that the resulting price will really represent market value)

#13

But it’s not a contest about TIP-2 core implementation, it’s about making a service. I think noone argue that TIP-2 is great.
I just propose to add exact auction/bid/prolongation rules and restrictions implementation to contest criteria, so jury can select a best submission in terms of business logic too, not only in terms of code quality.

#14

Hi!
I would suggest to support two types of names: unqualified - debot/blackjack and qualified -debot/yahoo@askmeanything

Unqualified names obey already described rules :

  • registered for a some period of time
  • participates in the auction
  • at risk, at each auction.

In general, the wild wild west.

To mitigate domain name speculation, the monthly registration cost must be greater than a certain limit (for example, 100 crystals). I didn’t see this point in the proposal.

Qualified names follow different rules:

  • For such names to work, someone must initially register the name “yahoo@”
  • Qualified name is also sold at auction, but once and forever
  • The minimum price is REALLY expensive (say, 100K crystals)

Resolution of qualified name “debot/yahoo@askmeanything” is done as follows:

  • At first the name yahoo@ should be resolved as usual
  • Then the “yahoo@” contract resolves the name debot/askmeanything

Thus, the owner of yahoo@ name maintains its own “DeNS zone”.

As a result, we get:

  • Anyone who wants to register a name automatically, cheaply but without guaranties to keep it after next auction, can register an unqualified name.
  • Companies looking for maximum guarantees can register qualified names in its own DeNS zone
  • Anyone looking for something in between can buy a name in someone’s DNS zone if the owner provides such a service.

Now it looks like real life )))

#15

this is not a market mechanism. it won’t work.

#16

Correct. Auction is required.

Correct

true

not possible

true, true and true

SMV voting interface

Corrected to UTF-8

Easy choice. Upgrade to the smart contract should be only supported via SMV mechanism for community voting if any.

Central registries are prohibited )

1 Like
#17

Added following:

Small fixes

#18

@Mitja
The contest duration in PDF is specified as:

Contest duration: 13.02.2021 - 11.03.2021 23:59 UTC

But in the governance itself the contest dates are:

Contest date
February 15 - March 11, 2021, 18:59 UTC

That’s entire worth of 5 hours time :frowning:
Is it fixable?

#19

Fuck this - just emotion.

Since I have not started work from the very beginning of the contest, I need three more days to complete the deployment scripts, debot, the certificate prolongation mechanism and the schematic picture for the documentation.

Code without submitting.

#20

why? submit your work!

your work can’t be rejected IMO