On June 10, Cipher, the author of the RGB++ protocol and founder of CELL Studio, Lin, the co-founder of DotSwap, Timxie, the co-founder of Shell Finance, and NIGO, the CMO of TBC (Turingbitchain), visited the Twitter Space of UTXO Stack to discuss whether the UTXO model can give birth to a new model of Bitcoin ecology.
UTXO Stack is a modular BTC L2 one-click chain issuance platform that can help project developers issue Bitcoin L2 based on the UTXO architecture with one click, and natively integrates the RGB++ protocol.In terms of security, UTXO Stack ensures the security of L2 by staking Bitcoin, CKB, and Bitcoin L1 assets. Simply put,we can imagine UTXO Stack as the OP Stack + EigenLayer of the Bitcoin ecology.
UTXO Stack has completed its seed round of financing, led by ABCDE and SNZ Capital, and followed by OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab and UTXO Management, the venture capital department of Bitcoin Magazine's parent company BTC Inc.
The following is the key points sorted out based on the audio:
1. What are the essential differences and advantages between the UTXO model and the account model in terms of design philosophy, security, efficiency, etc.
Cipher: I think there are some differences in design philosophy and efficiency. Security may depend more on the consensus mechanism and has little to do with the account model.
In terms of design philosophy, UTXO is actually more verification-oriented than calculation-oriented. We know the account model of Ethereum. When you write a program or send a transaction, you don’t know the result of the transaction. You send an action or a function call. As for the result of the call, you will only know the result after the transaction is packaged into a block.
A typical example is, assuming that there is only 0.1 ETH in your account, can you send a transaction to transfer 0.2 ETH outward? Yes, you can send it out, but after the transaction enters the transaction pool, it will be packaged and return an error because you don’t have so much money, but your gas fee will still be deducted. But if someone happens to transfer money to your account at the same time you send it, making your account balance exceed 0.2 ETH, then your transaction will be successfully executed, and of course the gas fee will be deducted.
However, for the UTXO model, your transaction cannot be sent out because you do not have enough money in your account and you cannot collect enough input. Therefore, under the UTXO model, there is no such state as transaction failure. It only has two states: transaction success or failure to send out. That is, the so-called transaction failure means that the verification fails, and your handling fee will not be deducted. UTXO believes that the blockchain is a verification machine, not a calculation machine. Ethereum, which adopts the account model, once had a nickname called the world computer. It is for calculation, which is a completely different design philosophy.
There is also a huge difference in efficiency between the two. UTXO clearly points out which states were used before, then destroys them and updates them to new states. When Ethereum calls a function, it does not know which states it will access before the call, so it can only handle it according to the worst case, that is, no preprocessing is done on all states. Therefore, each transaction in Ethereum can only be executed serially. An ordinary desktop computer has a CPU with at least six cores and 12 threads, but for the standard EVM, it is still executed by a single thread. UTXO is different. UTXO is naturally parallel. All its transactions can automatically distinguish which transactions are conflicting, and even conflicting transactions will not be sent to the transaction pool. Therefore, the efficiency of the UTXO blockchain is significantly higher than the account model. Of course, there is now a narrative called parallel EVM, which wants to solve this problem in some form, but from the description just now, everyone can also realize that this is impossible to solve it fundamentally.
Tim Xie: I agree with what Cipher just said, "Bitcoin UTXO model is more verification-oriented, and Ethereum's account model is more computation-oriented". During the DeFi Summer, we did some swaps, and Ethereum's gas fee would be very high. Although compared with Bitcoin, Ethereum has a faster block speed, larger blocks, and better performance, Ethereum's demand for expansion is actually higher than Bitcoin. Why? The reason is that Ethereum is a computing model. When we play DeFi, 98% of the gas fee we pay is spent on computing, and the cost of verification, dissemination and storage of account status is actually very small. Bitcoin is a verification network, it does not do computing, so we do lending or swap on the second layer of Bitcoin, and in the same scenario, the handling fee is cheaper than that of Ethereum.
The second is concurrency. Cipher just explained why EVM is serial, and UTXO can do concurrency very clearly. What difference will this bring in doing business? To do lending on Ethereum, you need to deposit first before you can borrow, because the business logic is that you need collateral, and you have to wait for the transaction of the collateral to be confirmed and the status to be fixed before it can calculate your collateral net value and liquidation threshold, and let you borrow, all of which is serial. And UTXO can do concurrency, we can compress all transactions as much as possible, which means that users' deposit transactions and borrowing transactions can be merged together to improve efficiency.
From our experience, using the UTXO model to do DeFi on Bitcoin, the user experience is not as bad as people imagine. Although the experience is not as smooth as the applications on Ethereum or Arbitrum, it is not too bad and can still be used.
Lin: Let me make a supplement. Existing technologies are constantly evolving.I think UTXO is not not doing calculations, it can also do calculations. For example, the Bitcoin operation code OP_CAT that everyone has been discussing recently, if enabled, we can retain the state in Bitcoin's UTXO. If we remove all the native restrictions of Bitcoin, we can simulate countless Ethereums in Bitcoin's UTXO, and each UTXO can be a state of Ethereum, and then continue the data and execution in this state, so that this state can be deduced continuously, although this may not necessarily achieve full EVM compatibility.
So I think Bitcoin can also do calculations, and the logic of Bitcoin is that you can open a new thread at any time, you can split a new UTXO at any time, and the new UTXO is completely separated from the original UTXO. This is a feature of Bitcoin UTXO in calculation.
After adding OP_CAT, it will bring some very clever application scenarios.For example, Ethereum ERC-20 tokens will maintain a list to know which accounts have how much money. After adding OP_CAT, we can do similar things on Bitcoin, and may even do better than Ethereum.
In UTXO, data sharing is actually a large unknown space.For example, Covenants (restrictive clauses) still need some time to build. After this matter is moved forward, how to share data among different UTXOs, how to reference data outside of transactions in transactions, etc., may have breakthroughs.
NIGO：I have always believed that Ethereum changed Bitcoin's UTXO model into an account model, which is a typical superfluous addition, and turned a system that could have been concurrent into a serial system. Ethereum is called the world computer by many people. Why should the computing tasks of an ordinary person be calculated by miners around the world? This process consumes huge energy and is very costly, but it does not bring any substantial benefits, but instead delays the overall efficiency. After Ethereum switched to PoS, the miners (nodes) of the entire network lost their evolutionary motivation. The UTXO model designed by Satoshi Nakamoto is naturally suitable for high concurrency and high performance. I believe that more Web3 users will see the potential of the UTXO model.
2. Is it the UTXO model that causes Bitcoin to not have smart contract capabilities? If you want to implement smart contract capabilities based on the UTXO model, what mechanism is generally used to achieve it? Cipher: There are definitely many ways to implement smart contract capabilities based on the UTXO model. Let me introduce how CKB, which I am most familiar with, implements it. CKB introduces the lock script, which is consistent with Bitcoin's lock script. When the UTXO is spent, the lock script will be automatically executed. It will be executed based on the data in the witness as input, and the current transaction will also be executed as input. The difference between it and Bitcoin's lock script is that it supports a complete Turing-complete virtual machine, rather than the very limited script environment of Bitcoin, so it is Turing-complete at the unlocking stage. At the same time, CKB has introduced the type script field, which will be executed regardless of input or output. It is more of a category of this asset, or the same type represents the same asset. This logic is executed. For example, the total amount of fungible tokens remains unchanged before and after transactions, the amount and content of non-fungible tokens remain unchanged before and after transactions, or it is used to determine who has the right to issue a new asset, etc. It is also a Turing-complete VM.
CKB's virtual machine is based on the RISC-V hardware instruction set. Any adjustment involves re-tapeout, so the design of the RISC-V instruction set is very streamlined, efficient and comprehensive.
To summarize, CKB uses the RISC-V virtual machine, which is Turing-complete, and it also has two places, lock script and type script, to store the scripts of smart contracts, and a field called data to store the status of smart contracts, so it is a complete contract execution environment. Tim Xie: During the entire product construction process of Shell Finance, we needed some advanced contract functions because we needed to do lending protocol and clearing. Finally, we chose DLC (Discreet Log Contracts). DLC and Lightning Network are both expansion technologies of the same level. Both are offchain. The difference is that Lightning Network is mainly used for payment, while DLC is mainly used for oracle. We are not Turing complete and there are still many restrictions. But even with many restrictions, we can do lending through DLC. Bitcoin actually has many OP Codes. If we can enable or unlock OP_CAT mentioned by Lin of DotSwap before, or some other operation codes, then we can actually continue to create more possibilities along the route of Lightning Network and DLC. Smart contracts can definitely do it. The key point is whether there is demand, whether there are users, whether there is a market, and whether more people will invest time and energy to conceive it, use it, and meet the needs of users. As long as there are people using it and there is a market, new ideas and new concepts will naturally emerge.
What I am sure of now is that the form of the Bitcoin ecosystem will be completely different from that of the EVM. Maybe at the business level, the user experience may be similar. They are both doing swaps and lending, and both have oracles, but the systems behind them and the tools that can be used in the end are actually very different. If it is on the Bitcoin mainnet, the difference will be even greater, so I am actually looking forward to L2 with a better UTXO structure, because it can release the potential of the Bitcoin ecosystem to a greater extent.
Lin: I think it is not very difficult to design something to be Turing complete. On the contrary, it is very difficult to be Turing incomplete. Designing a script to be non-Turing complete is actually a very advanced technical job.
The original script of Bitcoin can be Turing complete, but many capabilities of Bitcoin are now sealed. For example, OP_CAT, which I mentioned earlier, is a very important capability, but this capability is disabled by the operator, not that Bitcoin did not have these operators when it was first designed. Bitcoin involved a lot of operators at the beginning, but because of the so-called security, or the so-called hidden dangers of this security, or because it was not clear what it was and how to use it, etc., some operators were disabled. What's more, many functions that could have been used for smart contracts were filtered by the so-called standard transactions. We all say that Bitcoin is a decentralized system, but in this decentralized system, there is actually something called standard transactions, which is determined by certain organizations. Standard transactions do not exist in the field of miners, because miners can package any legal transactions. It is a policy issue based on the user side.
So in general, I think the original Bitcoin's ability is very powerful, but now Bitcoin has been hijacked. If you are interested, you can read Roger Ver's book "Hijacking Bitcoin: The Hidden History of BTC". Because the original ability of Bitcoin has been sealed, we are forced to find a way out in various places. This is the current situation we are facing, but the prospect and future of Bitcoin are definitely better.
I have been saying that many of the so-called Bitcoin L2s are actually parasite protocols. They do not contribute their own value to Bitcoin, and there is no way to make miners have higher incomes, but in fact there is really no way, because Bitcoin has many restrictions. Let me give you an analogy. The HTTP protocol is actually L2 built on the TCP/IP protocol, and our HTML protocol is built on the HTTP protocol. Here I think it is a layer-by-layer concept, rather than saying that the transaction data is completely separated from TCP/IP, from the upper layer protocol, and goes to another place, and then turns back to tell others that my second-layer protocol is. The real second-layer protocol is actually stacked layer by layer, so the L2 we build should also be accepted as a legal transaction in the upper layer. This is a very important reason why we are now exploring the swap on the first layer. We think that in most cases we actually need to settle to the first layer, and we need to have a lot of verification and consensus on the first layer, rather than saying that I will build a so-called asset bridge and then move everyone's assets to another place, which may not be a particularly good thing.
NIGO: Can the UTXO model support complex smart contract functions? Of course it can. It stores the logic and data of the contract in UTXO, and then uses the call and parameters of the contract as input to try to unlock the contract, execute the logic of the contract through BVM (Blockchain Virtual Machine), and finally return true or false through the unlocking function to achieve the purpose of controlling the state of the contract. This model may be unfamiliar to developers of Ethereum smart contracts, but in fact, if you combine the idea of functional programming and some concept conversion, UTXO smart contracts can implement very complex logic.
Since the UTXO model does not have a global state, it needs to store the state and logic of the contract in UTXO, and then transfer and convert the state through the transfer of the UTXO transaction call chain. Therefore, each UTXO transaction will consume the previous UTXO and generate a new UTXO. In this way, the chain state transfer of the contract can be realized. Therefore, whether UTXO can be unlocked corresponds to the execution result of the contract, whether it allows the state to be transferred. If the contract determines that the state cannot be modified, such as not allowing transfers or data modification, it will return false, then UTXO will not be unlocked, and the contract execution fails.
We regard the contract as a state machine that transfers the data state, so here we can see the difference between the UTXO contract and the account-type contract. The EVM of the account contract is to maintain the global state. A transaction may cause the EVM to transfer the state multiple times, and frequently modify the state data until the contract is executed or the gas is consumed. The transaction of the UTXO contract is an input contract. The call will only trigger a state transfer once, and no matter how complex the logic inside the contract is, or how many times the state transfers, the BVM will only record the final state transfer result on the chain. Therefore, the UTXO contract has no global state, only functions waiting to be executed.
UTXO is multi-input and multi-output. What Ethereum wants to do, including the parallel EVM that Monad wants to do, can actually be achieved through UTXO. If you need to transfer the state, you must first find the function where the state is located, modify the state through function calls, and generate new functions. This mode makes the state transfer of the UTXO contract clearer.
UTXO contracts do not rely on external states. Therefore, once a contract is called, no matter how many times it is called, its result must be certain, so this also brings great convenience to the analysis, debugging and unit testing of the contract. However, the EVM contract relies on the global state, so the execution result of the contract is likely to be affected by the external environment, resulting in uncertain execution results of the contract, for example, if the balance is enough, it will be one result, and if it is not enough, it will be another result. So this is also an important issue for the security and predictability of EVM contracts.
Of course, each time the state is passed down, it is not without cost. In some scenarios that require traceability, the state may increase with the increase of the UTXO transmission chain, because traceability requires verification, and the data is increasing, so the state itself will expand infinitely. We TBC has solved a major problem of state expansion through other technologies and cryptographic means such as hashing and data extraction. Therefore, an important feature of TBC's smart contract that distinguishes it from other UTXO chains is that the UTXO model is a basis for TBC to expand infinitely, making it very simple to make the UTXO model perform standard transfer transactions.
In summary, TBC has fully considered the advantages and disadvantages of the UTXO model, and on the basis of absorbing the essence of Ethereum and other UTXO public chains, introduced a BVM concept and other technologies to realize a real layer of UTXO smart contracts, and then cooperated with some more friendly smart contract development tools to lower the threshold for writing and deploying BVM smart contracts.
JinseFinance
Finbold
Cointelegraph