The use of blockchain technology has grown exponentially in recent years, and with it has come to the need for more secure and efficient wallet solutions. Enter MicrovisionChain, a cutting-edge blockchain that has been designed to solve the “blockchain trilemma” by leveraging the bitcoin UTXO model. And with Metalet Wallet, the first wallet extension based on this new blockchain, users can experience the many benefits of this emerging technology.

The UTXO (Unspent Transaction Output) model is an essential component of the Bitcoin blockchain technology. This system is designed to manage financial transactions more securely and efficiently than other traditional account-based approaches. The UTXO model works by maintaining a detailed record of all spent and unspent financial transactions on the blockchain network. Each individual transaction is recorded on a separate UTXO entry, enabling Bitcoin users to transact more flexibly, securely, and privately.

Advantages of Metalet Wallet

UTXO Model Support: One of the major benefits of Metalet Wallet is its support for UTXO model wallets. This offers users enhanced security and performance when managing their digital assets. The UTXO model has become increasingly popular as it provides a robust and efficient way of handling transactions on the blockchain.

Cross-Chain Asset Support: The Metalet Wallet offers cross-chain support for a wide range of UTXO-based public chain assets, including Bitcoin. This means that users can easily manage multiple digital assets from within the same wallet, without having to switch between different applications.

Customized Transaction Formats: Metalet Wallet is designed to be highly interoperable, with a customizable protocol that can handle a wide range of transaction formats. This means that it can support a variety of complex use cases such as NFTs, DeFi, social networks, and other DApps.

Security and Privacy Benefits One of the key advantages of utilizing Metalet Wallet is its enhanced security and privacy features. The integrated smart contract technology used by Metalet Wallet ensures that all transactions are conducted securely and transparently. This means that users can have confidence in the safety of their assets and transactions.

Furthermore, the Metalet Wallet is designed to be highly private, with all transactions being conducted in a secure and encrypted environment. This ensures that user data and digital assets are kept safe and secure.

Low Transaction Fees and Speedy Zero Confirmations While low transaction fees and speedy zero confirmations are often attributed to the underlying blockchain technology, Metalet Wallet takes this further by offering an intuitive and user-friendly interface that allows for seamless and hassle-free transactions. All transactions can be conducted quickly and with ease, ensuring that users can access their digital assets or complete transactions without delay.

In conclusion, Metalet Wallet is a promising new wallet extension that offers a range of compelling features for users of the MicroVisionChain blockchain. The UTXO model is one of the main reasons Bitcoin has retained its position as the most dominant cryptocurrency over the past decade, and it continues to be a vital component of the broader cryptocurrency ecosystem.

With support for UTXO model wallets, cross-chain asset management, customizable transaction formats, enhanced security, and low transaction fees, it has the potential to be a game-changer in the world of blockchain wallet technology.

Visit https://www.microvisionchain.com/ to learn more about MicroVisionChain and visit https://chrome.google.com/webstore/detail/metalet-mvc-wallet/lbjapbcmmceacocpimbpbidpgmlmoaao to learn the many benefits that Metalet Wallet can offer.

When it comes to smart contracts, the first reaction of many people is Ethereum. Even when searching for smart contracts in Wikipedia, they will give the following definition:

Smart contract is a special protocol that is used when making a contract in the blockchain which [i] contains code functions (e.g., Function), [ii] can interact with other contracts, [iii] make decisions, [iv] store data, [v] send ether coins, and other functions.

Obviously, it is a bit overgeneralized to only define smart contracts as part of the functions of Ethereum. In contrast, the definition of smart contracts given by IBM is more accurate and more in line with various modern public chains and contracts:

Smart contracts, as defined by IBM, are simply programs stored on the blockchain that are run when predetermined conditions are met. They are often used to automate the execution of agreements so that all participants can determine the outcome immediately without any intermediaries involved and without wasting time. They can also automate workflows, triggering the next action when a condition is met.

The summary is:

1. Stored on the blockchain

2. Specific logic will be run when certain conditions are met

3. The running logic does not require any involvement of a third-party Therefore, those that meet these three points can be regarded as smart contracts. In fact, Bitcoin, Litecoin, and Doge, which seem to only transfer tokens, also meet the definition of smart contracts. In fact, their “transfer” function itself is also a type of smart contract.

   However, we usually don’t think that blockchains that can only transfer coins are smart contract platforms, mainly because they have too few logic scenarios under the second summary (specific logic will be run when certain conditions are met), and this specific logic is limited to few [fixed] scenarios. For example, Bitcoin only has standard transaction logic such as P2PKH, P2PK, P2SH, etc.

   The scenarios that can be used are only limited scenarios such as single- and multi-signature, and the execution logic cannot be freely customized according to the needs of developers such as richer preconditions, more complex logical controls, more flexible interactions between contracts, etc. Therefore, smart contracts in a broader sense should add a fourth point:

