Solid implementation! Expedient gas, block is used as tx_proof (ok).

First of all, a great work! Learned from it.

Some notes. Not the major ones, but anyway.

Uses additional `callback` param in lite-client's `check_block` message to simplify transaction-checker. Not sure if it's allowed or not.

`verify_block_signatures` doesn't check if the same signature is used multiple times. So in theory it is possible to achieve any required total weight having only one valid signature.

Transaction-checker silently accepts all bounced messages, so if associated lite-client failed to verify block, excesses will be accumulated on transaction-checker smc.

Gas consumption:
When you parse label of `HashmapAug` you generate new cell.
Creating new cell is one of the most expensive operation. It consumes 518 unit of gas

1) In Transaction-checker you ignore `current_block` and send to lite-client contract transaction proof and then get it back. In common cases transaction proof will have many cells, because we go though account and lt aug-dictionaries.

Sending many cells is pretty expensive operation.
https://github.com/ton-blockchain/token-contract/blob/main/misc/forward-fee-calc.fc#L21C67-L21C75
https://tonviewer.com/config#24

It's better to have block proof.

2) In Transaction-checker you ignore bounced messages. It's better to return change to original sender.

extract_merkle_proof doesn't seem to validate that the merkle_proof's hash corresponds to the data it contains. The hash in a merkle proof cell can't be trusted on its own

@Daring Yak
Can confirm, nevermind my comment :)

`prev_key_block == ctx_current_seq_no` is good check.
But `ctx_current_epoch_until == next_utime_since` is not good because:
1) `utime_since` can be shifted
https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/elector-code.fc#L843-L848
2) We should consequently add mc key blocks without gaps. In current epoch currently known validators have power. In next epoch currently known validators may have no majority.

In function `check_block` in lite-client contract you don't check that the block in from currently known epoch. In current epoch currently known validators have power. In prev/next epoch currently known validators may have no majority.

Replay on `Daring Yak Feb 8 at 22:56`
I faced with it. Block 27746819, account 5555555555555555555555555555555555555555555555555555555555555555, lt 30931344000003.
https://testnet.tonviewer.com/block/(-1,8000000000000000,27746819)
Just ordinary block.