On June 10, Cipher, the author of the RGB++ protocol and founder of CELL Studio, Lin, the co-founder of DotSwap, Timxie, the co-founder of Shell Finance, and NIGO, the CMO of TBC (Turingbitchain), visited the Twitter Space of UTXO Stack to discuss whether the UTXO model can give birth to a new model for the Bitcoin ecosystem.

UTXO Stack is a modular BTC L2 one-click chain platform that can help project developers issue Bitcoin L2 based on the UTXO architecture with one click, and natively integrates the RGB++ protocol. In terms of security, UTXO Stack guarantees the security of L2 by staking Bitcoin, CKB, and Bitcoin L1 assets. Simply put, we can think of UTXO Stack as the OP Stack + EigenLayer of the Bitcoin ecosystem.

UTXO Stack has completed its seed round of financing, led by ABCDE and SNZ Capital, and followed by many well-known institutions such as OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab, and UTXO Management, the venture capital department of Bitcoin Magazine's parent company BTC Inc.

The following are the key points based on the audio:

1. What are the essential differences and advantages between the UTXO model and the account model in terms of design philosophy, security, efficiency, etc.?

Cipher: I think the main differences are in design philosophy and efficiency. Security may depend more on the consensus mechanism and has little to do with the account model.

In terms of design philosophy, UTXO is actually more verification-oriented than computation-oriented. We know the account model of Ethereum. When you write a program or send a transaction, you don’t know the result of the transaction. You send an action or a function call. As for the result of the call, you will only know the result after the transaction is packaged into a block.

A typical example is, if you only have 0.1 ETH in your account, can you send a transaction to transfer 0.2 ETH? Yes, you can send it, but after the transaction enters the transaction pool, it will be packaged and return an error because you don’t have that much money, but your gas fee will still be deducted. But if someone happens to transfer money to your account at the same time you send it, making your account balance exceed 0.2 ETH, then your transaction will be successfully executed, and of course the gas fee will be deducted.

But for the UTXO model, your transaction cannot be sent out because you don’t have enough money in your account and you can’t get enough input. Therefore, under the UTXO model, there is no such state as transaction failure. It only has two states: transaction success or failure to send out. That is, the so-called transaction failure means that the verification fails, and your handling fee will not be deducted. UTXO believes that the blockchain is a verification machine, not a calculation machine. Ethereum, which uses the account model, once had a nickname called the world computer. It is for calculation, which is a completely different design philosophy.

There is also a big difference in efficiency between the two. UTXO clearly indicates which states were used before, then destroys them and updates them to new states. When Ethereum calls a function, it does not know which states it will access before calling it, so it can only handle it according to the worst case, that is, it does not preprocess all states. Therefore, each transaction in Ethereum can only be executed serially. An ordinary desktop computer has a CPU of at least six cores and 12 threads, but for the standard EVM, it is still executed by a single thread. UTXO is different. UTXO is naturally parallel. All its transactions can automatically distinguish which transactions are conflicting, and even conflicting transactions will not be sent to the transaction pool. Therefore, the efficiency of the UTXO blockchain is significantly higher than that of the account model. Of course, there is now a narrative called parallel EVM, which wants to solve this problem in some form, but from the description just now, everyone can realize that this cannot be solved fundamentally.

Tim Xie: I agree with what Cipher just said, "Bitcoin UTXO model is more verification-oriented, while Ethereum's account model is more computation-oriented." During the DeFi Summer, we did some swaps, and Ethereum's gas fee was very high. Although Ethereum has a faster block generation speed, larger blocks, and better performance than Bitcoin, Ethereum's demand for expansion is actually higher than Bitcoin's. Why? The reason is that Ethereum is a computational model. When we play DeFi, 98% of the gas fee we pay may be spent on computing, and the cost of verification, dissemination, and storage of account status is actually very small. Bitcoin is a verification network, it does not do calculations, so when we do lending or swaps on Bitcoin's second layer, in the same scenario, the handling fee is actually cheaper than that of Ethereum.

The second is concurrency. Cipher just explained very clearly why EVM is serial. UTXO can be concurrent. What difference will this bring in business? To do lending on Ethereum, you need to deposit money before you can borrow money, because the business logic is that you need collateral. You have to wait for the transaction of the collateral to be confirmed and the status to be fixed before it can calculate the net value of your collateral and the liquidation threshold to let you borrow money. All of this is serial. UTXO can be concurrent, and we can compress all transactions together as much as possible, which means that users' deposit transactions and loan transactions can be merged together to improve efficiency.

From our experience, using the UTXO model for DeFi on Bitcoin does not actually bring as bad an experience to users as people imagine. Although the experience is not as smooth as applications on Ethereum or Arbitrum, it is not too bad and can still be used.

