Info

Dreamy Pug
Author
Download ZIP (8.4 KB)

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

22

Comments

Dreamy Pug Oct 19, 2019 at 20:18
> - dns-resolver-manual-update-pk.fif assumes old owner has access to new private key, when only public key is required

Agree, it looks like an issue, but no one says that the private key should be in place in the new .pk input file. You can provide a .pk file with actual new public key in place and zeroes in place of private key.
Referencing to requirements again, there is nothing about input data format for public key change, so I decided to go the easiest way (for me personally) for demoing purpose - read keys from files.
Dreamy Pug Oct 19, 2019 at 20:19
> - why would anyone trust a contract that can change its code at any moment?

Because a one want to use this smart contract as a base for his own smart contract. This way he can change the code, debug multiple code versions with ease and in the final code version remove code update action from the smart contract at all.
I left code update action intentionally following existing implementation at https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/config-code.fc#L114
You have not added any comments yet...
by rating

Issues

Clever Turkey Nov 4, 2019 at 19:40
Manual DNS:
+ Mostly good baseline implementation.
- There is no way to completely delete expired domains.
- Returns number of bytes instead of number of bits.
- Ability to change code of an inited smart contract is very dangerous.
10
Dreamy Pug Nov 6, 2019 at 14:22
Thank you for the review.
Let me reply on you remarks.

- There is no way to completely delete expired domains
I focused on functionality which is required by description. There is nothing in TON_Contest.txt about deletion.

- Returns number of bytes instead of number of bits.
Right, this is the way I understand requirement in TON_Contest.txt. Now, when I read it again I see that the text is quite confusing and number of bits is expected.
"If the subdomain is found, the smart contract should return (8m, dns-record-value), where *m* is one plus the number of bytes in the subdomain found."

- Ability to change code of an inited smart contract is very dangerous.
Agree, I should have delete this functionality before submitting the code, but it really helped me a lot in debugging.
Clever Turkey Nov 6, 2019 at 17:01
#issue9046
> I focused on functionality which is required by description.
> There is nothing in TON_Contest.txt about deletion.
A contract without deletion of expired domains is not production ready and can't be deployed or used, because it stores data forever and someday it will run out of money. Contest description mentions that each domain has expiration time and clearly there is no reason to store domain data after expiration.

> Agree, I should have delete this functionality before
> submitting the code, but it really helped me a lot in debugging.
Exactly. It is good for debugging, but bad for a smart contract that needs to be trusted.
10
Dreamy Pug Nov 7, 2019 at 08:35
I agree that delete operation and expiration time for each record should be implemented in a production ready smart contract, but following strictly by TON_Contest.txt, expiration time is mentioned in the requirement of Automatic DNS, not Manual DNS ("...or to extend the registration of the subdomain. A special get-method may be defined to inspect the expiration time of any registered subdomain.").

Perhaps, I treat requirements too strictly and should have apply a common sense, however I took the way to implement exactly what is requested (I'd even say nothing more than requested) with the best quality I can.
Chic Dolphin Oct 18, 2019 at 14:45
No exception should be thrown handling external message after it was accepted. That message can be replayed by anyone draining contract out of funds.

https://gist.github.com/rainydio/b59f20c2342c71c8d7df34e5795cf821
Dreamy Pug Oct 19, 2019 at 19:31
1) I accept message only after a signature is validated successfully. It is unlikely to happened that someone send a correct message (correct in term of signature) had set unknown action value. Because the one who send a message with correct signature is most likely the owner, and the owner must be aware about actions his smart contract supports. In case the owner indeed send unsupported action, the smart contract will throw an error, which is OK in me opinion because it indicates a specific error 32. This way the owner knows what went wrong on his smart contract during execution.
2) I wrote this code basing on existing ton blockchain code, in which error is being thrown (https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/config-code.fc#L123) after accept message (https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/config-code.fc#L103).
Huge Giraffe Oct 18, 2019 at 21:50
- subdomains can't be deleted, which is an issue because if you have "a.b" registered, and want to instead have "a.b.c" and "a.b.d", you are out of luck ("a.b" is a prefix of a new key),
- dns-resolver-manual-add-single.fif only supports addresses as values
- dns-resolver-manual-update-pk.fif assumes old owner has access to new private key, when only public key is required
- why would anyone trust a contract that can change its code at any moment?
Dreamy Pug Oct 19, 2019 at 20:17
> - subdomains can't be deleted...

I don't delete subdomains, please clarify where do you see an issue.

> - dns-resolver-manual-add-single.fif only supports addresses as values

Correct, but again what is the issue here? TON_Contest.txt does not specify format of DNSRecord, it just specifies an output format, saying that smart contract should return a cell containing DNSRecord if category has found, or cell containing the an entire dictionary (HashmapE 16 ^DNSRecord). I've met these requirements I believe.
As I specified in the README, I choose to hold addresses within DNSRecord as this is the simplest in my mind to demonstrate how my smart contract works. Obviously, dns-resolver-manual-add-single.fif can be easily adjusted to any DNSRecord format, once this format is clarified.
Nobody added any issues yet...