How do you view the recent hotly debated Bitcoin new proposal OP_CAT? Although it has not been formally merged into the Bitcoin Core code at present, it has sparked widespread discussion in the BTC community. So, what problems does the OP_CAT opcode solve? What improvements will its introduction bring to the programmability of BTC? What impact will it have on the subsequent market evolution of the BTC ecosystem? Next, let me briefly discuss my understanding:

1) OP_CAT is a brand new opcode proposal, jokingly referred to by developers as being in a quantum entangled state between BIP420 and BIP347. The specific EIP is not important, as long as it is clear that this is a proposal that is still being discussed and has not been formally adopted. Simply put, OP_CAT can achieve the combination and connection processing of multiple UTXO unlocking script byte strings, which can enhance the programmability, program scalability, and on-chain verification computational complexity of the BTC mainnet.

2) Similar to the Covenant contract as a Bitcoin script extension proposal, the goal of OP_CAT is also to enhance the extensibility of Bitcoin scripts. The difference is that the goal of Covenant is to enable more complex programmability in Bitcoin transactions to support complex smart contracts and application scenarios. In comparison, OP_CAT is more practical, aiming to simplify the construction and execution of complex scripts to improve on-chain verification efficiency.

In layman's terms: OP_CAT provides the ability to combine script fragments. Before its introduction, each UTXO script was executed independently. With OP_CAT, we can split a complex execution logic into a series of combined simple script fragments, stored in different UTXOs, created by different transactions. When complete execution is required, full nodes use the OP_CAT instruction to concatenate these script fragments in order and execute them.

3) With this combination capability, theoretically, many complex execution logics can be implemented on Bitcoin, such as:

1. Multi-signature with time locks, enabling complex unlocking conditions across multiple entities, UTXOs, and complex time lock settings.
2. Recursion and looping, allowing multiple script byte strings to form recursion and conditional execution, continuously looping until a certain termination condition is met.
3. Modular applications, common script logics can be extracted and reused in multiple program execution fragments. For example, Alice transfers money held on platform C to Bob, requiring signatures from three parties simultaneously. If the platform C exceeds the signature time, Alice and Bob can sign together to retrieve the funds. If Bob does not sign for a long time, Alice can withdraw the transaction. If Bob believes there is an issue with the source of Alice's funds, he can refuse the transfer, and so on. This is just a simple example, and in reality, the combination of script fragments can be used to achieve more complex and granular control.

4) Previously, BitVM executed complex operations off-chain, only implementing critical verification and settlement on-chain, igniting great imagination for BTC's programmability and Turing complete computation. The introduction of OP_CAT for "recursive" combination execution on the BTC mainnet is another supplement to imagination. Moreover, OP_CAT is beneficial for accelerating the implementation of BitVM and reducing on-chain verification costs.

How to understand it? Originally, for BitVM to execute, the off-chain programs needed to be encapsulated into independent script fragments that could be executed on a single UTXO. The off-chain construction cost was high, and executing and assembling these fragments on-chain would require a more complex TaprootTree structure, meaning that the cost of on-chain interaction verification for a program execution would be relatively high. With the introduction of OP_CAT, the fragments encapsulated by BitVM off-chain do not need to be able to execute independently in full on-chain. Instead, on-chain accumulation of UTXO unlocking conditions can be performed once, significantly reducing the number of interactions and costs required for on-chain verification.

In summary, the heated discussion of OP_CAT embodies everyone's expectations for further enhancing the programmability of Bitcoin. If it is truly implemented, it will catalyze the implementation of BitVM, the security enhancement of various BTC layer2 cross-chain asset solutions, the expansion of the UTXO isomorphic binding chain ecosystem, and the synchronous development of the mainnet. It may even promote progress in potential expandable markets such as the Lightning Network and RGB client verification. In theory, any improvement in BTC's programmability will have an immediate stimulating effect on its expandable ecosystem. After all, everyone is trying to build an oasis in the desert. If one day the sand turns into a concrete floor, wouldn't it be much more convenient to build buildings?

However, will it be truly merged? It's also good to use the new proposal of OP_CAT to imagine some market space, just like the Covenant proposal that has been put forward for many years but has not been adopted.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。