On the Origin of Qtum

Published in

On The Origin of Smart Contract Platforms

18 min readApr 7, 2018

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at how Qtum could challenge today’s dominant platform, Ethereum.

Qtum (pronounced Quantum) is a smart contracts platform designed to be Ethereum-compatible while addressing some perceived deficiencies of Ethereum such as scalability, lack of formal verification tooling, and lack of lite mobile solutions using simple payment verification (SPV). Qtum addresses these issues with a different underlying blockchain and consensus algorithm that Qtum believes will enable the platform to provide better support for lightweight mobile and Internet of Things (IoT) applications. The project aspires to become the “public blockchain for business” by bringing its technology to financial services, supply chain management, social media, gaming, and other industries in the future. By positioning itself as an Ethereum-compatible platform with several improvements, Qtum is directly competing with Ethereum to become the dominant smart contracts platform.

Qtum was founded in 2016 by Patrick Dai (AKA Steven Dai), Jordan Earls, and Neil Mahi. Their ICO, held in March 2017, raised approximately 15.6 million USD in just five days. The funds are managed by the Singapore-based Qtum Foundation, whose stated functions are to “oversee the development of the Qtum blockchain, to advocate governance transparency, and promote the safety and harmony of the open source ecosystem.” The Foundation and development team have quickly and consistently achieved delivery milestones. In June, 2017, just three months after the ICO, Qtum launched its first testnet, Sparknet, and followed with the deployment of a second, upgraded testnet, Skynet, two months later. On September 13, 2017 Qtum’s Ignition mainnet officially went live.

One of the reasons for Qtum’s fast track to launch is that, rather than building an entirely new blockchain from scratch, Qtum integrated open source code from the Bitcoin, Ethereum, and Blackcoin projects. Qtum is essentially an Ethereum-based smart contracts system running on top of a Bitcoin-based blockchain using a modified version Blackcoin’s Proof of Stake (PoS) implementation for consensus. Qtum has added a custom adaptation layer that maps Ethereum account balances to sets of Bitcoin Unspent Transaction Outputs (UTXOs).

This integration of existing systems has resulted in Qtum becoming the world’s first proof of stake smart contracts platform based on the UTXO transaction model. Qtum also became the first blockchain in space when the Singapore-based SpaceChain launched a satellite running a Qtum full node. At the time of writing, there were 25 decentralized applications (dApps) running in various stages (such as demo, prototype, live, and stealth) on the Qtum mainnet and about 5K transactions per day were being processed. Although Qtum is off to an impressive start, it still has a long way to go to catch up with Ethereum, which currently supports over 1000 dApps and processes about 700K transactions per day.

The remainder of this article will look in depth at Qtum’s technology and how it compares to Ethereum’s to illuminate how Qtum could pose a challenge to Ethereum’s position of dominance in the decentralized application space.

Performance

A common theme for improving on-chain transaction throughput among Ethereum challengers is replacing Proof of Work (PoW) with a faster PoS consensus mechanism, and Qtum is no exception. In keeping with the project’s apparent philosophy to not reinvent the wheel, Qtum chose to reuse an existing PoS algorithm from the Blackcoin project.

Unlike many of the Ethereum challengers we’ve looked at so far, Qtum’s PoS doesn’t use delegates or depend on voting; anyone staking QTUM can produce a block. This makes Qtum’s implementation even more inclusive than Ethereum’s plan for CASPER, since there is no minimum amount required to stake. However, a downside is that Qtum’s implementation has some of the same scaling limitations as Bitcoin’s PoW implementation.

Qtum’s PoS consensus works much like Bitcoin’s PoW consensus in that the right to produce a block is granted to the first staker who can produce a hash that is below a target threshold. This threshold gets lower (increasing the difficulty) as the power of the network increases, so that rate of block production remains relatively constant. The probability that any given staker will win the right to produce a block is proportional to the percentage of total network power they possess.

However, in Qtum, power is not determined by the number of hashes per second a staker can perform, but by the amount of QTUM they have staked. Rather than perform billions of hashes over slightly different inputs trying to find one below a fixed threshold, Qtum stakers perform one hash per UTXO they control over a fixed input (only the UTXO changes) to see whether or not the result falls below a weighted threshold. The threshold is weighted for each hash by the amount held in the UTXO being hashed so that UTXOs with higher amounts have a proportionally higher chance to win. If a winning hash is produced, the user broadcasts their block; if not, they simply stop hashing and wait for the next chance to play.

