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.
I was using TDD approach for developing the smart-contract and the most time I've spent on creating the tools for it. Now you may use compile/test scripts with unified options no matter with what smartcontract. It was a crucial thing because without this approach it is really difficult to see edge cases (форма освобождает).
> You can put try/catch around
Have you handled the case? Interesting, I'm going to check your submission then and will share my thoughts
> Also do you really need update code
In my case, it was done for development, as drop-data. But rather then drop-data, updating code I think should be kept. Updating code lies in a different dimension then interface consistency. Also there is no reasons to break existed interface, rather then extend it
+ Support for partial matches.
- Cycle in dnsresolve is useless, because pfxdict_get_q immediately returns suitable prefix.
- There is no way to completely delete expired domains.
- add_resource_record doesn't check that zone_cs matches whole domain, i.e. suffix is empty.
- Sanity checks can be performed client-side, because all requests are signed. There is no reason to do them in the contract.
- When domain is found, but category is not found the returned length must be non-zero.
- Ability to change code of an inited smart contract is very dangerous.
That's an actual problem. If I spot faulty transaction on chain, I can replay it and drain resources until you update seqno with another.
You can put try/catch around, but you'll loose error information. It would look like message was successfully processed. Alternative solution would be to send internal message to contract itself. So that seqno is updated, but the actual processing happens in another transaction. This way you can track the errors by following created message.
Also do you really need update code? It's a trust issue. If I make calls into your contract I expect it to behave the same way everytime. Code update introduces uncertainties, will it always behave the way I expect or maybe an author will change the rules later?