Technical Paper|Quras

Structure of P2P Communication

A blockchain is a system in which all nodes are connected in a P2P system without a specific server.

In other words, all nodes of the QURAS Blockchain proceed its communication with the P2P method.

In this section, we will specifically describe how all the communication structures between the Full Node, Light Node, and Consensus Node of the QURAS Blockchain will be reflected.

All communications between nodes will now be described here.

All communications carried out in a QURAS Blockchain are to be proceeded by the communication structure of the Quras Command which encapsulates all the communication parts.

Now, we will look at the structure of the Quras Command and explain the individual communication parts.

Structure of QURAS Command

The structure of the Quras Command is as follows:

Items	Description
Network Type (Magic)	The item in Magic indicates the type of Network, and it becomes an item to distinguish Mainnet and Testnet from QURAS Blockchain.
Command	The value of this item divides the basic mission as command. The description for the command will proceed as follows.
Checksum	This item is used to distinguish whether or not the item of the Payload is correct as the Checksum.
Body (Payload)	This item can be viewed by the command as the basic parameter of the command. The structure of this item is described below along with the command parameter.

Table 1. Quras Command Items

The communication of all the packets in the QURAS Blockchain is carried out in accordance with the above Quras Command structure.

All nodes in a QURAS Blockchain will proceed with the following authentication if they receive a Quras Command:

Comparing the Local Network Type and Quras Command Network Type, we will perform the next step if these are the same. Otherwise, we will disconnect the concatenation.
Calculate the Checksum of Payload and compare it to Checksum in the Quras Command, and then perform the next step. Otherwise, we will disconnect the concatenation.
Check the length of the parameter and disconnect the concatenation if the length is greater than 0 x 2000000. Otherwise, we will interpret the item in Payload.

The QURAS Blockchain carries out tests on the above 3 types and verifies the accuracy of the Quras Command.

Now, let's talk about what kind of command is in a QURAS Blockchain communication command, and what kind of structure the corresponding Parameter has.

SYN Command

This is a command that exchanges information on a node to establish a concatenation between nodes.

The parameter of the SYN command is as follows:

Items	Description
Protocol Version	It is the node engine communication parts as the Protocol Version of the current node.
Module Services (Services)	This item is an item that displays the state of the current QURAS Blockchain on the node network.
Timestamp	Represents the time when a command was generated.
Port	It represents a Port to send and receive command in the current node.
Nonce	This item means the number assigned randomly to identify the node that sent the command.
User Agent	It refers to a build version of a node.
Block Start Height (StartHeight)	This means the size of the Local block of a node.
Relay	It is an item that determines whether a packet is to be transmitted. It is set to a True value in general.

Table 2. Version Command Item

All nodes will be able to know the state of the remote node through SYN Command and to determine which nodes it will be able to be provided to receive the necessary document, such as the block, from.

ACK Command

This command does not have any parameters.
This is a command sent to the answer when the node receives an SYN command.

In other words, it is a reply command to SYN that is sent in the sense of confirming the verification for SYN command and establishing a connection with the remote node.

GetBlocks Command

This is a command that the node sends to download the block.

The parameters of this command are as follows:

Items	Description
Start	It refers to the block which is to be downloaded first.
End	It refers to the block which is to be downloaded last.

Table 3. GetBlock Command Items

This command is sent to the Remote node as a command that is used to synchronize its own log blockchain from the Remote node.

Addr Command

This is a command used when sending the information on the remote node connected to itself to the requested node.

Items	Description
Address List	It will be sending information about the nodes that are connected to it in a List format.

Table 4. Addr Command Items

In this case, the meaning of the Address List item is as follows:

Items	Description
Module Services	This item is an item that displays a state of a node in a QURAS Blockchain that is attached to a network.
Timestamp	This item means the time associated with the local node.
Protocol Version	It means the node engine version of the node engine as the protocol version of the current node.
End Point	It is the current node's Network information. Specifically, the IP address and port number.

Table 5. Address List Items in the Address List

