Abstract
One of Qtum's main goals is to establish a smart contract model based on the equity consensus mechanism (PoS) and support UTXO. At the smart contract level, Qtum is compatible with Bitcoin UTXO model and AAL-compliant virtual machines. The first compatible virtual machine is Ethereum's EVM. Subsequent implementations of x86 virtual machines will support a variety of popular Smart contract programming language. Qtum has been doing a lot of exploration and practice in the creation, operation, stability and usability of smart contracts.
The blockchain platform that implements smart contracts, whether it is Qtum or Ethereum, has designed a Gas model to avoid the use of smart contracts to exhaust blockchain resources and cause the entire system to collapse. But this also brings a problem: if an address wants to operate a smart contract, it must pay Gas and determine its identity. In the Qtum blockchain, the contract operator is judged by checking the UTXO as the transaction input. This means that an address must have a QTUM that can pay for Gas in order to make contract calls. This is for ordinary smart contract users and exchanges and other institutions Both have brought some problems.
In order to solve this problem, QIP-5 proposes to add OP_SENDER opcode to the Qtum chain, so that an address can call smart contracts by paying Gas on behalf of others without QTUM (UTXOs). For specific implementation, click to read the original text: https://github.com/qtumproject/qips/issues/6
Implementation of smart contracts on the Qtum chain
01 AAL realizes the adaptation of UTXO and EVM
In order to increase the flexibility and functional complexity of UTXO, Qtum chose to migrate the smart contract virtual machine to the UTXO model. The first integrated virtual machine was EVM. EVM uses 256-bit machine code, which is a stack-based virtual machine used to execute Solidity smart contracts. Qtum uses the Account Abstraction Layer to convert the UTXO model into an account model that can be executed by the EVM, and adds an account-based interface so that the EVM can directly read the information on the Qtum chain. For details, see: "Deep Analysis of Qtum Quantum Chain Account Abstraction Layer (Qtum AAL)"
02 OP_CALL and OP_CREATE handle smart contract operations
Bitcoin supports five standard transaction operation codes: P2PKH (Pay to Public Key Hash), P2PK (Pay to Public Key), multi-signature (less than 15 private key signatures), P2SH (Pay to Script Hash) and OP_RETURN. Using these five transaction standards, the Bitcoin client can meet the complex payment logic. Qtum adds three new operators on this basis to support querying contract balances and sending funds for the contract operations:
•OP_CREATE – used to execute the creation of a smart contract, pass the byte code transmitted through the transaction to the contract storage database of the virtual machine, and generate a contract address;
•OP_CALL-used to transfer the relevant data and address information needed to call the smart contract, and execute the code content in the contract. This operator can also send funds for smart contracts;
•OP_SPEND – Use the ID hash value of the current contract as the input transaction HASH, or the transaction HASH sent to the UTXO of the contract, and then use OP_SPEND as the spending instruction to construct the transaction script.
Introduce OP_SENDER opcode
01 Realistic needs
AAL supports a transaction output including UTXO address and contract address, OP_CALL and OP_CREAT opcodes will trigger contract execution. So how do we get the sender of the contract transaction? The existing consensus stipulates that if a transaction has the OP_CALL operator, the address corresponding to the first input vin[0] of the transaction is used as the contract call address, and a legal input must have a balance greater than 0, which is currently The only way to get sender information. That is, AAL determines the contract caller (and authenticates it) by analyzing the first UTXO input of the transaction and checking whether the UTXO address has spent tokens in this transaction. This means that if an address does not have enough UTXO available (without QTUM balance), it will not be able to verify the execution message sent by the address to the contract, that is, the address without UTXO cannot make contract calls.
Let's analyze the wallet situation. A wallet can import many addresses, and generate many new addresses for change. These addresses have their own set of UTXOs. However, the entire blockchain system cannot recognize that these addresses belong to the same wallet, and only distinguish permissions and identities by addresses. Therefore, when a QRC20 contract token is transferred to an address, although the address belongs to a wallet and there is enough QTUM in the wallet, but the address itself does not have UTXO, these QRC20 tokens are also unusable. Because there is no UTXO belonging to this address as the input of calling the contract, it is impossible to send a transaction to the contract to prove that it can transfer QRC20 tokens. The solution to this situation is generally to transfer a QTUM to the address with QRC20 to ensure that it can call the contract. This restriction has brought a lot of trouble to QRC20 token users: users not only need to pay attention to QRC20 tokens, but also need to maintain the QTUM balance management of the address for QRC20 token operations.
02 Introduce OP_SENDER opcode
In QIP-5 (Qtum Improvement Proposals-5), we proposed an improvement proposal-adding a signature proof to the output script for contract transactions. This proposal will allow users to sign the contract and prove their identity to the contract without QTUM (UTXOs), that is, to call the contract as a sender without paying Gas. The proposal only takes effect for contract calls, and it allows msg.sender to be set to an address without QTUM (UTXOs). However, the proposal does not mean that the contract can be called for free, and someone (address) must pay the corresponding Qtum consumption for this transaction.
Technical realization of OP_SENDER
01 Introduction to OP_SENDER opcode
The OPSENDER opcode is only valid in the output script containing OPCALL or OPCREATE. This is to ensure that it is only used for smart contract related operations. Compared with the OP_CALL method of selecting sender, QIP-5 proposes a new method of obtaining sender information: retain the original rules, and if the OP_SENDER operation code is included in the output script, select the address and signature passed in the output script As the caller of the contract, the gas consumed by the transaction can be paid by others. The payer provides the UTXO required to call the contract and signs it in the input script.
The OPSENDER opcode contains three parameters:
- UniversalAddress type - the type of the contract caller (msg.sender)
- UniversalAddress data - data of the caller of the contract (dynamic length)
- scriptSig - the serialized scriptSig (script signature) necessary to complete the address signature
For the output containing OP_SENDER, we give an example:
- 1 // pubkeyhash (public key hash) address type
- Address// pubkeyhash address of sender
- {signature,pubkey} //serialized scriptSig
- OP_SENDER
- 4 // EVM version
- 10 //gas price
- 100000 //gas limit
- 1234 //Data to be sent by the contract
- Contract Address//Contract address
- OP_CALL
- The OP_SENDER opcode will cause the execution of an internal script. If the result of the script execution is not 1, it will return execution failure. Examples are as follows:
- signature
- pubkey
- OP_DUP
- OP_HASH160
- address
- OP_EQUALVERIFY
- OP_CHECKSIG
The above serialized scriptSig is processed in the same way as the normal scriptSig used for verification. If its execution result is 0, the transaction is invalid, and the transaction will not be packaged into a new block. The verification script of OP_SENDER is only used for transaction verification, and will not affect the related call functions of the contract. The sender message that has passed the verification is converted into the msg.sender of the contract through the QtumTxConverter of AAL.
02 OP_SENDER signature
The signature in OP_SENDER is a special case. Usually in Bitcoin and Qtum's UTXO model, only the scriptSig input by vin contains the signature, so it is only necessary to simply propose a signature scheme to avoid the problem of "signing signed data" (duplicate signature). However, QIP-5 breaks this default situation and adds a signature to the vout output script. Therefore, in order to prevent the destruction of the existing Bitcoin script-based signature paradigm, we design the signature as two separate steps:
•Sign the output of vouts with OP_SENDER opcode
• Ordinary vin input signature
The vin signature process will remain unchanged, and the vout output signature will also be implemented with a signature method similar to segwit (isolated verification). This design may not be the most perfect, but for the existing Bitcoin and Qtum blockchain networks, this design is more secure and simple, and is more compatible with previous versions.
In the solution proposed by QIP-5, vin's signature is not affected, vout signs according to the segwit method and introduces the OP_SENDER opcode into the transaction. The transaction with OP_SENDER can be constructed to realize the address without QTUM UTXOs and be paid by others The method of Gas calls the smart contract.
03 OP_SENDER transaction example
As shown in the figure above, we have added OP_SENDER opcode to Hard Fork version, and successfully created a transaction with OP_SENDER in the new test network for Hard Fork. This transaction includes various transactions such as ordinary transfer, Create, Call, Create_Sender, and Call_Sender. The following characteristics can be seen:
No changes are made to the input script, and the previous format and signature are retained
Multiple contracts can be called in a single transaction. The two outputs with OP_SENDER in the figure specify the same sender address, but we support specifying different sender addresses for each contract call;
The transaction contains multiple outputs, including ordinary transfers, contract operations, and contract operations with OP_SENDER
Comparing the output of the ordinary contract in the figure with the output of the OP_SENDER contract, it can be seen that the output related to the contract must have OP_CALL or OP_CREATE, and OP_SENDER needs to be valid in the output with OP_CALL or OP_CREATE
The output format is the same as the output example described above. The order is address type, sender address, serialized signature script, OP_SENDER opcode, EVM version (4 after upgrade), gas price, gas limit, contract data, contract address, OP_CREATE Or OP_CALL opcode
Impact of QIP-5 Upgrade
01 Technical impact on Qtum network
Since QIP-5 needs to add an opcode to pass the sender in the output, we need a hard fork to introduce it into the Qtum network. But QIP-5 only adds a new opcode, which is compatible with previous blocks and transactions.
The hard fork was first released on the testnet in September this year, and was officially updated to the Qtum mainnet in October after extensive testing on the testnet.
This upgrade supports all the functions of the previous version iteration. Some of the advantages of the QIP-5 design and the impact on the Qtum network can be summarized as follows:
QIP-5 has little impact on consensus, because the introduction of OP_SENDER opcode only affects transactions that include smart contracts, and the codes of other modules have not been modified.
The transaction with OP_SENDER maintains the same format as the normal smart contract transaction, and no new transaction format will be introduced
Allow multiple contracts to be executed in a single transaction, each contract can have a different sender
Strong scalability, can support more address types in the future
However, during implementation and use, some additional operations need to be done to ensure its availability:
A special signature tool and RPC interface must be provided to use this function
The output script must be parsed and checked for OP_SENDER when verifying the signature. Generally speaking, the output script is ignored when doing signature verification
02 Impact on users
Due to the introduction of OP_SENDER, a modern payment transaction gas service will be introduced, so that users can directly operate Dapps without worrying about whether they have enough UTXOs to pay for Gas and verify permissions. This is a great convenience for the Dapp ecology and users. :
Dapp maintainers can build OP_SENDER transactions to do gas payment services by themselves, or access trusted gas payment services to bring Dapp users a more convenient and simple operation experience
Users can directly access the Dapp ecosystem without considering the restriction of QTUM balance on address operations, which reduces the threshold for Dapp usage
Dapp users can frequently change addresses without transferring QTUM to the new address for Gas payment, which can effectively ensure the security of Dapp users’ digital assets
03 Impact on the exchange
A large number of QRC20 tokens are circulating in the exchange, and the exchange needs to create a QTUM address for each QRC20 user. It is more complicated to maintain these addresses and make these addresses available for deposit and withdrawal.
The general practice is to maintain hot and cold wallets. Users transfer QRC20 from the chain to the exchange. After the exchange confirms the transaction, it will be transferred to the hot wallet. The QRC20 tokens that have not moved for a long time will be transferred to the cold wallet. Gas is required to be paid when transferring money from the user's address to the hot wallet. Therefore, even if the address is only used for the transfer and transaction of QRC20 tokens, it is necessary to ensure that it has a certain amount of QTUM to realize QRC20 transfer. In the above process, each exchange will have different designs and risk control, but in general, it is necessary to maintain the QTUM balance of the user address to complete the token transfer.
After the OP_SENDER post-op code is introduced, the exchange no longer has to maintain the gas payment balance for the user address operating the smart contract token, but can transfer the user address to the hot wallet by constructing the OPSENDER transaction, thereby greatly reducing the transaction The complexity of maintaining user addresses and organizing wallets helps exchanges improve efficiency and reduce costs.