Author: Cookie
In the past half month, OP_NET and Arch, two smart contract implementations on the Bitcoin mainnet, have sparked a lot of discussion. Interestingly, 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 use cases are still very abstract. In the current discussion, we can hardly see any clear and direct examples 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 unlocking 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 has nothing to do with Bitcoin opcodes.
ON_NET
The framework of OP_NET can be roughly divided into two parts. First, since it is the smart contract implementation plan of Bitcoin Mainnet, Bitcoin Mainnet must occupy a part of the entire technical framework. It can be said that the role of 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 - isn't 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. The OP_NET transaction fee consists of an execution fee and a priority fee, both of which are paid in Bitcoin. The OP_NET transaction fee must be more than 330 satoshis to ensure that it will not be regarded as "dust" (too small UTXO) and rejected by the node. 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, let's 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 Moto on CBRC-20. Although OP_NET itself uses Bitcoin as a token consumed by protocol interactions, it also has built-in standards for 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 asset” 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, building blocks of 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 Arch's 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" or 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 are somewhat similar in terms of technical implementation. In general, 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 Arch’s 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 popularity of the entire ecosystem may make it difficult for OP_NET to be launched like the ARC-20 protocol in the past.
