On June 10, Cipher, the author of the RGB++ protocol and founder of CELL Studio, Lin, co-founder of DotSwap, Timxie, co-founder of Shell Finance, and NIGO, CMO of TBC (Turingbitchain), were guests on the UTXO Stack Twitter Space, discussing whether the UTXO model can give rise to new models in 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 with native integration of the RGB++ protocol. In terms of security, UTXO Stack ensures the safety of L2 by staking Bitcoin, CKB, and assets on Bitcoin L1. Simply put, we can think of UTXO Stack as the OP Stack + EigenLayer of the Bitcoin ecosystem.
UTXO Stack has completed its seed round financing, led by ABCDE and SNZ Capital, with follow-on investments from several well-known institutions including OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab, and the venture capital department of Bitcoin Magazine's parent company, BTC Inc.
This nearly 2-hour Space was rich in content, and we welcome those who haven't had the chance to listen to the Space to catch the audio replay: https://x.com/utxostack/status/1799046046812942369
Here are the key points organized 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: I think the main differences lie in design philosophy and efficiency; security is more about the consensus mechanism and is less related to the account model.
In terms of design philosophy, UTXO is more about validation rather than computation. We know that in Ethereum's account model, when you write a program or send a transaction, you don't know the result of that transaction; you are sending an action or a function call, and you only know the result after the transaction is packed into a block.
A typical example is, suppose your account has only 0.1 ETH, can you send a transaction to transfer 0.2 ETH? You can send it, but this transaction might enter the transaction pool, get packed, and then return an error because you don't have enough money, but your gas fee will still be deducted. However, if at the same time someone transfers money to your account, making your balance exceed 0.2 ETH, then your transaction will be successfully executed, and of course, the gas fee will still be deducted.
But for the UTXO model, you cannot send that transaction because you don't have enough money in your account; you can't gather enough inputs. Therefore, in the UTXO model, there is no state of transaction failure; it only exists in two states: transaction success or unable to send. The so-called transaction failure is simply a validation failure, and you won't be charged a fee. UTXO sees the blockchain as a validation machine rather than a computation machine, while Ethereum, which adopts the account model, was once nicknamed the world computer, as it is meant for computation, reflecting a completely different design philosophy.
There are also significant differences in efficiency between the two. UTXO explicitly points out which states were used previously, then destroys them and updates to new states. In contrast, Ethereum does not know which states it will access before making a function call, so it can only handle the worst-case scenario, meaning it does not preprocess any states. Therefore, each transaction in Ethereum can only be executed serially. A typical desktop computer has at least a six-core, 12-thread CPU, but for the standard EVM, it still executes in a single thread. UTXO, on the other hand, is inherently parallel; all its transactions can automatically distinguish which transactions are conflicting, and even conflicting transactions will not enter the transaction pool, so the efficiency of UTXO blockchains is significantly higher than that of account models. Of course, there is now a narrative called parallel EVM, which aims to solve this problem in some way, but as described earlier, it is clear that this cannot fundamentally resolve the issue.
Tim Xie: I completely agree with what Cipher just said, "the Bitcoin UTXO model is more about validation, while Ethereum's account model is more about computation." During DeFi Summer, when we were doing some swaps, Ethereum's gas fees were very high. Although Ethereum has a faster block time, larger blocks, and better performance compared to Bitcoin, the demand for scalability in Ethereum is actually higher than in Bitcoin. Why? Because Ethereum is a computation model. In DeFi, the gas fees paid may be 98% spent on computation, while the costs for validation, propagation, and storing account states are actually very low. Bitcoin is a validation network; it does not perform computations, so when we do lending or swaps on Bitcoin's second layer, the fees are actually cheaper than those on Ethereum.
The second point is concurrency. EVM is serial, as Cipher just explained very clearly, while UTXO can handle concurrency. What difference does this make in business? In Ethereum, to do lending, you need to deposit first before you can borrow because the business logic requires collateral, and you have to wait for the confirmation of the collateral transaction before it can calculate your collateral net worth and liquidation threshold, making everything serial. UTXO can handle concurrency; we can compress all transactions together as much as possible, which means we can combine user deposit transactions and borrowing transactions, improving efficiency.
From our experience, using the UTXO model for DeFi on Bitcoin does not provide a user experience as bad as people imagine. Although the experience may not be as smooth as applications on Ethereum or Arbitrum, it is still usable.
Lin: I would like to add. Existing technologies are constantly evolving, and I believe UTXO can also perform computations. For example, the recently discussed Bitcoin opcode OP_CAT can allow us to retain state in Bitcoin's UTXO. If we remove various native limitations of Bitcoin, we can simulate countless instances of Ethereum within Bitcoin's UTXO, where each UTXO can represent an Ethereum state, and the data and execution can continue within that state, allowing it to evolve continuously, although this may not achieve complete EVM compatibility.
So I believe Bitcoin can also perform computations, and the logic of Bitcoin allows you to open new threads at any time; you can split off a new UTXO, and the new UTXO is completely separate from the original UTXO, which is a characteristic of Bitcoin's UTXO in computation.
After adding OP_CAT, it will bring about some clever application scenarios. For example, Ethereum's ERC-20 tokens maintain a list to know how much money each account has. After adding OP_CAT, we can do similar things on Bitcoin, and it might even be better than Ethereum.
In UTXO, data sharing is actually a vast unknown space. For example, Covenants still require some time for development. Once this progresses, how to achieve data sharing among different UTXOs and how to reference data outside of transactions may lead to breakthroughs.
NIGO: I have always believed that Ethereum's transformation of Bitcoin's UTXO model into an account model is a classic case of overcomplicating things, turning a system that could perform concurrently into a serial system. Ethereum is often referred to as the world computer; why should an ordinary person's computational tasks require global miners to compute? This process consumes enormous energy and incurs high costs without providing substantial benefits, ultimately hindering overall efficiency. After Ethereum transitioned to PoS, the entire network's miners (nodes) lost their evolutionary motivation. The UTXO model designed by Satoshi Nakamoto is inherently suitable for high concurrency and high performance, and I believe more Web3 users will see the potential of the UTXO model.
2. Is the UTXO model the reason Bitcoin lacks smart contract capabilities? If we want to implement smart contract capabilities based on the UTXO model, what mechanisms are generally used?#
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, achieves this.
CKB introduces a lock script, which is consistent with Bitcoin's lock script. When this UTXO is spent, the lock script automatically executes, using the data in the witness as input, along with the current transaction as input for execution. The difference from Bitcoin's lock script is that it supports a complete Turing-complete virtual machine, rather than Bitcoin's very limited scripting environment, so it is Turing-complete at the unlocking stage.
At the same time, CKB also introduces a type script field, which executes regardless of whether it is input or output. It serves more as a category for the asset, or the same type represents the same asset. For example, fungible token transactions maintain a constant total before and after the transaction, non-fungible token transactions maintain the same quantity and content before and after, or it can be used to determine who has the right to issue a new asset, etc. It is also a Turing-complete VM.
The CKB virtual machine is based on the RISC-V hardware instruction set, and any adjustments involve re-taping, so the RISC-V instruction set is designed to be very concise, efficient, and comprehensive.
In summary, CKB uses the RISC-V virtual machine, which is Turing-complete, and it has both lock script and type script to store smart contract scripts, along with a field called data to store the state of smart contracts, making it a complete contract execution environment.
Tim Xie: In the entire product development process at Shell Finance, since we need to create a lending protocol and perform liquidations, we required some advanced contract functionalities, and ultimately we chose DLC (Discreet Log Contracts). DLC and the Lightning Network are both off-chain scaling technologies of the same level, with the difference being that the Lightning Network primarily focuses on payments, while DLC is mainly used for oracles. We are not Turing-complete, and there are still many limitations, but even with many restrictions, we can already do lending through DLC.
Bitcoin actually has many OP Codes, and if we could enable or unlock some of them, like OP_CAT mentioned earlier by Lin from DotSwap, or other opcodes, we could continue to create more possibilities along the lines of the Lightning Network and DLC; smart contracts can definitely be done. The core point is whether there is demand, whether there are users, whether there is a market, and whether more people are willing to invest time and energy to conceive, use, and meet user needs. As long as there are users and a market, new ideas and concepts will naturally emerge.
I can now confidently say that the shape of the Bitcoin ecosystem will definitely be completely different from that of EVM. Perhaps at the business level, users' experiences may be similar, doing swaps and lending, both having oracles, but the underlying systems and the tools available will have huge differences. If it is on the Bitcoin mainnet, this difference will be even greater, so I am actually looking forward to a better UTXO structure L2 because it can greatly unleash the potential of the Bitcoin ecosystem.
Lin: I think designing something to be Turing-complete is not very difficult; rather, making it non-Turing-complete is quite challenging, and designing scripts to be non-Turing-complete is a very advanced technical task.
Bitcoin's original script could achieve Turing-completeness, but many capabilities have been sealed off in the current Bitcoin. For example, the OP_CAT I mentioned earlier is a very important capability, but it has been disabled by the operators, not because Bitcoin was originally designed without these operators. In the beginning, Bitcoin involved many operators, but due to so-called security concerns or uncertainties about what they were and how to use them, certain operators were disabled. Even more so, many functionalities that could have been used for smart contracts have been filtered out by so-called standard transactions. We all say Bitcoin is a decentralized system, but within this decentralized system, there is actually something called standard transactions, which are determined by certain organizations. Standard transactions do not exist in the miner domain because miners can package any legitimate transaction; it is a policy issue based on the user side.
In summary, I believe the original capabilities of Bitcoin are very powerful, but Bitcoin is currently hijacked. If anyone is interested, they can read 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 ways out in various places, which is the current situation we face, but the future of Bitcoin is definitely promising.
I have always said that many so-called Bitcoin L2s are actually parasitic protocols; they do not contribute their own value to Bitcoin and cannot provide higher income for miners, but in reality, they cannot, because Bitcoin has many restrictions. I will give an analogy: the HTTP protocol is actually built on top of the TCP/IP protocol as an L2, while our HTML protocol is built on top of the HTTP protocol. Here, I think it is a layered concept, rather than saying that transaction data is completely separated from TCP/IP or from the previous layer protocol and runs elsewhere, then comes back and claims that this is a second-layer protocol. True second-layer protocols are actually stacked layer by layer, so the L2 we are building should also be accepted as legitimate transactions within the previous layer. This is why we are currently exploring swaps at one layer.
NIGO: Can the UTXO model support complex smart contract functionalities? Of course, it can. It involves storing the logic and data of the contract in the UTXO, then attempting to unlock the contract by using the contract call and parameters as inputs, executing the contract logic through the BVM (Blockchain Virtual Machine), and ultimately returning true or false through the unlocking function to control the contract state. This model may be somewhat unfamiliar to Ethereum smart contract developers, but in reality, if you combine functional programming ideas with some conceptual transformations, UTXO smart contracts can implement very complex logic.
Due to the absence of a global state in the UTXO model, it needs to store the contract's state and logic in the UTXO, then pass the state through the UTXO transaction call chain for transmission and transformation. Therefore, each UTXO transaction consumes the previous UTXO and generates new UTXOs, allowing for chain state transfers of contracts. Thus, whether a UTXO can be unlocked corresponds to the execution result of the contract, determining whether it allows state transfers. If the contract determines that state modifications are not allowed, such as prohibiting transfers or data modifications, it will return false, and the UTXO will not be unlocked, resulting in contract execution failure.
We can view contracts as state machines that perform state transfer operations on data, which highlights the differences between UTXO contracts and account-based contracts. The EVM of account contracts must maintain a global state, and a transaction may lead to multiple state transfers in the EVM, frequently modifying state data until the contract executes or gas runs out. In contrast, UTXO contract transactions are input contracts; the call will only trigger a single state transfer, and regardless of how complex the internal logic of the contract is or how many state transfers occur, the BVM will only record the final state transfer result on the chain. Therefore, UTXO contracts do not have a global state; they only have individual functions waiting to be executed.
UTXO is multi-input, multi-output, and what Ethereum wants to do, including what Monad wants to achieve with parallel EVM, can actually be fully realized through UTXO. To transfer a state, one must first find the function where that state resides, modify the state through function calls, and generate new functions. This model makes the state transfer of UTXO contracts clearer.
UTXO contracts do not rely on external states; therefore, a single contract call, regardless of how many times it is called, will yield a definite result. This also brings great convenience to contract analysis, debugging, and unit testing. In contrast, EVM contracts depend on global states, so the execution results of contracts may be influenced by external environments, leading to uncertain execution results. For example, having enough balance is one result, while not having enough is another. This is also an important issue regarding the security and predictability of EVM contracts.
Of course, passing the state down each time is not without cost. In some traceable scenarios, the state may increase as the UTXO transfer chain grows, as tracing requires verification, and the data increases, leading to potential state inflation. We at TBC have addressed the significant issue of state inflation through other technologies and cryptographic means such as hashing and data extraction. Thus, a key feature that distinguishes TBC's smart contracts from other UTXO chains is that the UTXO model serves as a foundation for TBC's infinite scalability, making standard transfer transactions very simple.
In summary, TBC has fully considered the advantages and disadvantages of the UTXO model and, based on the essence of Ethereum and other UTXO public chains, introduced the concept of BVM and other technologies to realize true first-layer UTXO smart contracts, along with more user-friendly smart contract development tools, lowering the threshold for writing and deploying BVM smart contracts.
3. What is the biggest challenge you have encountered in developing projects based on the UTXO model?#
Cipher: Earlier, we discussed the advantages of the UTXO model, such as simplicity, concurrency, and easier debugging, but its drawbacks are also quite obvious, such as its global state being relatively troublesome.
The global state updates in Ethereum's account model are actually performed by miners, who update the global state while adding transactions to blocks. However, in the UTXO model, the global state can only be updated by the person sending the transaction off-chain, and then committed. This raises a problem: if a certain UTXO holds the so-called global state, it seems to imply that only one person can update it within the same block. If two people try to update it simultaneously, there will be a conflict.
In our actual development work, a lot of effort goes into this, as we need an off-chain aggregator to consolidate many people's accesses to the global state into a single result, which is then put on-chain, with the blockchain only processing the final state migration. This essentially combines the account model and UTXO model approach. This is what we consider the biggest technical challenge, as it increases a lot of development workload. Compared to the account model, in addition to the usual on-chain smart contracts and off-chain access interfaces, you also need to create an off-chain aggregation operation and computation interface, off-chain computation and aggregation will bring a lot of workload.
Of course, we also have solutions. We are trying to bring miners into L2; they might not be called miners anymore, but L2 nodes would be more appropriate, and they would also undertake the role of aggregators. This also requires some development.
We have a brother project called Khalani, which has an idea of using a formal language to build another layer of VM on this RISC-V VM. This VM processes the formal language mentioned earlier. What can this formal language do? When you write a UTXO-oriented smart contract, it will automatically generate an off-chain aggregator and generator simultaneously, achieving the goal of writing code once and generating multiple processors. This idea is actually very cool, but they have not completed development yet, and the technical difficulty is quite high.
Tim Xie: If I were to use an analogy, I would say that Ethereum is like a highly segmented assembly line factory; anything you want to do, whether developing or acquiring knowledge, is relatively easy, and the ecosystem is very rich, with support and solutions for infrastructure and middleware. When you return to the Bitcoin ecosystem, it feels like going from an industrial society back to an agricultural society. Before Ford developed the assembly line, if you wanted to produce cars, you had to make the wheels and also the tools to make the wheels. For example, when we were building Shell Finance, we needed an oracle and had to use DLC, but there were no available DLCs on the market, so we had to create one ourselves and collaborate with others to develop it. This is similar to when MakerDAO on Ethereum needed an oracle for stablecoins, but there was no Chainlink available, so they had to create Chainlink themselves.
From my perspective, the biggest difficulty in developing within the Bitcoin ecosystem lies in ecosystem support, and the difficulty of developing based on UTXO is much greater than that of developing based on EVM. Of course, this is a stage that must be experienced; early participants in an ecosystem must bear more pressure and solve more problems than later entrants.
4. What UTXO-based L2 solutions are currently on the market, and how do they address Bitcoin's scalability issues?#
Lin: If I strictly follow the criteria I mentioned earlier, then there are none, because their transactions are not executed on L1. In other words, on the Bitcoin first layer, we can still have some overlay layers that execute new rules, which only take effect on the overlay layer and not on the first layer. However, these overlay layers enjoy the benefits of the first layer, such as UTXO's double-spending prevention mechanism. This is actually my personal view, so I currently do not consider those so-called Bitcoin L2 projects as second layers.
In a broad sense, I have seen very few UTXO-based L2 projects. I am mainly researching how to create a trustless bridge using ZK (zero-knowledge proof) to leverage the advantages of UTXO. Most of the cross-chain bridges on the market are relatively centralized, transferring assets from one blockchain to another. In my view, neither strictly nor broadly can they be considered L2. (Note: Here I recommend reading "Why RGB++ Assets Can Achieve Bridge-less Cross-chain")
5. Some people worry that introducing complex protocols may challenge Bitcoin's security and consensus mechanism. What are everyone's thoughts?#
NIGO: Ordinals and BRC-20 have indeed sparked a lot of debate, which can be divided into two main camps. Supporters believe that as long as you pay the transaction fee, you have the right to use block space in any way, regardless of the content of the transaction. They argue that BRC-20 and NFTs bring new culture and narratives to Bitcoin, enhancing its practical application value. On the other hand, the Core development team is relatively opposed, believing that the Bitcoin main chain should remain simple, allowing BTC to serve as digital gold, and does not want it to engage in applications. They view BRC-20 and NFTs as worthless garbage transactions, arguing that excessive garbage transactions occupy transaction bandwidth, leading to longer transaction inclusion times and higher fees. So fundamentally, it is a difference in ideology.
Personally, I believe that the Bitcoin UTXO model combined with the underlying Merkle tree is inherently suitable for high concurrency and high-performance transactions. If the Core development team of the main chain does not support it, then we can implement it on the second layer or even side chains. I resonate with the idea of "you play, you pay"; as long as you pay, you can play, and I believe everyone here belongs to the supportive camp.
Lin: I think everyone should consider what the challenges are when people say that introducing complex protocols may impact Bitcoin's security and consensus mechanism. We cannot just accept others' claims that there will be challenges, right? Also, if this challenge were to occur, how can we, as individuals and supporters of Bitcoin, protect our Bitcoin assets from being affected in a decentralized manner? These questions are worth pondering. It essentially returns to the essence of decentralization. Since we are talking about decentralization, it cannot just be the views of a few people; there must be a consensus mechanism for reaching agreement on this matter. This is quite interesting, and I don't want to directly provide my own opinion.
I would also like to pose a question: if someone claims that certain protocols or applications impact Bitcoin's security, okay, regardless of whether we support or oppose such views, what ways can we express and protect our Bitcoin assets? How do we protect them? These are worth thinking about.
Tim Xie: I have been closely watching whether the overall hash power of Bitcoin and miner income can cover their expenses. Bitcoin's block rewards halve approximately every four years, decreasing over time, while miners are primarily profit-driven. After block rewards diminish, how will miners maintain network security? They must receive returns for their hash power investments. Therefore, it is clear that if the Bitcoin system is to continue operating, its development path must involve increasing on-chain transactions, a flourishing ecosystem, and sufficient miner fees.
Ordinals and BRC-20 have not forked Bitcoin, nor have they affected Bitcoin's consensus and security; they expand capacity through indexers, and on the Bitcoin main chain, they are just a UTXO, albeit a more complicated one. In my view, they have not harmed the core value of the entire Bitcoin network — the network itself — nor have they implanted any viruses.
On the contrary, new protocols like Ordinals and BRC-20 bring new possibilities to Bitcoin, attract a new batch of users, and retain some users in the Bitcoin ecosystem, while also increasing miner fee income, contributing to the sustainable operation of the Bitcoin system.
6. Can the unique features of UTXO give rise to new ecological models, and which projects are worth paying attention to?#
Cipher: The Bitcoin ecosystem has started to thrive since the introduction of inscriptions, and now everyone is talking about the Bitcoin Renaissance. The entire ecosystem is entering a stage of potential. I believe there is a significant opportunity here as the Ethereum ecosystem encounters bottlenecks.
In the past, Bitcoin was thought to only need to serve as a SoV (store of value) and did not need to do anything else. Ethereum is the world computer, and we want to build the ideals of a decentralized world on Ethereum, with decentralized media, financial applications, games, etc., all built on Ethereum. However, as Ethereum becomes increasingly rigid, capital concentration grows, opportunities for new entrepreneurs diminish, and the transition from PoW to PoS raises doubts about whether we should really place all future Web 3 infrastructure on Ethereum. At the same time, emerging platforms like Solana are rising, which do not care about decentralization and even claim to be somewhat centralized, but they are efficient, fast, and cheap, continuously capturing Ethereum's market.
At this moment, a group of people says they instead recognize the earliest Bitcoin, which is more decentralized and streamlined, and they want to reconstruct the entire decentralized infrastructure within the Bitcoin ecosystem. This narrative is more intriguing and has its uniqueness, but its connection to UTXO is not that strong. In other words, this is actually a difference in value orientation, and UTXO is merely becoming more prominent in this narrative due to its advantages.
Additionally, the development of Ethereum's ecosystem is also leaning towards UTXO, such as the parallel EVM computation, which specifies which states will be consumed or occupied at the initiation of each transaction, facilitating parallel processing. This is essentially the idea of UTXO.
In the fields of DeFi, NFTs, and the metaverse, which innovative projects are worth paying attention to? I am more familiar with the CKB ecosystem, and projects like Nervape and Unicorn are different from previous PFP NFT projects; they emphasize interaction, gamification, and internal parameter changes, resembling Loot.
Moreover, I am quite optimistic about the Lightning Network, which is more suitable for UTXO. The Ethereum world has basically not seen the emergence of the Lightning Network. Payment based on the Lightning Network and various financial applications based on it will definitely be a significant track, and new developments will emerge; it is just that the technology is not yet mature, but it will develop rapidly, and we can look forward to it.
Tim Xie: I believe that Ethereum is still at the forefront of innovation, but it has encountered problems. The things described in Ethereum's white paper, including prediction markets, trading, DeFi, oracles, RWA, etc., have basically been completed, so it is uncertain what Ethereum should do next. When no new demands arise, everyone may fall into collective confusion and need to forge their own path.
Currently, the market's response is two different branching routes: one is Solana's focus on AI and DePIN, while another part of users feels we should return to Bitcoin. The Bitcoin ecosystem is currently engaging in inscriptions and DeFi, and our ideological framework is still progressing according to the Ethereum paradigm, so the early development of the ecosystem is fundamentally similar.
Once Bitcoin completes this stage, whether in one, two, or three years, will the Bitcoin ecosystem begin to differ from the Ethereum ecosystem? From the current perspective, Bitcoin has both capital and the capability to do so. However, the issue here is that it is very decentralized, unlike Ethereum, which has a foundation to organize and coordinate uniformly. Of course, this has its pros and cons. The advantage is that everyone can explore various possibilities without being constrained by others and does not have to worry about orthodoxy; everyone can explore using their skills. My current view is that in the foreseeable two years, we are actually in a catch-up role, replicating what has happened in Ethereum and what has been validated as successful in the Bitcoin ecosystem. After two years, once we have caught up, how we proceed will be a very important question.
Lin: My personal thought is that if we consider Bitcoin as digital gold, then various assets on Bitcoin can be seen as gold artworks. Gold artworks do not necessarily have to be purchased with gold; they can also be bought with fiat currency or other currencies. Similarly, assets on Bitcoin do not necessarily have to be exchanged for Bitcoin.
Now that Bitcoin ETFs have been approved, we need to broaden our horizons; not everything needs to pursue on-chain transactions, and we should not only focus on the small group of people who understand Bitcoin and own Bitcoin, as this is actually incorrect because this market is very small. In other words, we need to broaden our horizons, go beyond our circle, and move towards a broader market.