Yona Research: Ways to Connect to Liquidity in Bitcoin

1. Introduction
2. The main types of bridges
3. BitVM and Taproot
4. BitVM2
5. OP_CAT as an opportunity to change the landscape of BTC-based bridges
6. OP_CTV
7. Bitcoin atomic swaps 
8. BitcoinOS
9. zkBridge
10. StarkWare M31 multiplication for Bitcoin
11. State Bridge
12. Yona Network Canonical Bridge
13. Conclusion

Introduction

One of the fundamental things for BTC L2 is to create a link to Bitcoin in order to be able to use the economic power embedded in BTC. In the case of L2, it is for Bitcoin that bridges occupy an important place in the architecture, as Bitcoin does not have the functionality of an L1 like Ethereum and cannot be used as an execution layer. So it is the bridges that are the core piece that ensures that the massive liquidity of Bitcoin is recycled.

And building this road from the two-dimensional world of Bitcoin to the three-dimensional world of Bitcoin-based DeFi is a non-trivial task. All BTC L2s, including Yona Network, are building it in different ways, creating many paths from Bitcoin to the DeFi ecosystem on top of it. So now let's take a look at how these paths are being built, some of which could become huge highways in the future.

The main types of bridges

Bridges can be compared to a normal real bridge, where assets and information can be moved as cargo from one side to the other. In the case of platforms operating without smart contracts, it is only a matter of moving liquidity as cargo. However, in the case of platforms operating with smart contracts on L1, the bridge enables not only the movement of goods, but also the exchange of different cultures with the connection of different protocols - because in this case it becomes possible to transfer various information, for example, the results of DAO votes, logs of smart contracts, etc. 

Accordingly, bridges can be classified into different types based on different criteria:

1. Unidirectional and bidirectional bridges:

• A unidirectional bridge allows funds to be sent only to the target blockchain, but not back to its own blockchain.
• A bidirectional blockchain bridge allows assets to be freely traded between two blockchains.

2. Operation according to the principle of liquidity operation or mint/burning:

• In the case of a liquidity-only operation, the bridge must have liquidity on both sides. This technique involves allocating an equivalent amount of the desired asset from the bridge's liquidity pools on the target blockchain instead of blocking and releasing assets for each transaction.
• Mint/burning technology involves locking a cryptocurrency on its own blockchain and simultaneously issuing a representative token on another blockchain, often referred to as the wrapped asset method. In the reverse process, the wrapped asset is burned and the bridge unlocks the appropriate amount of liquidity on the native blockchain.

3. Centralization Spectrum Bridges:

• Centralized Bridges: These bridges are like crossing a bridge controlled by a central authority. They aim for ease of use and speed, making them great for beginners or quick transfers, but it strongly resembles a traditional banking system. 
• Decentralized non-custodial Bridges: Think of these bridges as community-built networks, eliminating the need for a central authority. They have more complex architectures and can be slower than centralized solutions. This is currently the most common bridge design principle. Trustless Smart Contract Bridge, Proof-of-Stake (PoS) Bridge. 
• Federated bridges: are managed by a group of trustees or a committee balancing centralisation and decentralization.
  
  This can also include bridges that work with TSS (Threshold Signature Scheme), where there are multiple nodes and actions are confirmed when a minimum threshold of agreeing nodes is reached. For example, this could be 4/7 or 6/11 - when consensus agreement is reached. Federated bridges can also work according to this principle, especially in the case of cluster of nodes implementations with Intel SGX.

4. Verification Mechanism Bridges:

• Natively Verified Bridges: Merkle Proof Bridge, Smart Contract Verification Bridge
• Externally Verified Bridges: External Oracle Bridge, External Validator Bridge

5. Optimistic Bridges: When using optimistic bridging, the system assumes the accuracy of the transaction data provided and the correct amount. Within 7 days, nodes have an opportunity to challenge the accuracy of the data. If an issue is raised and fraud is proven, the bridged transaction will fail. However, if the issue is not claimed, the funds will be carried forward after the 7 day period.

• Optimistic Rollup Bridge: Assumptions are made regarding transaction validity, with the possibility of subsequent challenges.
• Optimistic PoS Bridge: Implements an optimistic approach combined with a PoS consensus mechanism for transaction assurance.
• Zero-Confirmation Bridge: Allows immediate transfers without transaction confirmation, assuming low-risk scenario
  
  One example of Optimistic Bridges can be considered BitVM2. Similar to Truebit and Arbitrum, BitVM2 makes use of optimistic computation where the computing party (operator) is assumed to be honest until proven guilty using so-called fraud proofs.

