Original text: "What impact will the hotly discussed new proposal OP_CAT have on the BTC ecosystem?" 》
Author: Haotian CryptoInsight
What do you think of the recently discussed new Bitcoin proposal OP_CAT? Although it has not yet been officially merged into the Bitcoin Core code, it has triggered extensive discussions in the BTC community.
So, what problem does the OP_CAT opcode solve? What improvements will it bring to BTC's programmability if it is introduced? What impact will it have on the subsequent market evolution of the BTC ecosystem? Next, let me briefly talk about my understanding:
What is OP_CAT?
OP_CAT is a brand new opcode proposal, jokingly called by the developers to be in the quantum entanglement superposition state of BIP420 and BIP347. The specific EIP is not important, as long as it is clear that this is just a proposal that is still being discussed and has not been officially included. Simply put, OP_CAT can realize the combined connection processing of multiple UTXO unlocking script byte strings, which can improve the programmability features of the BTC main network, program scalability and on-chain verification calculation complexity;
What does OP_CAT achieve?
Similar to the Covenant contract as a Bitcoin script extension proposal, OP_CAT also aims to improve the scalability of Bitcoin scripts. The difference is that Covenant aims to enable Bitcoin transactions to achieve more complex programmability to support complex smart contracts and application scenarios. In comparison, OP_CAT is easier to implement and aims to simplify the construction and execution of complex scripts to improve the efficiency of on-chain verification.
Popular understanding: 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, and They are stored in different UTXOs and created by different transactions. When complete execution is required, the full node uses the OP_CAT instruction to splice these script fragments together in order to execute the trigger.
What changes can OP_CAT bring to Bitcoin?
With this combination capability, many complex execution logics can theoretically appear on Bitcoin: for example,
1. Multi-signature plus time lock can set more complex execution unlocking conditions across multiple UTXOs and time locks across multiple subjects;
2. Recursion and looping can allow multiple script byte strings to form recursion and conditional execution, looping until a certain termination condition is met;
3. Modular application, common script logic can be extracted and reused in multiple program execution fragments. When Alice transfers money hosted on platform C to Bob, three subjects must sign at the same time. If platform C exceeds the signing time, Alice and Bob can sign together to retrieve the funds; if Bob does not sign for a long time to obtain the transfer, Alice can withdraw Transaction; if Bob thinks there is a problem with Alice's source of funds, he can reject it, etc. This is just a simple example, in fact it is possible to use combinations between script fragments to achieve more complex and granular control;
Does OP_CAT have any gain effect on BitVM?
Previously, BitVM performed complex operations under the chain and only implemented the key verification and settlement paradigm on the chain, which aroused everyone's imagination about BTC's programmable and Turing-complete calculations. The "recursive" combination execution of OP_CAT on the BTC main network is another imaginative addition, and OP_CAT is of great benefit to accelerating the implementation of BitVM and reducing on-chain verification costs.
How to understand it? Originally, to execute BitVM, the off-chain program needs to be encapsulated into an independent script fragment that can be executed by a single UTXO. The off-chain construction cost is high. To put these fragments together for execution on the chain will also require a more complex TaprootTree. The structure means that the cost of on-chain interactive verification after a BitVM program is executed will be relatively high. When OP_CAT is introduced, each of the fragments encapsulated under the BitVM chain does not need to be executed completely and independently. The chain can summarize and update the status after the UTXO unlocking conditions have accumulated to a certain extent. Obviously, the combination of script fragments can greatly Reduce the number and cost of on-chain verification interactions.
In short, the hot discussion of OP_CAT includes everyone’s expectations for Bitcoin to further enhance programmability. If it is truly implemented, it will be the implementation of BitVM, the security improvement of various BTC layer2 cross-chain asset solutions, and UTXO isomorphic binding. The ecological expansion of the chain and the co-development of the main network, and even the progress of potentially scalable markets such as the Lightning Network and RGB client verification, will play a catalytic role. In theory, any improvement in BTC's programmability will have an immediate stimulating effect on its extended ecology. After all, everyone is trying to build an oasis in the desert. If one day the sand turns into a cement floor, wouldn't it be much easier to build the building?
But, will it be truly merged? Thinking about the Covenant proposal that has been proposed for many years but has not been adopted, it is also good to use the new OP_CAT proposal to brainstorm some market imagination.
What is this article OP_CAT? What impact will it have on the BTC ecosystem? First appeared in Zombit.
