Background
Challenges for running DeFi on Bitcoin
BTC requires a scalable solution to serve as the infrastructure for DeFi and even more ecosystem applications. We first consider what issues a blockchain must solve to run DeFi applications:
Security: The blockchain must ensure robust security to prevent issues such as double-spending, unauthorized modifications to transaction records, and other malicious activities. High TVL also reinforces trust in DeFi platforms.
Programmability: Critical for DeFi, the blockchain should support complex financial transactions and protocols, ensuring reliable and accessible outcomes from contract executions.
High throughput and low transaction costs: DeFi applications demand high transaction throughput and low costs, necessitating a scalable and efficient infrastructure.
Governance mechanism: A robust governance framework is crucial for encouraging community involvement, consensus, and managing updates to the network.
Risk control: The financial risks in DeFi exceed those in traditional trading, requiring dependable price data sources and risk mitigation strategies.
Given these prerequisites, Bitcoin's original design seems less suitable for the complexities of DeFi. However, potential solutions include:
Bitcoin's capability to support advanced smart contract logic has improved with recent upgrades. Using Merkleized Abstract Syntax Trees (MAST), DeFi logic can be encapsulated into scripts within the Witness component, intended for off-chain node execution rather than on the main chain.
Capitalizing on Bitcoin's unmatched security, DeFi transactions could be streamlined to Unspent Transaction Output (UTXO) transactions against Pay to Taproot Hash (P2TH) addresses, ensuring secure settlements for DeFi contracts. Incorporating yield farming concepts could encourage Bitcoin users to contribute their assets, enhancing TVL.
Considering the high transaction fees and prolonged block times on the Bitcoin network, limiting throughput, a significant portion of DeFi transactions should be processed off-chain. Bitcoin would then finalize the settlements, ensuring consensus and security.
Implementing governance mechanisms for DeFi community members is crucial for protocol governance, network upgrades, and parameter settings within the Bitcoin ecosystem.
Bitcoin's volatility, accentuated by its 10-minute block intervals, increases risk in its DeFi ecosystem compared to other chains, necessitating reliable oracles for price feeds and effective risk management measures.
Introducing a Bitcoin-native stablecoin could significantly stabilize liquidity in DeFi applications, serving various roles, including lending, hedging, and settlements.
Existing solutions
There are various proposed solutions for expanding Bitcoin to support complex applications such as DeFi, primarily Bitcoin Layer 2 solutions taking the form of rollups or EVM-compatible sidechains with similar underlying approaches. Rollup solutions generate fraud or validity proofs for off-chain transaction execution, solutions that are then validated by publishing the proofs to scripts within Bitcoin's Taproot witness data. At the same time, the EVM sidechain approach involves launching a new EVM-compatible blockchain network that interacts with the Bitcoin mainchain cross-chain. However, practical rollup implementations face challenges, including constraints on proof complexity due to limited witness data size. Additionally, simply posting data on Bitcoin's blockchain does not automatically ensure the authenticity of off-chain rollup transactions. As a result, most current Bitcoin rollup projects opt for a "sovereign rollup" or "client validation model" where validators synchronize and validate the entire rollup state data off-chain, failing to leverage Bitcoin's consensus and security model, exemplified by the client-validated RGB protocol.
A practical strategy for rollups involves leveraging the BTC network to validate transaction commitments. It's crucial to also have mechanisms that ensure assets within the rollup can be safely accessed or recovered during unexpected incidents or system breakdowns, even when rollup nodes/sorters are unavailable or decline transactions. A secure emergency channel allows for the retrieval of assets. BitVM, integrating fraud proofs with Taproot's MAST scripts, is a notable solution adopted by many rollup projects. However, BitVM's major drawback is its absence of an emergency asset release feature, posing a risk of asset loss in the event of attacks or failures.
Besides the direct Bitcoin expansion BTC L2 solutions, DLC.link proposed a different solution, mapping BTC to Ethereum L2 based on the DLC protocol, to participate in the ETH DeFi ecosystem as dlcBTC. This only provides cross-chain interoperability for Bitcoin, relying on the security and consensus of other chains, not exploiting the characteristics of the BTC ecosystem. However, the use of Discreet Log Contracts (DLCs) is a very valuable BTC contract primitive, essentially a condition judgment between transaction parties, determining the final direction of funds based on an agreement by two or more parties on the outcome of a specific event chosen by one or multiple oracles.
We believe native DeFi applications and other ecosystem applications for Bitcoin should be built directly utilizing Bitcoin's native asset types, including BTC itself, BRC20, Animoca's tokens, Taproot Assets, Omni Layer tokens, and more, with data structures encoded either in OP_RETURN outputs or through OP_FALSE OP_IF...OP_ENDIF script constructs within the witness data exhibiting similar formats. These diverse native asset encodings can be unified under the "inscriptions" model enabled by the Ordinals protocol, providing a standardized format for associating arbitrary data with satoshis and storing this content off-chain in Taproot script-path spend scripts. Building upon inscriptions allows layering more complex business logic onto off-chain indexer servers, such as introducing new operational primitives like "list", "collateralize", "destroy", "authorize" alongside "mint", "deploy", and "transfer" under the inscription JSON "op" field, with combinations evolving into higher-level functionalities like swaps, lending, inscribed financial instruments ("Inscription-Fi"), and even complex decentralized applications spanning social networks and gaming ("SocialFi" and "GameFi") - thereby standardizing Bitcoin's native assets into a richly extensible framework for native DeFi and broader applications deeply integrated with Bitcoin itself.
The Yala Protocol is a proposed solution that addresses the challenges of implementing complex transactions using Bitcoin's native assets. Yala draws on the concept of decoupling to apply it to the Bitcoin ecosystem, leveraging the security of the BTC network and the Turing-completeness of other blockchains. Yala's native operability aims to realize the programmability of BTC assets, and the protocol plans to first implement a DeFi layer on Bitcoin based on this theoretical architecture.
Native operability and interoperability on Bitcoin
We evaluated the limitations and reference technologies of current solutions. Taproot's MAST enables complex transaction logic on Bitcoin, while DLCs streamline transaction processes by moving most operations off-chain, ensuring both security and privacy. Leveraging these technologies, transaction contracts are stored similarly to Ordinals, facilitating direct on-chain storage and off-chain execution by nodes. This approach allows contracts to be executed in a manner akin to Ordinals, blending efficiency with blockchain integrity.
This approach maintains the intrinsic qualities of Bitcoin assets in DeFi, addressing the need for high throughput and cost efficiency. In DeFi's multifaceted transaction processes, it's unnecessary for BTC to be involved in every step. The primary value of the BTC main chain in executing contracts lies in its security and consensus capabilities. Therefore, we should preserve these aspects while separating all other system functions from BTC. A modular approach allows us to extend Layer1 functionalities, enhancing main chain scalability. By decoupling system functions and strategically distributing tasks across modules, we significantly boost system throughput and concurrently reduce transaction costs.
Blockchain interoperability allows for the sharing of information and value across different blockchain networks, facilitating direct interaction between users and developers with multiple platforms. The aim of achieving Bitcoin interoperability is to enable those holding BTC to leverage their assets in transactions on other blockchains without needing to sell. Methods to achieve this include cross-chain bridges, atomic swaps, and relay chains. A key challenge is conducting transactions with BTC assets on other chains without significantly burdening BTC's resources. Thus, mapping BTC assets for use on trusted alternative blockchains presents a viable strategy for providing BTC interoperability, though it's not without its challenges.
Most Bitcoin Layer 2 (L2) solutions utilize cross-chain bridges, where security hinges on creating cryptographic proofs off-chain that are later verified on the Bitcoin blockchain. This approach, however, runs into considerable difficulties, especially because the Bitcoin script language, designed for simplicity and security, isn't well-suited for complex verifications. This limitation raises concerns about the practicality of efficiently executing these advanced verification processes within Bitcoin's existing framework. Furthermore, coordinating emergency risk management across different blockchains adds layers of complexity to these systems. L2 projects are exploring the reactivation of the OP_CAT operator to enhance data interaction capabilities, but this move could inadvertently increase the risk of Distributed Denial of Service (DDoS) attacks, adding another dimension of concern.
Another approach is Drivechain, whose idea was detailed in two proposals: BIP 300, involving a system called Hashrate Escrows, and BIP 301, related to Blind Merged Mining. The Drivechain proposal aimed to let developers customize sidechains and use Bitcoin locked on the main blockchain to manage assets on these sidechains. However, neither BIP 300 nor BIP 301 received the necessary approval to be implemented. As a result, the Drivechain approach is generally regarded as unreliable.
Atomic swaps facilitate direct cryptocurrency exchanges between two parties on the Bitcoin network, leveraging its script language without needing a central authority or intermediary. This process uses special types of scripts, such as those found in Hashed Timelock Contracts (HTLCs) within the Lightning Network. These scripts ensure that transactions can only be completed if certain conditions are met, effectively creating a secure and trustless exchange mechanism. While atomic swaps offer a decentralized way to trade cryptocurrencies, they face challenges like the "replacement cycle attack," which questions the security of the Lightning Network. Despite these concerns, atomic swaps are a significant advancement for peer-to-peer transactions.
Native SegWit, Taproot and BRC-20
The SegWit upgrade eliminated Bitcoin transaction malleability by splitting transactions into two parts. It removed the unlocking signatures ("Witness data") from the original portion and appended them as a separate structure at the end. This approach mitigated the block size limit, continuing to store sender and receiver data in the original portion with the new "Witness" structure containing scripts and signatures. The original data segment is counted normally, but the "Witness" segment is effectively counted as one-quarter of its actual size. This upgrade expanded the complexity achievable by BTC Script. Although the space provided is insufficient for complex DeFi transactions, it is enough for simple conditional statements, thus laying the foundation for the later development of the Lightning Network. Taproot includes three separate Bitcoin Improvement Proposals (BIPs): BIP 340, BIP 341, and BIP 342, corresponding to Schnorr signatures, Taproot, and Tapscript, respectively. The SegWit upgrade's Pay to-ScriptHash (P2SH) relieved senders of the costs associated with PubKey scripts occupying significant transaction volumes. As transactions become more complex, with scripts specifying numerous spending conditions, the transaction volume could become exceedingly large. This issue was effectively addressed in BIP114 and BIP117 with the MAST concept. Taproot uses the concept of Merkle branches, revealing only the part of the script executed to the blockchain rather than all possible ways the script could execute. Among the various known mechanisms for implementing this, using a Merkle tree as part of the script structure maximizes space savings. Schnorr signatures introduced key aggregation, combining multiple public keys and signatures into one, making Bitcoin transaction signatures faster, more secure, and easier to process.
Tapscript modified the OP_CHECKSIG and OP_CHECKSIGV -ERIFY signature operation codes to verify specified Schnorr signatures and simplified the OP_CODESEPARATOR operation code for efficiency. The signature checked by OP_CHECKSIG is a signature of the hash of the preimage. The preimage includes the entire transaction's outputs, inputs, and lock script. Typically, the lock script is complete. However, if OP_CODESEPARATOR is executed before OP_CHECKSIG, the preimage only includes the portion of the lock script from the position of the most recently executed OP_CODESEPARATOR to the end of the script, thus containing only part of the lock script. This feature can be used to reduce the size of the preimage, thereby reducing the overall size of the transaction. The OP_CODESEPARATOR can compress the time-lock contract script code size by $80%$, greatly aiding the implementation of conditional judgment scripts.
The Taproot upgrade provides a foundation for many schemes to enhance BTC's scalability, including Ordinals, Taproot Assets and other asset interaction protocols. All of these offer a basis or reference for the underlying architecture of Yala Protocol. The BRC20 based on Ordinals provides a way to write assets into UTXOs, setting deploy, mint, and transfer functions as the basis for operating assets on BTC. This logic allows us to grant BTC assets more extensibility, initially through DeFi.
New framework from BRC-20
This compartmentalized architecture significantly eases the burden on Layer 1, making it particularly suitable for BTC, whose tasks are notably demanding and transaction computation costs on the network are quite high. With Bitcoin's consensus based on Proof of Work (PoW), its security is considered the highest among all blockchain systems. The scripting language for BTC transactions is Turing incomplete, and the cost of computing transactions on BTC is prohibitively expensive. As a result, BTC has traditionally been used solely for transfer transactions. If we could take a compartmentalized approach to extend BTC to make it a LazyLedger Tas et al. By offloading tasks other than UTXO transaction state consensus and security to other components, we could obtain a low-cost BTC ecosystem capable of executing complex transactions. Then, our task would be to ensure that Bitcoin solely manages consensus and security.
The upgrades of SegWit and Taproot have laid a solid foundation for this vision. The Segregated Witness upgrade separates the Witness from transaction inputs, increasing transaction capacity. With Taproot's Schnorr signatures, transactions can be batch verified, and Tapscript, alongside MAST, enables Bitcoin to run smart contracts similar to Ethereum's, allowing for complex transactions. These upgrades have introduced the concept of BRC20, based on Ordinals, where unexecuted script codes are written into the Witness's taproot script-path spend scripts, resembling:
Ordinals inscription. Ordinals confer additional token value to sats, allowing them to be collected and traded as curios. Any content can be engraved on an individual sat, creating unique native Bitcoin digital artifacts that can be stored in a Bitcoin wallet and transferred using Bitcoin transactions. The deployment, minting, and transfer of Ordinals tokens became the foundation of the earliest BRC-20 standard .
UniSat's modular proposal presents a new method to accommodate diverse inscription-based applications within the BRC-20 framework. Modules function separately, allowing indexers to parse only relevant data, ensuring consistency across the BRC-20 system. Modules are categorized into Black Modules, supporting deposits, and White Modules, enabling withdrawals. Black Modules transition to White upon unanimous indexer approval. White Modules necessitate full indexer support and consensus algorithm implementation for operation.
The BRC-20 update introduces deployment and new withdrawal inscription formats. Deploying it requires specifying the name, source, and optional initialization data, with the source linking to the code-defining module functionality. Withdrawals requiring a module ID are permitted only for White Modules.
This design enables complex transactions that would otherwise require Bitcoin processing to be handled on another layer. Yala's approach utilizes Taproot Script to simplify complex transaction processes. It decouples transaction execution, settlement, consensus, and data availability of Bitcoin assets, entrusting all complex transactions and settlements to off-chain execution. This transforms Bitcoin into a LazyLedger, solely responsible for the system's consensus and security.
Last updated