TON Trustless Bridge Challenge

Overview

TON mainnet is configured in such a way to provide reasonable fees and (almost) unlimited throughput through asynchronous execution, without compromising decentralization or censorship-resistance. However there are applications where limited throughput is acceptable if it results in lower fees and much faster finality. TON-based network can work in this regime too.
Because of this, we can get the best of all possible regimes by spawning separate blockchains with specific configurations and binding them into one borderless ecosystem with bi-directional trustless bridges.

All data in TON, in particular blocks, proofs, transactions is stored in Bag-of-Cells for which TVM (virtual machine for transaction execution) is very efficient for work with cells.

Task description

Given two networks, in particular TON Testnet and a specially deployed Fastnet, your task is to implement a trustless bridge in order to prove the existence of a transaction from one network to a contract on another.

You must provide the following components:
1. Lite-client smart-contract that syncs a chain of keyblocks of the counterparty network, knows the current configuration of the counterparty network (particularly ConfigParam34 with the list of current validators) and can check the validity of new blocks by checking signatures.

This contract should handle internal messages (from any user) with the following scheme:

new_key_block#11a78ffe query_id:uint64 block:^Cell signatures:^Cell = InternalMsgBody;
check_block#8eaa9d76 query_id:uint64 block:^Cell signatures:^Cell = InternalMsgBody;

where a block is Cell with the counterparty network masterchain block and signatures is a hashmap with signatures for that block (exact format at participant discretion).

Block in new_key_block message may have all unused branches pruned, however the block header and McBlockExtra field that contains configuration contract state (in particular 34 config) should be presented.
Block in check_block message may have all unused branches pruned.

Upon receiving new_key_block message, contract should check that the block corresponds to currently known epoch, that it is indeed a keyblock, it has valid signatures, loads new epoch parameters (validators), updates currently known epoch and messages back ok#ff8ff4e1 query_id:uint64 block_hash:uint256 = InternalMsgBody; confirmation. If the block is invalid (or does not correspond to currently known epoch) it should be rejected.

Upon receiving check_block message, contract should check that the block corresponds to currently known epoch and correctly signed. If true, the message correct#ce02b807 query_id:uint64 block_hash:uint256 = InternalMsgBody; should be sent back to sender, otherwise request should be rejected.

Besides smart-contracts, the solution should contain a script that gets data from lite-server and builds new_key_block message.

2. Transaction-checker smart-contract that can check proofs to confirm that a given transaction was committed in some masterchain block of the current epoch.

Transaction checker smart-contract should handle

check_transaction#91d555f7 transaction:^Cell proof:^Cell current_block:^Cell = InternalMsgBody;

and respond with

transaction_checked#756adff1 transaction:^Cell = InternalMsgBody;

the format of proof and current_block are at participant discretion (current_block should contain proof for itself), transaction can be a pruned branch cell. Transaction-checker may also interact with Lite-client to check the validity of a given block.

Besides smart-contracts, solution should contain a script that gets data from lite-server and builds check_transaction message for any given transaction in Masterchain.

Technical details

Environment

1. TON testnet with publicly available lite-servers, ton-http-api, explorers. Average masterchain block generation time: 2.4 sec. Duration of validator round: 4 hours. Max_main_validators:15
2. TON fastnet with publicly available lite-servers, ton-http-api, explorers. Average masterchain block generation time: 1 sec. Duration of validator round: 24 hours. Max_main_validators:1
3. Faucets for testcoins and fastcoins.

Tools

1. Smart-contracts can be written in Tolk, Tact and FunC at participant discretion.
2. We recommend using blueprint for testing and deployment. Test coverage is encouraged.
3. Scripts for message composition can be written in any common language, in particular python, rust, typescript, c++, go, kotlin, etc.

Solution

Solution should contain
1. Code of Lite-client smart-contract and script for generation messages for that contract with build instructions.
2. Code of Transaction-checker smart-contract and script for generation messages for that contract with build instructions.
3. Addresses of smart-contracts deployed in Testnet and Fastnet respectively, with the tx_hash of transactions that demonstrate both successful and unsuccessful checks of blocks and transactions.

Scoring

1. Correctness: the solution should correctly determine the validity of blocks and transactions.
2. Gas usage
3. The quality of the source code of your implementation of the smart contract (i.e., its readability and extensibility) will affect your final score.

Resources

1. Cells - documentation on cells.
2. block.tlb - formal specification of TON data structures. TL-B format overview
3. TON blockchain whitepaper - contains detailed descriptions of the blockchain structure and the block format.
4. https://docs.ton.org/trustless-interaction-with-ton_v1.1_23-05-15.pdf - documentation with TS example (note @ton/core code in doc may be outdated)

Testnet resources

Environment

Basic TON testnet

Average masterchain block generation time 2.4 sec. Duration of validator round 4 hours. max_main_validators:15.

Fastnet

Average masterchain block generation time 1 sec. Duration of validator round 24 hours. No workchains available. max_main_validators:1.

Faucets