6. Atomic swaps: This type of bridging is different in that it facilitates direct peer-to-peer exchanges by eliminating the need for intermediaries. That is, unlike the bridge types listed above, atomic swaps operate on the basis of a direct exchange of assets between users.
7. State Bridge: Besides bridging assets, bridging only the Bitcoin network state to an L2 is also being explored. By synchronizing the Bitcoin state to another blockchain system, applications can read all Bitcoin transactions and UTXO state to enable certain applications in a "non-bridge" approach. E.g. Babylon is enabling PoS security with Bitcoin remote staking; Rooch is enabling non-custodial gaming apps with state binding.

In the case of BTC, the difficulty is that it is not a platform for smart contracts and does not allow verification of data at its level. Therefore, most types of bridges are not suitable to work in the BTC ecosystem. In addition, the UTXO model also introduces significant differences in the fundamental organization of bridges compared to the more familiar Account model. Then how can you bridge BTC and L2 on top of it?  Let's further look at current main implementations so that the key differences between the various technologies can be understood.

BitVM and Taproot

A unique attempt to extend the functionality of Bitcoin L1 is BitVM . The concept is based on the update of Taproot for Bitcoin. The concept behind BitVM is to extend the functionality of Bitcoin by executing programmes off-chain with the guarantee that the execution can be challenged on-chain with evidence of fraud. BitVM uses a model that combines fraud evidence with a query response protocol to process and verify transactions between two parties: a verifier and a checker. The verifier initiates a computational task and sends it through a channel established between itself and the verifier, who then validates the computation. After verification, the transaction is added to the overall package, which is stored in the underlying Bitcoin blockchain.

BitVM itself is operated by Taproot. Taproot Assets is a protocol for operating tokens on the Bitcoin network that uses Taproot's UTXO and related solutions Tapscript and taptweak to store information about the supply and balance of an asset in bitcoin transaction data. Taproot Assets records the information in the Taproot output of a transaction in the form of a so-called "sparse Merkle tree". In effect, Taproot Assets embeds a Merkle tree into the bitcoin transaction, proving the balance of a particular user and the total token supply. This tree in turn displays data from Universe, a repository that stores the entire history of the asset and is maintained by the token issuer.

And BitVM uses Merkle's tree to proving on the Bitcoin network, which is basically incapable of performing calculations to prove fraud. Using Taproot, it creates a NAND logic schema written to the Taproot transaction. That is, the Merkle tree in the transaction data becomes a NAND schema where each "branch" contains one of two possible values - 1 or 0. The on-chain computation is performed literally bit by bit, and the output of the previous "branch" becomes the input for the next. Transactions are constantly exchanged between the parties to the smart contract to reconcile the values. 

While it may seem possible that BitVM can be used to implement arbitrary logic off-chain, in practice the cost of performing a fraud proof in L1 grows rapidly with the size of the off-chain programme. This problem limits the applicability of BitVM to certain problems, such as BTC bridging with minimum trust. Another problem with BitVM-based bridges is that they must rely on pre-signed transactions. Since there are no covenants, the only options in a BitVM setup are 2 options: 

1. Pay the blocked UTXO to the proving party,
2. Burn the UTXO

