Yona BTC Canonical Bridge explained
Overview of how Yona Canonical Bridge works and its components
Last updated
Overview of how Yona Canonical Bridge works and its components
Last updated
This section provides an overview of the Yona Canonical Bridge, a secure and efficient solution for cross-chain transactions between the Bitcoin and Yona networks. The bridge facilitates seamless asset transfers to Yona L2, broadening Bitcoin's use cases by introducing a programmable layer powered by Solana's high-performance virtual machine.
The bridge is made up of several components. The core of the Yona Canonical Bridge is the Yona Bitcoin on-chain Relay Program. This module is a Solana program implementing an on-chain Bitcoin blocks and transactions relay (light-client) needed for the proper functioning of the Yona Bridge.
This module is responsible for several processes at once:
Accepting and verifying Bitcoin block headers
Handling blockchain forks of varying lengths
Accepting and verifying Bitcoin deposit transactions with minting the corresponding bridged amount on Yona
Handling large Bitcoin transactions via splitting their data to multiple Yona txns
Burning BTC on Yona allowing further withdrawal on the Bitcoin side
Bitcoin Relay Program validates blocks based on the following criteria:
Correct PoW difficulty target
Possible difficulty adjustments
Previous block hash
Blockhash is lower than target (block's PoW)
Timestamp is greater than the median of the last 11 blocks
Timestamp is less than the current time plus 4 hours
Based on this functionality, the Bitcoin Relay Program is also responsible for deposit transaction processing. When a deposit transaction is relayed, the program checks its Merkle inclusion proof and then searches the outputs sent to deposit script pubkey. When such an output is found, its amount is added to the total BTC that will be minted to the selected Yona address.
To save on storage costs, the blockheader data is emitted as an Event from the program, and only sha256 fingerprint of that blockheader data is stored on-chain. Another storage costs saving mechanism used is pruning - only last X block headers are kept stored on-chain in a ring buffer. Where X is the pruning factor.
Yona Bitcoin on-chain Relay Program module is forked from https://github.com/adambor/BTCRelay-Sol. Yona On-chain Relay program inherits all functionality of the BTCRelay project with the following additional features required for Bridge:
Stores a certain amount of locked Yona BTC on PDA, which is released on users' deposits as opposed to the standard BTCRelay -Sol implementation, which could only just listen to the state of the BTC network. In fact, this is the core functionality of Bridge.
Parses submitted bitcoin transaction and checks that it is sent to the correct deposit address. The original version of the program only checked the fact that the transaction was included in the block, while the extended implementation adds parsing of this transaction. This allows to verify that the transaction was sent to the correct address and allows you to unblock BTC.
Handles large Bitcoin transactions by splitting their data into multiple Yona txns. in SVM the transaction limit is 1232 bytes and 1 Yona transaction can not always process 1 BTC transaction. This implementation allows breaking the data into pieces. After unloading, a separate method is called to check if the reassembled data corresponds to the transaction in BTC. Storing this data is quite costly, so Yona Network is considering pruning mechanisms with the replacement of old block data with new block data after every 250 blocks.
Processes bridge withdrawals by locking users' Yona BTC back in the program's PDA. This is due to the fact that Yona Canonical Bridge works on the principle of freeze/unfreezing assets logic rather than mint/burn. BTC on the Yona side is used as a gas token and has a fixed Supply corresponding to the total Bitcoin supply.
Relayer off-chain client is an executable file that has different modes of operation. When running the Relayer off-chain client executable file, 2 processes can be started in parallel, which are shown in the diagram (Blocks Relayer and Transaction Relayer). The user or administrator starts these processes manually, they are independent of each other but are important parts of the Yona Canonical Bridge operation:
relay-blocks (Blocks Relayer) - starts a process to monitor new Bitcoin blocks. When a new block is discovered, the off-chain client sends its header to the on-chain relay program.
relay-transactions (Transaction Relayer) - serves as an API for the Bridge UI. Waits for the receipt of Bridge Deposit transaction TXIDs from the UI. Once a new transaction ID is received, the off-chain client creates Merkle proofs and relays transaction to the on-chain program. The program validates transaction data and mints deposited BTC on Yona.
In the future, it is planned that the Relayer off-chain client will be a decentralised structure that will run as a separate component in parallel with the Yona Network State validation node software. Running the Relayer off-chain client will be at the discretion of the validators and is not a mandatory component for validators.
Bridge nodes implement p-of-n Schnorr signatures and FROST (Flexible Round-Optimized Schnorr Threshold Signatures) as a TSS to hold bridged BTC assets on Bitcoin L1. For more information about Bridge Nodes and how they work, see the following section "Bridge Nodes".
