OP_NET and Arch: BTCSmart Contract's New Exploration

In the past half month, there has been a lot of discussion about the OP_NET and Arch, the two smart contract implementation solutions on the BTC Mainnet. Interestingly, the name OP_NET is similar to the well-known OP_CAT, both starting with ‘OP_’, which has a strong misleading effect that makes people think they are similar.

Therefore, I would like to mention to you a OP_CAT at the beginning. First of all, OP_CAT is the BTC opcode, and since last year, there have been community forces led by Udi Wertheimer, the founder of the “Quantum Cats”, that is, the “Great Wizard” Taproot Wizards, who have been calling for the “resurrection” of OP_CAT. It is said to be “resurrected” because OP_CAT is a BTC opcode that already exists, but Satoshi Nakamoto removed it in 2010 for reasons that could lead to potential DoS attacks. CAT is an abbreviation for the word “concatenate”, and as the word means, the purpose of OP_CAT is to allow the concatenation of strings, concatenating two strings into one.

So how does this opcode help BTC implement smart contracts? To be honest, it’s really abstract and hard to understand, so here I recommend frens who are interested to read an article from another dynamic author Jaleel (“13 lines of code to help BTC implement Smart Contracts? Understand the OP_CAT soft fork”). Here I want to quickly summarize a few key points for everyone:

OP_CAT involves a soft fork on the BTC network, and to reach this stage, BIP-347 proposal needs to be passed. Currently, the proposal is only in the second stage ‘Proposed’ of the entire proposal process.

The OP_CAT on BCH and BSV has been revived for more than a few years, but the related 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-stop solution, and reviving OP_CAT is more like the first step in unlocking the BTCSmart Contract seal. A reasonable expectation is that if OP_CAT can be successfully revived, some excellent use cases will appear, and then further discussions will continue on unlocking more BTC operation codes. We can look forward to seeing some refreshing innovations on Fractal activated with OP_CAT.

OP_NET should actually be classified as part of the “protocol” category, along with runes, BRC-20, and ARC-20. Although its name also has an “OP_”, its implementation has nothing to do with Bitcoin opcodes.

OP_NET

The framework of OP_NET can be divided into two parts. Firstly, since it is a Smart Contract implementation plan for BTCMainnet, BTCMainnet must occupy a part of the entire technical framework. It can be said that the role played by BTCMainnet 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 are another part, which is the “Execution Layer” composed of OP_VM and OP_NET Node.

Based on the technical framework diagram above, we can briefly describe the process of OP_NET implementing Smart Contracts on the BTC Mainnet. First, users who deploy/interact with contracts initiate transactions on the BTC Mainnet. The data field of this transaction will contain the string “BSI”, allowing the execution layer to detect that this is a transaction of an interactive nature for OP_NET contracts. After the transaction is confirmed, OP_VM executes the corresponding contract operation and updates the state, which is then confirmed by the OP_NET Node, ultimately providing the state to the BTC dApp. When the BTC dApp obtains the contract execution result and takes corresponding actions, it will also submit their action results to the BTC Mainnet.

You may have a familiar feeling when you see this - isn’t it the same trap as the off-chain indexer “off-chain execution, on-chain confirmation”? It does have some resemblance. However, the interesting mechanism of OP_NET is that it actually “burns BTC”.

Money Laundering on OP_NET consists of two parts: the first part is the basic BTC network fees for a BTC transaction, and the other part is the OP_NET transaction fees, which are composed of execution fees and priority fees. Both of these fees are paid in BTC. The OP_NET transaction fee must be more than 330 satoshis to ensure that it will not be rejected by Nodes as “dust” (small UTXO). The priority fee allows contract execution actions to pump high Gas, similar to Ethereum, to ensure that their transactions are executed with priority (OP_VM can sort which action is executed first).

