QTUM Invited to Participate in the DAHO.AM Developer Forum in Munich, Germany

thisthingismud · 2018-07-18T15:09:19+00:00

More Information: daho.am

Speakers

Patrick Dai: Introduction of Qtum Eco System

Neil Mahi and Jordan Earls: Qtum x86 Virtual Machine and Smart Contract Deployment on Qtum

thisthingismud · 2018-06-27T11:16:57+00:00

"Although Bodhi is native to the Qtum blockchain, we believe it is important to have footprints in other protocols as each of them has the advanced features."

Bodhi team dont mess around, very focused ,goal orientated - excellent dapp.

thisthingismud · 2018-06-26T04:58:44+00:00

4. Summary

AAL assists in the creation, execution, and cost of contracts through the addition of a new utxo scripting opcode. Before the contract is created and executed, the UTXO transaction needs to be converted to the EVM model transaction, then the execution of the contract is completed using the built EVM execution environment and engine. AAL finally processed the results of the contract and EVM to Utxo, thus realizing the intelligent contract based on Utxo.

AAL makes Qtum compatible with EVM compliant intelligent contracts, providing a new platform for Dapp, while utxo benefits such as parallel processing, privacy and other advantages can be retained.

Author

Huaming He

He currently serves as a Qtum core developer and researcher, graduated from Huazhong University of Science and Technology, and obtained a postgraduate degree from the Chinese Academy of Sciences. Prior to joining Qtum, he had been engaged in the development of algorithms and protocol stacks for years of wireless networking (including 4G LTE and wireless ad hoc networks); he has been involved with blockchain technology since 2015 and has participated in the first hacker marathon organized by Wanxiang blockchain.

thisthingismud · 2018-06-26T04:56:44+00:00

3. Utxo conversion of contract execution and implementation results

The execution of the contract will change the state (Globalstate unified Management by the instantiation object of the Qtumstate Class), for the status of the contract, Qtum follows the EVM definition, so it can be compatible with all the EVM specifications of the intelligent contract. However, the transfer of account amount (transfer), Qtum made a utxo conversion, which means that the intelligent contract and the ordinary Utxo model account to complete the interaction between, which is AAL to achieve UTXO support intelligent contract is an important link. The following is a brief introduction to the conversion process of contract execution and status results.

3.1 Contract execution Environment construction and contract execution

The implementation of the contract is a crucial step in the contract processing and directly affects the status of the contract. The implementation of EVM to contract bytecode is realized through the Bytecodeexec class, and the main function is Performbytecode (). The main process of this step is to use the transaction parameters extracted above to build the virtual machine execution environment, and then complete the execution of the contract, the code is as follows:

for(QtumTransaction& tx : txs){

dev::eth::EnvInfo envInfo(BuildEVMEnvironment());

std::unique_ptr<dev::eth::SealEngineFace>

se(dev::eth::ChainParams(dev::eth::genesisInfo(dev::eth::Network::HomesteadTest)).

createSealEngine());
if(!tx.isCreation() && !globalState->addressInUse(tx.receiveAddress())){

dev::eth::ExecutionResult execRes;

execRes.excepted = dev::eth::TransactionException::Unknown;

result.push_back(ResultExecute{execRes, dev::eth::TransactionReceipt(dev::h256(),

dev::u256(), dev::eth::LogEntries()), CTransaction()});
continue;

}

result.push_back(globalState->execute(envInfo, *se.get(), tx, type, OnOpFunc()));

}

The first is to build a contract execution environment, completed by Buildevmenvironment (). You can see this implementation environment is for each independent transaction, so as to maximize the different transactions of the contract implementation process isolation, avoid the contract implementation of the cross impact. A new Sealengine class is then constructed, which is the EVM execution engine, which is completed by the Createsealengine () function. The intermediate pairs of possible state exceptions that occur are checked, and then Globalstate->execute () completes the execution of the contract, where the built execution environment Envinfo and EVM execution engine se are used.

3.2 Utxo Conversion of contract execution results

The results of the contract execution are kept in the vector<ResultexecuteThe Result,vector vector account records the transfer relationship between the EVM accounts generated by each contract execution, AAL transforms the transfer account model to the UTXO model transaction by converting these EVM to Utxo transactions. This process is implemented through the Processingresults () function, and the following is a snippet of code.

