Info

Source on GitHub

https://github.com/qpIlIpp/blocklab-ton_contest_2

Smart Contract Address

kQAn6mblBx4yxWCdbLKCFNBFtTeI9HDyQf6PMzUeDKTRQQt8

Testing and Issues

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

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

Voting

by rating

Issues

Chic Dolphin Dec 26, 2019 at 19:34
Contract contains rating calculation logic. But no-one except owner can broadcast likes/dislikes. So owner has to be trusted.
Cuddly Hamster Dec 27, 2019 at 06:32
We understand this weakness of our solution that you had mentioned. Such implementation was chosen just because at the moment we do not have affordable UI tools for the user to interact with the contract directly from the current Telegram application. When telegram application will be fully integrated with TON blockchain we will easily upgrade our solution to make it user-friendly and truly decentralized. You can check our contract and you will see that it will be a really easy upgrade because initially, we were planning to support direct user interaction.
Chic Dolphin Dec 26, 2019 at 19:35
Also it doesn't hande internal messages, and so there is no way to query those rating from another contract.
Cuddly Hamster Dec 27, 2019 at 06:36
The answer from the other message explains that question too.
Clever Turkey Feb 11 at 03:16
I like the idea, but the current contract implemenation seems to be far from its achievement.

Currently, the contract is highly centralized, because only the owner can send queries to the contract and the owner can do anything. The contract has overall bad performance due to seqno check and is not able to handle more than one external request per blockchain block. Also, there is no any protection from cheating by voting multiple times.
Cuddly Hamster Feb 11 at 06:11
In the current version, Telegram does not provide a flexible mechanism for signing custom transactions via the client on UI. It's the main reason for implementing an entry point for the smartcontract in a centralized way with using telegram bot.
Further user signing can be added by storing the user's public key and seqno (nonce) and using global seqno just for the contract maintenance. In that case, we will solve the issue of speed and centralization.
The main idea of anti-cheating is based on the internal economics model. But you are right that double votes are prevented only on the UI level.
Extended cheat checking system can be easily added because of the smartcontract extendible architecture.
Nobody added any issues yet...