Author: Haotian
How to understand the latest ColliderScript white paper released by @StarkWareLtd? In short: ColliderScript uses a hash collision mechanism to implement Covenant without modifying the Bitcoin protocol, and implements the complex contract functions of the Bitcoin mainnet ahead of the OP_CAT proposal. How does it work? What is the difference from OP_CAT? Will it accelerate the landing of Starknet Bitcoin layer2? After reading the white paper, I will share with you:
1) ColliderScript, as the name suggests, is a "collider", indicating that its core mechanism is to implement hash collision on scripts. Since Bitcoin has two types of scripts, Big Script and Small Script, the big script can see transaction data such as signatures but can only process limited calculations, and the small script can perform arbitrary calculations on 32-bit data, but cannot see transaction data.
This means that the verification of the big script can only be limited to limited verification such as signature transactions, and it is impossible to handle complex contract logic. The small script has the ability to accommodate complex logic, but without the transaction signature ownership association, it is meaningless to handle it alone.
What to do? ColliderScript cleverly designed a "bridge" to implement 160-bit hash collision using SHA1 and RIPEMD, and realized the equivalence proof between the big script (processing big data such as signatures) and the small script (which can only process 32-bit data). Although it is impossible to process the signature data of the small script larger than 32 bits, a set of cryptographic verification mechanisms can prove that the contents of the big and small scripts are consistent.
It is such a clever mathematical technique that ColliderScript can effectively connect the information of the big and small scripts, and the complex contract transaction logic can be integrated into the small script for calculation, while the big script retains the transaction signature verification. Finally, ColliderScript can effectively connect the information of the big and small scripts, so that complex contract functions can be realized in the Bitcoin script.
2）OP_CAT I have previously written an article to analyze in detail. It is a new opcode proposal that can connect multiple script byte string data for processing, thereby realizing the overall complex contract verification and computing capabilities.
Through OP_CAT, the logic that originally needed to be processed in a single data block can be split into multiple data fragments, which can be dynamically combined during the script execution process to achieve more flexible verification and calculation. https://x.com/tmel0211/status/1783756759662043462
Since OP_CAT is an unmerged proposal, whether it can be successfully launched is unknown, and the emergence of ColliderScript can preemptively realize the contract function of the Bitcoin mainnet.
However, like the implementation logic of BitVM, ColliderScript incorporates off-chain preprocessing logic, and the so-called hash collision requires a lot of computing and storage costs. According to the white paper, each use of the contract function requires 2 to the 86th power hash query and 2 to the 56th power storage space, which is equivalent to consuming more than 30 hours of computing power of the Bitcoin network, and naturally will increase the hardware cost and power consumption of the node investment, etc.
Therefore, ColliderScript will not completely replace OP_CAT. It will serve as a transitional solution to handle high-value contracts in some specific scenarios. Other small and micro-transaction business scenarios will not be proportional to the input and output of ColliderScript.
Having said that, the launch of BitVM also has the problem of low practicality, but it has enabled a large number of projects such as @GOATRollup and @BSquaredNetwork to implement Native cross-chain bridges and Bitcoin Specific challenge proof mechanisms based on it.
Take GoatNetwork as an example. As a Bitcoin layer2 solution that can realize decentralized sequencer and Native secure cross-chain, the kernel implements an OCP optimistic challenge protocol based on BitVM2. All calculations and interactions are executed offline on the second layer. When a "challenge" occurs, the on-chain protocol will be executed on the Bitcoin main network, and Bitcoin layer1 will act as an arbitrator to ensure security.
CollideScript's real "practicality" dilemma is similar to its potential innovative catfish effect. Although there are cost barriers to large-scale popularization, its collision size script promotes the exploration of Bitcoin programmability and will definitely activate some specific application scenarios first.
The key is that this combination of off-chain preprocessing + on-chain will unlock many complex application scenarios in the long run, which is more down-to-earth than the logic of pure on-chain computation verification.
3) However, Starkware’s release of the ColliderScript white paper is quite interesting. Previously, @Starknet announced a plan to build bitcoin layer2 based on OP_CAT, and now has launched a new transition plan, from passive to active, which shows that the purpose is to accelerate the implementation of its bitcoin layer2.
In addition to praising the Starkware team’s ability to innovate technology, we must look forward to what Starknet’s bitcoin layer2 launch will bring to the bitcoin layer2 ecosystem.
Joy
Brian
Hui Xin
Davin