In the blockchains, the consensus algorithm is an important indicator of the characteristics of the blockchains.

Various consensus algorithms have entered in the history of the block.

Beginning with the consensus algorithm used by Bitcoin and Ethereum, which has been implemented in the early stages of the block, many consensus algorithms, such as POS and DBFT, have emerged.

In the QURAS Blockchain, the DBFT algorithm is used in the Consensus algorithm.

We propose how the solution to the Byzantine General Problem applied to a blockchain system was implemented.

Because there is no reliable authority in a blockchain system, it is difficult to verify the accuracy of the commands.

All nodes of the system of a blockchain are connected in the P2P Method, and there is a possibility for the nodes connected to a blockchain to be connected and disconnected at any time.

You can also get rid of the nodes by receiving inaccurate data, which can be caused by incorrect nodes concatenated into a blockchain.

Now, let’s take a look at the Consensus Node that forms a blockchain.

We cannot trust all of the nodes on the P2P network.

Let's assume that the number of the Consensus Nodes is n, where f is the number of the untrustful nodes.

In this case, the safety index of the blockchains is determined by n and f in the blockchain system.

If f is less than (N-1) / 3 in the DBFT algorithm, then the QURAS Blockchain is safe.

So let's look at the DBFT algorithm in a specific way.

The blockchain is formed such that all nodes are connected to each other in a P2P network as a distributed ledger system.

All commands that occur on a node will be broadcasted to the entire P2P network and connected to the blockchain network.

There are 2 large nodes here, one is a typical node, and the other is a Consensus Node.

A typical node is responsible for transmitting and exchanging bookkeeping materials, i.e., accepting incoming commands and retransmitting them to other connected nodes.

The Consensus Node forms and maintains the command processing and distributed ledgers raised on the entire P2P network.

Therefore, the process for the data transmitted by using the digital signature proceeds here.

In other words, when the Node i creates and sends a transaction, the Node i sends the transaction using and signing a Private Key. Then, the Public Key of the transaction generator can be checked to see if there is any change in the practical transaction.

If the number of untrustful nodes is smaller than (n-1) / 3 in the agreement algorithm, the safety of the blockchain is ensured.

Here, n indicates the number of consensus nodes that maintain a blockchain.

At this time, the number of untrustful nodes allowed in this system equal to f = (n-1) / 3.

In fact, a node that maintains a blockchain is a Consensus Node rather than a general node.

All Consensus Nodes MUST maintain a state transitions table that records the state of the current consensus.

The collection of data used from the beginning of and to the end of the agreement is called the View. If the agreement does not currently reach the View, a change in the View will be requested. All Views will be incremented by 1 starting from 0 until the agreement is reached, and it will be distinguished v.

All the Consensus Nodes are distinguished by a given number from 0 to n - 1.

In the agreement, one node in the Consensus Node in the View will directly play a representative role and the other node will play a voter role.

The selection of a representative node is carried out by the following algorithm:

Let's say that the block length is h; then we will determine the representative node as p = (h - v) mod n.

Here, v represents the View number.

The new form will be generated by at least n - f signatures from the Consensus Node in all agreement items.

Once a block has been generated, the new Consensus will be re-initiated.

The general procedure of the agreement algorithm is as follows:

The algorithm executes the block generation interval time as t by the following procedure in the standard situation.

1. The node generates and signs a transaction and broadcasts it to the QURAS Blockchain. All Consensus Nodes inspect the transaction that is generated and store the data in their own memory area.
2. After t hours from a previous block generation, the node that is selected as the representative node composes and sends a command to the Consensus Node, etc. (ConsensusRequest).
   Block height h, View number v, representative node number p, and block and block signature generated by p.
3. When a node receives a command sent by a representative node (for example, if it receives the i-th node), the node sends a reply command (ConsensusResponse).
   Block height h, View number v, answer node number i, signature information for the block.
4. If all nodes receive the signature data for a block that is at least n - f, then the block is placed in the QURAS Blockchain in a successful agreement.
5. When all nodes receive the block information, they check the transaction contained in the block and remove them from their mempool.

The algorithm executes the block generation interval time as t by the following procedure in the standard situation.