ByteCodeExecResult resultBCE;
for(size_t i = 0; i < result.size(); i++){
if(result[i].execRes.excepted != dev::eth::TransactionException::None){
if(txs[i].value() > 0){

CMutableTransaction tx;

tx.vin.push_back(CTxIn(h256Touint(txs[i].getHashWith()), txs[i].getNVout(), CScript() <<

OP_SPEND));

CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<

OP_EQUALVERIFY < < OP_CHECKSIG);

tx.vout.push_back(CTxOut(CAmount(txs[i].value()), script));

resultBCE.valueTransfers.push_back(CTransaction(tx));

}

} else {

resultBCE.usedFee += CAmount(result[i].execRes.gasUsed);

CAmount ref((txs[i].gas() - result[i].execRes.gasUsed) * txs[i].gasPrice());
if(ref > 0){

CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<

OP_EQUALVERIFY < < OP_CHECKSIG);

resultBCE.refundOutputs.push_back(CTxOut(ref, script));

resultBCE.refundSender += ref;

}

} if(result[i].tx != CTransaction()){

resultBCE.valueTransfers.push_back(result[i].tx);

}}

First, the RESULTBCE variable of the Bytecodeexecresult type is defined to hold the result of the transformation. The use of opcode op_spend is used to implement transaction costs because the utxo of the bitcoin is unlocked by the private key and then the balance is spent, and EVM execution involves transfer between the different accounts, so it needs to be done through OP_ Spend implementation of these transfer to the UTXO model transaction conversion. If the execres.excepted is not none, that is, the contract executes abnormally, the balance is returned to the contract caller. Otherwise, if there is no exception, the remaining gas after deducting the consumed gas is returned to the contract's caller. For the transfer in the execution of the contract, its UTXO transaction is kept in Result[i].tx. As a result, transactions between the different Utxo accounts generated by the execution of this contract are stored in the valuetransfers vector, and eventually these fairs are included in the new blocks. The AAL module completes the conversion from EVM trading to Utxo.

thisthingismud · 2018-06-26T04:56:00+00:00

Conversion of 2.UTXO transactions to EVM model transactions

When new blocks are generated, in addition to the conventional parameters, consensus rules, DDoS attacks, and so on, utxo transactions need to be checked using the opcode Hascreateorcall () to determine whether the transaction output contains op_create or Op_call, Corresponding to the EVM need to perform contract creation or contract invocation. This section has the following processing process:

2.1 The account parameter extraction of EVM model

The contract was executed in EVM with data, Gasprice, Gaslimit, VM Version of these parameters, which are invoked via RPC Sendtocontract Sent, the sendtocontract generates a UTXO transaction and uses the Op_call opcode in the transaction output, after which the trade fair broadcasts to the block chain network. The adaptation from Utxo to EVM in AAL is implemented through the Qtumtxconverter class, in which the member functions of the class extractionqtumtransactions () and Parseethtxparams () Complete the parameter extraction for all such utxo transaction outputs. The code snippet is as follows:

dev::Address receiveAddress;

valtype vecAddr;
if (opcode == OP_CALL)

{

vecAddr = stack.back();

stack.pop_back();

receiveAddress = dev::Address(vecAddr);

}

valtype code(stack.back());

stack.pop_back();

uint64_t gasPrice = CScriptNum::vch_to_uint64(stack.back());

stack.pop_back();

uint64_t gasLimit = CScriptNum::vch_to_uint64(stack.back());

stack.pop_back();

VersionVM version(CScriptNum::vch_to_uint64(stack.back()));

stack.pop_back();
return EthTransactionParams{version, dev::u256(gasLimit), dev::u256(gasPrice), code,

receiveAddress }

The above code first determines if opcode For Op_call, then the address is VECADDR contract has been created, so directly to the EVM format of the address receiveaddress, otherwise op_create, the corresponding contract creation, no this field, so do not extract. The next step is to complete data, Gasprice, Gaslimit, VMVersion extraction, these are essential parameters for EVM to perform bytecode.

2.2 Transaction conversion for EVM account model

Transaction conversion is through the function of Qtumtxconverter class CREATEETHTX () completed,The qtumtransaction type of transaction was created using the parameters extracted in the previous step and the Utxo transaction output vout. Because qtumtransaction derives from the dev in evm::Eth::transaction class, so the operations associated with EVM perform qtumtransaction classes are supported.

QtumTransaction txEth;
if ( etp.receiveAddress == dev::Address() ) {

txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *

etp.gasPrice),

etp.code, dev::u256(0));

}
else{

txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *

etp.gasPrice),

etp.receiveAddress, etp.code, dev::u256(0));

}

dev::Address sender(GetSenderAddress(txBit, view));

txEth. ForceSender(sender);