4. Turing-complete and can execute arbitrary logic

Account model, UTXO model, and Smart Contract

Account model

The well-known smart contract public chain platforms such as Ethereum, EOS, Solana, etc., can be called account models in terms of execution methods.

The account model is very easy to understand, and our PayPal account, bank account, etc. are an example. Each person has one or more "accounts," and each account has a "balance."

The process of A->B transfer is to subtract X from the balance of account A, and then add X to the balance of account B (without considering the handling fee). If some logical conditions are added to the transfer process, and the transfer can only occur if certain conditions are met, then a smart contract is formed. There is a virtual machine inside Ethereum, called EVM, which is used to monitor specific conditions, and automatically execute transfers after the conditions are met. Because this virtual machine can execute programming code, it only needs to write logic in a high-level computer programming language and can be deployed on the chain to implement arbitrary logic easily.

Because this account model is very close to object-oriented programming, it only needs to define member variables (various balance data) and methods (contracts) to implement arbitrary logic easily. Because of this, the vast majority of smart contract platforms on the market run on the account model.

The account model also has a very significant disadvantage: how to ensure the consistency of the conditions of the EVM’s distributed nodes. Since all contracts on Ethereum are driven by sending transactions, the order in which a transaction is received affects the outcome of the transactions. In order to ensure that all nodes execute the same logic, it is necessary to ensure the order in which all nodes receive transactions is consistent, if not it will cause disorder.

Obviously, in a distributed environment, it is difficult for all nodes to maintain the consistency of receiving transactions, especially in high-frequency trading scenarios. As an example, if A sends 10 consecutive transactions to B, the settlement cannot be completed until all nodes receive and process all of the transactions in a sequence. If a node receives the tenth transaction first, it will have to wait until the other nine transactions are in place before it can process the tenth transaction. In addition, each Ethereum transaction can only be transferred one-to-one, which is very difficult in high-frequency scenarios, especially complex many-to-many situations.

In order to highlight the following performance problems of Ethereum, we assume the following scenario where account A wants to distribute money to 100 people. If $ETH is used to send the money, they must be sent in order from 1st, 2nd, 3rd and so forth. 100 transactions need to be constructed first and sent one after the other with the nodes processing them one by one in order. Because the balance of each transaction has to be determined whilst each transaction is being processed one after the other, the 100th transaction can only be processed and received after the rest before the 100th transaction has received the money.

Traditional internet applications that use the account model must coordinate with strong consistency database locks or strong transactional consistency to achieve account modification security.

This problem is particularly significant in distributed blockchains. The core reason is that changes to an account must be executed in a strict order, which can lead to very different results (this is why Ethereum’s swap has not been able to solve the problem of miners making a false start to benefit themselves. A transaction is inserted in front of other users to change the execution result).

UTXO model

The UTXO model is another model adopted by mainstream blockchains such as Bitcoin, Litecoin, DOGE and other blockchains.

UTXO means "unspent transaction output.” This model is very similar to the cash (banknotes and coins) we use every day and can be regarded as an improved version of cash (by the way, the digital currency to be issued by the central bank is under UTXO model).

The blockchain does not record and maintain the balance of a certain address, but records which address each bill belongs to. In the Bitcoin scenario, the balance of an address A cannot be directly queried, and the number of bills belonging to A needs to be counted. For example, we have a wallet (a real wallet) with $10, $100, and a $1 in it, then we can say that our wallet balance is $111 (and we know the balance is composed of a piece of $100, a piece of $10 and a piece of $1). In other words, if you don’t calculate each bill and face value, you don’t know how much balance you have just by the wallet itself, which is similar to the Paypal account model.

Transferring Bitcoin is also similar (but not exactly the same) to the way we normally pay with cash. From our previous example, if A wants to pay B $1, then A has 3 ways to pay B: [i] give him $1, [ii] give him $10 to get $9 back, and [iii] give him $100 to get back $99. Changing money is not the same as cash, or it can be said to be an improvement. When A gives $10 to B for $9, it does not mean that B find $9 and returns it to A. Instead, A burns the $10 (destroys UTXO), and then the system reprints a sheet of $1 to B and a piece of $9 to A (rebuild UTXO). After the transaction, A's wallet has a bill of $100, a bill of $9, and a bill of $1, with a total balance of $110.

According to what was described above, we can know that the transfer and collection of Bitcoin is the process of the continuous elimination and generation of bills in the wallet. To know the balance of the Bitcoin address, you need to take out all the bills of this wallet address, calculate all the denominations and sum them up.