Lin: Let me make a supplement. Existing technologies are constantly evolving. I think UTXO is not inactive, it can also be used for computation. For example, the Bitcoin opcode OP_CAT, which has been hotly debated recently, can be used to preserve the state in Bitcoin's UTXO if it is enabled. If we remove all the native restrictions of Bitcoin, we can simulate countless Ethereums in Bitcoin's UTXO, and each UTXO can be a state of Ethereum, and then continue the data and execution in this state, so that this state can be deduced continuously, although this may not necessarily achieve full EVM compatibility.

So I think Bitcoin can also do calculations, and the logic of Bitcoin is that you can open a new thread at any time, you can split a new UTXO at any time, and the new UTXO is completely separated from the original UTXO. This is a feature of Bitcoin UTXO in computing.

After adding OP_CAT, some very clever application scenarios will be brought about. For example, Ethereum ERC-20 tokens will maintain a list to know which accounts have how much money. After adding OP_CAT, we can do similar things on Bitcoin, and may even do better than Ethereum.

In UTXO, data sharing is actually a big unknown space. For example, Covenants (restrictive clauses) still need some time to build. After this matter is advanced, there may be breakthroughs in how to share data among different UTXOs, how to reference data outside of transactions in transactions, etc.

NIGO: I have always believed that Ethereum changed Bitcoin's UTXO model into an account model, which is a typical superfluous act, and it turned a system that was originally capable of concurrent operation into a serial system. Ethereum is called the world computer by many people. Why should the computing tasks of an ordinary person be calculated by miners around the world? This process consumes huge energy and is very costly, but it does not bring any substantial benefits, but instead delays the overall efficiency. After Ethereum switched to PoS, the miners (nodes) of the entire network lost their evolutionary motivation. The UTXO model designed by Satoshi Nakamoto is naturally suitable for high concurrency and high performance. I believe that more Web3 users will see the potential of the UTXO model.

2. Is it the UTXO model that causes Bitcoin to lack smart contract capabilities? If smart contract capabilities are to be implemented based on the UTXO model, what mechanism is generally used to achieve this?

Cipher: There are definitely many ways to implement smart contract capabilities based on the UTXO model. Let me introduce how CKB, which I am most familiar with, implements it.

CKB introduces a lock script, which is consistent with Bitcoin's lock script. When the UTXO is spent, the lock script will be automatically executed, and it will be executed based on the data in the witness as input, and the current transaction will also be used as input. The difference between it and Bitcoin's lock script is that it supports a complete Turing-complete virtual machine, rather than Bitcoin's very limited script environment, so it is Turing-complete at the unlocking stage.

At the same time, CKB has introduced the type script field, which will be executed regardless of input or output. It is more of an asset category, or the same type represents the same asset. For example, the total amount of fungible tokens remains unchanged before and after transactions, and the amount and content of non-fungible tokens remain unchanged before and after transactions, or it is used to determine who has the right to issue a new asset, etc. It is also a Turing-complete VM.

CKB's virtual machine is based on the RISC-V hardware instruction set. Any adjustments involve re-tapeout, so the design of the RISC-V instruction set is very streamlined, efficient, and comprehensive.

To summarize, CKB uses the RISC-V virtual machine, which is Turing complete. It also has two places, lock script and type script, to store smart contract scripts, and a field called data to store the status of the smart contract, so it is a complete contract execution environment.

Tim Xie: During the entire product construction process of Shell Finance, we needed some advanced contract functions because we wanted to do lending protocol and clearing. Finally, we chose DLC (Discreet Log Contracts). DLC and Lightning Network are both expansion technologies of the same level. Both are offchain. The difference is that Lightning Network is mainly used for payment, while DLC is mainly used for oracle. We are not Turing complete, and there are still many restrictions. But even with many restrictions, we can already do lending through DLC.

Bitcoin actually has many OP Codes. If we can enable or unlock OP_CAT, as mentioned by Lin of DotSwap, or some other opcodes, then we can actually continue to create more possibilities along the lines of Lightning Network and DLC. Smart contracts can definitely do it. The key point is whether there is demand, whether there are users, whether there is a market, and whether more people will invest time and energy to conceive it, use it, and meet user needs. As long as there are people using it and there is a market, new ideas and new concepts will naturally emerge.

What I am sure of now is that the Bitcoin ecosystem will be completely different from the EVM. Maybe at the business level, the user experience may be similar, both are doing swap and lending, both have oracles, but the underlying system and the tools that can be used in the end are actually very different. If it is on the Bitcoin mainnet, the difference will be even greater, so I am actually looking forward to L2 with a better UTXO structure, because it can release the potential of the Bitcoin ecosystem to a greater extent.

Lin: I think it is not very difficult to design something to be Turing complete. On the contrary, it is very difficult to design something to be Turing incomplete. Designing a script to be non-Turing complete is actually a very advanced technical job.