Every 16 seconds the fixed input changes, creating a new opportunity for stakers to generate new hash values for their UTXOs and see if any are winners. This is analagous to holding a lottery every 16 seconds, where each computed hash represents a weighted ticket. Each UTXO corresponds one unique ticket per lottery, and weighting ensures that splitting a high value UTXO into several smaller value ones will get you more tickets but not increase your chance of winning. The difficulty is set such that most lotteries do not have winners and a winning ticket is found only once every 128 seconds on average. Any lottery can produce multiple winning tickets and, as in Bitcoin, all rewards go to one winner while the rest get nothing.

An important consequence of adopting Bitcoin’s competitive winner-take-all lottery model is Qtum’s target block time for PoS must remain relatively high to keep the probability of multiple simultaneous winners very low. Otherwise, the competition results in too many forks and stale blocks. Producers of stale blocks are lottery winners that lose because they staked but received nothing. These races provide an unfair advantage to the most powerful and well-connected stakers that disincentivizes others from staking and ultimately leads to concentration of block rewards in the hands of a few stakers. Ethereum’s target block times are 10x faster than Qtum’s because when such races occur the block rewards are shared more fairly among the simultaneous winners, incentivizing them to keep mining. Faster block times equate to higher transaction throughput. By adopting Bitcoin’s consensus model for its PoS implementation, Qtum inherited Bitcoin’s primary scaling bottleneck and will struggle to achieve the transaction througput possible with other forms PoS.

Scalability

One of the primary changes Qtum makes to Ethereum is to implement account balances using UTXOs on a Bitcoin blockchain. Qtum’s choice to use Bitcoin core software was primarily driven by the network effects of being compatible with what they consider to be “the most mature, stable and secure blockchain” and leveraging all the benefits of innovation in a thriving ecosystem. However, the Qtum white paper also suggests some scaling benefit, “we consider the Ethereum account model to be a scalability bottleneck and see clear advantages of the Bitcoin-network UTXO model.”

The scalability benefit relates to the difference in how spending of an account balance works using Bitcoin’s stateless UTXOs vs Ethereum’s state-based balances. Transactions in both systems have inputs, which name sources of funds to be spent, and outputs, which name destinations of funds to be credited. In Bitcoin, transaction inputs point to UTXOs that named the spender as the destination of funds in some previously mined transaction. UTXOs are analogous to notes and coins that have accumulated in your pocket from previous transactions. Each has a specific value and when you spend them you might get some change back if, as often occurs, the sum of their values comes to more than the exact amount owed. In Ethereum, spending works more like a debit card where the transaction input is just the spender’s account, the output is the receiver’s account, and an exact amount is always transferred (i.e. no need for change). An account’s balance is stored as a single number that is updated in the blockchain whenever a transaction naming the account as input or output is mined. Transactions are ordered so that the balance available to each transaction is consistent and can be used to prevent overdrawing/double spending.

To see how this works in practice, let’s say Alice possesses four UTXOs in amounts 18, 16, 9, and 7, and she wants to send 20 to Bob. Her Bitcoin transaction could use the 16 and 7 UTXOs as inputs. Since the sum of the inputs is 23, the transaction would have an output of 20 to Bob and a second output of 3 to Alice (for change). Alice’s spending capability would be decreased by the two now-spent TXOs totalling 23 and increased by the one new UTXO for 3, resulting in a net of change of -20. Similarly, Bob’s spending capability would be increased by the one new UTXO for 20. In Ethereum, if Alice has a balance of 50 and wants to send 20 to Bob, she would just create a transaction specifying her account as an input, Bob’s account as output, and an amount of 20. Running the transaction would update the state of both accounts to show Alice’s balance is now 30 and Bob’s 20.[1]

Whereas Ethereum’s debit card model is simpler to implement, it has a scalability limitation in that all transactions involving an account must be executed and validated in a deterministic order, so that the initial account balance for each transaction is consistent across all nodes executing the transaction. The UTXO transaction model allows transactions involving the same account but not spending the same UTXOs to be run in parallel. In our Bitcoin example, Alice could send one transaction spending two of her four UTXOs (as above) and another spending the other two UTXOs, and because the transactions have no dependencies they could be processed in parallel without concerns for overdraft/double spending. In theory, this allows Qtum nodes to process more transactions per second by using multiple CPU cores to simultaneously process transactions that would otherwise need to be executed sequentially on Ethereum.