At the same time, Bitcoin supports many-to-many transactions. For example, one transaction can allow A to transfer $1 to D, E, and F at the same time:

1. Take out $100 and burn them, print out $99 and return them to A, and $1 to D.

2. Take out $10 and burn them, print out $9 and return them to A, and $1 to E.

3. Take out $1 and burn it, don’t give the change to A, and give $1 to F.

The magic of the UTXO model is that the three steps above can be sent in three unrelated transactions (parallel are sequentially independent) or they can be sent directly using one transaction.

Compared with Ethereum, if Bitcoin is to be sent to 100 people at the same time, only one transaction is needed to allow 100 people to receive Bitcoin at the same time, so the performance gap is obvious. In this way, we can understand why the central bank’s digital currency uses the UTXO model. Otherwise, how would Shenzhen, a city in mainland China, send 10,000,000 digital RMB to 50,000 wallets?

UTXO script controls whether a UTXO (a bill with a certain face value) can be destroyed or not. The granularity of control is at the level of UTXO (single bill); there is no order requirement for transactions, so many-to-many transactions and parallel transaction verification can be performed which has extremely high performance in cash transfer scenarios.

Intelligence of UTXO script

The UTXO model mentioned just now has great advantages in parallelization and scalability, but why do we rarely see smart contracts on the UTXO public chain? Mainly for the following reasons:

1. UTXO script programming is complex

2. Public chains such as BTC limit script types, script volume, etc.

3. Distributed state management is more complex Let's go through them one by one. First of all, many people don't know that Bitcoin can be freely programmed (Refer here: https://en.bitcoin.it/wiki/Script). As we can see from Bitcoin’s wiki, Bitcoin has a large number of opcodes which look extremely unfriendly and look very much like an assembly language.

Those who have studied the principles of Bitcoin script should know that the ability to spend Bitcoin is determined by a stack of structure that is stored and verified.

The unlock and lock script are placed on the stack, followed by the opcode. If the final stack returns true, the UTXO can then be spent, otherwise it cannot be spent.

In fact, many programming languages ​​we are familiar with also have a stack structure when executing logic 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 functions whereas the heap memory mainly stores data such as objects. It can be seen that the stack can actually execute all logic, and the Java-compiled bytecode operates the stack to implement various complex business logic.

Although the stack and virtual machine used by Bitcoin script are not as complicated as JVM’s features, a certain combination can implement almost all of the Turing-complete logic. Many people will say that the Bitcoin script does not have an infinite loop, so it is not 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 and the loop will stop after gas is burned out. When the Bitcoin script is doing the loop, it needs to write the loop repeatedly into the script stack in advance. To make the cycle an infinite loop, you must write an infinitely long script. This kind of transaction is obviously meaningless. In actual scripting, Bitcoin scripts will specify an upper limit for the number of cycles to ensure that the handling fee is within a reasonable range (the same as Ethereum gas burn principle).

With all that said about script stacks, let's take a look at how Bitcoin Script implements some smart contracts. One of the most typical contract scenarios is ERC721, which is an NFT contract. To create an NFT in the Ethereum scenario, 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, we design a UTXO that has a piece of data and code inside it, marking what NFT this UTXO represents, who can unlock it, how to destroy it, and how to guarantee the upper limit so that the UTXO can represent this NFT. Anyone who owns this UTXO owns this NFT. If you want to transfer this NFT, you must sign with your private key to meet the unlocking conditions, and then the Bitcoin miners will execute your script to determine whether you can transfer this UTXO. More importantly, the same series of NFTs are scattered in different UTXOs, so as long as you can 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 Bitcoin 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 whereas the contract state corresponding to Ethereum only exists in one account. In contrast, Bitcoin’s contract has the same level of concurrency as UTXO, which lays the foundation for large-scale high-performance use.

Regardless of the script size, practicability, and client limitations, it is theoretically feasible to implement the above logic on Bitcoin. However, due to the independent nature of UTXO, two problems will be encountered in actual engineering. One is that UTXO interacts with each other, and the other is the problem of contract traceability and anti-counterfeiting. These two problems are cleverly solved by the MVC chain, so a practical high-performance UTXO model smart contract can be finally achieved. MVC is a Web3 public chain that perfectly implements Bitcoin + high-performance smart contracts:

1. Adopt a layer of smart contract technology “MetaTXID scheme" compatible with UTXO parallel processing capabilities;

2. 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;

3. For the first time, a Turing-complete UTXO model public chain is achieved which can meet all application scenarios of web3 and metaverse applications How MVC solves these problems can be explained in detail in the whitepaper on the official website. https://www.mvc.space/