Over the past two weeks, OPNET and Arch, two smart contract implementation solutions on the Bitcoin mainnet, have sparked considerable discussion. Interestingly, the name OP_NET is quite similar to the familiar OP_CAT, both starting with “OP“, which can be misleading and make people think they are quite similar.

Let’s first mention OP_CAT. OP_CAT is a Bitcoin opcode that community forces, led by Udi Wertheimer, founder of “Quantum Cats” (also known as Taproot Wizards), have been calling to “revive” since last year. The term “revive” is used because OP_CAT was an existing Bitcoin opcode, but Satoshi Nakamoto removed it in 2010 due to potential DoS attack concerns. CAT is short for “concatenate”, and as the name suggests, OP_CAT’s function is to allow string concatenation operations, joining two strings into one.

How does this opcode enable smart contracts on Bitcoin? Honestly, it’s quite abstract and difficult to understand. For those interested, I recommend reading an article by another author, Jaleel (“13 lines of code help Bitcoin implement smart contracts? Understand the OP_CAT soft fork”). Here are a few key points I’d like to summarize quickly:

OP_CAT involves a soft fork of the Bitcoin network. To reach this step, the BIP-347 proposal needs to be passed first. Currently, this 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 several years, but related use cases are still very abstract. In current discussions, we hardly see any clear and direct examples of what kind of dApp can be created using OP_CAT.

OP_CAT is not a one-step solution. Reviving OP_CAT is more like the first step in unlocking Bitcoin’s smart contract potential. A reasonable expectation is that if OP_CAT can be successfully revived and some excellent use cases emerge, there will be further discussions about unlocking more Bitcoin opcodes. We can first look forward to seeing if there will be any refreshing innovations on Fractal, which has activated OP_CAT.

OPNET, on the other hand, should be categorized with “protocols” like inscriptions, BRC-20, and ARC-20. Although its name also has an “OP“, its implementation method has nothing to do with Bitcoin opcodes.

ON_NET

The framework of OP_NET can be broadly divided into two parts. Since it’s a smart contract implementation solution for the Bitcoin mainnet, the Bitcoin mainnet certainly occupies a part of the entire technical framework. It can be said that the Bitcoin mainnet plays the role of “action initiation layer” and “final confirmation layer” in OP_NET’s technical framework. The execution and state confirmation of smart contracts is another part, which is the “execution layer” jointly composed of OP_VM and OP_NET nodes.

Based on the technical framework diagram, we can simply explain the process of OP_NET implementing smart contracts on the Bitcoin mainnet. First, users who deploy/interact with contracts initiate transactions from the Bitcoin mainnet. The data field of this transaction will contain the string “BSI”, allowing the execution layer to detect that this is an OP_NET contract interaction transaction. After the transaction is confirmed, OP_VM executes the corresponding contract operations and updates the state, which is then handed over to OP_NET nodes for state confirmation, and finally provides the state to the Bitcoin dApp. After the Bitcoin dApp receives the contract execution results and performs corresponding actions, it will also submit the results of their actions to the Bitcoin mainnet.

At this point, you might have a familiar feeling - isn’t this just another off-chain indexer with “off-chain execution, on-chain confirmation”? Indeed, there are some similarities. However, OP_NET has an interesting mechanism in that it actually “burns Bitcoin”.

The transaction fee of OP_NET consists of two parts. The first part is naturally the basic Bitcoin network fee for a Bitcoin transaction, and the other part is the OP_NET transaction fee. The OP_NET transaction fee is further composed of execution fee and priority fee, both of which are paid in Bitcoin. The OP_NET transaction fee must be more than 330 satoshis to ensure it won’t be considered “dust” (too small UTXO) and rejected by nodes. The priority fee allows contract execution actions to raise Gas like Ethereum to ensure their transactions are executed with priority (OP_VM can prioritize which actions to execute first).

If the OP_NET transaction fee is greater than 0.0025 Bitcoin, 330 satoshis will be “burned”, and the excess will be given to node operators as a reward. The so-called “burning” is similar to the situation often seen in Ethereum where money sent to contract addresses can’t be withdrawn, because OP_NET actually uses a specific type of Bitcoin transaction, “Taproot script path spending”, to abstract Bitcoin addresses into contract addresses. This contract address is uncontrollable by anyone, thus achieving the effect of “burning”.

Finally, we make a small observation about this project based on its background. The team behind this project is the MotoSwap team. I don’t know if you still remember $OSHI, which ranked third in the total market value of BRC-20 Token during the BRC-20 market. OSHI was engaged in applications. Later, the team had some differences. , some of them were transferred to CBRC-20 to make Moto. Although OP_NET itself uses Bitcoin as the Token consumed by protocol interaction, it also has two built-in standards, OP_20 and OP_721. Therefore, it can be said that the style of this project is more towards the “new protocol, new protocol” that we were familiar with last year. Asset” style.

Arch

Unlike OP_NET, Arch has announced that it has received a US$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, both as a gas fee and as a pledge token for its PoS network validators.

Therefore, Arch’s positioning is completely different from OP_NET. If OP_NET is still 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 main network”, or in other words, “Bitcoin 1.5 layer”.

From the picture above we can roughly explain Arch’s workflow. Users initiate transactions from the Bitcoin main network. Arch nodes sniff transactions and process and verify them. The leader node is responsible for “block transactions”, that is, establishing the blocks of the Arch network. It is also responsible for submitting the final confirmed Bitcoin transaction. Return to the Bitcoin mainnet.

Looks a bit like OP_NET? But in fact, 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 used the “FROST + ROAST” signature scheme, which allows Arch to ensure that as long as 51% of network members are honest and cooperative, they can sign signatures to ensure the stability 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 performed on the backend. Therefore, in terms of use, Arch will not require another set of wallets.

Conclusion

OP_NET and Arch have some similarities in their technical implementation. Overall, we can say that both use the Bitcoin mainnet as the “initiation point” and “confirmation layer,” while the “execution layer” is their own. However, these two projects have distinctly different positioning - the former is a “protocol,” while the latter is a “Bitcoin layer 1.5”.

Of course, the long block time of the Bitcoin mainnet may still limit the efficiency of dApps developed on both platforms. While their own execution and confirmation processes are fast enough, the final confirmation on the Bitcoin mainnet still depends on the efficiency of Bitcoin miners. Nevertheless, we all welcome the continuous exploration of the Bitcoin ecosystem, as only through exploration can development occur.

Lastly, it’s worth noting that Arch’s token may have its TGE (Token Generation Event) in the first quarter of next year. Therefore, if there are related testing activities or dApps based on Arch launched in the future, those interested can pay attention and interact with them. As for OP_NET, there isn’t much to farm at the moment. Currently, we can only hope for some popular tokens to emerge on it, but the current heat of the entire ecosystem might make it difficult for OP_NET to take off like past protocols such as ARC-20.

Statement:

1. This article is reproduced from [BlockBeats], the copyright belongs to the original author [Cookie], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.