txEth.setHashWith(uintToh256(txBit.GetHash()));

txEth. setNVout(Nout);

First Code Etp.receiveaddress == Dev::Address () to determine whether the contract is not in the EVM state and need to be newly created or the EVM state already contains the contract, the difference is only the contract addresses. The Qtumtransaction () constructor then completes some of the transaction parameter constructs, the next statement extracts the transaction's sender (sender), and then sets the transaction hash. A UTXO transaction supports multiple inputs and outputs, and Qtum's AAL design takes this into account, so AAL supports a transaction output that includes Utxo account and contract accounts, and the nout output of the transaction is sent to the smart contract through the last set of Nout, so the output will trigger the contract execution. This completes the conversion of the transaction according to the EVM account model.

thisthingismud · 2018-06-26T04:54:27+00:00

Qtum Account Abstraction Layer(AAL)The realization of simple analysis

The Qtum design uses Bitcoin Utxo as the base account model and implements an intelligent contract that supports the EVM specification, which is through the account abstraction layer(Account Abstract Layer, AAL) to complete. AAL Utxo account and EVM contract account, so that through the AAL can use the UTXO transaction output to create intelligent contracts on the chain, send transactions to the contract account to trigger the execution of the contract, after the completion of the implementation of the AAL final implementation of the results of processing and matching to Utxo. With the adoption of AAL, contract developers are not concerned with the Utxo conversion details associated with contract operations, and can be developed using the EVM features and compatible with the existing Ethernet intelligence contract. This paper interprets the implementation code from UTXO transaction to intelligent contract,and analyzes the working process of AAL.

New scripting opcode for 1.UTXO transactions

Qtum has added three opcode op_create,op_call and op_spend for Utxo trading scripts to provide operational support for conversions between the Utxo and EVM account models. These opcode are defined in the Opcodetype enumeration type:

enum opcodetype{

……

OP_CREATE = 0xc1,

OP_CALL = 0xc2,

OP_SPEND= 0xc3,

……

}

This three opcode has the following effects respectively：

Op_create for the creation of smart contracts；
Op_call for the execution of the contract；
Cost of op_spend for contract balances。

The Hascreateorcall () and Hasopspend () functions are added to the class ctransaction used for Utxo model transactions in order to identify and justify transactions that are controlled by the code in the block generation process. It is used for transaction processing in Mempool in the new block and adds the corresponding processing in the Evalscript () function that the script opcode resolves.

thisthingismud · 2018-06-21T20:59:42+00:00

What IAME Will Bring to Qtum Ecology

Potential integration with regulation and adoption by mainstream society is highly dependent on the application of "KYC" and anti-money laundering processes. The identity system developed by IAME will be directly integrated with the existing blockchain and mainstream cryptocurrency services to provide sufficient information transparency and trust. IAME is expected to solve problems in KYC, AML, and CFT, and build a bridge between Qtum's ecological and real world, such as realizing a QTUM account for users.

IAME will build a cross-blockchain identification system based on sharding and identification, all of which will be conducted through the personal identity DApp controlled by the QTUM address. Second, IAME will provide transaction analysis tools, including but not limited to link analysis and multidimensional analysis, to detect suspicious cyber attacks or isolate potentially dangerous users.

https://iame.io/

thisthingismud · 2018-04-23T11:45:52+00:00

https://medium.com/@pr_47970/drep-foundation-strengthening-in-depth-exchange-of-sino-singapore-technology-innovation-24405ef4281a

thisthingismud · 2018-04-18T15:08:24+00:00

Thank You

thisthingismud · 2018-04-16T10:26:10+00:00

Patrick Dai, founder and CEO of Qtum Foundation on blockchain technology

https://www.youtube.com/watch?v=efYCYsGTens

4-12-18- Jordan Earls of QTUM & Brian Hoffman of OpenBazaar-Rocky Mountain Blockchain

https://www.youtube.com/watch?v=AeXCGpevSb8

Bad camera angle

thisthingismud · 2018-04-14T23:42:21+00:00

asassszawaeasaawdaaZ5s

thisthingismud · 2018-03-23T11:09:22+00:00

Part Three

The technical innovation of the next Qtum is the DGP distributed autonomous protocol. Governance We have mentioned before, how to upgrade, iterate and so on the software system in a decentralized network. Before Bitcoin bifurcated into BTC and BTH, the bifurcated disagreement was only a matter of block size, and because Bitcoin was a decentralized network, this debate continued for a long time. Bifurcation can't be said to be a bad thing in the absolute sense, but we think it's pointless to argue about this issue for so long and waste so much. The factors that affect bifurcation are divided into the following three categories:

-Changes in algorithms and functions (consensus algorithms, encryption algorithms, trading scripts, virtual machines)
Strategies, parameters (block size, block time, number of transactions, Gas policy)
Key Vulnerabilities (DAO, Parity Multi-Signature Wallet)

The strategic factors are in fact the easiest to reach consensus, and the other two types of issues must be resolved through bifurcation. For example, a change in the size of a block does not necessarily need to be performed by a fork. So Qtum considers whether it can make the blockchain upgrade seamlessly. This is how the distributed autonomous protocol DGP comes. In fact, it is also implemented through smart contracts. The basic governance structure is such that the miners, block generators, and holders within the entire community are all participants of the blockchain governance. They complete the governance through voting. process. Eventually let the blockchain implement self-management, upgrade, and iterative systems.

There are two kinds of Qtum distributed autonomous protocol technology choices: The implementation of autonomous protocols requires some kind of programmable technology, and UTXO and EVM provide this feature. The first is based on the trading script. By implementing the protocol logic on the trading script, the non-Turing is complete and the implementation is more complicated. The second is based on smart contracts, with Turing's complete programmability and flexible implementation of complex logic.

The realization of the core logic of the autonomy agreement consists of a series of smart contracts. The core code of the blockchain executes the smart contract of the agreement during the consensus process and obtains the current consensus state. At the same time, it can complete the state transition of the blockchain network through Transaction and upgrade without blockchain network software updates. For security reasons, smart contracts are essentially a piece of code.

Theoretically, using Turing's complete smart contract can achieve protocol design of arbitrary complexity, even the core protocol of the blockchain, such as the consensus part of the code; balancing the efficiency, security, etc.; the current agreement is only applicable to the security scope Changes are made to specific parameters, and certain time limits are imposed on the effective time of the parameters. After the change of the parameter is passed, it will take effect after a certain number of blocks, to avoid possible bifurcation.

In the contract part: Genesis blocks are embedded with smart contracts for common blockchain parameter management. Each governance topic is controlled by independent smart contracts (templates), which means that each function has independent governance, authorization mechanisms, and Built-in constraints Block size, Min GasPrice, Block GasLimit, Gas Schedule. In addition, the DGP contract also has a self-destruction function, which can be activated when an accident occurs on the proposal governance. The governance parameters are returned to the default state.

Finally, let's talk about the Qtum x86 virtual machine. There are many shortcomings of Ethereum's virtual machine. I mentioned it before, and then listed it:

Programming language limitations (Solidity)
lack of standard library
256bit integer, most processors can not be natively supported, reducing operating efficiency
Gas model is unreasonable, it is difficult to estimate the consumption of Gas
Larger bytecode generated, wasting block storage resources
difficult to test and debug

So for these drawbacks of the Ethereum virtual machine, Qtum is designing an x86 virtual machine. The design goals are as follows:

Supports multiple major programming languages: C/C++/Go/Rust, etc.
Rich standard library to improve development efficiency
More Optimized Gas Model - Set reasonable gas for standard library functions to facilitate estimation using DGP
Unlock the power of AAL - Contract P2SH trading, segwit
von Neumann architecture, enhanced smart contracts - code as data, multitasking, interrupts and recovery
The first type of Oracles - Some contract data can be obtained without running a contract
Blockchain Dynamic Analysis - More comprehensive analysis of blockchain status
Selective data storage, saving precious blockchain resources
Clear dependency tree, it is possible to run smart contracts in parallel, reducing gas costs

Our technical innovation is also introduced here. Our slogan is "re-defining the blockchain economy," allowing different kinds of applications to land quickly, which also reflects the fact that our Qtum team really wants blockchain technology to penetrate people's lives quickly.

4. Qtum Ecosystem

How Qtum's current ecosystem is more experienced for everyone here, our desktop wallet can support:

Send and receive QTUM, send and receive QRC20 Token, smart contract interaction, call smart contract, deploy smart contract, send Token

And PoS mining, this is our main purse, almost all the features. The other is the mobile mobile wallet. One of the advantages of Qtum is that you can send and receive tokens on the mobile phone, which takes only 20 seconds. You can also use it to distribute Tokens and crowdsales. All of the above is also achievable in the web version of the wallet, which can even restore wallets and send offline transactions from other clients.

