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 the Twitter Space of UTXO Stack to discuss whether the UTXO model can give rise to a new mode of 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 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, led by ABCDE and SNZ Capital, with additional investments from OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab, and UTXO Management, the venture capital arm of Bitcoin Magazine’s parent company BTC Inc, among other well-known institutions.
The following are key points from the audio discussion:
1. What are the fundamental differences and advantages of 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 primarily dependent on the consensus mechanism rather than the account model. In terms of design philosophy, UTXO leans more towards validation rather than computation. Unlike Ethereum’s account model where the transaction result is unknown until it is included in a block, UTXO transactions either succeed or fail at the time of submission, without the concept of transaction failure. UTXO believes in blockchain as a validation machine rather than a computing machine, contrasting with Ethereum’s account model known as the “world computer.” In terms of efficiency, UTXO’s approach of clearly defining and updating states leads to higher efficiency compared to Ethereum’s account model, which processes transactions in a more serial manner.
Tim Xie: I agree with Cipher’s point that the Bitcoin UTXO model focuses more on validation, while Ethereum’s account model leans towards computation. Ethereum’s high gas fees during DeFi Summer reflect the platform’s need for scalability due to its computational nature. On the other hand, Bitcoin’s validation network allows for cheaper fees in L2 applications such as lending or swaps. Additionally, the UTXO model’s ability to handle concurrency provides efficiency benefits in transaction processing.
Lin: I would like to add that while the UTXO model has traditionally been viewed as non-computational, recent developments such as the OP_CAT operation in Bitcoin allow for state preservation within UTXO, enabling computational capabilities. With the right enhancements, Bitcoin’s UTXO could potentially simulate multiple instances of Ethereum, offering new possibilities for data sharing and transaction referencing.
NIGO: Ethereum’s transition from the UTXO model to the account model is seen as unnecessary by many, as it sacrifices the inherent concurrency of the UTXO system for a more linear approach. The UTXO model’s suitability for high concurrency and performance makes it appealing to Web3 users, especially as Ethereum’s transition to PoS diminishes its mining network’s incentive to evolve.
2. Does the UTXO model prevent Bitcoin from having smart contract capabilities? How can smart contract capabilities be implemented on top of the UTXO model?
Cipher: There are various ways to implement smart contract capabilities on the UTXO model, with CKB being a prime example. CKB introduces lock scripts similar to Bitcoin’s, but with support for a Turing-complete virtual machine during the unlocking phase. Additionally, CKB incorporates type scripts for asset categorization and logic execution, allowing for various token types to be traded while maintaining quantity and content integrity.
Overall, the discussion highlights the unique strengths of the UTXO model in terms of validation, efficiency, and potential for smart contract capabilities within the Bitcoin ecosystem.Who has the authority to issue a new asset, etc. It is also a Turing complete VM in itself.
The CKB virtual machine is based on the RISC-V hardware instruction set, and any adjustments involve a reflow, so the design of the RISC-V instruction set is very streamlined, efficient, and comprehensive.
In summary, CKB adopts the RISC-V virtual machine, which is Turing complete, and it also has two places, the lock script and type script, to store smart contract scripts, and also has a field called data to store the state of smart contracts, so it is a complete contract execution environment.
Tim Xie: In the entire product construction process of our Shell Finance, because we need to build a lending protocol and settlement, we need some advanced contract functions, so we finally chose DLC (Discreet Log Contracts). DLC and the Lightning Network belong to the same level of scaling technology, both are off-chain, but the difference is that the Lightning Network mainly focuses on payment, while DLC is mainly used for oracles. We are not Turing complete, there are still many limitations, but even with many limitations, through DLC we can already do lending.
Bitcoin actually has many OP Codes, if we can enable or unlock, for example, the OP_CAT mentioned by Lin from DotSwap before, 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 demand, users, a market, and more people willing to invest time and effort to conceive it, use it, and meet user needs. As long as people use it, there is a market, new ideas, and concepts will naturally emerge.
I am now confident that the form of the Bitcoin ecosystem will definitely be completely different from that of EVM. Perhaps at the business level, the user experience may be similar, both doing swaps and lending, both having oracles, but the underlying system and the tools that can be used 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 better unleash the potential of the Bitcoin ecosystem.
Lin: I think designing something as Turing complete is not very difficult, on the contrary, making something non-Turing complete is very difficult, designing scripts as non-Turing complete is a very profound technical activity.
Bitcoin’s original script could have been Turing complete, it’s just that many of Bitcoin’s capabilities have been sealed off now, such as the important ability I mentioned before, OP_CAT, which has been disabled by operators, not because these operators were not present when Bitcoin was originally designed. Bitcoin initially involved a lot of operators, but due to so-called security concerns, or this kind of security vulnerability, or not understanding what exactly it is, how to use it, etc., some operators were disabled. Furthermore, many functions that could have been used to create 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, determined by certain organizations. Standard transactions do not exist in the mining field because miners can package any legitimate transaction, it is a policy issue based on the user side.
So overall, I think the original capabilities of Bitcoin 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 face, but Bitcoin’s future is definitely quite good.
I have always said that many so-called Bitcoin L2s are actually parasitic protocols, they do not contribute their value to Bitcoin, nor can they allow miners to have higher income, but in fact, there is no way, because Bitcoin has many restrictions. As an analogy, the HTTP protocol is actually built on the TCP/IP protocol L2, and our HTML protocol is built on top of the HTTP protocol. Here I think it is layer by layer concepts, rather than completely separating transaction data from TCP/IP, separating it from the upper layer protocol, running to another place, then turning back and telling others that this is a second layer protocol. In fact, the real second layer protocol is stacked layer by layer, so the L2s we build should also be accepted as legitimate transactions in the upper layer. This is why it is very important that we are exploring on top of the first layer swap. In most cases, we believe that we actually have to settle on the first layer, we need a lot of validation and consensus on the first layer, rather than 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, then calls the contract and parameters as input to try to unlock the contract, executes the logic of the contract through Blockchain Virtual Machine (BVM), and finally 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 fact, if you combine functional programming ideas and make some concept conversions, UTXO smart contracts can implement very complex logic.
Due to the lack of global state, the UTXO model needs to store the state and logic of the contract in UTXO, and then pass the state through the UTXO transaction call chain for state transmission and conversion, so each UTXO transaction will consume the previous UTXO and generate a new UTXO, this way can achieve chained state transfer of the contract. Therefore, whether the UTXO can be unlocked corresponds to the execution result of the contract, whether it allows state transfer. If the contract determines that it does not allow modification of the state, such as not allowing transfers or modifying data, 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 on the data state, so here we can see the difference between UTXO contracts and account-based contracts. The EVM of the account contract needs to maintain global state, a transaction may cause the EVM to perform multiple state transfers, frequently modifying state data until the contract is executed or gas is exhausted. The transaction of the UTXO contract, it is an input contract, and the call will trigger a state transfer only once, and regardless of how complex the logic inside the contract is, how many state transfers there are, the BVM will only record the final state transfer result on the chain. Therefore, UTXO contracts do not have a global state, only functions waiting to be executed.
UTXO is multi-input and multi-output, what Ethereum wants to do, including Monad also wants to do parallel EVM, can actually be achieved through UTXO, the need to transfer state requires finding the function where this state is located, modifying the state through function calls, and generating new functions, this pattern makes the state transfer of UTXO contracts clearer.
UTXO contracts do not depend on external states, therefore, each contract call, no matter how many times it is called, its result is always deterministic, so this also brings great convenience to the analysis, debugging, and unit testing of the contract. EVM contracts rely on global state, so the execution result of the contract may be affected by the external environment, leading to an uncertain contract execution result, such as having enough balance is one result, and not having enough balance is another result. Therefore, this is also an important issue of security and predictability of EVM contracts.
Of course, passing the state each time is not without cost, in some scenarios that require traceability, the state may increase as the UTXO transmission chain increases, because verification is required, data becomes more and more, so the state itself will infinitely expand. We at TBC have solved the problem of state expansion to a large extent through other technologies and cryptographic means such as hashing and data extraction. Therefore, a significant feature of TBC’s smart contract, different from other UTXO chains, is that the UTXO model is a foundation for TBC to achieve infinite scaling, making standard transfer transactions with the UTXO model very simple.
In conclusion, TBC fully considers the advantages and disadvantages of the UTXO model, draws on the essence of Ethereum and other UTXO public chains, introduces the concept of BVM and other technologies to realize a true first-layer UTXO smart contract, and then with more user-friendly smart contract development tools, reduces the threshold for writing and deploying BVM smart contracts.