How much of a performance gain can be practically realized from the UTXO model will depend on how many opportunities to exploit parallelism exist. Since transaction outputs must be fully spent or not at all, it’s sometimes not possible to find mutually exclusive sets of UTXOs to create parallel spending transactions even when sufficient funds exist. For example, if Alice’s account controlled only two UTXOs in amounts 43 and 7, then it would be impossible to parallelize any two transactions spending more than 7. In such cases, Alice must use the change UTXO from one transaction as input to the other, thereby serializing the transactions and losing any scaling benefit.

Vitalik Buterin has pointed out that many Bitcoin wallet implementations fail to make the optimizations necessary to enable parallelization, effectively minimizing the benefits in practice. In a response to that very point, Qtum Founder Jordan Earls wrote: “This is fair, however, you should notice that Bitcoin does not encourage this optimization he said in any manner. […] Qtum doesn’t have a simple answer to this, but there is more to parallizability than parallel execution on the blockchain.” Earls goes on to describe a situation where offline wallets can generate parallel transactions using carefully assigned UTXOs, which essentially is just a manual implementation of the optimization that would only allow for parallelization if the wallets were synchronized to come on line and send their transactions simultaneously.

A key advantage of the UTXO model touted by Qtum is that, by enabling the use of Bitcoin’s Simplified Payment Verification (SPV) scheme, the platform can support a wider range of light client applications on mobile and IoT devices. Client applications using SPV can transact without having to download the entire blockchain or trust a centralized server. They can efficiently query the network for specific transactions they care about and can verify for themselves whether the responses they get are valid based on their own determination of the canonical block chain.

Whereas adoption of the UTXO model allowed Qtum to leverage existing implementations of SPV, it did not create any significant advantage for Qtum over Ethereum. Ethereum research on light client protocols suggests that UTXOs aren’t necessary to build clients light enough to run on mobile and IoT devices. Unlike Qtum’s SPV light clients, which are limited to transfers of the QTUM token, Ethereum light clients can track arbitrary state changes such as the transfer of ERC20 tokens. At the time of writing the Light Ethereum Subprotocol and Parity Light Protocol are fully specified and have been integrated into multiple Ethereum clients (in experimental mode). If/when the need for completely trustless light client applications arises, these protocols will enable such applications to be built on Ethereum.

Both Qtum and Ethereum are looking to leverage layer 2 protocols for massive scaling of transaction throughput. Qtum’s adoption of Bitcoin’s UTXO-based blockchain enables it to leverage existing implementations of the Lightening Network. The Lightening Network scales transaction throughput by allowing a large number of payments to be made off chain via payment channels, which are secured by a single on-chain funding transaction. As with SPV, the implementation is limited to payments using only the native QTUM token. Ethereum’s Raiden Network, a self-proclaimed work in progress, will someday enable the use of off-chain payment channels to transfer arbitrary ERC20 tokens.

Both Lightening and Raiden implement a single application, the trustless offchain transfer of payment. Generalized State Channels in Ethereum have been developed to enable the off-chain operation of any application, allowing multiple applications to leverage the same funding transaction. Each application has its own smart contract that encodes the rules of engagement over application-specific contract state (e.g. moves in a game of chess, determining the winner of a bet, etc.). The contract is not actually deployed to the blockchain, but participants act as if it was because each participant holds a copy signed by all parties that can be deployed if necessary to resolve a dispute. This is similar to how payment channels are settled, except instead of sending a signed agreement on channel balances to the blockchain, a signed agreement on application state and a contract that interprets that state to enact arbitrary state changes (payouts, awards, statistics, etc.) is sent. Currently, Ethereum lacks mature tooling and frameworks for building applications on Generalized State Channels, but these are being developed and there is at least one implementation that is slated to go live on the Ethereum mainnet in April 2018. By supporting Solidity smart contracts, Qtum will likely be able to leverage these implementations as they are deployed on Ethereum.

Governance

Like many of the Ethereum challengers we’ve looked at so far, Qtum aims to overcome perceived governance challenges in Bitcoin and Ethereum with an on-chain governance mechanism, which they call the Decentralized Governance Protocol (DGP). The specific issues DGP is designed to address include the Bitcoin community’s gridlock over a block size parameter and Ethereum’s hard forks adjusting gas prices to prevent Denial of Service (DoS) attacks.

DGP automates updating blockchain parameters, such as block size or gas price, without forking or requiring users to download new software. The intent isn’t to completely eradicate the need for forks, which, according to Qtum, would be necessary for significant changes or new features. However, automating cryptoeconomic parameter changes via DGP could allow Qtum to respond more quickly to DoS attacks and speed the pace of innovation by avoiding community gridlock in some cases.