Transactions with UTXO are a consequence of the peculiarity of the accounting logic in the Bitcoin network as opposed to the account model in EVM for example. If in the account model it is the change of funds on the balances that is tracked: after the execution of a transaction there is less on one account and more on another, then with UTXO one of the cardinal differences is that it is virtually irreplaceable (reminds you of NFT, doesn't it?). Each transaction spends one or more previous UTXOs and creates one or more new UTXOs. The total value of the new UTXOs must equal the total value of the spent UTXOs, and the difference between the two is the transaction fee paid to the miners. Thus, in a blockchain based on UTXO logic, each UTXO has a separate owner and can only be spent by the owner. 

And whereas in an EVM network a user says "I have some coins and I can spend them", in a Bitcoin network a user actually says "I have some UTXOs that allow me to spend some BTC". That is, the conceptual difference is that the account model updates user balances globally. The UTXO model only records transactional receipts.

Accordingly, a bridge based on BitVM logic works as follows:

• Users deposit UTXO, not BTC itself, into the BitVM-based bridge contract
• L2 "listens" to the bridge contract, and when it sees UTXO credited to its contract, it credits the corresponding amount of BTC in L2 to these users.
• The users on L2 have received their tokens and everyone is happy.

What about the reverse process? Tyler Whittle and Rijndael highlight this problem in their study "BitVM Bridges Considered Unsafe": the logic of the BitVM bridge is currently such that L2 users cannot claim funds locked in the bridge. There are only two paths of expenditure: 

1. Redirecting to the bridge operator 
2. Burn

This means that if the bridge operator fails, L2 participants can only hope that validators will burn the bridge. Therefore, it is critical to consider that the ratio of funds at the bridge from deposited BTC on L1 to mine BTC on L2 should always be 1:1. This point seems very simple and logical, but there are 2 problems: the slowness of BTC itself and the fact that BitVM relies on bridge operators that have a settlement period of weeks to months. And at some point, there could be an outflow that exceeds the collateral held by the bridge operator. Accordingly, this is really similar to optimistic rollups, BitVM being an optimistic-based protocol. Another potentially dangerous point was highlighted by Bob Bodily of Bioniq, who noted that BitVM in combination with other similar solutions risks overloading slow and expensive BTC. And accordingly, one could speculate that the economic model could break down due to ultra-expensive transactions.

Part of what may solve this problem is the addition to BitVM technology that Taproot is based on, which is DLC. DLC allows two parties to make conditional payments based on predefined conditions. The parties define possible outcomes, pre-sign them, and use those pre-signatures to make payments when Oracle signs off on the outcome. In such a scenario, Taproot's MAST provides sophisticated transaction logic in Bitcoin, while DLCs optimise transaction processes by moving most transactions off-chain, providing both security and privacy. With these technologies, transaction contracts are stored similarly to Ordinals, facilitating direct storage on-chain and execution by nodes off-chain. This approach allows contracts to be executed in a manner similar to Ordinals, combining efficiency with blockchain integrity.

BitVM2

BitVM2 is inspired by the BitVM paradigm proposed and makes significant improvements in terms of computational and communication complexity, as well as security. While in BitVM and similar designs, only a fixed set of operators can perform challenges, BitVM2 supports for the first time permissionless challenging, i.e., any user with a Bitcoin full node can challenge faulty operators. The main difference is that the original Bit VM design required up to 70 on-chain transactions (over a period of multiple weeks or even months in practice) to disprove a faulty operator, whereas BitVM2 requires only 3 on-chain transactions that can be executed within 1-2 weeks, achieving similar practical properties as Ethereum L2S.

At the same time, things are not as simple as in the case of Optimistic solutions on Ethereum. The fact is that BitVM2 implements the Succinct Non-interactive Argument of Knowledge ( SNARK ) verifier in the Bitcoin script. This allows complex computations to be efficiently verified within the constraints of Bitcoin, allowing for a wide range of potential applications.This is to reduce the size of the data: the SNARK verifier is divided into subroutines, each of which is small enough to be executed within a single Bitcoin transaction. This allows bypassing Bitcoin script size limitations and verifying complex calculations piecemeal.

Besides the roles of depositor (Alice) and beneficiary (Bob), in BitVM2 bridge protocol we additionally have the following participant roles:

• Operators (O1,..., Om) : The operators are responsible for executing a pre-agreed program f; in the case of our bridge, this is the peg-out process. The operators are assumed to be rational, i.e., they are profit-maximizing agents.
• Challengers: The challengers ensure the safety of the peg-out process by challenging an operator in case of misbehavior. Anyone can act as a challenger, including the operators. We assume that challengers are rational
• Signers (S1, .., Sn): A committee of n signers that is responsible for the correct setup of a BitVM2 instance for a pre-agreed program f. One of the n signers is assumed to be honest (existential honesty).

How BitVM2 works:

1. The operator commits to the correct execution of the programme by placing a transaction on the Bitcoin blockchain.
2. The execution of the programme takes place outside the blockchain, with the operator providing the result and the necessary proof.
3. If anyone suspects foul play, they can challenge the operator's claim within a predetermined period of time.
4. If there is a problem, the operator must disclose the intermediate states of computation on the blockchain.
5. The challengers can then refute the erroneous computation by executing the corresponding subroutine in the chain, demonstrating the discrepancy between the operator's claim and the actual computation.

OP_CAT as an opportunity to change the landscape of BTC-based bridges

It is worth noting that BTC L2 protocols are currently exploring a new technology proposed by Bitcoin Core developer Ethan Heilman and Botanix Labs chief engineer Armin Sabouri in EIP347 (aka BIP420)  in early 2024, which proposes the re-activation of the OP_CAT (Operation Concatenation) operator. This technology is also supported by Udi Wertheimer and Erica Wall of Taproot Wizards, which promotes Ordinals, and who believe it's time to reclaim this particular transaction code. Taproot Wizards is a collection of Ordinals that includes 3,333 cats created in honour of the bitcoin improvement proposal known as OP_CAT.

The idea behind the implementation is to redefine and extend the existing code called "OP_SUCCESS126" without the need for a hardfork of the chain. This will enable the realization of improvements in data interaction capabilities. OP_CAT will enable agreements that will in turn enable the realization of technical advances such as total unspent transaction output (UTXO), which will enable greater scalability. But in doing so, this move could potentially inadvertently increase the risk of Distributed Denial of Service (DDoS) attacks, adding another dimension for risk.

The same opinion is held by Udi Wertheimer with Erica Wall of Taproot Wizards promoting Ordinals , who believes it's time to restore this particular transaction code.

Above we described how UTXOs work, which determine who can spend their Bitcoins and how. And all CAT does is combine the two values together. So if you have "abc" and "def", CAT will combine those two values together to get "abcdef". With this combined feature, theoretically, Bitcoin could have many complex execution logics:

1. Multi-signature plus time locking, which can set more complex runtime unlocking conditions for multiple entities, multiple UTXOs, and time locks;
2. Recursion and loops allow multiple lines of script bytes to form recursion and conditional execution, and loop until a certain termination condition is met;
3. Modular application: common script logic can be extracted and reused in multiple pieces of program execution.

The introduction of OpCat can also greatly affect the BitVM's logic. When OP_CAT is introduced, BitVM fragments encapsulated off-chain do not need to execute completely and independently. The chain can summarise and update the status once the UTXO unlock conditions accumulate to a certain level. Obviously, combining script fragments can significantly reduce the number and cost of verification interactions in the chain.

OP_CAT itself is not a new feature, as it existed in the earliest versions of Bitcoin, but was disabled in 2010 due to its potential to be exploited by attackers. For example, reusing OP_DUP and OP_CAT could easily cause a full stack of nodes to explode when processing such scripts. This is partially addressed by the fact that the current OP_CAT proposal includes its inclusion only in tapscript, which has a limit of 520 bytes per stack element, which should not lead to the previous stack explosion problem. 

OP_CAT refers to so-called Covenants, which is a mechanism that allows the sender of a Bitcoin transaction to impose certain conditions on how the recipient can spend coins. And in the context of covenants, there's another interesting BIP-119 proposal from Jeremy Rubin, who introduced it in 2020 and proposed OP_CHECKTEMPLATEVERIFY (or OP_CTV for short).

OP_CTV

The idea behind OP_CTV seems to sound very simple: CTV will allow Bitcoin users to specify exactly how many bitcoins can be spent in a transaction and exactly where that bitcoin can be sent. This is made possible by creating predefined transactions that ensure that the corresponding UTXOs can only be spent if those predefined conditions are met during subsequent transactions. In this way, CTV offers a more reliable alternative to partially signed Bitcoin transactions (PSBTs). 

It seems like it sounds pretty simple and easy. But in fact OP_CTV could be a huge breakthrough for building BTC bridges due to the fact that such simple mechanics could allow organizing cold and warm wallet vaults and systems.

It seems like it sounds pretty simple and easy. But in fact OP_CTV could be a huge breakthrough for building BTC bridges due to the fact that such simple mechanics could allow organizing cold and warm wallet vaults and systems. OP_CTV eliminates the need for coordination and online signatories, and reduces the ability of the help desk to move funds inappropriately. And for example, a cold wallet can be set up where a single customer service team can, without further authorisation, transfer a portion of funds (using a number of preset amounts) to a warm wallet managed by an isolated support team. The support team can then withdraw some of the funds to the hot wallet and send the balance back to the cold vault with a similar withdrawal mechanism. What's more - all such designs can be combined with relative temporary lockdowns to allow time for compliance and risk management services to intervene.

Another concept proposed based on this simple and elegant solution is Clique, which allows a pool of users to pay each other off-chain, i.e. without interacting with the blockchain, thus bypassing its bottlenecks. A user can directly send his coins to any other user in Clique: unlike payment channels, his funds are not tied to a specific counterparty, thus avoiding the need for multicast payments. An untrusted operator facilitates payments by verifiably logging them. Thus the concept of the first trust-free commit chain compatible with all major blockchains, including (a future version of) Bitcoin.

Bitcoin atomic swaps 

Another trend that differs from concepts that are close to familiar bridge implementations is atomic swaps. Atomic swaps do not rely on custodians (or custodians) to manage reserves, which undermines decentralised structures. Instead, they eliminate the need for wrapped tokens. Atomic swaps thus enable peer-to-peer exchanges, allowing users to exchange cryptocurrencies directly without the need for intermediaries. 

Bitcoin atomic swaps are possible because of two key components encoded in Bitcoin's HTLC (Hashed Time Lock Contracts):

• Hashlock - this mechanism allows the contract to be protected with a separate cryptographic key that can only be created by the depositor of the cryptocurrency. This unique key serves as a guarantee that the exchange will be completed when the party with the key (secret, prototype) agrees to the transaction.
• TimeLock - this mechanism can be compared to a time limit for a swap. It ensures that the transaction is completed within a predetermined period of time, and if this condition is not met, it allows the depositor to return the funds. Time lock plays a crucial role in securing swap transactions. It obliges both parties to complete the swap within a set time window for a successful swap.

This technology facilitates the direct exchange of cryptocurrency between two parties on the Bitcoin network using its scripting language without the need for a central authority or intermediary. This process uses special types of scripts, such as those found in HTLC contracts on the Lightning Network. Another representative of this trend is LNSwap, a decentralised protocol that enables fast and private P2P exchanges between Bitcoin and L2 stacks. LNSwap uses Lightning to reduce transaction fees and increase transaction speeds. The protocol also uses underwater swap technology to make Bitcoin addresses on-chain compatible with Lightning addresses off-chain. As a result, it can facilitate BTC transfers from the Bitcoin blockchain to the Lightning off-chain channel. LNSwap provides Lightning nodes for users who want to open Lightning channels using the protocol. 

Another representative of this trend is Portal, which provides fast and inexpensive atomic swaps between proprietary Bitcoin assets, such as BTC, Ordinals and Runes, on L2 and other L1s. Portal harnesses the power of non-custodial atomic swaps based on Layer 2 HTLC, and showcases its unique Automated Dynamic Market Maker (ADMM) design for instant cross-chain swaps.

BitcoinOS

In April 2024, BitcoinOS introduced BitSNARK, a new software library to efficiently verify zkSNARKs in Bitcoin, which are a type of ZKP. And on 23 July 2024, BitcoinOS successfully verified ZKP for Bitcoin for the first time in history. 

BitSNARK, a revolutionary BitcoinOS technology, is thus a software library for verifying zkSNARK, a type of ZKP on Bitcoin, allowing developers to create Level 2 (L2) drives. With BitSNARK, Bitcoin users can now create covenants - conditional payments that are only executed when the correct cryptographic proof is provided. 

Covenants are the key to building decentralised bitcoin bridges - the ‘holy grail’ innovation that enables true Bitcoin convolutions. These bridges require only one honest participant in a pool of potentially hundreds of operators (1 in n) in a decentralised, dynamic and permissionless set of operators to keep your funds safe. Thus, the exchange between BTC as L1‘s and BOS L2’s takes place through the so-called Grail Bridge.

Grail Bridge operates with the help of agents, which are referred to here as operators. Operators are responsible for monitoring the operation of the bridge and helping users to deposit and withdraw funds. They must constantly monitor both the bitcoin network and the rollups network, as well as participate in certain steps of the protocol. In addition, operators must register and maintain an active endpoint on the Internet to support P2P interactions with other operators.

Operators can block funds on the bitcoin side by sending them to Taproot addresses created with BitSNARK. In this way, funds are blocked at UTXO until a SNARK proof-of-stake is provided to allow their retrieval. On the L2 side, the operator sends the SNARK proof to the bridge's smart contract, thereby causing the bridge to mine tokens to the operator's wallet. In the reverse process, the operator burns its tokens through the smart contract, thereby receiving the SNARK proof-of-stake, which allows the operator to retrieve its funds on the Bitcoin side from UTXO using BitSNARK.

Thus, it turns out that the Grail bridge generally works by using two types of proofs: proof of transaction enablement in the Bitcoin network and proof of state transition of the bridge's smart contract on the L2 side.

Proof of inclusion of a transaction in the Bitcoin chain: Given a hash of a transaction, a proof that the transaction was mined in the bitcoin network is generated by combining the following conditions:

• Proof that the transaction was included in a particular blockchain
• Proof that a predefined number of blocks have been validated afterwards
• Proof that a known accepted block is present in the chain

Proof of state transition of the bridge smart contract on the L2 side: this proof is used in two cases: to confirm that the UTXO has been assigned to an operator for withdrawal or to confirm that the share has been released after the operator leaves. Depending on the design and security assumptions of the rollup, the evidence may be constructed as follows:

• Proof of transaction inclusion in the bitcoin network - provided that the rollup commits transaction information to the bitcoin network as a data availability layer, and that the rollup has a dispute mechanism to reject invalid state transitions.
• Proof of state persistence in the rollup smart contract - an alternative is to show that the target variable with its value was included in the smart contract store when computing the rollup block hash.

zkBridge

This is a technology based on Polyhedra's LayerZero (Polyhedra's zkLightClient technology is fully integrated with LayerZero's messaging protocol) and zkSNARKS, which at first glance does not quite fit into the concept of L2 liquidity capture on top of Bitcoin. It is its implementation that interests us in this case, which could possibly be laid down as one of the options for L2 connectivity in the future. Especially, the zkBridge module that works with BTC can be remotely considered L2, as it is not a simple relayer as in the case of the rest of the chains.

In order for zkBridge to work with Bitcoin, Polyhedra had to implement two things:

• Bitcoin AVS to provide fast and low-trust interaction with Bitcoin with its node set and slashing mechanism - this is presented as an EigenLayer-based AVS that overcomes the key hurdle of bridging messages with Bitcoin as the reciever chain.
• ZK proof checking directly on Bitcoin using FRI (Fast Reed-Solomon Interactive) style ZK proofs.

At a basic level, zkBridge works as a two-way liquidity bridge:

• Maker contributes BTC to the liquidity pool on Bitcoin and contributes collateral to the collateral pool on Ethereum. Maker also specifies a receiving address on Ethereum to receive exchanged WBTC.
• Users send WBTC to the liquidity pool on Ethereum. The user's tokens are stored in the liquidity pool on Ethereum until the maker provides proof of transfer of the corresponding BTC to Bitcoin.
• The maker transfers the BTC to the user's receiving Bitcoin address from the liquidity pool.
• Upon successful confirmation of the transaction on the Bitcoin network, the maker sends the proof of transaction to a smart contract on Ethereum using our Bitcoin messaging protocol zkBridge.
• The Ethereum smart contract verifies the proof and issues tokens to the maker, completing the cross-chain bitcoin exchange.

Why is this interesting in the context of liquidity recycling from BTC to L2? The fact is that Polyhedra did extensive research, and concluded that the main problem with checking ZK proofs in Bitcoin is that the Bitcoin script supports a small list of opcodes that only allows for a very limited form of computation. And they found that some of the prime numbers used in STARK are Bitcoin friendly and you can use OP_ADD and OP_SUB to do all the addition and subtraction.

And to ensure that zk commits and checks in BTC are not perceived as spam due to the fact that such operations require many transactions due to the small capacity of BTC blocks, Polyhedra decided to turn to data aggregation layers such as Nubit. This complex solution reflects the problem of L2 interoperability with Bitcoin due to the large number of constraints in this network and the need to find unconventional solutions to consistently occurring problems.

StarkWare M31 multiplication for Bitcoin

Although Starknet is an EVM-oriented zk-technology stack, the StarkWare team is working to improve interoperability with Bitcoin. This technology came to the BTC world from Ethereum, for which Circle STARKs was introduced back in July 2024 by Vitalik Buterin. In particular, in August 2024 Avihu Levy unveiled the continuation of the co-development with L2V - a new algorithm based for M31 multiplication that reduces multiplication cost by 70%. Unlike STARKs, this new multiplication algorithm (like the previous algorithm) does not require OP_CAT, cementing M31's status as a Bitcoin-friendly prime number independent of OP_CAT.

As far as we know, multiplication of numbers in the Bitcoin script is difficult because the OP_MUL operation code is disabled. Therefore, multiplication must be emulated using other Bitcoin operation codes. A neat approach to emulating OP_MUL is to use multiple OP_ADD operation codes using a ‘doubling and adding’ algorithm, such as is commonly seen in elliptic curve arithmetic: this algorithm involves bit decomposition and repeated additions. So Weikeng Chen from L2V was able to implement this algorithm with ~1.4k opcodes for a single M31 multiplication. And the most amazing thing is that this direction is evolving and new iterations of M31 - CM31 and QM31 are constantly appearing with changes and additions to the formulas to improve efficiency and reduce cost.

So, theoretically, if OP_CAT is not implemented in the conservative Bitcoin blockchain, there is a chance to get information compression working through new iterations based on M31. This provides another branch of interoperability and liquidity movement around Bitcoin.

State Bridge

This category covers the solutions that enable utilities for Bitcoin without actually bridging the BTC and other L1 assets. 

The solution is based on synchronizing the entire Bitcoin state to a L2’s state database (in the case of Rooch, a State Merkle Tree), and making the Bitcoin state available for smart contracts to read. In order to ensure all the synced states are correct, the L2 needs to execute all Bitcoin transactions since the Bitcoin Genesis block. From an architecture perspective, the L2 would practically have a Bitcoin full node embedded into it.

The advantage of this solution is that no assets will be exposed to custodial risk or systematic risk. All assets are always secured by the users’ private key so that asset security concerns are eliminated for the users.

The downside, however, is that as the BTC is not bridged, no smart contract can transfer the BTC or alter its state. Most liquidity-based applications are not feasible. The main application scenarios include Babylon’s remote staking and Rooch’s state binding. 

Yona Network Canonical Bridge

Yona Canonical Bridge is designed to be as simple as possible on the one hand, and on the other hand to be open to new technologies and innovations thanks to its modular structure. The bridge is made up of several components. These components include: Relay on-chain Program, Relayer off-chain client and Bridge Nodes, that 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.  

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

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.

Conclusion

We believe that any improvement in BTC's programmability will have an immediate stimulative effect on its extended ecosystem. On the other hand - there are many questions around OP_CAT. The possibility of OP_CTV implementation is also a very interesting direction. This could both give more development space on Bitcoin and lead to more mainnet programmes and applications, which in turn will increase the processing fees on the mainnet. Will this have any negative impact given that it will be easier and cheaper to interoperate in L2? And will it affect the emergence of MEVs on the Bitcoin network, for example? Only time will tell.

Thus, we can see that technologies are changing even in such a conservative ecosystem as Bitcoin. And in order to introduce new technologies while improving Yona Network, we need to constantly monitor and analyse updates. We are very positive about the initial rapid development of various solutions to connect with Bitcoin - it allows us to unlock the value of the largest asset in the Web3 and keep our finger on the pulse. Therefore, we are focused on creating the most reliable, understandable and convenient solution for users and developers. That said, it is also worth considering that it is the synergy of different solutions with collaborative development that drives progress in the current modular world of web3. And one of the most important abilities in web3 is the ability to quickly adapt to new conditions and integrate new technologies to keep up with industry developments.

Dion Cornett, CEO at Tatum:

Bridging Bitcoin’s liquidity is not just a technical challenge—it’s the key to unlocking its true potential. Yona team's research on BitVM, OP_CAT, and zkBridge is nothing short of groundbreaking. These innovations take Bitcoin beyond its limitations, creating highways for its liquidity to flow into the centre of decentralized finance. When you build the bridge, you don’t just move assets—you transform Bitcoin from a store of value into a dynamic force in the new world of DeFi. And that’s the future Yona's team is shaping.

About Yona Network

Yona is a real-time latency Bitcoin L2 blockchain enabling Web2 experience for dApps. We use custom hyper-optimized modularized SVM to achieve superior performance with less than 40ms latency and block time. Yona enables lightning-fast transactions and offers limitless scalability, paving the way for next-generation protocols tailored to enhance the user experience within the Bitcoin ecosystem.

Yona Network links:
Website | Documentation | Twitter | Discord | Blog

This research was written with members of teams from different projects and we are very grateful for the participation of Rooch Network, Molecula, NeonEVM and other teams.