If OP_NET Money Laundering is greater than 0.0025 BTC, 330 Satoshi will be “burned”, and the excess will be given to the Node operator as a reward. The so-called “burning” is actually a bit like the situation often seen in Ethereum where money sent to a contract Address cannot be withdrawn, because OP_NET actually abstracts the BTCAddress into a contract Address using a specific type of BTC transaction “Taproot script path spending”, which is uncontrollable by anyone, thus achieving the effect of “burning”.

Finally, let’s make a small observation of this project in the context of this project. The team behind this project is the team of MotoSwap, I don’t know if you still remember the BRC-20 market when the BRC-20 market was ranked third in the BRC-20 Token total Market Cap $OSHI, OSHI is doing the application, and then the team had some disagreements, and some of them went to CBRC-20 to do Moto. Although OP_NET itself uses BTC as the token consumed by the protocol interaction, it also has built-in OP_20 and OP_721 standards, so it can also be said that the style of this project party is more like the “new protocol, new asset” style that we were familiar with last year.

Arch

Unlike OP_NET, Arch has announced that it has secured a $7 million seed round of financing led by Multicoin Capital, with participation from OKX, Portal Ventures, Big Brain Holdings, ABCDE, and others. Arch will have its own Token, which will serve as both gas fees and stake Token for its PoS network validators.

Therefore, the positioning of Arch is completely different from OP_NET. If OP_NET is more inclined towards the style of ‘new protocol, new assets’ in the short term, then Arch is completely a ‘smart Contract Layer built on BTC Mainnet’ or ‘BTC 1.5 layer’.

From the above figure, we can roughly describe the working process of ARCH. Users initiate transactions from BTC Mainnet, and ARCH Nodes sniff the transactions for processing and verification. Leader Nodes are responsible for ‘Block transactions’, i.e., establishing Blocks for the ARCH network, and also for submitting the finally confirmed BTC transactions back to BTC Mainnet.

It looks a bit like OP_NET, but if you read the official documentation of Arch carefully, you will find that they are more detailed in explaining how to ensure network stability and other ‘execution layer’ related technologies than OP_NET. For example, they use the ‘FROST + ROAST’ signature scheme, which enables Arch to ensure the robustness of the network as long as 51% of the network members are honest and cooperative to sign the signature.

Finally, although Arch has its own Token as the ‘execution layer’, which is the Gas fee for the Arch network, users can still pay with BTC when interacting with contracts through Arch, and the fee conversion will be done on the backend. Therefore, in terms of usage, Arch will not require another trapWallet.

Conclusion

OP_NET has some similarities with Arch technology in terms of implementation. Overall, we can say that they both treat BTCMainnet as the “initiating end” and “confirmation layer”, while the “execution layer” is their own. However, the positioning of these two projects is very different, with the former being a “protocol” and the latter being a “BTC 1.5 layer”.

Of course, the problem of BTC Mainnet Mining a Block taking too long may still limit the efficiency of the dApps developed by both parties. Their own execution and confirmation are fast enough, but ultimately the confirmation on BTC Mainnet still depends on whether the BTC Mainnet miners are powerful enough. Nevertheless, we are pleased to see the continuous exploration of the BTC ecosystem, because only through exploration can there be development.

Finally, it is worth noting that the Token of Arch may have a TGE in the first quarter of next year, so if there are future related tests and activities, or dApps based on Arch, everyone can pay attention and interact. There is nothing much to expect from OP_NET for now. We can only hope for some popular Tokens to be launched on it. However, the current ecosystem’s enthusiasm may not be able to support OP_NET to produce something like the protocol of the past such as ARC-20.

Statement:

1. This article is reproduced from [[BlockBeats]Cookie], the copyright belongs to the original author [(https://www.theblockbeats.info/newsauthor/106)], if you have any objections to the reprint, please contact [Gate Learn Team](https://www.gate.io/questionnaire/3967, the team will process it as soon as possible according to the relevant procedures.

2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.

3. The other language versions of the article are translated by the Gate Learn team. Without mentioning [Gate.io], copying, spreading, or plagiarizing the translated article is not allowed.