The governance process is run by a set of governing parties, who may be people or smart contracts. The governing parties submit proposals to change network parameters. The proposals are stored in a standard, machine readable format such that the Qtum software can incorporate them in an automated fashion. If a proposal receives enough on-chain votes from governing parties, then the proposal becomes active in the current version of software without requiring users to download and run a new version.

Qtum will initially launch with a set of “trusted” people acting as governing parties. However, Qtum expects to outgrow this structure quickly, and outlines a scenario where the governing parties could vote on a “meta-proposal” to replace them with a two bodies, board members and core developers, that would both need to approve a proposal before it can be enacted. Qtum claims that DGP “is powerful enough that its governance structure can be completely replaced” through such meta-proposals, while at the same time emphasizing the system’s narrow focus on protocol parameter changes. It seems unlikely that fundamental changes such as replacing the underlying structure of the DGP could be automated by the DGP itself without some amount of off-chain coordination within the community.

Qtum envisions a scenario in which smart contracts can serve as governing parties. A simple smart contract could be used to incorporate votes from stakers and other users. A more complicated smart contract could monitor the network and generate proposals for parameter changes in response to certain conditions, such as too many full blocks. According to Qtum, such contracts would enable the blockchain to be “self-regulating, self-modifying, and self-aware.” Imagine a self-aware Bitcoin network that proposes a block size increase whenever it detects the past 10,000 blocks are 90% full. This is Qtum’s vision of the future of blockchain govenernance.

Whereas having a formalized mechanism for enacting changes can be useful, the key challenge of governance is to enact only the changes that are agreed upon by a sufficiently large majority of users. Determining what constitutes a sufficiently large majority is not straightforward and can depend on the situation. Both Ethereum and Bitcoin have experienced community splits over governance decisions that were supported by a significant majority of the community, resulting in the creation of the Ethereum Classic and Bitcoin Cash blockchains. Automation of upgrades may be useful for non-contentious changes, but when there is even a small amount of contention, automation of community splits may not be the best approach.

Automated community splits and other hazards of a “self-modifying” blockchain could be prevented, in theory, by the votes of governing party seats that are still held by people. However, this theory raises several important questions. Who are the people in governing party seats? How were they elected? Do they represent the wishes of the larger community? How easy is it to replace them when they don’t? At the time of writing specific answers regarding Qtum’s governing parties could not be found online. It’s reasonable to assume that, like most nascent blockchains, the governing parties will initially be appointed and later elected by some kind of vote involving community members. There are, however, numerous challenges with on-chain voting systems that would need to be overcome.

The problems with on-chain governance and coin holder voting have been discussed at length in thought pieces by Ethereum thought leaders Vitalik Buterin and Vlad Zamfir. Getting enough user interest and participation to ensure that votes are representative of the whole community is always a challenge. Representative democracy can give a small cartel of governing parties too much power to change the rules in their favor. The inevitability of cartel formation in a delegated on-chain governance system isn’t just theoretical; it has manifested as a real world problem for the Lisk community and vote buying continues to plague EOS.

The question of whether on-chain governance can work and in what form(s) remains open and is an important facet of the evolution of smart contract platforms. Much like real world governance, it seems we will learn slowly by trial and error. Whereas Ethereum may not have found a silver bullet solution to governance, they certainly have looked carefully at the various on-chain mechanisms being proposed and have thus far avoided falling into the traps of existing naive implementations.

Smart Contract Security

Smart contract security is the area in which Ethereum’s dominance is most vulnerable to disruption. Continued high profile attacks costing users hundreds of millions of USD are a sure path to extinction. In July, 2017 a popular Ethereum smart contract used in nearly 600 wallets to protect more than 500k ETH was exploited, resulting in the theft of over 150k ETH. A postmortem from the contract’s developer, Parity Technologies, outlined an extensive list of things Parity would do to ensure this wouldn’t happen again. Less than four months later, a second attack on the new and improved version of the contract froze all the ETH and other tokens held in all of the wallets using it.

It’s not that this one contract was uniquely buggy or its developers especially reckless. On the contrary, the contract was entrusted with a large amount of funds largely due to Parity’s reputation for smart contract expertise. Parity Technologies founder and CTO Gavin Wood, is one of the primary developers of both Ethereum and the Solidity smart contract language. The pedigree of Party Technologies team, the level of effort they devoted to securing the contract after the first hack, and the fact that thousands of other deployed Solidity contracts exhibit similar vulnerabilities suggest there is a more fundamental and systematic problem at play.

