Info

Download ZIP (4.2 MB)

Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

65

Comments

The archive contains solutions for two tasks in Blockchain Contest / Smart contract competition: Automatic DNS resolver and Manual DNS resolver.

The documentation PDF file provided throughtly describes the smart contracts, their usage, behaviour, implementation details, and some considerations about their behaviour possibilities.

The archive also contains small pleasant bonus for writing Fift and FunC scripts in Notepad++ (until some IDE arrives), at least for me it considerably helped writing the code.

Cheers!
I am happy to note the fact that due to latest change in TON lite-client source-code, now runmethod provides c7 to the getter, therefore now dnsresolve actually accounts for current time when resolving :-)
You have not added any comments yet...
by rating

Issues

Clever Turkey Nov 4, 2019 at 19:08
Manual DNS:
+ Support for storing of a domain and its subdomains.
+ Support for whole domain and single subdomain changes.
+ Ability to completely delete expired domains.
+ Support for different value types.
+ Well documented code.
+ Pretty usage and output in .fif scripts.
10
Shiny Giraffe Nov 4, 2019 at 19:22
Continuation of the response to the Judge (due to 1000 characters limit, for AUTOMATIC DNS):

* (About the possible hash collision): It may be possible also to use chained 32-bit expiration dict -> prefix dict, but that would incur way higher storage costs, but will result in 100% collision resiliency, or inner linked list (may increase gas costs). Nevertheless, despite very slim probability of the collision the point is reasonably valid.

* (About the prices change impossibility): That way, it is not possible to allow subsequent price change without introducing contract owner - which may effectively move "automatic" resolver into a more "automated" one. But allowing owner just to change prices may be somehow reasonable, if to be required. I had doubts about impossibility of subsequent price change, but aforementioned points outweighted this problem for my vision.
Clever Turkey Nov 4, 2019 at 19:09
Automatic DNS:
+ Checks for domains expiration in dnsresolve.
+ Support for sending back excessive grams.
+ Support for storing of a domain and its subdomains.
+ Automatic deletion of expired domains.
+ Manual deletion of expired domains.
+ Correct price calculation.
+ Domain name sanity checks.
+ Ability to receive donations.
- If two domains with the same 32-bit hash expire at the same second, one of them will be never deleted.
- There is no way to change prices after the contract is created.
10
Shiny Giraffe Nov 4, 2019 at 19:23
Thank you for your long-awaited judgement. Nevertheless, I have several comments concerning the negative points:

* Concerning the 32-bit hash, it is a reasonable compromise of storage costs and anticollision. The hash length may be increased to decrease probability of colliding if extremly heavy-duty is to be expected, which will increase storage costs. 32-bit hash should provide collision resilience for several million registration per second (outlined in documentation, not only 32 bit hash is in dict, but only 32-bit time prefix). .....

* About the prices changing, the automatic DNS resolver has no owner by design - it is a self contained script, that works by itself on strictly defined manner in code (thats how I know "automatic" strictly is defined). .....

!!! I have more comment to say concerning the points, so continuation is in separate reply to MANUAL DNS (due to 1000-characters limit)
Clever Turkey Nov 4, 2019 at 19:55
#issue9032
> 32-bit hash should provide collision resilience for several million registration per second
No, there will be collisions if approximately 2^16 domains are registered in the same 5 seconds. See birthday paradox. The main concern is that such colliding domain will stay forever. The simplest way to mitigate this is to allow manual deletion of expired domains.

> that works by itself on strictly defined manner in code
It is "automatic" because of the way new domains are added. You are right that owner could break the contract with price changes, so there should be sanity checks to not allow fast or big price changes. But inability to change the prices could easily lead to smart contract freeze if gas usage will grow with the smartcontract data grow and the contract will be unprofitable.
10
Shiny Giraffe Nov 9, 2019 at 18:24
Thank you for your precise clarifications.

Was very silly of me to forget about B.P. (precisely, 77163 regs = 50% coll. prob. for 2^32), and block time interval. Yes, that would be the simplest solution. The closest possible migitiation is that expired domain can be registered again and therefore be used and eventually purged, with obvious drawback (registration and storage fee is to be paid).

!!! I could not stop thinking about a good solution to this, so I designed effective algorithm, which is now attached as a picture. !!!

Very good point, as a security researcher I planned and developed SCs from a "security-first" point of view of SC itself. I did not actually expect contract's gas usage to highly explode due to primary prefix tree or expiration timer tree grow (as the structures are highly optimized and, as I understand, have (sub-?)logarithmic time complexity), however I therefore agree that being able to change prices may be crucial.
D
Deleted Account Oct 19, 2019 at 07:39
Pretty cool solution with counting delimiters and using it as prefix.
2
Shiny Giraffe Oct 19, 2019 at 17:14
Hello, thank you for nice words. Initially this counter was introduced just to filter names with multiple zero-code characters, but later, at the penultimate day, it was repurposed with a very nice result.
Very cool submission (properly handles different cases, follows guidelines, has documentation, prefix dict workaround). One thing i would point out is that Auto-DNS does not have any way for owner to withdraw money from it.
Good luck!
1
Shiny Giraffe Oct 22, 2019 at 09:08
Thank you for your review.

As per contest requirements I expected that automatic (not automated, automatic, which means that operates without any interaction from controlling operator) resolver does not actually have owner, it is operated entirely by itself and therefore does not permit balance withdraw (having owner who can withdraw balance can put the automatic nature at risk, because the owner could cause harm to contract by withdrawing too much from it).

However, I too was in doubt about this point, but considered finally that registration price is anti-spam/flood measure - that is, to register domain you need to pay some reasonable value.

But I appreciate your point, it may be possible to calculate safety margin (balance minus storage expenses) and allow owner to withdraw some safe amount of funds not threatening contract functionality.
Nobody added any issues yet...