In other words, all nodes will receive an Addr Command and establish connections based on the information of the other nodes and connect to P2P of the QURAS Blockchain.

GetHeaders Command

This is a command that the node sends to the Remote node to download the header of the block.

The parameter of this command is the same as the GetBlocks command.

Items	Description
Start	This means the block to be downloaded first.
End	This means the block to be downloaded last.

Table 6. GetHeaders Command Items

This command will be implemented in FullNode and LightNode.

Specifically, LightNode downloads only the header of a block.

Mempool Command

Mempool means the storage space for a node's Transaction.

This is a command to be called to synchronize the appropriate Remote Node and Transaction.

This command does not have any parameters.

In other words, the aim of this command is to send a command to call to synchronize the currently generated Transaction.

GetAddr Command

This command will be used in the following cases:

All nodes store the information of the connected node in a PeerList.

This is because a node is connected to a chain of P2P blocks again when a node is rebooted or reconnected to the Internet.

Since the QURAS Blockchain is a P2P method instead of a Server / Client method, all nodes are connected to the server by any number of nodes, thereby forming a single large P2P network in connection with any number of nodes.

In the case where this command is available is when the node is started for the first time, and the node’s PeerList is empty. In this case, the node connects to a node called a SeedNote of blockchains and sends this command. In other words, this command is used to obtain the connectable node information, and it is connected to the P2P network of the QURAS Blockchain.
In the second case, the node has a PeerList, but the number of nodes in the PeerList or the number of nodes that are currently concatenated is smaller than the number of nodes that are bound to the standard. In other words, a node needs to be concatenated with about 6 nodes, but the number of nodes currently connected to the node is assumed to be 2. In such a case, the node can send a GetAddr command to the 2 nodes to which the node is connected to secure the concatenation information. When all nodes on the P2P network receive a GetAddr command, they query the information on the node that is connected to it, collect the latest information, and send it back.

In the same manner, all nodes in the QURAS Blockchain will be connected to a P2P network to form a blockchain.

GetAddr command does not have any parameters.

The GetAddr response will result in an Addr Command.

INV Command

This is a command that sends a hash value for the Transaction, Block, and Consensus.

The items for the parameters are as follows:

Items	Description
Type	This is an item that specifies the format of an INV command. 0: Transaction 1: Block 2: Consensus
HashList	This means the List of Hash corresponding to the Item of Type.

Table 7. Inv Command Items

The description of the above items is as follows.

In the case of Type: 0, the Hash List of the Transaction is sent in the form of a Hash list in response to the response of the Mempool Command.
When Type: 1, when a Get Blocks Command is received, the block Hash value from the Start of the block to the end of the block is generated by the hash list.
Type: 2 will be used in the communications between the Consensus Nodes

This command will also work in response to GetData Command.

Tx Command

This is a command that sends the information of a Transaction as a response to a GetData command.

This command will also be used to send the Transaction information for Hash, which is requested in response to the Inv Command.

The Tx Command is the same as the Structure of the Transaction as the parameter.

The structure of the Transaction will be specifically mentioned later.

Block Command

This is also a command transmitted by the request of GetData or Inv Command like the Tx Command.

In the same manner as the Tx Command, the block value corresponding to the Hash of GetData or Inv Command is transmitted in the parameter.

The structure of the block will also be mentioned later.

Merkle Block Command

This command will form the parameter in the block header value of the block, the number of transactions that the block has, and the Merkle Tree Hash value that is created by the Transaction.

Items	Description
Block Header	This part will be described later. (Link)
Tx Count	It refers to the number of transactions contained in a block.
Hash List	It forms the Merkle tree and is an array value for the Merkle Tree.

Table 8. MerkleBlock Command Items

Consensus Command

This command includes agreement and related content as a command exchanged between agreed nodes.

For this command, refer to the link.

Headers Command

This command requests the header value of the block, that is, this command extracts and transmits the header information as a response to the request by the Get Headers Command.

The parameter of this command is the same as the block header and so refer to the link.