Bitcoin's original script can be Turing complete, but now many capabilities of Bitcoin have been sealed. For example, the OP_CAT I mentioned before is a very important capability, but this capability is disabled by the operator. , rather than saying that Bitcoin did not have these operators when it was originally designed. Bitcoin involved a lot of operators at the beginning, but because of the so-called security, or the so-called hidden dangers of this security, or because there was no clear understanding of what it was, how to use it, etc., some operators were Some operators are disabled. What’s more, many functions that could have been used for smart contracts have been filtered by so-called standard transactions. We all say that Bitcoin is a decentralized system, but in this decentralized system, there is something called a standard transaction, which is determined by certain organizations. Standard transactions do not exist in the field of miners, because miners can package any legal transaction. It is a policy issue based on the user side.

So in general, I think the original Bitcoin's ability is very powerful, but now Bitcoin has been hijacked. If you are interested, you can read Roger Ver's book "Hijacking Bitcoin: The Hidden History of BTC". Because the original ability of Bitcoin has been sealed, we are forced to find a way out in various places. This is the current situation we are facing, but the prospect and future of Bitcoin is definitely better.

I have been saying that many of the so-called Bitcoin L2s are actually parasite protocols. They do not contribute their own value to Bitcoin, and there is no way to make miners have higher incomes. But in fact, there is really no way, because Bitcoin has many restrictions. Let me give you an analogy. The HTTP protocol is actually an L2 built on the TCP/IP protocol, and our HTML protocol is built on the HTTP protocol. I think this is the concept of layer by layer, rather than saying that the transaction data is completely separated from TCP/IP, from the upper layer protocol, and runs to another place, and then turns back to tell others that this is a second-layer protocol. The real second-layer protocol is actually stacked layer by layer, so the L2 we build should also be accepted as a legal transaction in the upper layer. This is a very important reason why we are now exploring the swap on the first layer. We believe that in most cases we actually need to settle to the first layer, and we need to have a lot of verification and consensus on the first layer, rather than saying that I will build a so-called asset bridge and then move everyone's assets to another place. This may not be a particularly good thing.

NIGO: Can the UTXO model support complex smart contract functions? Of course it can. It stores the logic and data of the contract in UTXO, and then uses the call and parameters of the contract as input to try to unlock the contract, execute the logic of the contract through the BVM (Blockchain Virtual Machine), and finally return true or false through the unlocking function to achieve the purpose of controlling the contract status. This model may be unfamiliar to Ethereum smart contract developers, but in fact, if you combine functional programming ideas with some concept conversions, UTXO smart contracts can implement very complex logic.

Since the UTXO model does not have a global state, it needs to store the state and logic of the contract in UTXO, and then transfer and convert the state through the UTXO transaction call chain. Therefore, each UTXO transaction will consume the previous UTXO and generate a new UTXO. In this way, the chain state transfer of the contract can be realized. Therefore, whether the UTXO can be unlocked corresponds to the execution result of the contract, whether it allows the state to be transferred. If the contract determines that the state cannot be modified, such as not allowing transfers or data modification, it will return false, then the UTXO will not be unlocked and the contract execution fails.

If we regard the contract as a state machine that performs data state transfer operations, then we can see the difference between UTXO contracts and account-based contracts. The EVM of the account contract is to maintain the global state. A transaction may cause the EVM to perform multiple state transfers, frequently modifying the state data until the contract is executed or the gas is consumed. The transaction of the UTXO contract is an input contract, and the call will only trigger one state transfer. No matter how complex the logic inside the contract is, or how many times the state transfers, the BVM will only record the final state transfer result on the chain. Therefore, the UTXO contract has no global state, only functions waiting to be executed.

UTXO is multi-input and multi-output. The parallel EVM that Ethereum wants to do, including Monad, can actually be achieved through UTXO. If you need to transfer the state, you must first find the function where the state is located, modify the state through function calls, and generate new functions. This model makes the state transfer of the UTXO contract clearer.

UTXO contracts do not rely on external states, so once a contract is called, no matter how many times it is called, its result must be certain, so this also brings great convenience to the analysis, debugging and unit testing of contracts. However, EVM contracts rely on global states, so the execution results of the contract are likely to be affected by the external environment, resulting in uncertain execution results of the contract, for example, if the balance is sufficient, it will be one result, and if it is insufficient, it will be another result. Therefore, this is also an important issue of the security and predictability of EVM contracts.

Of course, each time the state is passed down, it is not without cost. In some scenarios that require traceability, the state may increase as the UTXO transfer chain increases, because traceability requires verification, and the data is increasing, so the state itself will expand infinitely. We TBC has solved a major problem of state expansion through other technologies and cryptographic means such as hashing and data extraction. Therefore, an important feature of TBC's smart contract that distinguishes it from other UTXO chains is that the UTXO model is a basis for TBC to expand infinitely, making it very simple to use the UTXO model for standard transfer transactions.

In summary, TBC has fully considered the advantages and disadvantages of the UTXO model. On the basis of absorbing the essence of Ethereum and other UTXO public chains, it has introduced the concept of BVM and other technologies to realize a true layer-one UTXO smart contract, and then cooperated with some more friendly smart contract development tools to lower the threshold for writing and deploying BVM smart contracts.

(To be continued)