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
https://contest.com/docs/TrustlessBridgeChallenge
According to the task: `transaction can be a pruned branch cell.`
But you use
```
int transaction_hash = transaction.cell_hash();
;; scan for `transaction_hash` in block -> extra -> account_blocksint found? = extra.block_extra::scan_tx(transaction_hash);
```
You should use opcode `0 CHASHI`.
According to the task: `transaction can be a pruned branch cell.`
But you use
```
int transaction_hash = transaction.cell_hash();
;; scan for `transaction_hash` in block -> extra -> account_blocksint found? = extra.block_extra::scan_tx(transaction_hash);
```
You should use opcode `0 CHASHI`.
Looks OK to me. I like the `used` bitmap for duplicate signature checking.
- It feels unnecessary to take (untrusted) root_hash and seqno as arguments in both contracts, since they're being extracted from the to-be-validated block anyway
- Might want to check for global_id in case another network uses the same validators
- It feels unnecessary to take (untrusted) root_hash and seqno as arguments in both contracts, since they're being extracted from the to-be-validated block anyway
- Might want to check for global_id in case another network uses the same validators
Weight of signatures must be STRICTLY greater than 2/3 of total weight.
https://github.com/ton-blockchain/ton/blob/master/crypto/block/check-proof.cpp#L659
https://github.com/ton-blockchain/ton/blob/master/crypto/block/check-proof.cpp#L659
In `check_block` function you check:
` throw_unless(0xbad1, prev_key_block_seqno == state::validators_source);`
But it's better to check
- `prev_key_block_seqno from testing block` >= `first key block seqno in epoch`
- `prev_key_block_seqno from testing block` <= `last known key block seqno`
` throw_unless(0xbad1, prev_key_block_seqno == state::validators_source);`
But it's better to check
- `prev_key_block_seqno from testing block` >= `first key block seqno in epoch`
- `prev_key_block_seqno from testing block` <= `last known key block seqno`
Problem with gas usage.
In function `check_transaction` of Transaction-checker contract you go though all not pruned cells in transaction dictionary.
In functions `~shard_account_blocks::hashmap_aug::scan_tx` and `~account_block___transactions::hashmap_aug::scan_tx` you do not use `label` and remove it from the target key. In each fork of hashmap_aug you load left and right nodes. But it's pretty expensive operation. Opcode "XCTOS" consumes 126 units of gas.
In function `check_transaction` of Transaction-checker contract you go though all not pruned cells in transaction dictionary.
In functions `~shard_account_blocks::hashmap_aug::scan_tx` and `~account_block___transactions::hashmap_aug::scan_tx` you do not use `label` and remove it from the target key. In each fork of hashmap_aug you load left and right nodes. But it's pretty expensive operation. Opcode "XCTOS" consumes 126 units of gas.
You have already written in your code:
"TODO: potential DoS-vector: sending many request with not enough gas, that fulfill pending queries pool"
But it can be easy solved by checking msg.value. Each contract should check that msg.value > 1 ton + epsilon. And even if contract failed with out of gas than bounced message will be generated.
"TODO: potential DoS-vector: sending many request with not enough gas, that fulfill pending queries pool"
But it can be easy solved by checking msg.value. Each contract should check that msg.value > 1 ton + epsilon. And even if contract failed with out of gas than bounced message will be generated.
Proper implementation of lite-client, in tx-checker scan of all (unprunned) txses in the block (expensive but works for small blocks). Minor: no global_id checks.
Nobody added any issues yet...