All nodes of the QURAS Blockchain will communicate the requested data through the above command structure.

Wallet Structure

Provides coin encryption and transparent transmission and reception for 2 types of QURAS Blockchains.

Transparent Wallet Structure

Transparent Wallet will use ECC encryption to generate Private Key and Public Key and generate Address by Public Key.

The basic key problem here is how Private Key and Public Key generation generate the address used by users, and how to proceed with the verification of Transaction using Private Key and Address.

ECC encryption (elliptic curve cryptography) is a public-key cryptography based on elliptic curve theory. Elliptic curve encryption has the advantage of requiring shorter keys (for example, RSA) than the other public key cryptography. [1]

The elliptic curve cryptosystem theoretically can calculate theoretically finite time by the theory of computational complexity, but it takes advantage of the fact that it takes too long to actually calculate it.

The same encryption as RSA of initial public key encryption was developed by a theoretical basis that took a long time to split 2 or more prime numbers.

ECC encryption was created in that it takes a long time to look for discrete logarithms of random elliptic curves for a known point in time.

For encryption purposes, an elliptic curve means a set of points satisfying the following equation as a kind of planar curve.

x^3+ax+ b=y^2

This is a standard elliptic curve equation used in general ECC encryption.

The elliptic curve used herein QURAS Wallet is secp256r1, which is proposed as a standard.

The ECC encryption is not specifically described here because there is a number of references.

The Private Key length of QURAS Wallet is 32 bytes.

This Private Key is generated randomly by an algorithm which cannot be reissued by time and device information.

The method of generating the Public Key by Private Key is as follows:

G point as the standard for secp256r1 of ECC is as follows:

0x036b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296
The Public Key is a value derived discretely from the above-mentioned G point and Private Key.

The length of the Public Key obtained at this time is 66 bytes.

At this time, the first 33 bytes of Public Key means the X-axis value, and the next 33 bytes mean the Y-axis value.

X Value (33byte)

Y Value (33byte)

66 Byte

In this case, Script Hash is generated as follows depending on whether the Y value is even or odd:

If the Y value is an even number, the first byte of X is set to 02.

If the Y value is odd, the first byte of X is set to 03.

After generating Script Hash, the Script Hash length is 0 x 21 bytes.

Add 1 byte of Address Version to the last byte of this Script Hash, and then take Hash 160.

If the Hash 160-byte column is set to encoding Base 58, Address is displayed.

The above description can be represented in the following table:

Figure 2. Generating a Transparent Address

When speaking of wallets in a QURAS Blockchain, it means a basic Private Key, and it is recommended that this Private key is being stored well.

Users can also get a variety of services by simply keeping the Private Key or using the Wallet, and users can check the balance of the coins stored in the Address.

We will continue to evolve the encryption algorithm for Address and will further improve research so that users can make more secure money.

Anonymous Wallet Structure

There are 2 major types of the Anonymous Address.

There is a bandwidth of the Address using the ZK - Snarks and the Address using the Ring - Signature.

First, we will look at the Address band using the ZK - Snarks.

zk-SNARKs Address Structure

The key for the Anonymous Wallet is different from the Transparent Key’s format.

The Private Key length of Anonymous Wallet is 31 bytes.

The Private Key of Anonymous Wallet is also a random byte column of 31 bytes which is created by a random generator.

In the Anonymous Wallet, the Private Key is called the Spend Key.

You can generate Receiving Key, Viewing Key, and Address based on this Spend Key.

The Receiving Key can be viewed as the Public Key of the Spend Key.

The Receiving Key is obtained by using the crypto _ scalamult _ base function of the library of Sodium as a key to be obtained by advancing the scalar multiplication from the Spend Key.

Of course, this algorithm is also performed by using the ECC algorithm.

Viewing Key will be created by using the PRF function from the Spend Key.

The PRF function is a function defined by itself and can be confirmed by referring to the source in order to see it concretely.

The Address is composed of a combination of Public Key and Public EncKey of ECC.

The configuration diagram of Anonymous Address is as follows.

