On June 10th, the author of the RGB++ protocol and founder of CELL Studio, Cipher, co-founder of DotSwap, Lin, co-founder of Shell Finance, Timxie, and NIGO, CMO of TBC (Turingbitchain), visited UTXO Stack’s Twitter Space to discuss whether the UTXO model can foster a new model for the Bitcoin ecosystem.
UTXO Stack is a modular BTC L2 one-click chain issuance platform that helps project developers issue Bitcoin L2 based on the UTXO architecture and natively integrates the RGB++ protocol. In terms of security, UTXO Stack ensures the security of L2 by pledging Bitcoin, CKB, and assets of Bitcoin L1. In simple terms, we can imagine 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, with participation from OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab, and UTXO Management, the investment arm of Bitcoin Magazine’s parent company, BTC Inc.
The following key points were summarized 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, and efficiency?
Cipher: The main differences lie in design philosophy and efficiency, with security being more related to the consensus mechanism rather than the account model. Design-wise, UTXO leans more towards verification rather than computation. In Ethereum’s account model, when you write programs or send transactions, you don’t know the result of the transaction; you send an action or a function call, and only after the transaction is included in a block do you know the result.
A typical example is if you have only 0.1 ETH in your account, can you send a transaction for 0.2 ETH? You can send it, but after it is included in the transaction pool, it may be rejected and your gas fee will be deducted. However, if someone transfers money to your account at the same time, increasing your balance to over 0.2 ETH, the transaction will be successful. In the UTXO model, if you don’t have enough money in your account, you can’t send the transaction because you can’t produce enough input. Therefore, in the UTXO model, there is no concept of transaction failure; it’s either a successful transaction or one that cannot be sent, meaning that failed transactions are not charged a fee. UTXO views the blockchain as a verification machine rather than a computation machine, while Ethereum’s account model, known as the world computer, focuses on computation, showcasing different design philosophies.
In terms of efficiency, there is a significant difference between the two. UTXO clearly indicates which states were used before and updates them to new states. Ethereum, on the other hand, doesn’t know which states will be accessed before a function call, so it processes all states without any pre-processing, resulting in serial execution of each transaction. UTXO, on the other hand, is inherently parallel, automatically distinguishing conflicting transactions, not even including conflicting transactions in the transaction pool. Therefore, the efficiency of UTXO blockchain is significantly higher than the account model of Ethereum. While there is a narrative of parallel EVM to address this issue, it is clear from the description that it cannot fundamentally solve the problem.
Tim Xie: I agree with Cipher’s statement that “Bitcoin’s UTXO model leans more towards verification, while Ethereum’s account model leans more towards computation.” During DeFi Summer, when we conducted swaps, Ethereum’s gas fees were high. Despite Ethereum having faster block times, larger blocks, and better performance compared to Bitcoin, its scalability demands are higher due to its computational model. In DeFi, most of the gas fees on Ethereum are spent on computation rather than verification, propagation, and storing account states. Bitcoin is a verification network and doesn’t perform computations. Therefore, when we conduct lending or swaps on Bitcoin’s layer two, the fees are cheaper than on Ethereum.
Another point is concurrency. Cipher explained why EVM is serial, while UTXO can be concurrent, bringing about differences in business operations. On Ethereum, for lending, you need to deposit before borrowing, as the logic requires collateral and confirmation of the collateral transaction before calculating the collateral net value and liquidation threshold for borrowing, which happens serially. With UTXO, we can compress all transactions together, allowing deposit and borrowing transactions to be merged, improving efficiency.
From our experience, using the UTXO model for DeFi on Bitcoin doesn’t provide as smooth an experience as on Ethereum or Arbitrum, but it is still usable.
Lin: Let me add to that. Existing technologies are constantly evolving, and I believe UTXO can also perform computations. For example, the recent discussion on the Bitcoin opcode OP_CAT shows that we can retain state in Bitcoin’s UTXO. If we remove all the native restrictions of Bitcoin, we can simulate numerous Ethereums within Bitcoin’s UTXO, where each UTXO can be a state of Ethereum, continuing data and execution in that state, although it may not achieve full EVM compatibility. Therefore, I believe Bitcoin can also perform computations, and the ability to open new threads at any time, splitting a new UTXO from the original one, is a unique feature of Bitcoin’s UTXO in terms of computation.
The introduction of OP_CAT will lead to clever applications. For example, Ethereum’s ERC-20 tokens maintain a list of accounts and their balances. With OP_CAT, we can do similar things on Bitcoin, possibly even better than Ethereum.
Data sharing in UTXO is a vast unexplored space. For example, Covenants require further development, but once advancements are made, sharing data across different UTXOs and referencing data outside transactions may lead to breakthroughs.
NIGO: I have always believed that Ethereum’s transformation of Bitcoin’s UTXO model into an account model is unnecessary and has turned a system that could have been concurrent into a serial one. Many refer to Ethereum as the world computer, but why should a global network of miners compute a regular person’s task, consuming significant energy and costs without substantial benefits, hampering overall efficiency? With Ethereum transitioning to PoS, the network’s miners (nodes) have lost the incentive to evolve. On the other hand, Satoshi Nakamoto’s UTXO model is naturally suited for high concurrency and performance, and I believe more Web3 users will recognize the potential of the UTXO model.
2. Does the UTXO model prevent Bitcoin from having smart contract capabilities? If smart contract capabilities need to be implemented on the UTXO model, what mechanisms are generally used?
Cipher: There are many ways to implement smart contract capabilities on the UTXO model. I will explain how CKB, which I am most familiar with, achieves this.
CKB introduces a lock script similar to Bitcoin’s lock script. When a UTXO is spent, the lock script automatically executes based on the data in the witness and the current transaction. The difference from Bitcoin’s lock script is that CKB supports a Turing complete virtual machine, rather than Bitcoin’s limited scripting environment, making it Turing complete during the unlocking phase.
Additionally, CKB introduces a type script field that executes for both input and output, mainly serving as the asset category or logic for the asset. For example, fungible token transactions maintain the total quantity before and after the transaction, while non-fungible token transactions keep the quantity and content unchanged, or used to determine.Who has the authority to issue a new type of asset, etc.? It is also a Turing complete VM in itself.
The virtual machine of CKB is based on the RISC-V hardware instruction set, and any adjustments involve reflowing, so the design of the RISC-V instruction set is very concise, efficient, and comprehensive.
In summary, CKB adopts the RISC-V virtual machine, which is Turing complete, and it also has two places, lock script and type script, to store smart contract scripts, and there is also a field called data to store the status of smart contracts, so it is a complete contract execution environment.
Tim Xie: Throughout the entire product construction process of our Shell Finance, because we want to build a lending protocol and do settlement, we need some advanced contract features, so we finally chose DLC (Discreet Log Contracts). DLC and the Lightning Network belong to the same level of scaling technology, both are offchain, the difference is that the Lightning Network mainly does payment, while DLC is mainly used for oracles. We are actually not Turing complete, there are still many restrictions, but even with many restrictions, through DLC, we can already do lending.
Bitcoin actually has many OP Codes, if we can enable or unlock, for example, OP_CAT mentioned by Lin from DotSwap, or other opcodes, then we can continue along the path of the Lightning Network and DLC to create more possibilities, smart contracts can definitely be done. The key point is whether there is a demand, users, a market, and more people investing time and energy to conceive it, use it, and meet user needs. As long as people use it, there is a market, new ideas, new concepts will naturally emerge.
I now dare to assert that the form of the Bitcoin ecosystem will definitely be completely different from that of EVM. Maybe at the business level, the user experience may be similar, both doing swaps and lending, both have oracles, but the system behind it and the tools that can be used are actually very different. If it is on the Bitcoin mainnet, this difference will be even greater, so I am actually looking forward to a better L2 with a good UTXO structure, because it can better unleash the potential of the Bitcoin ecosystem.
Lin: I think designing something to be Turing complete is not very difficult, on the contrary, making it non-Turing complete is very difficult, designing a script to be non-Turing complete is actually a very profound technical activity.
Bitcoin’s original script could be Turing complete, it’s just that many of Bitcoin’s capabilities have been sealed off, such as the important capability I mentioned earlier, OP_CAT, which has been disabled by operators, not that these operators didn’t exist when Bitcoin was originally designed. Bitcoin originally involved a lot of operators, but because of so-called security concerns, or the so-called security vulnerabilities, or not understanding what they were, how to use them, etc., some operators were disabled. Moreover, many functions that could have been used for smart contracts were filtered out by so-called standard transactions. We all say that Bitcoin is a decentralized system, but in this decentralized system, there is actually something called a standard transaction, which is decided by certain organizations. Standard transactions do not exist in the mining field, because miners can package any legal transactions, it is a policy issue based on the user side.
So overall, I think Bitcoin’s original capabilities are very powerful, but now Bitcoin has been hijacked. If you are interested, you can take a look at Roger Ver’s book “Hijacking Bitcoin: The Hidden History of BTC”. Because Bitcoin’s original capabilities have been sealed off, we are forced to find a way out in various places, this is the current situation we are facing, but the future of Bitcoin is definitely good.
I have always said that many so-called Bitcoin L2s are actually parasitic protocols, they do not contribute their value to Bitcoin, nor do they allow miners to have higher income, but in reality, it is also impossible, because Bitcoin has many restrictions. I’ll give you an analogy, the HTTP protocol is actually built on top of the TCP/IP protocol as L2, and our HTML protocol is built on top of the HTTP protocol. Here, I think it’s a concept of layering, not completely separating transaction data from TCP/IP, from the upper layer protocol, moving it to another place, and then turning around and telling others that this is a second-layer protocol. The real second-layer protocol is actually stacked layer by layer, so the L2 we are building should also be accepted as valid transactions in the upper layer. This is why it is very important for us to explore on the first layer of swaps. In most cases, we actually want to settle on the first layer, we want to have a lot of validation and consensus support on the first layer, instead of creating an asset bridge and moving everyone’s assets to another place, which may not be a very 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 attempts to unlock the contract by using the contract’s call and parameters as input, executes the contract logic through the Blockchain Virtual Machine (BVM), and ultimately controls the contract state by returning true or false through the unlock function. This mode may be unfamiliar to Ethereum smart contract developers, but in reality, if you combine functional programming ideas, and make some concept transformations, UTXO smart contracts can implement very complex logic.
Because the UTXO model does not have global state, it needs to store the contract’s state and logic in UTXO, and then pass the call chain of UTXO transactions to carry out state transfer and conversion, so each UTXO transaction will consume the previous UTXO and generate a new UTXO, which can achieve the chain state transfer of the contract. So, whether UTXO can be unlocked corresponds to the execution result of the contract, whether it allows state transfer. If the contract judges that it does not allow modification of the state, such as not allowing transfers, not allowing data modification, etc., it will return false, and the UTXO will not be unlocked, and the contract execution will fail.
We regard the contract as a state machine that operates state transfer operations on data states, and here we can see the difference between UTXO contracts and account-type contracts. The EVM of account contracts must maintain global state, a transaction may cause the EVM to perform multiple state transfers, frequently modify state data until the contract is executed or the gas is consumed. The transaction of UTXO contracts, it is an input contract, the call will only trigger one state transfer, and no matter how complex the internal logic of the contract is, how many times the state is transferred, the BVM will only record the final state transfer result on the chain. Therefore, UTXO contracts do not have global state, only functions waiting to be executed.
UTXO is multiple inputs and multiple outputs, what Ethereum wants to do, including Monad also wants to do parallel EVM, can actually be implemented completely through UTXO, you need to find the function where the state needs to be transferred, modify the state through function calls, and generate new functions, this pattern makes the state transfer of UTXO contracts clearer.
UTXO contracts do not rely on external states, therefore, each contract call, no matter how many times it is called, its result will be deterministic, so this brings great convenience to contract analysis, debugging, and unit testing. EVM contracts need to rely on global state, so the execution result of the contract is likely to be affected by the external environment, leading to an uncertain execution result of the contract, such as having enough balance is one result, not having enough balance is another result. So this is also an important issue of security and predictability for EVM contracts.
Of course, passing the state down each time is not without cost, in some scenarios that require tracing, the state may increase as the UTXO transaction chain increases, because tracing requires verification, more and more data, so the state itself will expand infinitely. We, TBC, through other technologies and cryptographic means such as hashing, data extraction, etc., have solved the problem of state expansion. So, a key feature that distinguishes TBC’s smart contracts from other UTXO chains is that the UTXO model is the foundation for TBC’s unlimited scaling, making standard transfer transactions on the UTXO model very simple.
In conclusion, TBC fully considers the advantages and disadvantages of the UTXO model, absorbs the essence of Ethereum and other UTXO public chains, introduces the concept of BVM and other technologies to achieve a truly first-layer UTXO smart contract, and then cooperates with more friendly smart contract development tools, lowering the threshold for writing and deploying BVM smart contracts.
