How MVC Runs Turing-Complete Smart Contracts
MVC can run the real Turing-complete high-performance smart contract on the UTXO public chain
Last updated
MVC can run the real Turing-complete high-performance smart contract on the UTXO public chain
Last updated
The traditional UTXO model has great advantages in parallelization and outstanding expansion performance, but we rarely see Turing-complete smart contracts on UTXO public chains. Mainly for the following reasons:
UTXO script programming is more complicated
Public chains such as BTC limit script types, script volume, etc.
Distributed state management is more complex
In fact, MVC is freely programmable. As can be seen from the Bitcoin wiki, Bitcoin has a large number of opcodes, which look extremely unfriendly and very much like an assembly language. Those who have studied the principles of Bitcoin script should know that the judgment of whether Bitcoin can be spent is stored and verified through a stack structure.
Put the unlocking and locking script in the stack in turn, and then execute the opcode in turn. If the return value of the final stack is true, then this UTXO can be spent, otherwise it cannot be spent.
Many programming languages also have a stack structure such as Java, Rust, go, etc. Taking Java as an example, Java has the concept of stack memory and heap memory. The stack memory mainly executes the internal logic of the function, and the heap memory mainly stores data such as objects. It can be seen that the stack can actually execute arbitrary logic, and the bytecode compiled by Java is operating this stack to implement various complex business logic.
Although the stack and virtual machine used by MVC scripts are not as complex as JVM, almost all Turing-complete logic can be achieved through a certain combination. MVC scripts don't have infinite loops, but that doesn't mean they aren't Turing-complete. In fact, this is intentional, in order to ensure that the calculation will produce a result. In fact, there is no real "infinite loop" in Ethereum, etc. as the loop will stop after the gas is burned out. When the MVC script loops, it needs to write the loop repeatedly into the script stack in advance. If you want to do an infinite loop, you must write an infinitely long scripts but this kind of transaction is obviously meaningless. In actual scripting such as MVC scripts will specify an upper limit number of cycles to ensure that the handling fee is within a reasonable range (the same principle as Ethereum gas burnout).
In Ethereum, one of the most typical contract scenarios is ERC721 which is an NFT contract. To create an NFT in Ethereum, you must first deploy a contract account, and then all NFT ownership is managed by this account, and all transfers of this NFT must interact with this NFT contract account.
Under the UTXO model of MVC, the UTXO is designed to have a piece of data and code inside, marking what NFT this UTXO represents, who can unlock it, how to destroy it, and how to guarantee the upper limit, then this UTXO can represent this NFT. Anyone who owns this UTXO owns this NFT. If someone wants to transfer this NFT, they must sign with the private key to meet the unlocking conditions, and then the MVC miners will execute this script to determine whether someone can transfer this UTXO. More importantly, the NFTs of the same series are scattered in different UTXOs, so as long as you find out the UTXOs that meet certain conditions from the distributed global state, you can determine who the NFTs belong to. The transfers of these NFTs can be performed in parallel without affecting each other, which provides the highest performance.
Therefore, the idea of the MVC contract is to use a single UTXO script stack to store state and logic. The overall state is composed of a batch of UTXO states. Correspondingly, the contract state of Ethereum only exists in one account. In contrast, the MVC contract has the same level of concurrency as UTXO, which lays the foundation for large-scale high-performance use.
Regardless of script size, practicability, and client limitations, it is theoretically feasible to implement the above logic on MVC. However, due to the independent nature of UTXO, two problems will be encountered in actual engineering. One is the mutual induction of UTXO and the other is the problem of contract traceability and anti-counterfeiting. These two problems are cleverly solved by the MVC chain. For details, please refer to the technical principle of MetaContract.
Therefore, MVC can finally achieve the Web3 public chain of practical high-performance UTXO model smart contracts:
Adopt a layer of smart contract technology "MetaTXID scheme" compatible with UTXO parallel processing capabilities;
Combining the advantages of the UTXO model, it is the smart contract solution on the Layer-1 chain with the highest concurrency and the lowest execution cost in the blockchain field;
For the first time, the practical Turing-completeness of the UTXO model public chain has been achieved, which can meet the usage scenarios of all Web3 applications and Metaverse applications.