Structure Of The Transaction

The QURAS Blockchain has a variety of transactions.

This will specifically describe the various transaction offered by the QURAS Blockchains.

Before describing the structure of a transaction, let's talk about the items and structures that all transactions include in common terms.

Transaction Structure (Common Part)

The transaction structure mentioned here is a structure that is included in all types of transaction.

In the future, when describing another structure of the transaction, we are trying to display this part as a transaction Field.

Items	Description
Transaction Type	As a type of transaction, it is modified by the structure and the mission of the transaction.
Version	This shows the version of the transaction, where if the item in the transaction is updated, it is designed to be processed by the value of this item.
Transaction Attribute	It applies to Smart Contract and specified transaction as an item associated with the additional function of the transaction.
Coin Reference	Coin Reference refers to Tx's Out Put reference for coins that are not currently being sent to Bitcoin in the same manner as UTXO information being sent.
Transaction Outputs	It is the Tx Output for the receiving side of the coin send / receive.
Script	Transaction validation and Smart Contract content would be placed here.

Table 9. Structure of the Transaction

Let's take a look at the type of transaction.

The type of transaction includes the type of all transactions used in the QURAS Blockchain.

The type of transaction defined for the type item is as follows:

Miner Transaction
Issue Transaction
Claim Transaction
Enrollment Transaction
Register Transaction
Contract Transaction
Anonymous Transaction
Publish Transaction
Invocation Transaction

The above transaction will be described later in detail.

Structure Of Miner Transaction

The Miner Transaction is a transaction that generates a Consensus Node, a node that generates a block.

This can be viewed as a transaction that is currently being sent to the current block creator account by integrating the commission fees of the transaction.

In other words, the Miner Transaction is registered in the first transaction of the block as a transaction to transfer a commission to the block creator’s account by calculating the commission for the transaction in the block after the creation of a block.

In addition to the item in the transaction, the Miner Transaction will further include items that represent the Nonce item, such as random value.

Structure Of Issue Transaction

The Issue Transaction does not have any special items.

The Asset creator can create an asset that will be registered in the QURAS Blockchain through Issue Transaction and will be transferred to all addresses.

When it comes to a QURAS Blockchain, the transaction fee is 0.

Claim Transaction Structure

The Claim Transaction is a transaction used when a QURAS coin holder receives a QURAS Gas Token according to a coin's equity interest.

In other words, if a user owning QURAS coin owns 1000 coins as an example, and receives 300 QURAS Gas Token as Reward, this transaction can be used to receive 300 QURAS Gas Token.

The Claim Transaction is a transaction that analyzes the current user's coin transaction to calculate the QURAS Gas Token bonus recognized so far and returns the bonus to the coin holder.

The approval process for the Claim Transaction will also be followed by verification of the accuracy of the bonus.

If the bonus validation fails, the transaction cannot be added to the block.

This is a transaction that only QURAS coin holders can use.

Here, the claim available amount is the calculation of spent coin and unavailable amount is calcualtion of unspent coins.

Structure Of Enrollment Transaction

The items added to this transaction are as follows:

Items	Description
PublicKey	It is the Public Key for the verifier.

Table 10. Additional Enrollment Transaction Items

This is the transaction that will be issued to become a verifier.

In order to become a verifier, you must configure the Enrollment Transaction and send a deposit to the PublicKey address.

You can cancel the registration by withdrawing the deposit in PublicKey.

Register Transaction Structure

This is a transaction that is used when registering assets such as QURAS coin and QURAS Gas Token in a QURAS Blockchain.

In other words, you can think of it as a transaction that registers a user-defined asset, such as an Ethereum ERC 20 token.

This transaction will add asset information to the transaction structure as an asset registration transaction.

The items of information to be added are as follows:

Items	Description
Asset Type	This is an item indicating the type of the asset.
Name	It is an item indicating the name of the asset.
Amount	It is an item indicating the number of assets to be issued when the asset is registered.
Precision	It is an item used to represent decimal places in the number of assets.
Owner	It is the information of the user who owns the asset.
Admin	It is an item indicating Script Hash.