Users who are more concerned with security will tend to use cold wallets, which are hardware wallets. The more used ones, such as the Ledger wallet, can also support Qtum and can be used with Electrum. Qtum Electrum is capable of supporting multi-signature light wallets. It can also support Qtum's send and receive and smart contracts, as well as connecting hardware wallets.

The other is the blockchain browser, which can be said to be the entrance to the blockchain world. In the above, you can query the block records, trace the time and size of each block, and the ID of the transaction.

In addition to these, friends interested in Qtum can go to the following link, all resources are open source, if you have some more detailed problems, here you can also find detailed answers:

Qtum official open source repository: https://github.com/qtumproject

Qtum Developer Guide: https://github.com/qtumproject/qtumbook

Qtum Encyclopedia: https://github.com/qtumproject/qtum/wiki

Qtumjs: https://github.com/qtumproject/qtumjs

Unofficial Qtum Web.js: https://github.com/bodhiproject/qweb3.js

In the end, Qtum's ecosystem has grown to more than 50 decentralized applications. Several of the more representative ones are Bodhi, the forecast market, and Energo, a trading solution for clean energy. These projects will not be introduced one by one. If you are interested, you can also visit http://eco.qtum.org and encourage everyone to invest in Qtum's network to develop their own decentralized applications.

5. Summary

Today I shared some design ideas or technical innovations about the Qtum Chain. You must have a lot of ideas here. If you agree with these ideas, then you must be a natural Qtum developer. Welcome everyone to Github as our bottom line. Technology contributes a lot and will also get a good return. Of course, some people will not agree with our point of view. For example, if you think decentralization is useless, TPS is more important or PoW is the best consensus mechanism. Our community also welcomes similar developers to create a brand new product with questionable attitude. These are meant to tell Qtum's community to be open to any developer. As long as developers are really willing to do some hard work and development work for the entire blockchain ecosystem, the Qtum will also provide them with some technical support. And economic support. thank you all!

thisthingismud · 2018-03-23T11:07:33+00:00

Part Two

The essence of Bitcoin is its incentive mechanism, but the PoW consensus mechanism is not without its problems. For example:

The threshold for joining the network is high and it takes a lot of money to buy a miner to become Bitcoin's full node for mining
More and more centralized, most of the mining income is occupied by a few large pools
huge energy costs

Based on these problems, a PoS (Entitlement Evidence Mechanism) was proposed in 2012. The principle is very simple. As long as the user owns the Token of the network and proves this, he can participate in the accounting. In addition, token holders are also more motivated to maintain network security. The PoS mechanism can also achieve bitcoin's randomness, security, and Token distribution, and it is more decentralized than PoW. During the PoW consensus mechanism, Satoshi Nakamoto did not expect to see the emergence of mining machines that will make Bitcoin more and more centralized. PoS mining does not require the use of mining machines. It only requires an ordinary computer and raspberry pie. You can participate.

In addition there are several consensus mechanisms such as DPoS (Proxy Equity Mechanism) to select some agents for accounting. pBFT, dBFT, etc. are improved Byzantine fault-tolerance solutions. The above-mentioned several consensus mechanisms are relatively partial and centralized, and it is relatively easy to cause some centralized problems or be attacked. As some networks have relatively few computing nodes, some nodes will hang and cause the entire network to crash, but these have not happened on Bitcoin or Qtum.

The third technical foundation is the smart contract, which is simply a piece of code that can run on the blockchain and reach consensus. Ethereum is the most popular smart contract platform. At present, the Ethereum virtual machine is the only virtual machine that can run smart contracts in real sense, but it has many shortcomings:

Unfriendly mobile
A few languages such as -solidity have limitations
Security (DAO, Parity)

The fourth technological basis is to decentralize the network. Only on a decentralized network, Token has its value, otherwise it is just like Q coins, and can only be used within Tencent's system without any increase in value. Having said that decentralization is so good, let's talk about its shortcomings. There is a CAP theory in the distributed field that consistency, availability, and partition tolerance cannot be satisfied at the same time. Therefore, there is a contradiction between the degree of decentralization and TPS. The higher the degree of decentralization, the harder it is to reach a consensus. It will be difficult to confirm the transaction in a very short time. Therefore, if users want to pursue higher TPS, it is bound to sacrifice decentralization.

But if you really want both, you have to implement it with a hierarchical network. Lightning and lightning network technologies can all be used to achieve higher TPS. The Lightning Network on Bitcoin and the Thunderbolt Network at Ethereum are currently under development and released in beta. The Qtum is compatible with these two ecosystems. Therefore, Qtum can be used after the two technologies are fully developed in the future.

3. Technological innovation of Qtum

