Qtum is on the move with the announcement of a partnership with Baofeng to begin running 50,000 full Qtum nodes and an upcoming x86 VM to support multiple languages for smart contracts.
Qtum is a hybrid of Bitcoin and Ethereum that is based on proof-of-stake consensus instead of proof of work, and is compatible with existing Ethereum contracts as well as Bitcoin gateways. Supporting the Ethereum Virtual Machine (EVM) wasn’t enough for Qtum co-founder Jordan Earls, who has been working on an x86 Virtual Machine for the Qtum system.
Earls comments that a great reason to build a x86 VM is to add more programming language support for smart contracts, his favorite being Rust. The overall list of objectives is much bigger though:
- Programming Language Support
- Standard Library
- Optimized Gas Model
- Unlock the full power of the Account Abstraction Layer (AAL)
- New possibilities for smart contracts
- First-Class Oracles
- Blockchain Analysis
- Alternative Data Storage
- Explicit Dependency Trees
Bitcoin Magazine spoke with Earls with some more in depth questions about some of those items:
Bitcoin Magazine: What proof of concept or scalability testing have you done for the VM?
Jordan Earls: We have a very rough proof of concept we completed a few months ago where we integrated a prototype x86 VM into the Qtum network. This success is what led us to pursue this plan. We are confident that the x86 VM will be more scalable than the EVM, but we are thus far unsure how much. We are designing the VM and all of its APIs and other aspects to be scalable. We are making a big shift in the smart contract world where we actually reward smart-contract developers (in the form of cheaper gas costs) for limiting the features their smart contract has access to, and we are confident it will be faster than current EVM technology.
Bitcoin Magazine: What are you doing to address the problem with x86 programming in general, where they assume near infinite memory and CPU time being available?
Jordan Earls: We think smart contract development crossed with this x86 paradigm will resemble something similar to real-time or embedded programming, where there are various constraints that developers must always be optimizing for.
We foresee the same kind of design optimizations happening in the smart contract world as happen in the embedded world, and, for the first time, Qtum’s blockchain will allow for these small optimizations to be directly rewarded for all users of the smart contract.
We know these optimizations are not cheap for smart contract developers to spend their time on, so we need to reward developers for taking such steps to keep the Qtum blockchain running smoothly and efficiently.
Bitcoin Magazine: What are some of the advantages with the Standard Library that will help keep smart contract code tight?
Jordan Earls: Currently in Ethereum, if you want to do a simple operation, like testing if two pieces of text are equal, you need to write your own code to do it.
This is a problem for a number of reasons: Developers in a secure context should rely on existing code that’s been tested and verified, if possible. A naive implementation of this function will be slow, but a more complex and optimized implementation could have security problems. Deploying this code with your contract means another 100 bytes or so of wasted code that every node in the ecosystem now has to worry about.
Qtum will provide a standard library of functions that contract developers can rely on to have reasonable gas costs, secure and validated implementation and an easy to use interface. This means less bloat on the blockchain, easier to write and understand smart contracts and even a faster blockchain (since these functions can be optimized with native code)…