Table 11. Asset Registration Items

The information on the assets registered by the above items is registered in a blockchain to make users use the information.

In other words, the QURAS Blockchains provide asset registration transactions that allow users to build and use their own assets in a QURAS Blockchain.

Structure Of Contract Transaction

This is the transaction associated with the sending and receiving of the asset. Users will be using this transaction to send and receive assets. This transaction uses the transaction common part as it is. So, let's take a look at how users can use this transaction to send their coins.

A blockchain is a collection of blocks as a distributed ledger. All blocks include transaction, etc. In other words, the Contract Transaction will also be all included in the block. All the user's coin transmission history will be included in the blockchain of the distributed ledger more accurately. All users in a blockchain are divided into Address created by ECC, and all users have Private Key that corresponds to Address.

The structure of the Transparent Address is mentioned above. The user has a Private Key, a Public key, a Script Hash, and an Address. The blockchain stores Script Hash and Address as data. The Private Key is a key that is stored separately by the user. Now let's go through an example of how to generate a real transaction.

Suppose User A is sending 100 coins to User B. Assume that A has 200 balances. A has 200 balances means that there is a Transaction Output that is still not sent. There is a Coin reference item in the Contract Transaction.

The meaning of this item is as follows:

Items	Description
PrevHash	Indicates the Hash value of the previously generated transaction.
PrevIndex	This item means the Index value of the Transaction Output List that is included in the transaction.

Table 12. Coin Reference Items

All transactions have a Transaction Output Item.

The Coin Reference will specify this Transaction Output as the Index value for the Transaction Hash and the Transaction Output List.

In other words, the Coin Reference items are specified as described above when sending coins from A to B.

Then when you send 100 coins to B, you have to add a Transaction Output.

However, since the Coin Reference has a balance of 200, it generates 2 Transaction Output to send a 100 to A and a 100 to B.

So, let's look at the meaning of the item on the Transaction Output.

Items	Description
AssetID	It is an item indicating which assets are to be transferred as an ID of the asset.
Value	It is an item indicating the amount to be remitted.
Script Hash	It is the Script Hash of the user who receives the coin.

Table 13. Transaction Output Items

If you transfer the Coin Reference and the Transaction Output Item to match the format described above, coins will be transferred.

The content of described above can be represented in the following table:

Figure 3. Transparent Tx Principle

The principle of remittance of all coins proceeds as described above.

Structure Of Anonymous Transaction

The Anonymous Transaction is divided into 2 types by the encryption algorithm.

zk-SNARKs Anonymous Transaction

The ZK- SNARKS is the first encryption module introduced by Zcash coin.

The QURAS Blockchain uses ZK- SNARKS to encrypt transactions with the aim of Anonymous Transaction.

It is important to implement the basic transaction validation of the encryption blockchain.

In the anonymized transaction using ZK- SNARKS, all the transaction contents are encrypted, so the verification method for this is different from the Transparent Transaction.

First of all, the Private Key and the Address method are different from the Transparent Address method in ZK- SNARKS algorithm.

The encryption algorithm is based on ECC, but the Address method is different.

This part will be referred to above because it has been mentioned above.

The term "encrypted transaction" means that the sender, the recipient, and the transaction amount of the transaction are encrypted as a result of the transaction, when 100 coins are transmitted in the form of A -> B as an example.

That is, because the contents of the transaction are encrypted, only a user who has a private key in the ZK-K SNARKS can interpret the encrypted portion of the transaction contents.

At this time, the verification method of the transaction will be required at the Consensus Node.

That is, using the features of the ZK- SNARKS algorithm, the Consensus Node can determine that the encrypted transaction is accurate even if you do not know the Private Key of the User at all.

The Anonymous Transaction has a byte column for the encrypted transaction and a sign for the encrypted byte column and an entry for the signed Public Key.

The added items are as follows:

Items	Description
AnonymousTx	It means the encrypted byte column of the transaction.
PubKey	This means Public Key to validate this encrypted item.
Sign	This item is an item for verification of Anonymous Tx as a sign for Hash of Anonymous Tx byte column.

Table 14. Additional Items for Anonymous Transaction

For the basic ZK- SNARKS algorithm, refer to the following.

Structure Of Publish Transaction

At the next step, the Publish Transaction is still trying to add a transaction that will be used when publishing a Smart Contract.

Structure Of Invocation Transaction

This is a transaction for a Smart Contract.

This transaction contains the byte column of a Smart Contract as a transaction to execute a Smart Contract, meaning it includes the compiled script.

This transaction runs on the Consensus Node and performs the function of the script in the VM and performs the function to return the results.

We will refer to the Smart Contract later.

Block Structure

A blockchain can be viewed as a concatenated set of blocks.

Before we look at the structure of blocks, let us explain intuitively how blocks are concatenated in blockchains.

The block chaining method of blockchain is as follows.

Figure 4. Block Chaining Structure of Blocks

As mentioned above, the block consists of a large block header and a parameter of the block.

The block header contains block information, and the parameter of the block consists of a collection of the transaction.

Let's start by looking at the header of the block.

Block Header Structure

Let's look at the header of the block and explain what it has to do.

Items	Description
Version	This is an item that considers when the header of a block is updated as an item indicating the version of the block.
Prev Hash	This item is an item indicating a hash value for a previous block.
Merkle Root	This is the Root Hash value of the Merkle Tree, which consists of leaves in the Hash of the transaction in the parameter of the block.
Time Stamp	Indicates the time when the block was generated.
Index	Indicates the length of the block.
Consensus Data	It means the Nonce value of the Node that generated the block.
Next Consensus	This is the Script Hash value of the Consensus Node, which has the authority to generate the next block.
Script	Shows the validation Script for a block.

Table 15. Block Structure

There is an item called the Merkle Root in the header of the block.

The meaning of this item is as follows:

The block generator forms the Merkle Tree by the Hash value of the transaction contained in the block.

Then the RootHash value of the Merkle Tree is assigned to this Merkle Root item.

All nodes can be verified by the Merkle Root calculation method for the wrong transaction of the transaction contained in the block.

The following is an intuitive explanation of how to build the Merkle Tree in the transaction.

Suppose that a block has 7 transactions as an example.

Let's say that the Hash of these 7 transactions is A, B, C, D, E, F, and G.

In this case, the Merkle Root value will be calculated as shown in the following figure:

Figure 5. Merkle Root Configuration

If you download the parameter of a block from another node and you accidentally receive the contents of the parameter, the Merkle Root Value for the parameter will change from the Merkle Root value for the header.

You can find it through the following figure:

Figure 6. Searching for Errors in the MerkleTree

In this case, it can easily be obtained through the Merkle Tree, whether its transaction is wrong or not.

That is, the node can use the Merkle Tree to download and validate the block header and block parameter from a number of nodes without a single node.

There is a lot of literature on the Merkle Root, so please refer to them. [2], [3]

Block Parameter Structure

The parameter of a block is a collection of transactions.

It will include the transaction, meaning all types of transaction.

Block Validation Method

The verification method of the block is as follows:

The block verification procedure first advances verification to the block header and then advances the verification to the parameter.

Let's look at the verification for the block header.

Verifying Block Header

The verification procedure for the header of the block is as follows.

Restore True Value if the hash value of the current block is the hash value of the Genesis Block.
Restore True Value if the Hash value of the block is already contained in a Local Block.
Restore False Value if the block header corresponding to the PrevHash Value of the current block is not in the Local Blockchain.
Restore False Value if the Index Value of the block header corresponding to the PrevHash Value is equal to or greater than the Index Value of the current block by 2.
Restore False Value if the Timestamp of the block header corresponding to the PrevHash Value is larger than the Timestamp of the current block.
Lastly, Restore False Value if the script fails after proceeding with the validation of the script for the block.

