Decentralized Name Service (DeNS)
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.
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.
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,
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 /
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.
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 - 50 000
- 2-nd place - 40 000
- 3-th place - 30 000
- 4-th place - 20 000
- 5-th place - 10 000
- participants who place below 5th, receive points and do not have “rejected” votes will receive a consolation prize of 1 500