Background
Qtum has been focused on developing the underlying infrastructure of our blockchain, while we continue to stay updated with the latest technical iterations based on Bitcoin and the Ethereum Virtual Machine (EVM). Since September 2017, the Qtum Mainnet has been running stably. In the process, a subtle imperfection in our Proof-of-Stake consensus algorithm has been discovered and repaired along with some smart contract opcode additions that have been proposed and added to improve smart contract functionality.
To adapt to the ever-changing application scenarios of blockchain technology, Qtum will gradually upgrade the underlying protocol and launch Qtum 2.0. The hard fork described in this article will be the first upgrade related to Qtum 2.0.
About QIP (Qtum Improvement Proposals)
Qtum Improvement Proposals (QIP) are a series of specific recommendations from Qtum developers and community members on the underlying Qtum technology upgrade. All proposals are posted on GitHub (https://github.com/qtumproject/qips/issues), and everyone can discuss the proposal publicly. Widely accepted proposals will be implemented by the Qtum development team.
Purpose and Motivation
This will be the first hard fork since the launch of Qtum Mainnet. It includes four consensus-related QIP upgrades:
- QIP-5: Add signature verification to the output script of the contract transaction;
- QIP-6: Add btc_ecrecover precompiled contract to the Qtum EVM;
- QIP-7: Upgrade the Qtum EVM to the latest Ethereum EVM Constantinople;
- QIP-9: Modify the difficulty adjustment algorithm to make the block time more stable.
Among them, QIP-5 and QIP-7 add several new features to Qtum to adapt to the complex application scenarios of smart contracts, and are also the technical basis for subsequent upgrades (such as private assets); QIP-6 eases the development of smart contracts while reducing the cost of usage; and QIP-9 further improves the stability of the Qtum network.
Why Do We Need a “Hard Fork” Update?
Qtum is a decentralized network, where each node runs a separate node/wallet program. Only individual users can control the version of the program running on their node, while all nodes can reach an agreement on all transactions and blocks on the Qtum network through uniform consensus rules. If some nodes adopt different consensus rules from other nodes, they will fork into two chains.
Common updates do not modify any consensus rules. Even if some nodes do not complete the upgrade, the network will not fork because the software update is backward compatible with older versions. However, since the changes involved in this update modify the consensus rules, updated nodes and the non-upgraded nodes will not be compatible, leading to a hard fork.
Please note that this hard fork is accepted and desired by the community so most nodes will be updated to support the hard fork. Any nodes or wallets that miss the update will be automatically disconnected from the network and stuck on a dying split chain unable to complete transactions and potentially staking their coins to the split chain, which are very difficult to recover. To save problems it is strongly recommended to update for the hard fork.
Hard Fork Related QIP Overview
QIP-5
Description
Signature verification is added to the output script of the contract transaction to prove ownership and invoke the contract without having any QTUM in the address.
Motivation
Calling any smart contract in Qtum requires a gas fee for smart contract execution. For every contract invocation, a balance is required in the address that calls the contract (even if the balance is very small). For example, the transfer of QRC20 tokens is the most common contract invocation. Suppose there are 1000 QC tokens (a QRC20 stable coin launched on Qtum) tied to address A. To send these 1000 QC, a certain amount of QTUM is required in address A to pay gas for the token transfer (typically 0.04 to 0.10 QTUM). If address A does not have any QTUM balance, it cannot pay the gas fee, and the 1000 QC cannot be sent to a new address.
The only solution currently is to transfer some QTUM to address A and then send the QC tokens. However, this not only wastes valuable UTXO dataset resources on the chain but also greatly affects the user experience. At the same time, for more complex application scenarios of smart contracts (such as forecasting market applications, decentralized exchanges, etc.), this limitation significantly increases the threshold for users to use blockchain applications.
Benefits
By adding the OP_SENDER opcode, QIP-5 provides a mechanism to prove the ownership of the contract invocation address, which can offer proof without any QTUM in the address and then invoke the smart contract. Although little change has been made to the original system, it has brought about major changes to the existing smart contract ecosystem:
- Addresses can invoke smart contracts (such as sending and receiving QRC20 tokens) without any QTUM, improving the token transfer experience for ordinary users. Note: This does not mean that the contract can be invoked free of charge, but can be paid by other addresses;
- More diversified services will emerge. Service providers will pay the fee, while users only need to use the service, which is closer to the actual application scenario;
- It allows multiple addresses to invoke multiple contracts in a transaction, increasing the flexibility of contract invocation;
- Save the UTXO dataset resources on the chain.
Possible Risks
QIP-5 adds additional consensus rules but remains compatible with the original rules, so there is no security risk in theory. But it will have some impact on the existing infrastructure:
- Additional RPC commands need to be developed to properly use this function, and service providers need to synchronize infrastructure upgrades;
- Due to the additional scripts, service providers will need to perform extra validation on scripts, otherwise, they will not be able to identify such transactions.
For the specific implementation of QIP-5, please refer to this document.
QIP-6
Description
Add a btc_ecrecover precompiled contract to Qtum EVM for direct invocation of common contracts.
Motivation
In Solidity, theecrecover function can restore an elliptic curve signature to the corresponding public key address. The msg.sender in Qtum’s smart contract uses a P2PKH address similar to Bitcoin, while the address format returned by the ecrecover function is the same as that of Ethereum, so the two cannot be directly compared. For developers, this will make some logical decisions in the contract cumbersome. At present, the common way to solve this problem is to invoke additional library contracts, but that will consume more gas, increasing the cost of using smart contracts.
Benefits
QIP-6 implements a function called btc_recover by precompiling contracts. The new function, while compatible with all interfaces of the original function, can bring the following benefits:
- The address type returned by
btc_recoveris identical with the address format of msg.sender, which allows direct comparison and simplifies the logical decision in the contract development process. - Precompiled contracts can greatly save gas consumption and reduce the cost of using smart contracts.
Possible Risks
QIP-6 does not make any changes to the original system, and the new function is fully compatible with the original function interface, so there is no risk in theory.
For the specific implementation of QIP-6, please refer to this document.
QIP-7
Description
Upgrade the Qtum EVM to the latest Ethereum’s Constantinople.
Motivation
Currently, Qtum uses an earlier version of the EVM. After the launch of Qtum MainNet, the EVM has been upgraded to the Byzantine and Constantinople. Many new developer-friendly features have been added to the new version of the virtual machine, such as returning variable-length data and invoking static contracts. More and more developers need to rely on these new features for contract and application development.
Benefits
QIP-7 includes all the new features of EVM Byzantine and Constantinople versions, enabling more complex smart contracts and applications. For example, Qtum plans to support private assets in QIP-19, where the related smart contracts rely on the new features provided in the new EVM. Also, after the upgrade, all the smart contracts and applications on Ethereum can theoretically be transplanted to Qtum while obtaining the unique security and stability of the underlying UTXO model.
Possible Risks
Both the EVM Byzantine and Constantinople have been activated on the Ethereum Mainnet, of which the stability has been verified, and they are fully forward compatible with low risk. However, the Qtum bottom layer adopts the UTXO model, which is inconsistent with EVM’s account model. Developers need to pay attention to the characteristics of Qtum EVM when transplanting existing contracts.
For the specific implementation of QIP-7, please refer to this document.
QIP-9
Description
QIP-9 actually two updates:
- Modify the difficulty adjustment algorithm for Qtum Proof-of-Stake to make the block time more stable and lower the average block timing to 128 seconds as given in the original design.
- Modify the Network Weight estimation algorithm to make it closer to the real value (not related to consensus).
Motivation
Qtum was designed for a block interval of 128 seconds. In Qtum’s decentralized Proof-of-Stake process, the timing of actual blocks should show random variation around 128 seconds, and the difficulty adjustment algorithm will adjust the difficulty up or down to maintain this average. Unfortunately, a subtle bug in the difficulty adjustment algorithm has caused two problems, 1) some excessive long intervals for blocks, and 2) an average block interval of 144 seconds. This higher average interval means the blockchain is running a little slower than design, and that transactions per second are 12.5% low and staking block rewards are 12.5% low.
Network Weight is an estimate of the total coins staking on the Qtum network and is used to calculate the expected returns for staking (expected time to a block reward). Since Qtum is a completely decentralized network, the weight of the entire network can only be estimated by the difficulty of staking. However, the existing Network Weight calculation fluctuates greatly and does not accurately reflect the current status of the network.
Benefits
- QIP-9 provides an improved difficulty adjustment algorithm adjusting for difficulty based on an exponential moving average of block intervals. This improved algorithm has the benefits of eliminating the very long block intervals and providing an average block interval of 128 seconds. This faster average block interval means network transactions per second and block rewards for staking wallets will increase by 12.5%.
- QIP-9 improves the Network Weight estimate by changing the calculation to use a fixed divisor for the 128-second interval. Compared with the original Network Weight approach, the variance between the new Network Weight and the real weight is smaller, and the fluctuation is smaller, which means a more accurate estimate of the current network status.
Possible Risks
- The difficulty adjustment algorithm involved in QIP-9 has no security risks.
- Although the Network Weight estimate calculation gives relatively smooth values, it cannot reflect the change of Network Weight if the actual weight fluctuates sharply, so there is still room for improvement. However, the Network Weight update does not involve the consensus mechanism, so it can be modified again in subsequent common updates.
For the specific implementation of QIP-9, please refer to this document.
The Hard Fork Release Plan
The code for this hard fork has been fully developed and tested for nearly half a year and has been running successfully on private testnets. It has already been activated on Qtum Testnet at block height #446,320. After a period of stable operation on Testnet, it will be officially activated on Qtum Mainnet.
The update automatically activated at the pre-set block height, on Testnet at block 446,320 on September 20, 2019, and it will on Mainnet at block 466,600 on October 17, 2019. It is recommended that users keep the running wallet as the latest official release version so that the wallets will update smoothly.
The update only applies to the Qtum Core wallet and full nodes using the Qtum Core wallet. There is no change required for users of other QTUM wallets, such as Electrum, Ledger or the Qtum Web wallet.
Impact of Not Updating
When the block height is reached to activate the hard fork, the updated wallets will disconnect any peers that have not been updated. This means the older version nodes and wallets that have not updated will not be able to conduct transactions or stake onto the main chain. Instead, their transactions and staking will take place on a forked split chain that will gradually die out as those nodes are updated. Nodes on the split chain will see a very low Network Weight, and staking wallets may see a large number of block rewards as they stake onto the split chain. Since these staking transactions are committed to the split chain, at that point even after updating the wallet and resyncing the blockchain, the stakes will be missing, which means more advanced wallet recovery techniques will be needed.
Preparations
Qtum will notify all exchanges, service providers (wallets, explorers), stakers, and ordinary users to complete the update in advance of hard fork activation to ensure a smooth update.
The Qtum development team has carried out successful internal testing for half a year before the release. The update will be activated on Testnet a month before Mainnet, to further validate operations and verify the expected changes.
All users should keep their Qtum Core wallets/nodes updated to the latest version and be aware of the symptoms for problems described above (low network weight, excessive staking) if their wallets are not updated in advance.
Will There be a Hard Forks in the Future?
As long as the update is related to consensus, it may require a hard fork. At that time, users will be notified of the update through a similar process. The subsequent x86 virtual machine, private assets, and smart contract staking features that Qtum plans to release may require hard forks. Qtum development team will merge updates that require forks to minimize hard fork updates.
What Do Users Need To Do?
For continued operations and to avoid staking onto the split chain, all users running Qtum Core nodes/wallets need to update to the latest version of the wallet before the hard fork activation block height. Please keep an eye on https://github.com/qtumproject/qtum/releases/ or https://qtumeco.io/wallet for the wallet release information and update to the latest version as soon as possible.
For different participants in the network, it is recommended to be fully prepared for the upgrade:
Exchanges & Wallets
- Before and after the hard fork activation, please pay attention to deposit and withdrawal records of QTUM and QRC20 tokens, and confirm the transfer after the transaction has collected enough confirmations on Mainnet;
- For the withdrawal of QRC20 tokens, it is possible to upgrade the supporting program (QIP-5 related) in advance so that the new features can be used to pay gas fees.
Service Providers (such as Explorers)
- It is recommended to develop QIP-5 related support in advance to avoid being unable to identify the transaction output with OP_SENDER after the hard fork activation.
Stakers (mining pools, personal stakers)
- Before and after the update is activated, please pay close attention to the Network Weight and block rewards. Block rewards will increase as the average block interval drops to 128 seconds (600 blocks per day vs. 675 blocks per day currently).
Developers
- Contracts and applications with new features can be developed on Testnet first and then deployed on Mainnet when the main network is activated. (QIP-7).
- Consider more scenarios based on QIP-5.
Every User
- Always backup your wallets!
Website: https://qtum.org/
Telegram Group: t.me/qtumofficial
Twitter: https://twitter.com/QtumOfficial
Facebook: https://www.facebook.com/QtumOfficial/
