The QURAS Blockchain has a Virtual Machine in the engine in order to perform the Smart Contract.

We will now look at the Virtual Machine Structure of the QURAS Blockchains.

Before you look at the Virtual Machine, please refer to Smart Contract.

Smart Contract consists of the byte column of the Opcode.

The user will also create the Smart Contract using C# and obtain bytecode which is a column of the opcode using the Smart Contract Compiler.

Let's start by looking at the Smart Contract Compiler.

The Smart Contract Compiler performs the role of converting a user-generated Smart Contract Code (C# code of the user level) into a script code, which is a column of opcode that can be executed on the VM in the QURAS Blockchain.

Users use the framework to provide the Smart Contract in a QURAS Blockchains and the role of converting the code into a script which can be recognized by VM can be performed by this Smart Contract Compiler.

The QURAS Smart Contract Virtual Machine provides the following Opcode Set.

The opcode content provided by the VM is as follows:

• A collection of string related opcode. provides a string related processing, etc.
• Stack operations and collection of related opcodes. provides instructions such as stack operations in C and C + +.
• A collection of processes associated with a process operation provides the same instruction as if and for.
• A collection of constant number related opcodes provides an instruction such as Const.
• A collection of arithmetic operation related opcodes. provides instructions related to arithmetic operations, such as +, -, *, and /.
• A collection of encryption related opcodes. provides ECDSA, SHA and a variety of other algorithms to enable users to use encryption.
• A collection of data structure related opcodes. provides this Opcode instruction so that it can define the structure of the array and the structure of the complex form of materials.

There are 2 types of fee in the commission.

Let us look at these 2 types.

In the QURAS Blockchains, users can use a variety of services for development by using the storage spaces provided by the Smart Contract.

The storage space used here is not free of charge.

In a QURAS Blockchain, users create the Smart Contracts and deploy them into a blockchain to make the content available to the users.

When users deploy the Smart Contracts, users must pay fees for the storage space and the System Call, etc.

The Deployment Fee is the commission that will be used when deploying the Smart Contracts.

Transactions fees for system functions are as follows:

The QURAS is designed to provide a secure execution environment for the Smart Contract and to have equal results for the Smart Contract by all nodes. In order to execute the Smart Contract to all nodes, the fee must be paid.

The commission is also determined by the Smart Contract calculation logic, that is the opcode, whose unit is the Quras Token unit.

If the fee is not enough, the Smart Contract will fail.

All users are free of charge for the Smart Contracts that corresponds to the Quras Token 10.

Transaction fees for basic opcodes are as follows:

The Smart Contract execution results must match on all nodes in the QURAS Blockchain.

If the result of the Smart Contract is changed by the node, the result of verification and agreement with the transaction will not be able to proceed.

Here, there is a difference in the execution results depending on the format of C, C + +, and the structured CPU.

There is also a possibility of the calculation result changing as the size of data such as int changes depending on whether the system is 32 bits or 64 bits.

However, the same result for the Smart Contract execution of a QURAS Blockchain must be produced regardless of all nodes or any CPU or OS environment.

The Blockchains cannot maintain itself if the data of blocks that reside on a node is changed because they are managed by a blockchain ledger of identical state on all nodes.

As such, Smart Contract VM of the QURAS Blockchains must be designed to leave the same result in the same input for all environment.

In other words, the QURAS Blockchain must be characterized by consistency.

Next, we will look at the characteristics of consistency in the QURAS Blockchains.

We will begin by time consistency.

All nodes have items like TimeStamp in the block agreement.

If there is any difference in time from a node using time related function in a Smart Contract, then the results will change.

That is, time synchronization of a node participating in a QURAS Blockchain is required.

All nodes participating in the QURAS Blockchain now require a time synchronization of the system, so that they are designed to be concatenated into a QURAS Blockchain.

By doing this, the time synchronization problem in Smart Contract is solved.

The following is a problem associated with the generation of a lance.

The generation of a lance can produce different results for all nodes.

The method to solve this problem in distributed networks is to introduce the concept of seed for the generation of a lance.

In other words, the blockchain synchronization can be executed by using a lance generator which is designed to produce the same result only for the same seed.

In the QURAS Blockchain, the hash value of the block is used as the Seed to use a lance generator.

The problem that may be raised is to ensure consistency of the storage space data used in Smart Contracts.

Since the QURAS Blockchain uses a distributed ledger, the decision on the data is the same on all nodes.

The data stored in the Smart Contract storage space can also be viewed as a deterministic since it can only be assessed by the contracts.

The state of all nodes that are generated in a blockchain can now be managed identically.

The Smart Contract type provided by the QURAS Blockchain can be divided according to the execution method.

When you look at a QURAS Blockchain, you can use a contract address instead of an address scheme managed by the public key, like other bitcoins.

In the QURAS Blockchain, all addresses are generated by the Script Hash.

The Script Hash contains the logic of an opcode that can validate sign code.

The address of the QURAS Blockchain is now created by this Script Hash, and the bandwidth of the address can be viewed as one contract.

In other words, if you look at a typical coin transmission, you can see it in a contract, and if a transaction occurs, you will be able to proceed with sign verification by executing the Script Hash opcode.

This contract is called the Verification Contract, but the value returned by the sign value and Script Hash value as input have one value between true and false simply as the bool type.

That is, if such a contract is true by the result of the return value, it will enter into a blockchain, and if false, the failure is acknowledged, and the transaction is lost.

This transaction is the most commonly used contract in the Smart Contract of the QURAS Blockchain.

This transaction is executed by a particular transaction, but it can proceed with access and updates to the state of the system while running and can also change and query the value of the Contract Storage.

If the Application Contract generates a transaction, the fee must be paid by the Contract Script, and the Application Contract will fail if the fee is not sufficient.

When creating a Smart Contract, the function can be of a public type so that the user can call it in another contract.

In such a case, there is a function contract as a contract that can be used.

In other words, the Smart Contract users will use such a contract when calling the function of a Smart Contract that has already been deployed.