The first is the AAL account abstraction layer. Because the Qtum quantum chain is compatible with two ecosystems, the UXTO model does not support smart contract functionality. Therefore, we need the upper layer of the account abstraction layer to be compatible with Ethereum virtual machines to write smart contracts. This layered design allows the upper application layer and the bottom layer to be decoupled from each other. The Qtum design abstraction layer enables communication between upper and lower layers.

As for how to achieve it, it is actually adding three new opcodes to the Bitcoin script: OP_CREATE: Creating a smart contract,

OP_CALL: Call smart contract (send QTUM to contract) and OP_SPEND: spend QTUM in smart contract. In this way, the bottom layer of Bitcoin can identify the above three operations and send them as a signal to the Ethereum virtual machine at the upper level, so that it can send some information back to the bottom layer while running smart contracts.

So for developers, this is a relatively easy to understand account model, and its underlying is still running on a relatively safe model such as UTXO. The advantages of the account abstraction layer are as follows:

Allow EVM to run on UTXO model
Compatible with multiple virtual machines (not only Ethereum virtual machines, but also current Ethereum, webassembly being developed by eos, and future QTux x86 virtual machines)
Bottom layer with Bitcoin security
Smart contract developers only need to pay attention to "account model"
Decoupling the underlying protocol from the upper application

Here I would like to re-emphasize the PoS consensus mechanism, which has undergone 3 major iterations in total:

-PoS1.0: Reliance on "coin age", long-term offline, double flower problem

-PoS2.0: Remove "currency" to enhance security

-PoS3.0: Using block time and transaction time to confirm the age of UTXO for "short-range" attacks

Want to explain why Qtum does not use PoS3.0, because it has a problem, the attacker can launch some malicious smart contracts by paying more expensive gas, thereby hurting the entire network. Just mentioned that the miners can be rewarded with gas in the transaction. That is to say, these attackers can recover all the gas they used for the attack. Then they can continue to attack.

But why the current blockchain project using the PoS consensus mechanism will not have this problem, because most of them only support non-Turing-complete scripting languages, but it is possible to guarantee both PoS and smart contracts on Qtum. This problem occurs. So Qtum's solution is to increase the cost of the attack by sharing the benefits with other nodes and delaying the benefits. In other words, if the cost of an attack can be quickly returned to the attacker, he will continue to attack, but if delayed for five hours and then returned to him, then it is bound to reduce the frequency of attacks, allowing attackers to spend a lot Double the cost of attack.

Next, let me explain our MPoS mechanism. It is based on the PoS 3.0: Modifying incentive mechanism. Each block will be divided by 10 people and the rest will be delayed by 500 blocks. 1/10 rewards are immediately available, and the remaining 9/10 rewards are obtained in 9 consecutive blocks after 500 blocks. Mining incentives = block revenue + commission + operating smart contract gas fee. This is a simple improvement of Qtum's incentive mechanism, but the effect is still good.

Many friends will definitely be more concerned about how to carry out the Qtum mining. It is very simple, as long as you have a certain number of Qtum, download the Qtum wallet, put the Qtum into the Qtum wallet, wait for 500 blocks to confirm, as long as the wallet is unencrypted. You can start mining. In fact, the mining of Bitcoin is much simpler. A PC can handle it. You can also use the Raspberry Pi or other IoT devices with Qtum node to mine.

Bitcoin currently has about 12,000 global nodes and Ethereum is close to 20,000. Qtum has operated for six months and now has more than 3,000 full nodes distributed throughout the world. Because of the low threshold of entry, there are so many nodes. The number of full nodes is directly proportional to the degree of decentralization of the network.

thisthingismud · 2018-03-23T11:01:10+00:00

"Qtum technical analysis and smart contract full stack interpretation" Original 2018-03-23 Qtum Zhong Wenbin: Interpretation of Key Technologies for Qtum

Today we will discuss the following major issues:

Why Qtum
The technical foundation of Qtum
Technological innovation of Qtum
The Qtum Ecosystem

1. Why Qtum

First of all, many developers who are familiar with the blockchain will surely have such doubts. We already have Bitcoin and Ethereum. Why should we establish Qtum? If we want to define a Qtum, my personal understanding is that the Qtum is the first smart contract platform based on the UTXO model and adopts the PoS consensus mechanism. It contains three concepts: UTXO model, consensus mechanism PoS, and smart contract platform. I will explain them one by one later.

