How to get through the qtum quantum chain account abstraction layer and get through the bitcoin and Ethereum ecology?

A brief analysis of Qtum account Abstraction Layer (AAL) implementation

Qtum is designed with the Bitcoin Utxo as the base account model and implements the smart contract that supports EVM specification, which is done through the account abstraction layer, the AAL. The AAL has adapted between the Utxo account and the EVM contract account so that the AAL can use the Utxo trade output to create a smart contract on the chain, send the transaction to the contract account to trigger the execution of the contract, and after completion the AAL will eventually process the execution result and adapt it to the utxo. Due to the AAL, contract developers do not need to be concerned about the Utxo conversion details associated with contract operations, they can be developed using EVM features and are compatible with existing Ethereum smart contracts. In this paper, the implementation code from UTXO transaction to intelligent contract execution is interpreted, and the work process of AAL is briefly analyzed.

1.UTXO trading new Script opcode

Qtum has added three opcode op_create,op_call and op_spend for Utxo trading scripts to provide operational support for transitions between the Utxo and EVM account models. These opcode are defined in the Opcodetype enumeration type:

This three opcode has the following functions: Op_create for the creation of smart contracts, op_call for execution of contracts, and op_spend for the cost of contract balances.

The Hascreateorcall () and Hasopspend () functions are added to the class ctransaction used for Utxo model transactions in order to identify and justify the transactions of the opcode control during block generation. It is used for transaction processing in Mempool in new chunks, and the corresponding processing is added in the Evalscript () function of script opcode parsing.

Conversion of 2.UTXO trading to EVM model trading

When generating new chunks, in addition to the usual parameter legitimacy, consensus rules, DDoS attack checks, etc. for utxo transactions, the opcode check function hascreateorcall () is used to determine whether the trade output contains op_create or Op_call, The EVM is required to perform contract creation or contract invocation, respectively. This section has the following processing procedures:

2.1 Account parameter extraction for EVM model

The implementation of the contract in EVM uses data, Gasprice, Gaslimit, VM version parameters, which are sent via RPC call Sendtocontract, Sendtocontract generates a UTXO transaction, The Op_call operation code is used in the trade output, and then the trade is broadcast to the blockchain network. The adaptation of the AAL from Utxo to EVM is implemented through the Qtumtxconverter class, where the member functions of the class extractionqtumtransactions () and Parseethtxparams () Complete the parameter extraction for all such utxo trading outputs. The code snippet is as follows:

The above code first determine if opcode is op_call, then the address is vecaddr the contract has been created, so directly converted to the EVM format address receiveaddress, otherwise op_create, the creation of the corresponding contract, there is no such field, so do not extract. The data, Gasprice, Gaslimit, and VM version extraction are then completed in turn, which are necessary for EVM to perform bytecode.

2.2 Trading conversions for the EVM account model

The transaction conversion is done through the function createethtx () of the Qtumtxconverter class, using the parameters extracted in the previous step and the Utxo trading output vout to create a qtumtransaction type of trade. Because qtumtransaction derives from the Dev::eth::transaction class in EVM, the operations associated with EVM execution qtumtransaction classes are supported.

First the code etp.receiveaddress = = Dev::address () determines whether the contract is not in the EVM state and needs to be newly created or the EVM state already contains the contract, the difference is only the contract address. The Qtumtransaction () constructor then completes the construction of some of the trading parameters, and the next statement extracts the sender (sender) of the transaction, then sets the transaction hash. A UTXO transaction supports multiple inputs and outputs, Qtum's AAL design takes this into account, so the AAL supports a trade output that includes Utxo account and contract account, and the final set of Nout indicates that the nout output of the transaction is sent to the smart contract, so the output will trigger the contract execution. This completes the conversion of the transaction according to the EVM account model.

3. Utxo conversion of contract execution and execution results

The execution of the contract changes state (Globalstate unified Management by the instantiation object of the Qtumstate Class), and for the state of the contract, Qtum inherits the EVM definition, so it is compatible with all the EVM-compliant smart contracts. However, the transfer of the account Amount (transfer), Qtum did a utxo conversion, which means that the smart contract and the normal Utxo model account can complete the interaction between, this is the AAL implementation of UTXO support smart Contract is an important link. The following is a brief introduction to the conversion process of contract execution and status results.

3.1 Contract execution Environment construction and contract execution

The execution of a contract is a critical step in the contract process and directly affects the state of the contract. The implementation of EVM to contract bytecode is realized through the Bytecodeexec class, and the main function is Performbytecode (). The main process of this step is to build the virtual machine execution Environment using the trading parameters extracted above, and then complete the execution of the contract, with the following code:

The first is to build the contract execution environment, which is completed by Buildevmenvironment (). It can be seen that the execution environment is for each individual transaction, so as to maximize the separation of the contract execution process of the different trades and avoid the cross-influences during the execution of the contract. Then build a new Sealengine class, which is the EVM execution engine, which is done specifically by the Createsealengine () function. The intermediate is checked for possible state anomalies, and then Globalstate->execute () completes the execution of the contract, which is used to build the execution environment Envinfo and the EVM execution engine SE.

3.2 Utxo Conversion of contract execution results

The results of the completion of the contract are saved in the vector<resultexecute> result,vector Vector records the transfer relationship between the EVM accounts generated by each contract execution, and the AAL converts these transfer into UTXO transactions. , the conversion from the EVM account model to the UTXO model transaction is completed. This is done through the processingresults () function, which is the code snippet below.

The RESULTBCE variable of the Bytecodeexecresult type is defined first to save the result of the transformation. Use opcode op_spend, which is used to realize the cost of the transaction, because the utxo of the bitcoin is realized by the transaction input unlocked by the private key signature, and the EVM execution involves transfer between the different accounts, so it needs to pass OP_ Spend implements the conversion of these transfer to Utxo model transactions. If execres.excepted is not none, which is the contract execution exception, the balance is returned to the contract caller. Otherwise, if there is no exception, the remaining gas after deducting the consumed gas is returned to the caller of the contract. For transfer that appear in contract execution, their utxo transactions are kept in result[i].tx. Thus, transactions between the different Utxo accounts resulting from the execution of the contract are stored in the valuetransfers vector, which eventually includes the new chunks. The AAL module has thus completed the conversion from EVM to Utxo.

4. Summary

The

AAL assists with the creation, execution, and cost of the contract by adding a new utxo script opcode. Before the contract is created and executed, the conversion of the UTXO transaction to the EVM model transaction is required, and then the execution of the contract is completed using the built EVM execution environment and engine. The AAL eventually processes the results of the contract execution and is adapted from EVM to Utxo, thus enabling a Utxo-based smart contract. The AAL makes Qtum compatible with EVM-compliant smart contracts, providing Dapp with a new foundation platform, while the benefits of utxo such as parallel processing and privacy can be preserved.