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 L2 security by staking Bitcoin, CKB, and assets from Bitcoin L1. In simple terms, we can think of UTXO Stack as the OP Stack + EigenLayer of the Bitcoin ecosystem.
UTXO Stack has completed its seed round financing, co-led by ABCDE and SNZ Capital, with participation from several well-known institutions including OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab, and the venture capital department UTXO Management 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 from 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 actually more focused on verification 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 once 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 may 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, gas fees 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 come up with enough inputs. Therefore, in the UTXO model, there is no state of transaction failure; it only exists in two states: transaction success or not being able to send it. The so-called transaction failure is simply a verification failure, and you won't be charged a fee. UTXO sees the blockchain as a verification machine rather than a computation machine, while Ethereum, which uses 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 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 from the earlier description, everyone can realize that this cannot fundamentally solve the issue.
Tim Xie: I strongly agree with what Cipher just said, “the Bitcoin UTXO model is more focused on verification, while Ethereum's account model is more focused on computation.” During DeFi Summer, when we were doing some swaps, Ethereum's gas fees were very high. Although Ethereum has a faster block speed, larger blocks, and better performance compared to Bitcoin, the demand for scalability in Ethereum is actually higher than in Bitcoin. Why? The reason is that Ethereum is a computation model. When we engage in DeFi, the gas fees we pay may be 98% spent on computation, while the costs for verification, propagation, and storage of account states are actually very low. Bitcoin is a verification 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. Why is the EVM serial? Cipher just explained it very clearly, while UTXO can achieve concurrency. What difference does this bring to business? When doing lending on Ethereum, you need to deposit first before you can borrow because the business logic requires collateral, and you must wait for the confirmation of the collateral transaction to fix the state before it can calculate your collateral value and liquidation threshold, making everything serial. UTXO can achieve concurrency; we can compress all transactions together as much as possible, which means we can combine user deposit transactions and borrowing transactions to improve 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, if enabled, would allow us to retain state in Bitcoin's UTXO. If we remove various native limitations of Bitcoin, we could simulate countless Ethereums within Bitcoin's UTXO, where each UTXO could represent an Ethereum state, allowing data and execution to continue within that state, thus pushing that state forward, although this may not achieve complete EVM compatibility.
So I believe Bitcoin can also perform computations, and the logic of Bitcoin is that you can open new threads at any time; you can split off a new UTXO at any time, and the new UTXO is completely separate from the original UTXO, which is a characteristic of Bitcoin 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 that can track 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, and 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, instead delaying overall efficiency. After Ethereum transitioned to PoS, it further diminished the evolutionary motivation of the network's miners (nodes). The UTXO model designed by Satoshi Nakamoto is inherently suitable for high concurrency and high performance, and I believe more Web3 users will recognize the potential of the UTXO model.
2. Is the UTXO model the reason Bitcoin lacks smart contract capabilities? What mechanisms can be used to implement smart contract capabilities based on the UTXO model?#
Cipher: There are definitely many ways to implement smart contract capabilities based on the UTXO model. I will 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 of the asset, or the same type represents the same asset. For example, fungible token transactions maintain the same total amount before and after, 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-spinning the chip, 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, 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 the smart contract, 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 require some advanced contract functionalities, and ultimately we chose DLC (Discreet Log Contracts). DLC and the Lightning Network are both off-chain scalability technologies of the same level, but the difference is that the Lightning Network mainly handles payments, while DLC is primarily used for oracles. We are not Turing-complete, and there are still many limitations, but even with these limitations, we can already perform lending through DLC.
Bitcoin actually has many OP Codes, and if we can enable or unlock some of them, like the OP_CAT mentioned by Lin from DotSwap, or other opcodes, we can 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 effort to conceive, use, and meet user needs. As long as there are users and a market, new ideas and concepts will naturally emerge.
I am now confident 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, both doing swaps and lending, both having oracles, but the underlying systems and the tools available for use are actually vastly different. 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, as designing scripts to be non-Turing-complete is a very advanced technical task.
Bitcoin's original script could achieve Turing completeness; however, many capabilities have been sealed off in Bitcoin now. For example, the OP_CAT I mentioned earlier is a very important capability, but it has been disabled by the operators, not because these operators were absent when Bitcoin was initially designed. Bitcoin initially involved many operators, but due to so-called security concerns or the potential risks associated with security, or a lack of understanding of what they were and how to use them, certain operators were disabled. Moreover, many functionalities that could originally be 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 now Bitcoin has been 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, we are forced to find solutions 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 miners with higher income, but in reality, they cannot, because Bitcoin has many limitations. I will give an analogy: the HTTP protocol is actually built on 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 completely separating transaction data from TCP/IP or from the previous layer protocol and running it elsewhere, then turning around and claiming it is a second-layer protocol. True second-layer protocols are actually stacked layer by layer, so the L2s we are building should also be accepted as legitimate transactions within the previous layer. This is a very important reason why we are currently exploring swaps at the first layer. We believe that in most cases, we actually need to settle at a layer; we need to have a lot of verification and consensus support at that layer, rather than creating a so-called asset bridge and moving everyone's assets to another place, which may not be a particularly good thing.
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 unlock 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 concepts with some conceptual transformations, UTXO smart contracts can achieve 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, and then pass the state through the UTXO transaction call chain for transfer and transformation. Therefore, each UTXO transaction consumes the previous UTXO and generates new UTXOs, enabling chain state transfer of the contract. Thus, whether a UTXO can be unlocked corresponds to the execution result of the contract, determining whether it allows state transfer. If the contract determines that state modification is not allowed, such as disallowing transfers or data modifications, it will return false, and the UTXO will not be unlocked, resulting in contract execution failure.
We can view the contract as a state machine that performs state transfer operations on data. Here, we can see the difference between UTXO contracts and account-based contracts. The EVM of account contracts must maintain a global state, and a transaction may cause the EVM to perform multiple state transfers, frequently modifying state data until the contract executes or gas runs out. In contrast, UTXO contract transactions are input contracts; calls will only trigger a single state transfer, and regardless of how complex the internal logic of the contract is or how many times the 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 and 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 pattern 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 a significant 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 a true first-layer UTXO smart contract, along with more user-friendly smart contract development tools to lower 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 disadvantages are also quite obvious, such as its global state being somewhat troublesome.
The global state update in Ethereum's account model is actually done 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 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; 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 as well; they might not be called miners anymore, but L2 nodes would be more appropriate, and they would also take on the role of aggregators. Of course, 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 handles 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, achieving the goal of writing code once and generating multiple processors. This idea is actually very cool, but they have not completed the development yet, and the technical difficulty is quite high.
Tim Xie: If I were to use an analogy, I would say that the Ethereum side is like a highly segmented assembly line factory; anything you want to do, whether it's development or knowledge acquisition, 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. It's like before Ford developed the assembly line; if you wanted to produce cars, you had to make the wheels and also create 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 had to create Chainlink themselves because it wasn't available.
So 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 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, but at the same time, these overlay layers enjoy the benefits of the first layer, such as UTXO's anti-double-spending mechanism, etc. This is just my personal view, so I currently do not consider those so-called Bitcoin L2 projects as second layers.
In the broad sense of UTXO-based L2 projects, I have seen very few. I am mainly researching how to use ZK (zero-knowledge proof) to create a trustless bridge, leveraging 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, whether in a strict sense or a broad sense, they cannot 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 on this?#
NIGO: Ordinals and BRC-20 have indeed sparked a lot of debate, which can be divided into two major 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, which is beneficial for enhancing Bitcoin's 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 they do not want it to be used for applications. Therefore, they view BRC-20 and NFTs as worthless garbage transactions, and excessive garbage transactions will occupy transaction bandwidth, leading to longer transaction inclusion times and higher fees. So fundamentally, it is still a difference in ideology.
Personally, I believe that the Bitcoin UTXO combined with the underlying model of the 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 agree with the notion of “you play, you pay”; as long as you pay, you can play. 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 what others say will be a challenge, right? And 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 certainly cannot be just the views of a few people; there must be a consensus mechanism for achieving agreement on this matter. I find this quite interesting, and I do not want to directly provide my own opinion.
I would also like to pose a question: if someone raises the concern that certain protocols or applications may affect Bitcoin's security, okay, regardless of whether we support or oppose such views, what means can we use to express and protect our Bitcoin assets? How do we protect them? These are worth considering.
Tim Xie: I have recently been looking at whether the total network hash rate and miner income can cover their expenses. Bitcoin's block rewards halve approximately every four years, becoming less over time, and miners are primarily profit-driven. After block rewards decrease, how will miners maintain network security? Their investment in hash power must yield returns. Therefore, it is clear that for the Bitcoin system to continue operating, its development path must involve increasing on-chain transactions, a thriving ecosystem, and sufficient miner fees.
Ordinals and BRC-20 have not forked Bitcoin, nor have they affected Bitcoin's consensus and security; they are expanding through an indexer approach. 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 keep some users within the Bitcoin ecosystem, while also increasing miners' fee income, contributing to the ongoing 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 readiness, and I feel there is a significant opportunity here because the Ethereum ecosystem is encountering bottlenecks.
In the past, Bitcoin was thought to be sufficient as long as it served as a SoV (store of value) without needing to do anything else. Ethereum is the world computer, and we aim 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 more solidified, capital becomes more concentrated, opportunities for new entrepreneurs decrease, and with the transition from PoW to PoS, people are beginning to question 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, even claiming to be somewhat centralized, but they are efficient, fast, and cheap, continuously capturing Ethereum's market.
At this time, a group of people says that we instead recognize the earliest Bitcoin, which is more decentralized and streamlined, and we 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 significant. In other words, this is actually a difference in value orientation, and UTXO is merely highlighting its advantages within this narrative.
Additionally, the development of Ethereum's ecosystem is also leaning towards UTXO, for example, the parallel EVM computation, which specifies which states will be consumed or occupied at the initiation of each transaction, facilitating parallel processing, which 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, with projects like Nervape and Unicorn, which differ from previous PFP NFT projects in that they emphasize interaction, gamification, and internal parameter changes, resembling Loot.
Moreover, I am optimistic about the Lightning Network, which is more suitable for UTXO. The Ethereum world has essentially never seen a Lightning Network. Payments based on the Lightning Network and various finance applications based on it will definitely be a significant track, and new developments will emerge, although the technology is not yet mature, 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 is encountering problems. The things described in the Ethereum white paper, including prediction markets, trading, DeFi, oracles, RWA, etc., have basically all been completed, so the next stage of what it should do is actually uncertain. When no new demands arise, everyone may fall into a collective confusion, needing to carve out a path independently.
Currently, the market's response is branching into two different routes: one is Solana's approach of focusing on AI and DePIN, while another part of users feels we should return to Bitcoin. The Bitcoin ecosystem is currently working on inscriptions and DeFi, and our ideological framework is still moving forward according to Ethereum's paradigm, so the early development of the ecosystem is basically similar.
Once Bitcoin completes this stage, whether it will start to diverge from the Ethereum ecosystem in a year, two years, or three years is a question. From the current perspective, Bitcoin has both the 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 without worrying about orthodoxy; everyone can explore according to their skills. My current view is that in the foreseeable two years, we are actually in a role of catching up, replicating what has happened in Ethereum and what has been validated as successful within 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 regard 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 that small portion of people who understand Bitcoin and hold Bitcoin, as this is actually incorrect because the market is very small. In other words, we need to broaden our horizons, step out of our circles, and move towards a broader market.