Info

Download ZIP (206.7 KB)

Testing and Issues

You can test this entry and submit issues during the testing period of the TON Trustless Bridge Challenge contest.

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

Voting

44
by rating

Issues

In your code:
`return (verified_weight * 3 >= 2 * ctx_total_weight);`
It should be
`return (verified_weight * 3 > 2 * ctx_total_weight);`
https://github.com/ton-blockchain/ton/blob/master/crypto/block/check-proof.cpp#L659
1
In `check_block_info` function you check that
```
throw_unless(504, gen_utime >= ctx_utime_since);
throw_unless(505, gen_utime <= ctx_utime_until);
```
But there can be some time shift:
https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/elector-code.fc#L843-L848

You should also check `prev_key_block_seqno`.
1
In Transaction-checker smart-contract you don't has handler for bounced messages.
1
Test coverage is very small.

Hard to read contract's code due to useless commented lines spammed everywhere.

Dump and strdump instructions should be removed to improve readability and gas usage.
Windows 10
In lite-client you save total_weight and all validators. In `check_block_signs` function you should take in account only first `main` validator and use weight of the first `main` validators.
In lite-client on check_block/new_key_block messages you load block as ordinary cell. You solution can't work with merkle proofs.
Cute Giraffe Feb 10 at 05:42
We need full data on some branches of the incoming block and we only trust them by checking the signatures. So I thought a merkle proof of the root cell should be useless as we cannot trust the stored hash. Also the task desc only states that the unused can be pruned.
In Transaction-checker smart-contract on `check_transaction` message you only proof that `target_tx` is in `cur_block`. You don't check that `target_tx` is transaction indeed.
Cute Giraffe Feb 10 at 05:36
The task description stated that the tx can be a pruned branch. So I thought that we do not necessarily have access to its details to check them.
Implemented basic functionality with a few security issues: no main_validators logic, no signature deduplication, no prev_key_block/global_id checks. In transcation checker "hints" approach is used - it is unsafe.

More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment
Nobody added any issues yet...