In the past half month, OP_NET and Arch, two smart contract implementations on the Bitcoin mainnet, have sparked a lot of discussion. The interesting thing is that the name OP_NET is very similar to the familiar OP_CAT, both starting with OP_, which is very confusing and makes people think that the two are similar.
Therefore, I would like to mention OP_CAT at the beginning. First of all, OP_CAT is a Bitcoin opcode. Since last year, the community led by Udi Wertheimer, the founder of Quantum Cats or Great Wizard Taproot Wizards, has been calling for the revival of OP_CAT. It is called resurrection because OP_CAT is an existing Bitcoin opcode, but Satoshi Nakamoto removed it in 2010 because it could cause potential DoS attacks. CAT is the abbreviation of the word concatenate. As the word means, the function of OP_CAT is to allow string concatenation operations, splicing two strings into one.
So how does this opcode enable smart contracts in Bitcoin? To be honest, this is really abstract and difficult to understand, so here I recommend friends who are interested to read the article from another legal author Jaleel ( 13 lines of code to help Bitcoin realize smart contracts? Read OP_CAT soft fork ). Here are a few key points I want to quickly summarize for everyone:
OP_CAT involves a soft fork of the Bitcoin network. To get to this step, the BIP-347 proposal must first be passed. Currently, the proposal has only progressed to the second stage of the entire proposal process, the Proposed status.
OP_CAT has been revived on BCH and BSV for more than a few years, but the relevant use cases are still very abstract. In the current discussion, we can hardly see a particularly clear and direct case of what kind of dApp can be made with OP_CAT.
OP_CAT is not a one-step “antidote”. Reviving OP_CAT is more like the first step to unlock the seal of Bitcoin smart contracts. It is reasonable to expect that if OP_CAT can be successfully revived, some excellent use cases will emerge, and then discussions will continue to unlock more Bitcoin opcodes. We can first look forward to whether there will be any refreshing innovations on Fractal with OP_CAT activated.
OP_NET should actually be classified as a protocol such as Rune, BRC-20, and ARC-20. Although its name also has an OP_, its implementation method has nothing to do with Bitcoin opcodes.
OP_NET
The framework of OP_NET can be roughly divided into two parts. First, since it is the smart contract implementation plan of the Bitcoin mainnet, the Bitcoin mainnet must occupy a part of the entire technical framework. It can be said that the role of the Bitcoin mainnet in the technical framework of OP_NET is the behavior initiation layer and the final confirmation layer. The execution and status confirmation of smart contracts is another part, which is the execution layer composed of OP_VM and OP_NET nodes.
Based on the technical framework diagram above, we can briefly explain the process of OP_NET implementing smart contracts on the Bitcoin mainnet. First, the user who deploys/interacts with the contract initiates a transaction from the Bitcoin mainnet. The data field of this transaction will contain the string BSI, which enables the execution layer to sniff that this is an OP_NET contract interaction transaction. After the transaction is confirmed, OP_VM executes the corresponding contract operation and updates the status, which is then confirmed by the OP_NET node and finally provided to the Bitcoin dApp. After the Bitcoin dApp obtains the contract execution results and performs corresponding actions, it will also submit their action results to the Bitcoin mainnet.
Seeing this, you may have a familiar feeling - isnt this the same off-chain execution, on-chain confirmation of the off-chain indexer? It is indeed a little similar. But OP_NET has an interesting mechanism that it actually burns Bitcoin.
OP_NET transaction fees consist of two parts. The first part is naturally the most basic Bitcoin network fee for a Bitcoin transaction, and the other part is the OP_NET transaction fee, which is composed of execution fees and priority fees. Both fees are paid in Bitcoin. OP_NET transaction fees must be more than 330 satoshis to ensure that they are not regarded as dust (too small UTXO) and rejected by nodes. The priority fee allows the contract execution action to increase the gas like Ethereum to ensure that its own transaction is executed first (OP_VM can sort which action is executed first).
If the OP_NET transaction fee is greater than 0.0025 bitcoins, 330 satoshis will be burned, and the remaining part will be given to the node operator as a reward. The so-called burning is actually a bit like the situation in Ethereum where the money deposited into the contract address cannot be withdrawn, because OP_NET actually uses a specific type of Bitcoin transaction Taproot script path expenditure to abstract the Bitcoin address into a contract address. This contract address cannot be controlled by anyone, so it has the effect of burning.
Finally, lets make a small observation on this project in light of its background. The team behind this project is the MotoSwap team. I wonder if you still remember $OSHI, which was once ranked third in the total market value of BRC-20 Tokens during the BRC-20 market. OSHI was an application developer, but later the team had some disagreements, and some of them switched to CBRC-20 to develop Moto. Although OP_NET itself uses Bitcoin as a token consumed by protocol interactions, it also has built-in standards of OP_20 and OP_721. So it can be said that the style of this project is more inclined to the new protocol, new asset style that we were familiar with last year.
Arch
Unlike OP_NET, Arch has announced that it has received a $7 million seed round of financing led by Multicoin Capital, with participation from OKX, Portal Ventures, Big Brain Holdings, ABCDE, etc. Arch will have its own token, which will be used as both a gas fee and a staking token for its PoS network validators.
Therefore, Arch’s positioning is completely different from OP_NET. If OP_NET is more inclined to the “new protocol, new assets” style at least in the short term, then Arch is completely “a smart contract layer built on the Bitcoin mainnet”, or in other words, “Bitcoin 1.5 layer”.
From the above figure, we can roughly explain the workflow of Arch. Users initiate transactions from the Bitcoin mainnet, Arch nodes sniff transactions and process and verify them, and the leader node is responsible for block transactions, that is, establishing blocks on the Arch network, and is also responsible for submitting the final confirmed Bitcoin transactions back to the Bitcoin mainnet.
Looks a bit like OP_NET? But if you read Archs official documents carefully, you will find that they are more detailed than OP_NET in how to ensure network stability and other technical explanations related to the execution layer. For example, they use the FROST + ROAST signature scheme, which allows Arch to ensure that as long as 51% of the network members are honest and cooperative, they can sign the signature to ensure the robustness of the network.
Finally, although Arch has its own token as the execution layer, which is the gas fee of the Arch network, users can still pay with Bitcoin when interacting with contracts through Arch, and the fee conversion will be done on the back end. Therefore, in terms of use, Arch will not require another set of wallets.
Conclusion
OP_NET and Arch have some similarities in terms of technical implementation. Generally speaking, we can say that we regard the Bitcoin mainnet as the initiator and confirmation layer, and the execution layer is themselves. However, the positioning of these two projects is very different. The former is a protocol and the latter is Bitcoin 1.5 layer.
Of course, the long block generation time of the Bitcoin mainnet may still limit the efficiency of the dApps developed by the two. Their own execution and confirmation are fast enough, but the final confirmation on the Bitcoin mainnet still depends on the miners of the Bitcoin mainnet. Despite this, we are all happy to see the continuous exploration of the Bitcoin ecosystem. Only with exploration can there be development.
Finally, it is worth noting that Archs token may have a TGE in the first quarter of next year, so if there are related testing activities in the future, or dApps based on Arch, everyone who is interested can pay attention and interact. There is nothing good about OP_NET. At present, we can only hope that it will produce some popular tokens, but the current popularity of the entire ecosystem may make it difficult for OP_NET to be like the past ARC-20 protocols.