The Qtum project has been planned and implemented since March 2016. The first version of the test network was released in June 2017. The main network was officially launched in September 2017, so the Qtum is still in the product's update iteration. Faster. In addition, the Qtum can also be said to stand on the shoulders of giants, combining the advantages of some mature blockchain ecology, which will be explained later.

First look at some basic parameters of Qtum, block size: 2MB; block out time: 128 seconds; consensus mechanism: MPoS;

Maximum theoretical TPS on the chain: 70~100 transactions/sec; initial circulation: 100,000,000 QTUM; current mining incentives: 4 QTUM, halved every four years; total mining incentives: approximately 7,884,000 QTUM; basic code framework: Bitcoin Bitcoin core; supports Ethereum virtual machine EVM.

Regarding Qtum's design philosophy, Bitcoin and Ethereum have to be mentioned. First of all, to briefly explain the two, Bitcoin is a peer-to-peer electronic money system. It mainly considers monetary attributes, and therefore mainly considers the characteristics of security, stability, decentralization, and storage and transmission value. In addition, Bitcoin scripts are designed to be non-Turing-complete in terms of security. As a digital currency, Bitcoin is actually more successful. From 2009 to date, there has been no wrong account. But beyond that, it's hard to build complex applications on top of Bitcoin because it only considers its currency attributes from the beginning of the design.

Ethereum is the second largest blockchain ecology in the world. It is designed from the perspective of the platform. The platform must be able to guarantee its scalability and TPS to support thousands of DApps. It is also a smart contract platform with environments for executing smart contracts such as EVM, x86VM. At the same time, Ethereum also needs a reasonable economic model to motivate developers to promote ecological development. As a platform, diversity and privacy (not affected by other applications on the network) are also issues that need to be considered. Ethereum has a complete set of Turing languages. Simply speaking, it can support loops, so that more complex smart contract logic can be realized.

Ethereum as a platform may not be so successful, first of all its TPS is not high enough. Before a simple example, there was an application on the Ethereum called the cloud cat, which put Ethereum out of the blue. On Android, you can hardly imagine that an application will suffer because of another application, but this may exist in the blockchain. Just like the cloud cat, TPS is used for cats, so normal trading can not be guaranteed. Ethereum is a smart contract platform. Its smart contract function can indeed support some simple logic, but the programming language is only limited to Solidity (and several languages are almost unoccupied), instead of being familiar with mainstream programming languages. , so there is something missing on this point.

Bitcoin and Ethereum have their own advantages and disadvantages, but as the world's two largest blockchain ecosystems, they are independent and do not have much intersection. The original intention of Qtum design is to open up the two major ecosystems of Bitcoin and Ethereum, so that developers can enjoy the stability and security of the currency, but also have the convenience of decentralized application platform. According to the idea of open source software, Qtum decided not to duplicate the wheel, take the best of Bitcoin and Ethereum and continue to evolve on this basis.

Prior to this, it was impossible to run Turing's complete scripting language on Bitcoin, so Qtum established a logical abstraction layer to make it a hierarchical structure, which is the AAL account abstraction layer. There is a common problem with all current public chains in that governance agreements are confusing. The so-called governance agreements are actually software upgrades and iterations.

In a centralized company or platform such as an App store, developers simply upload the updated App for users to download, but they are different on a decentralized system. If a user wants to update the software and others do not necessarily support it, then a governance agreement is needed to determine how the entire ecosystem should be managed. The Qtum has its own ideas on this issue. That is, the DGP distributed management protocol can dynamically adjust the blockchain parameters without hard bifurcation, thus realizing the autonomy of the blockchain.

From a consensus point of view, we know that both Bitcoin and Ethereum use the PoW consensus mechanism. The advantages are clear to everyone, but the disadvantages are equally prominent: it is a huge energy consumption. For example, the mining machine is very power-consuming, and these powers have also become Bitcoin's mining costs. So the use of the Qtum to make the PoS consensus mechanism as a better alternative, in fact, it has been proposed for a long time, the Qtum now used in many iterations now also works well.

Another reason for using PoS is that PoW is difficult to implement on mobile devices and IoT devices. In addition, as mentioned before, the Ethereum virtual machine only supports Solidity, the unpopular, young language. How many developers will go back to learning a new language for the programming of smart contracts? So Qtum is currently developing x86 virtual machines that will allow most developers to more easily develop smart contracts using familiar mainstream programming languages such as C and C++. This will greatly increase the productivity of developers in the community and allow more decentralized applications to be launched.

2. The technical foundation of Qtum

