Qtum Roadmap Breakdown

  • qtum team

    alt text

    Qtum Roadmap Breakdown:

    Subsection 1:

    Potentially incomplete GUI, full RPC methods for contract interaction

    A potentially incomplete Graphical User Interface (GUI) refers to the ‘frontend’ Qtum wallet. A Daemon is essentially a ‘service’ that runs on a server, it’s usually shortened to “D” meaning that Qtum Server or Quantum “Daemon” would be shortened to simply “QtumD”. The GUI is a wrapper that contains a compiled binary of the Qtum source code. This is usually done using the QT framework, allowing users of various operating systems to complete tasks, such as: transfer tokens, control smart contracts, create new accounts, etc. Some operations will not have graphical functions, these are usually RPC commands that require a console view, and will be operated using command line interfaces, such as viewing the network difficulty.

    When the Qtum source code is compiled and permissions are assigned, the Daemon process can be started. This allows the entity running this to call on RPC commands, which are defined as “Remote Procedure Calls”. Many people who use Bitcoin wallets may not realize they already use these calls frequently, when they send and receive coins in their QT wallet. The purpose of a GUI wallet is to eliminate having to compile source code and having to learn the various RPC functions. The nature of UTXO blockchains allows Qtum to be very familiar to users who have experience with Bitcoin and other projects that fall into its family, like Litecoin.

    This section of the Roadmap states that the Qtum testnet will be ready to compile, with full RPC methods for interraction with Smart Contracts that interract with the EVM (Ethereum Virtual Machine).

  • qtum team

    Subsection 2:

    Designed for developers, not consumers

    Stability is not the major concern at this point, the point of a Test Network is to find issues and improve the code, thus leading to a stable release. The Qtum developers will give test tokens to any interested party, allowing them to implement their ideas, and have the gas to execute contracts. These test tokens will hold no value and are not the same as the tokens which will be given to participants of the crowdsale.

    Interested parties that have been planning to develop on the Qtum platform will now be able to learn and test their ideas. Service providers, who have developed their own products, can start to explore if they will have to modify their systems to provide Qtum.

    For example, if an exchange would like to list Qtum, there are so many factors that come into effect. They need to make sure their accounting systems are compatible with the various RPC calls, and may need time to adjust their platforms.

  • qtum team

    Subsection 3:

    Should be stable, but features and RPC layer subject to change from community feedback

    The Qtum Test Network is a lead up to the Main Network release. It’s designed to attract interested developers. Service providers that plan to adopt Qtum into their business model will be able to analyze the code so they are prepared for the Main Network release in September 2017.

    The RPC layer mentioned in this section is the same part 1, but this section is about the RPC commands directly related to calling on the Qtum Daemon. Some of the typical BitcoinD calls, like “setgenerate” will obviously be removed, as this allows the user to mine for tokens with their computer, which is not needed for Qtum. The standard RPC commands will be available, but the Qtum developers may choose to add some that BitcoinD does not currently have. This is the best time for third party developers to make suggestions.

  • qtum team

    Subsection 4:

    SPV extended to support syncing contract state without full chain download

    The Simple Payment Verification protocol was created before the Ethereum Virtual Machine, so it needs to be extended to allow interaction with Smart Contracts, and to allow verification and validation of a contract’s state. In order to release a wallet that does not require the entire blockchain to be downloaded (only the headers) and can control a Smart Contract, the wallet needs to synchronize the Qtum contract state.

    The SPV protocol does not keep track of Smart Contract State, which is paramount to our goal here. This addition to SPV allows developers to create wallets that can validate both transactions and smart contract state, by only downloading the block headers and the interesting transaction or contract state data.

Log in to reply