If the validation for the block header fails to validate the block's parameter, then the validation of the block's parameter will not proceed.

Verifying Block Parameter

The verification procedure for the block parameter is as follows:

Restore False Value if the first transaction has no Miner Transaction, or the Miner Transaction is located at least in the second index in the list of transactions.
Check if the Next Consensus item corresponding to the transaction is calculated correctly, and if not, restore False Value.
Check to see the aggregate results of the transactions and the amount of Miner Transaction and restore False Value if the results differ.

If all of the above verifications succeed, the node recognizes that the block validation succeeded, and accepts the blocks in the Local Blockchain.

Structure Of Smart Contract

The concept of Smart Contract is originally proposed by Nick Szubo in 1994. When a contract was written in documents and the real person had to carry out according to the contract, but he insisted that the contract could be automatically executed if the contract was made with a digital command.

The contract result according to the condition is apparent in the digital agreement, and the contract contents can be carried out immediately.

When you decide to create and execute a digital agreement, and you will no longer need a third-party trust authority to execute the contract.

As of 1994, the digital smart contracts existed as a concept and had not been introduced into the field of operational services.

The advent of the concept of blockchain has led to the creation of an environment where smart contracts can be made.

In the QURAS Blockchain, the Smart Contract was designed to allow users to create and use contract terms directly in addition to such digital contracts.

In other words, all of the platforms are provided for the users to use the QURAS Smart Contract language to develop their own Smart Contracts so that they can run on the QURAS Blockchains.

Now, let's take a look at the Smart Contract execution procedures for the QURAS Blockchains.

Smart users create Smart Contract using the Smart Contract creation language supported by the QURAS Blockchain. The Smart Contract language supported by the QURAS Blockchain is C#. Users can create Smart Contracts in a visual studio environment using the Smart Contract Framework, which is supported by the QURAS Development Team.
After Smart Contract is created, the Smart Contract Compiler is used to build the corresponding Smart Contract and obtain the bytecode. The QURAS Development Team provides a compiler that allows users to develop Smart Contracts into themselves. Users will register the QURAS Smart Contract Plugin and other compilers with the system in a visual studio environment and make it available for use.
Once the build bytecode is prepared, the user deploys the Smart Contract to the QURAS Blockchain. The user generates a transaction that registers the bytecode which is built from the wallet or dedicated tool that supports Smart Contract in a blockchain.
The Miner runs the Smart Contract Script and registers it in the QURAS Blockchains if there is no error. When the Miner generates a Smart Contract Transaction, it would be added to the block and then registered to the blockchain if the Smart Contract bytecode is executed by the Smart Contract VM and succeeded.
After the Smart Contract has been deployed, the user can use the Smart Contract Script Hash to call functions, etc.

The structure of a Smart Contract can be viewed as a combination of opcode that is provided by the QURAS Smart Contract VM.

When a Smart Contract created by a user becomes compiled, it changes to bytecode changed by the opcode.

The QURAS Development Team will periodically advance updates to the Smart Contract VMs to provide a convenient Smart Contract creation environment for users.

Now let's take a look at the structure of the Smart Contract.

The Smart Contract is simple in structure as a byte column in opcode.

All the opcode in the byte column will be parsed and executed by the node's VM.

For the opcode meaning and the QURAS Smart Contract libraries, refer to the following topics.

Structure Of Level DB

The blockchain management on all nodes is proceeded by using the LevelDB.

Unlike other SQL databases, LevelDB is distinguished from other SQL databases in terms of DB in the Key-Value format.

Unlike SQL, LevelDB has a storage structure of the Key-Value format. [4] [5] [6]

The performance of the LevelDB is as follows:

Generally, it has excellent performance when compared to the SQLite and the Kyoto Cabinet Tree DB.

But there was a decline in the performance in the results of areas where big data was used.

In other words, the excellent performance has been displayed in the value of LevelDB is about 100 bytes.

If the value item is within this range, it will be suitable to use in the local, because it is superior in the performance.

See reference for more specific information on the LevelDB.