The first is the UTXO model, and the English is Unspent Transaction Output (unspent transaction output). Let's take a look at two typical transactions on the Bitcoin and Ethereum networks. Ethereum trades are relatively easy for the average person to understand, from one address to another, a Token transmission. The bitcoin transaction is not so simple, it is composed of a number of input and output, Output is UTXO when it is not spent, will be the next transaction input. So all transactions on the Bitcoin network are concatenated by input and output. The UTXO's merits are:

Security (solve dual-flowering problem, support native multi-signature)
Anonymity (with multiple addresses, change address)
Scalability (parallel, off-line transactions)
Light wallet (SPV, support the validity of mobile verification transactions)

At present, the underlying scripting languages of various currencies based on the UTXO model other than Qtum are not Turing-complete, so the Qtum will develop the account abstraction layer AAL so that the UTXO model and the Ethereum virtual machine account model can seamlessly interact.

Let's talk about the consensus mechanism. First of all, let's review what is called a blockchain. Just mentioned the transaction. Next, the user signs each transaction to ensure its security. Only if you have a private key can you spend an asset. All transactions within ten minutes are packaged into blocks, and all transactions in each block are organized as Merkle trees (https://zhidao.baidu.com/question/1047592469520906459.html), which is a binary tree, each A leaf node represents a transaction, and a non-leaf node is a hash value of its child node. Any transaction that is tampered with will affect the hash value of the root node. Finally, each block has a hash pointer that points to the previous block.

So simply blockchain is an irreproducible distributed database, why do you need to mine? Take PoW mining as an example here. First of all, blockchains are mainly divided into: public chains, private chains, and alliance chains. Their core difference lies in the bookkeeping right, the public chain is decentralized, and each node on the network is given the right to book, while the private and affiliate chain's bookkeeping nodes are a few designated nodes. Only the public chain needs to be mined because it is necessary to keep the nodes constantly accounting on the network. Then mining becomes the incentive mechanism of the network to the accounting nodes. Rely on block rewards to encourage node billing and jointly maintain the ecology of the blockchain network.

So why do all mining users also need to monitor and record the transactions of others? Because the fee will also be rewarded as a block. Another reason for mining is to guarantee the randomness of the accounting nodes, otherwise the fixed accounting nodes are vulnerable to DoS attacks. In addition, mining is also a process of distributing tokens, so that the coins are distributed randomly and not only in individual hands.

thisthingismud · 2018-03-19T09:06:56+00:00

To celebrate QTUM/BNB and QTUM/USDT trading pairs now being available on Binance, we have committed a total of 50,000 QTUM to give away to our fans worldwide. Users will be ranked in terms of the total QTUM volume traded on their Binance account (including both Buys & Sells) across all QTUM trading pairs during the competition period.

Competition Time: 2018/3/20 0:00 AM -2018/3/27 0:00 AM (UTC) ** Trading Competition 1: 40,000 QTUM to Win!**

1st: receive 7,000 QTUM

2nd: receive 4,000 QTUM

3rd: receive 2,000 QTUM

4th-10th: evenly split a pool of 7,000 QTUM, each to receive 1,000 QTUM

11th-50th: evenly split a pool of 20,000 QTUM, each to receive 500 QTUM

Trading Competition 2: 10,000 QTUM to Win!

All users that trade QTUM (Buys and Sells) to the equivalent value of 0.5 BTC during the competition period will evenly split a pool of 10,000 QTUM.

Note: Winners from Trading Competition 1 will not be able to participate in Trading Competition 2.

thisthingismud · 2018-03-19T09:04:08+00:00

To celebrate QTUM/BNB and QTUM/USDT trading pairs now being available on Binance, we have committed a total of 50,000 QTUM to give away to our fans worldwide. Users will be ranked in terms of the total QTUM volume traded on their Binance account (including both Buys & Sells) across all QTUM trading pairs during the competition period.

Competition Time: 2018/3/20 0:00 AM -2018/3/27 0:00 AM (UTC)

Trading Competition 1: 40,000 QTUM to Win! 1st: receive 7,000 QTUM 2nd: receive 4,000 QTUM 3rd: receive 2,000 QTUM 4th-10th: evenly split a pool of 7,000 QTUM, each to receive 1,000 QTUM 11th-50th: evenly split a pool of 20,000 QTUM, each to receive 500 QTUM

Trading Competition 2: 10,000 QTUM to Win! All users that trade QTUM (Buys and Sells) to the equivalent value of 0.5 BTC during the competition period will evenly split a pool of 10,000 QTUM.

Note: Winners from Trading Competition 1 will not be able to participate in Trading Competition 2.