The principles are listed below:
1. Create an entirely new kind of smart contract called Master Contract that can execute a contact triggered by off-chain and on-chain factors;
2. Achieve compatibility with different blockchain technologies;
3. Allow industry focused consensus mechanisms for public blockchain;
4. Take regulations into consideration and provide an Identity module;
5. Interact with the real world by executing Master Contracts triggered by off-chain inputs. Moreover, the Qtum blockchain provides a modular design and usability concept.
For the convenience of development and maintenance, Qtum is divided into three modules:
Qtum UI and
They provide different versions of the Qtum system – even mobile services for all operating systems and development requirements. They highly encourage third party developers to work with us to facilitate the implementation of blockchain technology that will benefit more.
Qtum pays more attention to the practical applications of smart contracts. It introduces Oracle, Data feeds and an Identity Module from third parties to fulfill the compliance requirements from traditional Internet enterprises, including finance, IoT, etc.
The Qtum smart-contract framework that aims for sociotechnical application suitability, the adoption of formal semantics language expressiveness, and the provision of smart-contract template libraries for rapid best-practice industry deployment.
While Qtum uses the Ethereum Virtual Machine (EVM) for a current lack of more suitable alternatives, the EVM has deficiencies such as earlier experienced attacks against mishandled exceptions and against dependencies such as for transaction-ordering, timestamps, and so on. It is also desirable for a smart-contract system to achieve industry-scalability with employing
sidechains and unspent transaction outputs (UTXO), achieving compatibility to other blockchain systems such as Bitcoins, or Colored coins. Furthermore, an adoption of features from the Bitcoin Lightning Network yields scalability via bidirectional micropayment channels.
One of the primary goals of Qtum is to build the first UTXO-based smartcontract system with a proof-of-stake (PoS) consensus model. The latter means the creator of the next block is chosen based on the held wealth in cryptocurrency. Thus, blocks are usually forged, or minted instead of being mined, there are block rewards in addition to transaction fees and forgers receive a percentage of ”interest” for the amount of funds they stake.
Qtum is compatible with the Bitcoin- and Ethereum ecosystems and aims at producing a variation of Bitcoin with Ethereum Virtual Machine (EVM) compatibility.
Note that differently to Ethereum, the Qtum EVM is constantly backwards compatible. Pursuing a pragmatic design approach, Qtum employs industry use cases with a strategy comprising mobile devices. The latter allows Qtum promoting blockchain technology to a wide array of Internet users and thereby, decentralizing PoS transaction validation.
The Ethereum account model has scalability bottlenecks. There are advantages for the Bitcoin-network UTXO model.
Qtum Contract and EVM Integration
The EVM is stack-based with a 256-bit machine word. Smart contracts that run on Ethereum use this virtual machine for their execution. The EVM is designed for the blockchain of Ethereum and thus, assumes that all value transfer use an account-based method. Qtum is based on the blockchain design of Bitcoin and uses the UTXO-based model. Thus, Qtum has an account abstraction layer that translates the UTXO-based model to an account-based interface for the EVM. Note that an abstraction layer in computing is instrumental for hiding the implementation details of particular functionality to establish a separation of concerns for facilitating interoperability and platform independence.
EVM Integration: All transactions in Qtum use the Bitcoin Scripting Language,
just like Bitcoin.
In Qtum however, there exist three new opcodes.
– OP_EXEC: This opcode triggers special processing of a transaction (explained below) and executes specific input EVM bytecode.
– OP_EXEC_ASSIGN: This opcode also triggers special processing such as OP_EXEC.
This opcode has as input a contract address and data
for the contract. Next follows the execution of contract bytecode while passing in the given data (given as CALLERDATA in EVM). This opcode optionally transfers money to a smart contract.
– OP_TXHASH: This opcode is used to reconcile an odd part of the accounting abstraction layer and pushes the transaction ID hash of a currently executed transaction.
Qtum however, must accommodate smart contracts that execute immediately
when merged into the blockchain. Qtum achieves this by the special processing of transaction output scripts (ScriptPubKey) that contain either OP_EXEC, or OP_EXEC_ASSIGN. When one of these opcodes is detected in a script, it is executed by all nodes of the network after the transaction is placed into a block. In this mode, the actual Bitcoin Script Language serves less as a scripting language and instead carries data to the EVM. The latter changes state within its own state database, upon execution by either of the opcodes, similar to an Ethereum contract.
A Qtum-blockchain deployed smart contract is assigned and callable by its address and comprises a newly deployed contract balance set to zero. There is currently no protocol in Qtum that allows a contract to be deployed with a non-zero balance. In order to send funds to a contract, a transaction uses the OP_EXEC_ASSIGN opcode.
Value Proposition of the Qtum Framework
The root of the goal for the Qtum-framework is the value proposition of cross organizational information- and value-transfer logistics automation.
Qtum Smart-Contract Language
To support the VTP (value-transfer protocol) scenario, the current smart-contract lingua franca Solidity does not have the required utility level with respect to contained concepts and properties. Instead, it is the objective to develop a Qtum smart contract language (QSCL) and compiler that has comparatively better utility for VTP management.
Qtum is more efficient and scalable and backward compatible
Qtum-framework is a novel smart-contract blockchain-technology solution. We show the specific Qtum transaction-processing implementation that uses proof-of-stake validation. Furthermore, Qtum integrates the Ethereum virtual machine (EVM) together with the Bitcoin unspent transaction output protocol. Note that the Qtum EVM constantly remains backwards compatible. Additionally, the Qtum-framework recognizes that smart-contract lifecycle management is important for supporting proper security vetting of collaborating parties. To support Qtum lifecycle management, the current lingua franca Solidity lacks suitability. Consequently, the emerging Qtum-framework requires a novel smart-contract language with enhanced utility.
The adoption of proof-of-stake into Qtum constitutes a considerable saving
of computational effort over the not scaling Ethereum alternative that still uses proof-of-work. While Ethereum plans to also adopt proof-of-stake, it is unclear when such a new version will be released. Also the use of unspent transaction outputs is more scalable in comparison to the account management of Ethereum. In combination with simple payment verification, Qtum already develops a smart contract mobile-device solution. While the not scaling Ethereum solution does not allow for mobile solutions, Qtum aims to achieve a democratized and highly distributed proof-of-stake transaction validation with its mobile strategy.
The Qtum-framework has a clear understanding of quality criteria that future
developments must satisfy. With respect to functional requirements, Qtum plans to develop an application layer for smart-contract lifecycle management. Most importantly, such lifecycle management is important for vetting collaborating parties to reduce security breaches such as those Ethereum recently experienced, resulting in multiple hardforks of the latter.
In the Qtum blockchain, the Contract Ledger stores all smart contract content in a readable format. It allows users to download the code and contracts in a peer-to-peer network based on their own interests. The Contract Ledger provides greater transparency, readability, and audibility.
In the Ethereum network, only data obtained on the blockchain can be used as a trigger to execute the smart contract. However, one of the most remarkable
innovations of Qtum is that off-chain factors can also be the trigger. For such contracts, Qtum will refer to them as Master Contracts.
Glossary of Blockchain and Smart Contract Terms
1. Bitcoin: A cryptocurrency and a payment system invented by an unidentified programmer, or group of programmers, under the name of Satoshi Nakamoto.
2. Ethereum: A public blockchain-based distributed computing platform, featuring smart contract functionality.
3. Value Transfer Protocol: A protocol that allows the secure transfer of value from peer to peer.
4. Internet of Things: The Internet-connected of physical devices, vehicles, buildings, and other items, embedded with electronics, software, sensors, actuators and network connectivity that enables there objects to collect and exchange data.
5. Oracle: A machine or a program which can select appropriate data inputs based on pre-defined rules.
6. Data feeds: Contracts on the blockchain that serve data requests by other contracts.
7. PoS: Proof of Stake is a consensus algorithm that relies on coin ownership to achieve distributed consensus.
8. UTXO: Unspent Transaction Output.
9. Smart Contracts: Smart contracts are computer programs that autonomously execute the terms of a contract.
10. Altcoin: Altcoins are cryptocurrencies other than Bitcoin.
11. PoW: Proof-of-Work is a consensus algorithm that produces a piece of data which is difficult to produce but easy for others to verify and which satisfies certain requirements.
12. Public chain: A blockchain which can be used and accessed by the public.
13. Ethereum Virtual Machine: EVM is a virtual machine designed to be run by all participants in a peer to peer network. It will only execute code when it receives a message verified by a digital signature.
14. IPoS: Incentive Proof of Stake, a combination of PoS, incentives, and estimation of online nodes.
15. Hard-fork: A permanent divergence in the blockchain, commonly occurs when non-upgraded nodes cannot validate blocks created by updated nodes that follow newer consensus rules.
16. DAO: A decentralized autonomous organization, running through rules encoded as smart contracts.
17. Turing complete language: A language that can simulate the computational aspects of any real world general-purpose language.
18. Colored Coins loosely describes a class of methods for representing and managing real world assets on top of the Bitcoin Blockchain.
By : Nextbigcoins.io
Sources – Qtum.org, Qtum White papers