1. The node generates and signs a transaction and broadcasts it to the QURAS Blockchain. All Consensus Nodes inspect the transaction that is generated and store the data in their own memory area.
2. After t hours from a previous block generation, the node that is selected as the representative node composes and sends a command to the Consensus Node, etc. (ConsensusRequest).
   Block height h, View number v, representative node number p, and block and block signature generated by p.
3. When a node receives a command sent by a representative node (for example, if it receives the i-th node), the node sends a reply command (ConsensusResponse).
   Block height h, View number v, answer node number i, signature information for the block.
4. If all nodes receive the signature data for a block that is at least n - f, then the block is placed in the QURAS Blockchain in a successful agreement.
5. When all nodes receive the block information, they check the transaction contained in the block and remove them from their mempool.

The total number of issued XQC tokens is 888,888,888.

The total amount of XQG supply is 888,888,888 units. 16,888,888 units of XQG are initially issued and the rest will be mined every time XQG block is generated.

A block is mined with an increment of approximately 15 seconds in average. Approximately 2,000,000 blocks are generated annually.

For the first 2,000,000 blocks, 64 units of XQG are mined for every block while 4 units of mined XQG ar reduced for every subsequent 2,000,000 blocks.

Such reduction continues until the volume of XQG per block becomes 4 units of XQG. The chart below shows more specific details:

When a token administrator issues tokens on QURAS blockchain, transaction fees that are generated from the exchange of said tokens are distributed to the administer.

The administrator who generated tokens using QURAS blockchain receives the fees paid by users of the tokens.

When that happens, 100% of the fees paid by the users will not go to the tokens’ administrator; the fees will be split between the token administrator and QURAS consensus node.The ratio of coins paid to the token administrator and QURAS consensus node is designed to set automatically between 6:4 and 8:2, respectively.

The distribution of token fees are as follows:

The diagram below illustrates a function in details that offers an opportunity for token issuers to receive smart contract’s transaction fees within a certain fee range. As described above, the above design allows token’s transaction fees to be returned to token issuers. In general, token fees’ return rate differs depending on a fee amount.

In Quras blockchain, Gas volume and its fees are used to execute a smart contract and establish transaction fees. Consensus nodes preferentially process transactions with high fees.

The Gas limit is used to set a maximum volume in which a transaction can consume. When executing a smart contract, the more complicated a contract is, the more Gas is required.

Also, since the programming language is turing complete language, the Gas limit shall be set to prevent from the contract logic from being an infinit loop state.

• Transparent transaction
  In case of normal XQG and XQC transaction, a user may select Gas consumption volume within a certain range when executing a transaction.
  When constracting a Quras blockchain, the range of XQC and XQG transactions fees is set as a certain range within the engine to continue with the construction.
  The higher a transaction fee is, the higher the priority is to speed up the process of a transaction within a blockchain.
• Anonymouse transaction and RingCT transaction
  A transaction fee is set statically.

When sending XQC, a transaction fee is paid with XQG.

• Transparent transaction
  When executing a XQC transaction, a user sets transaction fees freely between the upper limit and the lower limit of the XQC transaction fees being set when the blockchain was contructed.
  The higher a transaction fee is, the higher the priority is to process the transaction.
• Anonymouse transasction and RingCT transaction
  A transaction fee is set statically.

When sending XQG, a transaction fee is paid with XQG.

• Transparent transaction
  When executing a XQG transaction, a user sets transaction fees freely between the upper limit and the lower limit of the XQC transaction fees being set when the blockchain was contructed.
  The higher a transaction fee is, the higher the priority is to process the transaction.
• Anonymouse transasction and RingCT transaction
  A transaction fee is set statically.

The following is 2 situations for smart contract’s fees determined by the Gas limit.

Transaction fees = The transaction fees of Gas price * (Gas consumption volume by opcode) are paid out.

The transaction is executed, and excess Gas is refunded.

Transaction fees = The transaction fees of Gas price * Gas limit are paid out.

In this case, the issuance of a smart contract is failed, and the already-paid transaction fees is not refunded.

For this reason, a user should set sufficient transaction fees when issuing a smart contract.