MetaContract Technical Explanation

PARALLEL VERIFICATION OF CONTRACTS

Due to the UTXO model used by MVC, when the node receives the transaction, the running result of the contract has already appeared in the output of the transaction. It means that the node only needs to verify the correctness of the result, and does not necessarily need to do all the operations to get the result. This means that we can put some calculation-intensive contracts out of the chain and only verify the calculation results on the chain.

At the same time, since the contract virtual machine in the MVC node only performs verification (read-only operation), it will not bring side effects (write operation) to all contract operations, so the verification of the contract in the node can run completely in parallel. That is, as shown in the figure below, MVC nodes can run multiple VMs at the same time to verify different transactions. Take full advantage of the multi-core architecture of modern computers.

ZERO CONFIRMATION SECURITY

Since the MVC node's principle for TX sorting is the foresight principle, that is, as long as the transaction meets the minimum fee requirement, it will enter the node's memory pool and wait for the block to be generated, and there will be no problem of being replaced by a transaction with a higher fee. During the unconfirmed period of the transaction, if a transaction with the same utxo arrives, it will be identified as an illegal transaction by the node. As shown below:

After transaction TX1 enters the memory pool, transaction TX2 arrives. Since TX2 and TX1 use the same UTXO1 as input, and TX1 enters the node’s memory pool one step earlier than TX2, according to the foresight principle, TX2 is rejected by the node.

In actual operation, we only need to ensure that the contract transaction can be delivered to most of the mining pool nodes, that is, we can guarantee the high probability security of zero confirmation.

In addition, consider the worst case, that is, someone does evil, maliciously creates double spending, and is successfully packaged by the mining pool. That is, TX2 in the figure above is packaged by the mining pool, causing the TX1 transaction to be discarded by the node. In this case, only the operation of TX1 will be cancelled. Taking swap as an example, the consequences of the transaction being canceled will cause the swap to be rolled back, and the user's transaction assets will return to the original address, and there will be no loss of assets For general transfer transactions, we need to decide whether to wait for confirmation based on the value of our transaction. If it is a relatively large amount of asset transfer, waiting for confirmation is a safer approach, but for most cases, zero confirmation is secure enough. Users can flexibly decide their own security policies.

THE GLOBALLY UNIQUE ID OF THE CONTRACT

In the smart contract based on the global state represented by ETH, there is a globally unique address to mark a certain contract instance, and third parties can find the corresponding contract through the address of the contract and interact with the contract. Since there is no global state in MVC, all state data exists in each UTXO. After the UTXO contract is executed once, a new contract UTXO will be generated, so a method is needed to determine the ID of the contract, so that third parties can safely find the corresponding contract and interact with it.

CONTRACT ID

Each contract will have a unique input when it is created, so we use this unique input combined with the code hash of the contract as the input ID of the contract.

As shown above, UTXO1 has a unique identifier TXID1+outputIndex1, and contract1 is a newly created contract. We can combine the identifier of UTXO1 and the contract code of contract1 as the ID of the contract contract1. In actual contracts, hash(TXID1 + outputIndex1) + codeHash is generally used as the ID.

The above is the basic generation logic of the contract ID. For FT and NFT, due to some special requirements (additional issuance), some additional constraints will be made on this basis.

CONTRACT TRACEABILITY

Using the traceability method proposed by scrypt, we can effectively verify the ID of a contract, thereby preventing others from forging the same contract ID.

Simply put, to prevent contract forgery in MVC, it is necessary to verify the data of the parent transaction TX2 of the current transaction TX1 and the parent transaction TX3 of the transaction TX2. The specific verification content includes the ID of the contract and the Code of the contract. The definition of the parent transaction is if the input of TX1 uses the output of TX2, that is, TX2 is the parent transaction of TX1.

As shown in the figure above, TX1 needs to verify its parent transaction TX2 and grandfather transaction TX3 to check whether the contract code and data are consistent with itself.

TRANSACTION DATA INFLATION

During the verification process, TX1 needs to obtain the transaction data of TX2 and TX3, which will cause the transaction data of TX1 to expand. Therefore, using the MetaTxID method, the transaction input data can be hashed to prevent the expansion of TX transactions, so that the data required for this verification is always kept at a small constant, thereby preventing the infinite expansion of transaction data.

COMPOSABILITY OF CONTRACTS

Through a method of verifying Contract code and data, we can realize the combination of different utxo contracts.

The contract in MVC consists of two parts Code and Data, which are separated by the OP_RETURN operator. Code is the execution logic of the contract, and data is the data carried by the contract, that is, its own state data. For a contract, we only need to determine the execution logic of the contract and its current state to determine the function of the current contract.

Therefore, in the same TX, multiple contracts can be added to the input, and we can obtain the contract code and data of other inputs in this TX by reading the data of its own TX, so as to determine the identity of the contract. Different logic is executed according to different contracts, so as to achieve the effect of combining with different contracts.