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.
Info
Testing and Issues
Voting
by rating
Issues
Hey, good job.
Finally someone paid attention to storing the next validator set! It’s necessary to keep the bridge trustless; otherwise, the current validator set could submit a new key block with an arbitrary next validator set.
Finally someone paid attention to storing the next validator set! It’s necessary to keep the bridge trustless; otherwise, the current validator set could submit a new key block with an arbitrary next validator set.
macOS
In function `loadValidatorSet` you load and then save all validator set, but you should take only first `main` validators.
In function `validateSignatures` you take into account all of them.
In function `validateSignatures` you take into account all of them.
lite-client code looks so concise and clean.
Potential Issues:
1. no tests
2. lite-client stores prev, cur and next validator sets (not sure if that's a problem, there submissions who only store cur set or even just a hash of cur set)
3. It looks like whole block is sent to lite-client (no pruned branches)
Potential Issues:
1. no tests
2. lite-client stores prev, cur and next validator sets (not sure if that's a problem, there submissions who only store cur set or even just a hash of cur set)
3. It looks like whole block is sent to lite-client (no pruned branches)
Windows 10
Very clean code, lovely! Good work on the hashmap implementation
Some things I found
- I think you made it extra hard for yourself by using utime for epoch checking, checking block's prev_key_block_seqno would've probably been enough. To me it still seems correct, though it has some extra limitations.
- No need to create signed `data` every iteration in signature checking
- Transaction checker doesn't handle bounced messages to lite client, so might keep growing on check block failure
Some things I found
- I think you made it extra hard for yourself by using utime for epoch checking, checking block's prev_key_block_seqno would've probably been enough. To me it still seems correct, though it has some extra limitations.
- No need to create signed `data` every iteration in signature checking
- Transaction checker doesn't handle bounced messages to lite client, so might keep growing on check block failure
In function `validateGenTime` it's incorrect:
```
require(genTime > prevSince && genTime < currenUntil, "keyBlock relates to the epoch we don't know");
```
Because if `try_elect` failed (or was pauses in network), then current validator set will work even after `utimeUntil` moment.
https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/elector-code.fc#L843-L848
```
require(genTime > prevSince && genTime < currenUntil, "keyBlock relates to the epoch we don't know");
```
Because if `try_elect` failed (or was pauses in network), then current validator set will work even after `utimeUntil` moment.
https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/elector-code.fc#L843-L848
Gas usage:
1) In function `loadHashmap` you use loop `while (...) {...}` to parse labels of hash_map_aug. It can be done by one opcode: LDONES, UBITSIZE, etc.
2) In function `loadHashmap` you store all keys/values from hash_map_aug to "normal" hash_map. It's too expensive. Creating one cell takes about 500 units of gas.
1) In function `loadHashmap` you use loop `while (...) {...}` to parse labels of hash_map_aug. It can be done by one opcode: LDONES, UBITSIZE, etc.
2) In function `loadHashmap` you store all keys/values from hash_map_aug to "normal" hash_map. It's too expensive. Creating one cell takes about 500 units of gas.
Implemented basic functionality in Tact with an issue: no max_main_validators logic. No global_id/prev_keyblock checks (minor). In tx_checker full tx scan. Combination of Tact and full scan makes solution quite gas expensive.
More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment
More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment
Nobody added any issues yet...