Bitcoin-based blockchain with the Ethereum Virtual Machine and support for other virtual machines, connected by the Qtum (pronounced “Quantum”) Account Abstract Layer
Many cryptocurrency users and investors are heavily in favor of either Bitcoin or Ethereum, to the degree of being “maximalists.”
Maximalists believe that their favored coin will dominate the market and reach widespread adoption while all other cryptocurrencies ultimately die out — or just serve as testnets for the dominant coin.
Indeed, the BTC and ETH currencies are the top digital assets today, and very well may be for the foreseeable future. And yet Bitcoin and Ethereum are quite different, with different weaknesses and different advantages.
So, in 2016 a simple idea was born:
What if a cryptocurrency could have the advantages of both Bitcoin and Ethereum?
By March 2017, this idea of combining Bitcoin and Ethereum had become a successful ICO, and the product launched later in 2017.
Meet Qtum. Pronounced “Quantum.”
Qtum combines Bitcoin technology and Ethereum technology.
Over the course of The Ethereum Challengers, I’ve prefaced most of the Challengers with a summary of some related concepts. For example, we talked about Turing-completeness and sidechains with RSK, PoS and DPoS with EOS, and formal verification with Cardano.
Since Qtum (remember: read this as “Quantum” in your inner reading voice) pitches its platform as a combination of Bitcoin and Ethereum, let’s talk about the two major blockchain transaction models. Then, we’ll talk about other features of Qtum, including some recent announcements, and see how it stacks up against our seven big questions.
So, transaction models first. Bitcoin uses the UTXO model. Ethereum uses the account model. Qtum wants both.
UTXO Model (BTC) vs. Account Model
Have you ever sent BTC from one address to another, only to see in a block explorer that your account actually sent a much higher amount of BTC?
This is because of how the UTXO model works, and it’s not intuitive to someone used to an account model. In fact, it can be downright scary to see your address apparently sending more BTC than you told it to.
You’re used to an account model, where your personal account has a balance.
For example, your Ethereum address is also your Ethereum account. You can spend from your balance and receive payments to your balance.
While it is recommended to only use an address once — for reasons of privacy and security — in practice the account model incentivizes users to re-use an address, since that is the simplest way to spend.
Types of Ethereum accounts:
Ethereum has two kinds of accounts: accounts controlled by private key — which is what you have if you use ETH — and accounts controlled by contract code.
Private key accounts make and sign messages to send to other accounts, while contract accounts activate their code to do an assortment of things (including sending other messages, making contracts, and reading or writing to their own storage) when messages are received.
Note that "messages" in blockchain-speak include transactions.
Accounts use a balance management system that resembles a bank account.
But a UTXO (Unspent Transaction Output) model like Bitcoin’s is different.
A UTXO model is similar to how life would feel if you got paid exclusively in checks and just kept them around until you needed to spend them.
Just as you cannot cash a part of a check at a bank, but must cash the whole thing, in Bitcoin when an address receives certain amounts and later wants to spend some of it, it must spend all of it.
When you send BTC, you spend “vins” and create new “vouts.” UTXOs cannot be reused, so spending a vin by using it to create vouts destroys it.
So if you receive a UTXO vin of, say, 3.152 BTC, and then send 2.1 BTC, you actually must send the entire 3.152 BTC — in this case, as two vouts: ~2.1 to your recipient and ~1.052 to yourself. (Small mining fees reduce the actual numbers a bit.) The UTXO of 3.152 BTC you received is done and cannot be reused, but the BTC lives on in new UTXOs.
Behind the scenes, vout scripts (sends) you create require the permission of vin scripts. In other words, in order to spend money, you must have a valid check or checks that show you have received that money (or more than that) in the past, and the check must not be torn up.
So while with an account model, your balance is checked and debited and credited, that’s not how Bitcoin works.
Perhaps you’ve noticed this if you send BTC from a Ledger wallet to someone else and checked the transaction on a block exporer.
A seemingly arbitrary amount of BTC will be sent. The actual amount you’re sending goes to the recipient, while the remainder going to a new address that you control. The BTC you did not send to the recipient is still yours, but it gets sent to a new address.
This is because of how UTXOs work. Again, if you have received two UTXOs of 1.1 BTC and 0.8 BTC and you want to spend 1.3 BTC, both UTXOs will get “spent,” and the remainder will be sent to you as a new UTXO — in this case, 0.6 BTC, minus transaction fees.
Why in the world might this be better than a simple account balance system?
The UTXO model incentivizes users to limit their re-use of addresses, since BTC automatically gets sent to new addresses every time you spend it.
This is more secure, even against advances like quantum computing, because your public key is not revealed until you spend from an address. Your public address is a hash of your public key, not your public key itself, even though many people incorrectly use the terms interchangeably. Public keys and addresses are related but different things.
Once you spend from an address, though, that address’s public key is published to the blockchain, and thus is theoretically vulnerable to attack. It is now revealed. But even a successful attack on your public key is worthless if the balance of the address is empty — sent to a new address you control, with an unexposed public key — so when BTC sends the “change” to a new address, you regain the security benefit of an unknown public key.
Single-use addresses also have privacy advantages. This behavior of sending BTC around from address to address makes it harder to track an individual. The BTC itself can still be easily tracked, but in many instances ownership of the many addresses involved is difficult to determine.
Other coins have achieved similar or greater levels of privacy and security in other ways, allowing these advantages while also preserving the convenience of re-using an address. However, these coins have not been tested nearly as long nor as intensely as Bitcoin, and there may be unforeseen complications with their solutions.
If users of an account model cryptocurrency like Ethereum follow the recommended practice of only using each address once, they enjoy the same security and privacy benefits as those provided by UTXO. But in Bitcoin, users are more likely to follow this best practice since it is the default behavior.
These advantages did not apply to single-address wallets, which are no longer popular. Single-address wallets sent the “change” from UTXOs back to the same address.
They do apply to the other two major types:
1) Wallets with random new address generation, which are now also uncommon. The “change” from a spent UTXO was sent to a new random address when BTC was sent. This was risky, since if the wallet were lost, random addresses generated since the last backup would be lost, as well.
2) Wallets with deterministic address generation. The wallet you use today for BTC probably creates addresses deterministically. Hardware wallets and the Electrum desktop wallet, for example, are deterministic. They contain near-infinite pools of mathematically-generated addresses. These wallets send the “change” from a spent UTXO is sent to a newly generated address whenever BTC is sent.
Deterministic address generation is superior to random address generation since one seed can re-generate all of the same addresses, providing much better backup and recovery capabilities.
Bitcoin’s Simplified Payment Verification
One of the advantages of the UTXO model is SPV, Simplified Payment Verification, which allows clients to verify that a transaction was included in a block without needing to download and verify the entire blockchain.
In short, much less data is required to be fetched since UTXO outputs can be forgotten as soon as they are spent with compromising anyone’s funds.
Block headers are enough for verification as they can provide a Merkle branch as “proof of inclusion.” The idea behind SPV, though not all of the functionality, is described in Satoshi’s original whitepaper.
This lightweight verification method does have some risks, but various measures such as Bloom filters and connecting to multiple nodes instead of just one are used to mitigate the security issues that arise with this approach.
Otherwise, full nodes contacted by light Bitcoin clients could potentially 1) deceive those clients by pretending transactions do not exist or 2) obtain data needed to easily track Bitcoin users.
Combining Both Models: Qtum
Qtum runs on a UTXO model, along with its SPV capabilities, as its base, but adds the Ethereum Virtual Machine — and also support for other virtual machines, but we’ll get to that later.
In addition, though a UTXO model (BTC, BCH, LTC, and DGB are all examples of UTXO coins) cannot support refunding extra fees, Qtum can and does refund fees by creating new outputs. Setting a “gas limit” in Ethereum and getting a refund of any unspent gas only works because Ethereum is not running on a UTXO model. But Qtum has successfully enabled this refund functionality even though it is based on Bitcoin’s transaction model.
Running on Bitcoin allows Qtum to easily adopt Bitcoin developments such as SegWit and the Lightning Network, as well as future Bitcoin Improvement Proposals.
Running with Ethereum’s Virtual Machine allows for Qtum to support Turing-complete smart contracts, something that Bitcoin cannot support.
Why the Bitcoin Script Isn’t Enough
Bitcoin has only very limited smart contract ability — though RSK and CounterParty are working on enabling smart contracts on the Bitcoin blockchain, in different ways.
In particular, there is no loop functionality in Bitcoin’s scripting language. Code cannot execute multiple times depending on given variables. This and other things cripple the Bitcoin language from being able to fulfill all but the simplest of tasks.
So Qtum enables Turing-complete scripts on a Bitcoin code base — though not on the actual Bitcoin blockchain — by allowing the Ethereum Virtual Machine on top of Bitcoin code.
In order to do that, it needs a layer in between.
Qtum Account Abstract Layer
In order to make smart contract virtual machines and their account model work on Bitcoin’s account-less UTXO model, Qtum includes an “account abstraction layer.” As you might imagine, getting an account-based system to run on an account-less underlayer requires some complex work on the part of the AAL.
But the result gives users the advantages of UTXO and developers the advantages of the Turing-complete Ethereum Virtual Machine.
Opcode: The portion of a line of code that identifies what operation is going to be perfomed. Check out Bitcoin’s available opcodes here for other examples. These opcodes are all of the capabilities of the Bitcoin scripting language.
Solutions seeking to add smart contract capabilities to Bitcoin, such as RSK, usually need a couple of new opcodes, requiring Bitcoin to upgrade its code.
Qtum doesn’t need a Bitcoin fork to add new opcodes since it has forked Bitcoin’s code into a new project and thus was able to simply add the new opcodes on its own.
Qtum still uses the Bitcoin Scripting Language, but three new opcodes enable virtual machines to run on top of this base.
- OP_EXEC: Executes specific Ethereum Virtual Machine bytecode.
- OP_EXEC_ASSIGN: Same as above, and can include a contract address and data for the contract. It optionally transfers money to a smart contract.
- OP_TXHASH: Pushes the ID hash of a currently executed transaction.
Qtum must allow smart contracts to execute immediately when added to the blockchain, so the first two opcodes are processed with special priority.
With the addition of these opcodes and its Account Abstract Layer, Qtum successfully allows the Bitcoin code base to support the Ethereum Virtual Machine.
Now any Ethereum applications can run on Qtum instead and enjoy the benefits of a UTXO base.
But wait … there’s more.
Proof of Stake, Templates, and Backwards Compatibility
Qtum’s implementation of Ethereum’s Virtual Machine does not mean that it includes the limitations of Ethereum.
Ethereum, like Bitcoin, is built on Proof of Work. Nodes expend large amounts of energy to solve very difficult puzzles first and claim mining rewards. We discussed consensus models including Proof of Work in episode 2, on EOS.
Qtum is instead built on a Proof of Stake model that originated with Peercoin (PPC), the first cryptocurrency to go live with a staking model.
A Proof of Stake consensus model allows Qtum to run without high computing power demands and with a higher number of transactions per second.
If you’d like to read about Proof of Stake in detail, especially in comparison with Proof of Work, I recommend this article by a member of the Ethereum team. Admittedly, many other currencies have since moved to Proof of Stake, and Ethereum plans to do so in part or in full at some point.
Qtum is also implementing templates to ease dApp development — something that is a large focus of alternatives such as NEM and is also being brought to Ethereum through projects such as Crowd Machine.
Qtum does offer one feature that, unlike PoS and templates, Ethereum will most likely never have: backwards compatibility. Qtum nodes can participate in consensus even if they’re not completely updated to the latest version of Qtum.
The Qtum X86 Virtual Machine
The Qtum AAL most famously allows for the Ethereum Virtual Machine, but it also allows for other virtual machines.
On May 23, just a couple of weeks before this writing, Qtum gave a presentation in South Korea on the Qtum X86 Virtual Machine. The X86 VM allows developers to work in many different programming languages. C and C++ were mentioned as already included, with others like Rust, Python, and Go on the way.
The current Qtum roadmap places X86 integration at late 2018.
Qtum Enterprise (Qtum X)
Qtum Enterprise (Qtum X), also described in the same May 23 session, is a new initiative designed to appeal to businesses. Qtum X will be a Proof of Authority system that allows for many more transactions per second.
Qtum X and Qtum are separate products, at least for now. I haven’t been able to find any information yet on whether the two products will be interoperable, i.e. whether they will share the same currency.
It is probably too soon after the announcement to expect many details yet, especially in English, so I would appreciate any readers in the know reaching out if they have more information.
Connecting to the World
In addition to Qtum X and the X86 Virtual Machine, Qtum has a number of other projects in the works designed to attract developers and businesses to the Qtum ecosystem.
APIs. Templates. A full-featured SDK. Atomic swaps. Qtum satellites.
Atomic Swaps: Trading one cryptocurrency for another without any third party involved. In a typical atomic swap, a time-locked smart contract is initiated on one blockchain. The transaction is then cancelled if the other party does not deliver the currency being traded for within a set time period.
Yes, I am not kidding about the satellites. Like Nexus, Qtum plans to launch satellites, in collaboration with SpaceChain. It seems that unlike the former, which is after censorship resistance, Qtum is mostly pulling a publicity stunt at this stage — as they put it, an “undisputed demonstration of our resolve to be the leading cryptocurrency and blockchain platform in the world.”
Alright, let’s bring things back to Earth.
How does Qtum answer our seven big questions?
As it is built from Bitcoin and Ethereum, Qtum doesn’t have a high number of transactions per second. Proof of Stake helps, and SegWit has been implemented, boosting TPS to about 60. As of the last information I saw, Qtum’s future scalability developments may include off-chain channels and/or a feature similar to Ethereum’s proposed sharding.
Qtum Enterprise (Qtum X) will use Proof of Authority to enable a much higher transaction throughput. It is unclear how or whether the Qtum X and Qtum will be integrated at this point, but enterprises may be interested in Qtum X due to its scalability advantages.
Proof of Stake for Qtum, originally built on PeerCoin’s pioneering PoS code. Qtum does have a Decentralized Governance Protocol (DGP). Qtum X will run on Proof of Authority.
The Qtum Blockchain Foundation directs decisions outside of the scope of the DGP.
3. Development Complexity
Though Qtum can use Ethereum’s EVM and Solidity, the new Qtum X86 Virtual Machine will allow C and C++ and late other languages such as Ruby, Go, and Python. Qtum’s EVM is always backwards-compatible, unlike Ethereum’s.
eSML is a planned language for Qtum with formal verification ability. We discussed formal verification in episode #3 (Cardano), as formal verification is a major focus of Cardano. To be fair, some third-party solutions and possibly the upcoming Casper will bring formal verification to Ethereum, too.
Qtum is live, and the new X86 Virtual Machine will be integrated later this year. The Qtum X (Qtum Enterprise) project timeline is still unclear as of this writing.
5. Generalized Features
As mentioned above, templates are planned to provide generalized features to app developers, reducing repetitive work and propensity for error. Beyond this, generalized features have yet to emerge. I would not be surprised to see a number of interesting features as the X86 Virtual Machine is integrated.
Several basic Qtum adoptability features are in place, such as Ledger wallet integration, but as the business-focused Qtum X is still early in development, I suspect we won’t know how user-friendly the ultimate Qtum dApp ecosystem is until later in the game.
Qtum does have transaction fees, though like Ethereum’s fees they may ultimately be abstracted away from users by businesses. I have not found information about plans for human-readable address on Qtum.
7. Market Position
As far as I can determine, Qtum does not have as large a developer community or broader community as most solutions we’ve discussed so far. Nevertheless, there are a few dApps and ICOs running on Qtum. If the Qtum Blockchain Foundation can quickly implement the planned X86 VM, Qtum X, and more features while stepping up Qtum marketing, it may position them to become a strong Ethereum challenger.
Of course, as we move farther down the list by market cap, we should expect to see projects which are at an earlier stage. They simply don’t have as much buzz as top projects — nor as much money.
Qtum brings many of the advantages of other smart contract platforms to the table, along with a few focuses of its own. So despite my loud opinion that Qtum really needs a new logo, I’m excited to watch where the project goes.
After all, in episode 4 on NEO, we discussed how Chinese projects tend to do better in China than foreign projects do. Much better, in fact. A strong advantage in China may turn Qtum into a serious challenger for Ethereum.
Like all of the platforms in this series, I’ll be closely following Qtum as the X86 VM and Qtum X launch.
If you learned a few things, make sure you check out the rest of the Ethereum Challengers series, starting with RSK. We still have challengers like Lisk, Stratis, Komodo, and CounterParty ahead of us, plus a final episode defending Ethereum’s chances.
But first, tune in next week for Ethereum Classic. See you then.