|
Preface: Qtum Quantum Chain is committed to building a bridge between the Bitcoin ecosystem and the Ethereum ecosystem. It uses an incentive-based proof-of-stake mechanism as Qtum's consensus mechanism, and is based on Bitcoin's UTXO model. It supports Turing-complete virtual machines (such as Qtum VM/EVM/Lua, etc.) and builds mobile applications based on blockchain technology DAPP and smart contracts through mobile strategies. Through the efficient and fast distribution of DAPP Store (decentralized application store), it promotes blockchain technology to ordinary Internet users. In addition, Qtum has also innovatively proposed the concept of the Value Transfer Protocol (VTP protocol), which is embedded in the protocol layer through smart contracts, and through the management of different user address permissions and address types, as well as the standards of the World Wide Web, to achieve a blockchain payment protocol that integrates the existing TCP/IP protocol. This payment protocol will bring more intelligence and more business possibilities. How to realize this grand vision requires the continuous efforts of countless developers. Qtum's development team is a very international team, which is in line with the distributed characteristics of blockchain technology. As of the time of writing, a total of 29 developers have participated in the Qtum project development process. How to coordinate developers from different countries and time zones is also a difficult problem faced in the development of blockchain projects. In addition to collaborative development through GitHub, the Qtum team has also adopted many other collaborative tools, including some collaborative work developed by itself, including code sharing, code testing, code environment migration, etc. Today, let us go back a few months with the Qtum team and review the design process of the GAS mechanism in the Qtum Virtual Machine (QVM). In order to let everyone better understand the development process and working methods of blockchain technology and better understand blockchain developers, we have preserved the original discussion process of the team on the GAS mechanism at that time, and the process of starting over after the GAS1.0 design was completed. We hope that the publication of these development details can bring certain help to other blockchain development teams and blockchain development projects, and improve the development efficiency of the projects. We also hope that through the publication of relevant details, everyone can enter the blockchain development team and have more exchanges with the Qtum development team. The team members involved in the design of the GAS mechanism are as follows: first row, second row, from left to right Shuai Chu: Founder of Qtum, graduated from Draper University (Hero Academy) and the Chinese Academy of Sciences. Previously worked at Alibaba. During his doctoral studies, he devoted himself to the development and research of blockchain technology and has rich development experience in the blockchain industry.
John: Graduated from the University of Florida, previously worked for blockchain companies such as Bitwage and Coinpip.
Ouyang Yunqi: Graduated from Beijing University of Posts and Telecommunications, previously worked at Baidu, Asian Rubik's Cube Championship.
Neil: 15 years of software development experience, proficient in Bitcoin and Ethereum development and design, white hat developer.
Top 100: Dropped out of Peking University’s theoretical physics program and previously worked at Kingsoft Software and Cheetah Mobile.
Jordan.earlz: Started programming at the age of 13, has 18 years of development experience, is a Coin Reviewer, has reviewed the designs of more than 100 virtual currencies in the community, is a security expert, and is one of the most famous developers in the North American Bitcoin community.
Emiliano: PhD in Computer Science, specializing in data feed and data mining.
IBai: Cryptography expert, PhD in Cryptography, early participant and developer in the blockchain community
Qtum (Chinese members) Development Team Shanghai Office
·alex： Hi, everyone. What is our final design for the GAS mechanism?
earlz: We chose the current design mechanism, used the bitcoin fee mechanism (for example: input-output = miner fee), and completed the MAX_GAS opcode, so that miners can predetermine the amount of work required to execute a contract.
Here is the design mechanism of MAX_GAS https://qtumproject.atlassian.net/browse/QTUM-7
neo: hi good morning
·earlz: Good morning, Neo
·alex: Thank you, it’s already night here haha
·earlz： How do you feel about this GAS design mechanism, Alex?
·earlz： We need everyone to determine the purpose of our design and have the same understanding of this design.
·shuaichu： Not sure if it is a good idea to reissue a new token to execute the contract?
earlz: It is not a new token, but just a counting unit. The Max gas opcode is just to help miners know how much computation is required for a transaction.
·Alex: Yes, max gas is not a new token
·shuaichu： I think we need to implement operators through economic design, similar to the mechanism of handling fees, and it should be noted that all nodes in the network need to execute the same operator. If the execution of the contract is free, some people may ddos the network.
·earlz： We can design this aspect and make all transactions include a certain amount of gas fees (for example, in extreme cases, these fees are directly lost and miners cannot get these fees), but in this case, we need to make sure that the currency itself is not too deflationary.
This idea is okay. In this way, we can give part of the GAS fee to miners, and directly use the other part as node fees. This way, the incentives for malicious nodes are greatly reduced.
·shuaichu: I think we should adopt a fee mechanism similar to Bitcoin, so that each operator needs to pay a small fee in the Qtum virtual machine
·earlz： Yes, but what I mean is that miners can’t take all the transaction fees, because they need to pay some for the GAS cost.
·shuaichu: If the transaction fee in a transaction is not enough, we need to discard the transaction.
And speed up their transactions by allowing senders to set higher fees.
earlz: Yes, miners can still create transactions with high fees
·alex: What are the advantages and disadvantages of using the GAS and MAX_GAS mechanisms and OP_EXEC?
·earlz： I am not sure that using MAX_GAS will have a bad impact. Other options may cause miners to determine whether a transaction is expensive based on the size of the transaction data, and affect the judgment of whether to package it into the block.
·shuaichu: I think the bad thing is that gas itself is free and has nothing to do with qtum itself
·earlz： I think in this case, it will be similar to Ethereum, just with a different code implementation. If in Ethereum, all GAS is obtained by miners, then it is the same in Qtum. The only difference is that in Ethereum it is implemented through "gas price", and in Qtum it is implemented through gas amount and transaction fees.
·Alex： Yes, we share the same opinion. I think GAS should come from the Ethereum network, and the value also depends on the cost of Qtum.
·earlz： GAS is just a number and has no value. It is just a unit of calculation. When you construct a transaction, you need to declare how much GAS the transaction requires (for example, how many operators are required for calculation). If your transaction costs more GAS, then the transaction will be classified as OutOfGasException. This is similar to Ethereum, which allows miners to ultimately decide whether it is worth mining by looking at the transaction fees.
Yes, GAS may be adjusted based on the price of Qtum and the state of the Qtum network, similar to the transaction fee model in the Bitcoin network.
·alex： I think GAS should be part of the transaction fee and will be consumed when the bytecode is executed.
·shuaichu： Earlz, where does gas come from?
·Alex: Gas should come from transaction fees
·earlz： Technically speaking, gas doesn't actually come from anywhere, it's just a measurement method for miners to decide whether a particular transaction fee is worth mining.
·shuaichu： But if a miner sets all transactions to the maximum allowable gas, will this cause a DOS to the network, because the miner can get all the gas for free?
earlz: This is why MAX_GAS is set by the sender of the transaction, not the miner itself. MAX_GAS is part of the transaction and cannot be manipulated.
·shuaichu： Yes, but if the transaction initiator sets a very high value every time, will it have any impact?
earlz: If they set it very high, it means that miners may not accept the transaction unless they have a high transaction fee.
·shuaichu: I see, so it ultimately depends on the transaction fee (my understanding)
·earlz: Yes
·shuaichu： Then why not design this part of the mechanism based solely on transaction fees?
earlz： Because there is no gas and max gas mark, miners will not know how much a transaction will eventually cost?
·shuaichu: For example, similar to Ethereum, a fixed gas price
·alex: tx fee = inputs – outputs – gas price for all bytecodes executions
·shuaichu: Because if the user sets the max gas, there is no way to determine the final computational cost.
·earlz: In the Bitcoin system, the design mechanism of transaction fees is OK, but this language is not Turing complete and cannot perform loop operations. In this case, the size of the transaction is a very good indicator of the time it takes for miners to process the transaction, but for the Qtum virtual machine, a small transaction may take a lot of time to process. For example, the operators involved in this transaction include loops, etc.
·shuaichu: The cost of the computation depends on how many operators are ultimately executed, and on the state of the execution.
earlz: If there is no max_gas limit, it will be very easy for an attacker to attack the Qtum network. They need to process many transactions with low fees, and miners may not execute the corresponding packaged transactions because the fees are too low. With max_gas, it is easier to determine whether a transaction is expensive, and miners can decide in advance whether to process the transaction.
·shuaichu: This method will bring some problems, because we cannot trust a value set by the initiator of a transaction.
earlz: For Max_gas, each opcode operator consumes a certain amount of gas. If a transaction consumes more gas than the max-gas they claim, the execution of the entire Qtum virtual machine will be rolled back and rolled back through OutOfGasException. However, a transaction will still be accepted by the blockchain network and the miner will receive the corresponding fee.
·shuaichu： And similar to Eth, when the given handling fee cannot cover the corresponding expenses, the operation of the virtual machine will stop.
earlz： Yes, if they use the wrong Max-gas, then they risk losing all the funds in a transaction, which is also a problem with the current OP_EXEC_ASSIGN operator. This is also a situation that needs to be considered, because in the UTXO model, it is not easy to return funds directly.
So maybe we need to design a return address for the OP_EXEC_ASSIGN operator.
·shuaichu： I think in the outofgas example, we can design the network to still charge the corresponding handling fee, but send the other funds to the sender's address.
In this case, outofgas will create a new transaction
earlz: Yes, but the problem is that sometimes the sender’s address is not a simple address, but may be a multi-signature (multisig) address or a pay-to-script address (P2SH)
·shuaichu： But in the max gas model, how does Qtum's blockchain network charge fees?
·earlz： In the max-gas model, the collection of transaction fees can be similar to the transaction fee model of Bitcoin, that is, the input is greater than the output, and the difference in the middle is the transaction fee.
·shuaichu： In this case, the transaction fee should be included in a block, which means that the transaction is packaged into the blockchain network.
·earlz: Yes
Shuaichu: Rejected transactions will not be included in the blockchain, so it will be difficult to collect their fees.
·earlz： If an EVM transaction runs out of gas, the transaction is still valid and will be included in the block, but no virtual machine operations will be executed. However, in our current QVM, the initiator of this transaction will lose part of the funds. This is a shortcoming in our design. We need to correct this shortcoming through a return address.
·shuaichu： I think the idea of maxgas cannot solve this problem. It is similar to the concept of using fee.
This is a major problem, as using a return address will add complexity to the system. Perhaps we can find a simpler implementation.
·earlz： We need to find other alternative ways so that we can maintain compatibility with the UTXO model of the Bitcoin ecosystem.
·shuaichu： That is true. We need to think about this issue carefully.
·earlz： Yes, we need to think about this issue seriously. I haven’t tested all possibilities (edge cases). My original intention is that when OutOfGasException occurs, the fee can be spent (to the miner), but other funds cannot be lost.
How do others think about this?
·shuaichu: I am thinking about this situation. Maybe I will think about it when I sleep. Haha
·earlz: Yes
·shuaichu: We need to summarize the various problems we are facing now
·earlz： I feel that the idea of max-gas can continue to be borrowed, but unlike when out of gas, when funds are lost, we can send the funds to a target contract, but one problem is that QVM does not execute the transaction.
Haha, if EVM's mechanism for handling gas wasn't so bad, it seems that outofgas transactions should consume handling fees like this: it means creating a transaction and adding the transaction to a blockchain (it means spending the input, creating new outputs, and giving the new outputs to the sender, but in the case of p2sh, we can't know who the sender is)
·earlz： We may need to design the max-gas and warning-gas parts, and warning-gas will trigger the program to predict the current execution status of the virtual machine and tell the virtual machine what to do next?
·shuaichu： I think the idea of max-gas is similar to the idea of fee.
·earlz: Yes
The idea of Max-gas is to give miners a little more information so that they can predict how much gas a transaction will cost before executing the contract.
·shuaichu： But this will bring a problem, that is, miners don’t actually know the actual cost. For example, the cost is 1 at blockx, but at blockx+1, the cost is 1000. And the change of some values of the contract may cause the program to point to a more complex contract.
earlz： Yes, this is also the reason why max-gas exists, so that we can predict how long it will take to execute
·shuaichu: I think we are not talking about the same thing haha. For example, we have a contract like this. Let’s write some pseudo code smile:
·earlz: Yes, we need a whiteboard to write together.
·shuaichu： slightly_smiling_face:
earlz： Yes, I know what you mean, the same contract will cost different gas when executed in different blocks (this depends on which step in the blockchain network is accepted and how it is executed).
max-gas can set an upper limit and estimate the amount of computation required. When creating a transaction, we need to plan well to avoid the problems currently faced by the ETH system (you can see the various problems currently faced by Ethereum due to the design of the gas mechanism)
·shuaichu：
int a=0;
void increment(){
a++;
return;
}
void weirdcalc(){
if(a==0){
return;
}else{
int i;
for(i=0;i<10000;i++)a++;
return;
}
}
·shuaichu: where weirdcalc() depends on the execution time of each time. I think you should know what I mean
·earlz: Yes
·shuaichu: The problem is that it is very difficult to determine a specific upper limit. In this case, we can only determine how much gas is consumed by blind execution.
·earlz： Yes, in this case, all contracts must be written in a way that predicts gas.
·shuaichu： Yes, but we have no way to control what others are writing. We need to consider all possibilities, including the worst possibility.
earlz: Yes, if they can't determine how much gas a contract needs in a predictable way, then they will face the same problem in QVM as EVM and lose their transaction fees, similar to the outofgas situation in Ethereum.
Shuaichu: Yes, I think the main issues we need to focus on are: 1. Collecting the corresponding handling fees 2. Returning the corresponding inputs. This is the main problem faced by the current solution.
earlz: OK
shuaichu: Then we need to decide whether there is any advantage to looking at the max gas way versus the gas way.
One way we can do this is by sending the fee to a separate transaction and note that as we extend the EVM, transactions can check how much GAS is being consumed and can change their behavior based on that.
·shuaichu: Extended EVM?
earlz: Yes the link is here: https://github.com/bitsegroup/qtum-evm/blob/master/docs/dev-doc.md#opcount
I am also curious why EVM does not have such a method
·shuaichu： Yes, this has some benefits, but we can focus on the classic VM first, and then test it after the prototype is completed.
I think we need to clarify some difficult issues regarding fees.
·earlz： Yes, adding opcode is not a particularly difficult thing. The difficulty lies in how to integrate it with the existing solidity and ensure its security.
But no matter what, it still cannot solve the problem of how to return the returning money.
I can continue to think about how to solve this problem tomorrow. I guess I will have some new ideas after I wake up from a good night’s sleep.
Haha O (∩_∩) O Haha~
Welcome to follow the recent releases:
Design of GAS Mechanism in Qtum Virtual Machine (QVM) (Part 2)
The figure below is the first version of the design sketch of the GAS mechanism in the Quantum Chain Virtual Machine. It has been significantly modified. In the next article, we will further analyze the entire design process, so stay tuned.
|