The common thread in the Parity wallet hacks as well as the famous DAO hack, which ultimately led to an Ethereum community split, was the ability for an attacker to call methods in ways the contract authors didn’t intend. These vulnerabilities arise commonly in Solidity code due to fundamental flaws in the language that make the behavior of, for example, reentrant and delegated methods surprising to developers. When significant funds are at stake, all potential suprises will be tested and any vulnerability exploited.

By being fully EVM compatible and supporting Solidity contracts Qtum inherits all of Ethereum’s smart contract security weaknesses. However, this compatibility does afford Qtum the opportunity to leverage all the innovation in the Ethereum community aimed at addressing them. There is currently a vibrant ecosystem of projects aimed at developing better code analysis tools as well as new, programming, languages that are more suitable for formal verification and static analysis that can detect bugs at the compilation stage. If, despite these efforts, users continue to experience Solidity exploits in which their funds aren’t successfully rescued by white hat hackers or returned by contentious hard forks, they may leave Ethereum, but they won’t be flocking to Qtum for its Solidity and EVM compatibility.

Qtum does plan to extend their smart contracts offering to include an x86 virtual machine that would enable the development of smart contracts in languages such as C++, Java, and Haskell. While this would allow Qtum projects to tap into a wider base of developers and leverage existing tooling, it doesn’t specifically address the security issues inherent to Solidity’s design. In fact, each new general purpose language supported comes with news ways to surprise developers and introduce vulnerabilities into smart contracts. Qtum founder and CTO Joran Earls identifies features such as “cooperative-multitasking, pause and resume execution (ie, resuming execution in a later transaction), and watchdog timers” as improvements the x86 VM could bring to Qtum smart contracts. These are among the most difficult programming constructs for developers to reason about, and would likely expand the attack surface of contracts that use them. Whereas some general purpose languages (e.g. Haskell) will be better suited to meeting the stringent security requirements for smart contract programming, others (e.g. C++) will be more unsuitable than Solidity for smart contracts managing valuable assets.

The Qtum white paper states that it is Qtum’s objective to develop a Qtum Smart-Contract Language (QSCL) that is claimed to be “backed by formal verification means.” No details are provided other than a reference to an academic paper from one of the white paper authors describing another language, developed by that same author, defining a “cross-organizational collaboration ontology.” Given the lack of information available about QSCL, it appears that Qtum has not and is not pursuing this initiative.

Conclusion

Qtum has made rapid progress by integrating the source code from multiple open source projects. They have successfully deployed a working blockchain based on Bitcoin UTXOs and Blackcoin PoS consensus that supports smart contracts compiled for the EVM. A handful of dApps are running in production on Qtum, and a Qtum node is running on a satellite orbiting the earth. Still, it is difficult to envision a scenario in which Qtum unseats Ethereum as the dominant smart contracts platform. Whereas EVM compatibility significantly lowers the cost of switching from Ethereum to Qtum, dApp developers still need some motivation to do so.

If users were to become spooked by continued high profile exploits of Solidity code they would most likely switch to platforms such as Cardano and Tezos that provide languages designed specifically to meet the security needs of smart contract programming. In such a scenario, Qtum’s offering of Solidity plus general purpose languages not designed for smart contract programming would be no less spooky than Ethereum’s.

If Ethereum’s scaling solutions such as sharding, plasma, and state channels don’t come soon enough to handle growing user demand, applications would likely move to platforms such as DFINITY and EOS offering significantly higher on chain througput from PoS implementations that provide synchronous, high frequency block production. Qtum’s PoS implementation, in which block times follow a Poisson distribution and need to be kept at low frequency, won’t be able to come close the throughput of those platforms without greatly sacrificing decentralization. If the Lightening Network succeeds on Bitcoin, why would it be used on Qtum? It wouldn’t be for Qtum’s smart contract capability because Lightening only provides a throughput increase for transactions that send simple payments in the platform’s native token, not the execution of arbitrary smart contract code.

If a large number of users decide to leave Ethereum over governance concerns, they would likely switch to an EVM-compatible platform such as DFINITY, whose on-chain governance model puts voting power in the hands of all users. Qtum’s DGP, which concentrates power in the hands of a few governing parties, would, even if it implemented user voting, likely face the same problems experienced by other platforms employing on-chain representative democracy without a solid plan to unseat cartels.

Qtum’s compatibility play may increase its chances of survival through coevolution with Bitcoin and Ethereum, but it also lessens Qtum’s chances for disruption. Unseating Ethereum as incumbent would require some disruptive innovation in scalability, governance, security or other aspect that is important enough to users that they would leave Ethereum for Qtum. At present Qtum’s technology has no such innovation, and the project does not seem to have any on the horizon.