Whitepaper version 1.0

 

​

August 2021

​

 

​

1 Project introduction

​

1.1 Project background

 

Since the birth of Bitcoin, blockchain technology has matured and gradually entered the application fields of various industries. Traditional companies have embraced another technological revolution brought about by blockchain, trying to take the lead in taking the lead in the new historical turning point and inject new blood into their own transformation. It can be seen that the changes brought by the blockchain to the entire market are indeed disruptive. However, the current blockchain industry has many shortcomings, and there is also a big disconnection from traditional enterprises and the real economy. This is mainly reflected in some aspects: the popularity of the first tokens has caused the market to be mixed, and many projects are serious and lacking. Actual value; market tokens are flooded, good and bad coins are confused and difficult to distinguish; many industries spawned by blockchain are seriously out of touch with economic entities, and they do not have the capacity for sustainable development. At the same time, market viability is extremely weak and risk-resistant Low sexuality has become an extremely unstable factor that causes market fluctuations; the development and application of smart contracts has become a market blank, and there is no good channel for docking with traditional industries, and it has not really promoted its in-depth transformation and change. . In 1995, Amazon was established, setting off the e-commerce revolution in the retail industry. The online business model broke the limitation of time and space. The transformation from physical stores to virtual stores greatly saved operating costs and broke through the physical space limitations of goods on the shelves. The "Long Tail Theory" proposed by Chris Anderson in his book "The Long Tail" has truly become a reality. It has been fully verified in the operation of the market, and niche products can also find their users and obtain their unique market segments. field. However, it did not fundamentally solve the problem of "fake goods" and the trust between the parties to the transaction. Customers still place their hopes on a centralized intermediary platform with third parties for the products and business reputation of merchants. GTP came into being. Different from the traditional e-commerce industry, the development of GTP relies on the lowest level support of blockchain technology. One is the smart contractualization of transactions, and the other is the digital monetization of payment methods; GTP uses blockchain-based technology Developed based on standard web technologies such as HTML, HTTP, RDF and OWL, allowing computers to share information through predictive analysis. At the same time, the use of traditional gaming data is upgraded, introducing the principle of external data in the blockchain, the principle of Counterparty, and the latest IBLT technology:

​

1. Put the social model into the data circulation model to quickly filter out the data needed by the industry to which the company belongs, and guide the data demander to use the data correctly and maximize the value of the data.

2. Established clear data quality standards and monitored data in circulation to help companies better distinguish whether the data can meet their needs.

3. QL language: efficient integration of multiple data sources, convenient for users to use different types of data, saving time and effort;

4. The establishment of a personal data authorization system allows personal data to be used legally on the Internet and solves the problem of personal data authorization. The innovation lies in the use of blockchain smart contracts to create a new "to create a global and convenient retail payment economic community", to standardize and unify the chaotic gaming market. It is also very active in the market development and influence of digital products, and plays an indispensable role in protecting the rights and interests of producers and consumers.

 

1.2 Company history

​

The Eurasian Digital Trade Development Foundation was established by the Russian Pearl Service Company, in conjunction with the Russia-China One Belt and One Road Strategic Development Research Association to provide policy support, and the Russian-Chinese Blockchain Innovation Technology Research Institute to provide technical support. An investment management and advisory agency for sub-digital trade ecosystem issues, and build a cross-border trade ecosystem with borderless application circulation, trustworthy, and traceable data assets through trust, so that each participant can share resources and value to innovate Thinking leads a new era in which the digital economy drives the development of the real economy. The core business includes blockchain infrastructure investment, health care fund, agricultural and forestry resource industry investment, environmental and ecological enterprise services, structured financing, asset management and special investment, management of blocks The scale of the chain industry guidance fund exceeds 50 billion rubles. Established in July 2015, the Russian Pearl Sea Service Company aims to find effective partners and investors for Chinese and Southeast Asian companies and establish mutual trust business partnerships. It forms a carrier for exchanges and cooperation between governments and institutions in various fields. It also provides the most valuable services for Chinese and Southeast Asian enterprises in business legal affairs, customs clearance, logistics and other aspects. In the field of innovation and technology, it has become a well-known professional technical solution provider in the Eurasian green economy and trade system. Its shareholding companies include: Qinhuangdao Hotel, the largest Chinese hotel in Eastern Europe, Northwest Russia Import and Export Trading Company, and Russia-China Business Center.

 

 

 

1.3 Team introduction

​

The GTP team includes developers who are prestigious in the industry and have experience in successful projects, as well as senior operators and experts who have been immersed in the target industry for many years. The GTP team is a team that focuses on the basics and landing applications of the blockchain industry. There are now more than 70 blockchain research, technology and business teams. With the development of GTP and the increase in application market share, the fund The club will adopt an open attitude to attract talents who are willing to contribute to the community.

 

 

 

1.4 Terminology

​

• Address/wallet

  • The address or wallet composed of account credentials on the GTP network is generated by a key pair, which includes a private key and a public key, and the latter is derived from the former through an algorithm. The public key is usually used for session key encryption, signature verification, and encryption of data that can be decrypted by the corresponding private key.

​

• ABI

  • Application Binary Interface (ABI) is an interface between two binary program modules. Usually, one of these modules is a library or operating system tool, and the other is a user-run program. ​​​

​

• API

  • Application programming interface (API) is mainly used for user client development. With API support, it is also convenient for subsequent docking with governments and international organizations for currency acceptance. At the same time, it is also convenient for subsequent access to third-party apps to accelerate the growth of the ecosystem.

​

• assets

  • In the GTP documentation, assets are the same as tokens, also called GTP-30 tokens.

​

• Bandwidth point (BP)

  • In order to maintain the smooth operation of the network, GTP network transactions use BP as fuel. Each account can get 5000 free BP per day, and more can be obtained by freezing BP's B-iD. Both B-id and GTP-30 token transfers are normal transactions and cost BP. The deployment of smart contracts and execution of transactions will consume BP and energy.

​

• piece

  • The block contains the digital record of the transaction. A complete block is composed of magic number, block size, block header, transaction counter and transaction data.

​

• Block rewards

  • Mass production rewards will be sent to the sub-account (address/wallet). Super representatives can obtain rewards intelligently during the transaction or directly through the API.

​

• Bulk

  • The block header is part of the block. The GTP block header contains the hash of the previous block, Merkle root, timestamp, version and witness address.

​

• Cold wallet

  • A cold wallet, also known as an offline wallet, completely disconnects the private key from any network. Cold wallets are usually installed on "cold" devices (for example, computers or mobile phones that remain offline) to ensure the security of GTP private keys.

​

• DAPP

  • A distributed application is an application that can run without a central relying party. An application that enables direct interaction/protocol/communication between end users and/or resources without an intermediary.

​

• gRPC

  • gRPC (GTP-RPC Remote Procedure Call) is an open source remote procedure call (RPC) system originally developed by Google. It uses HTTP/2 for transmission, uses protocol buffers as an interface description language, and provides functions such as authentication, two-way flow and flow control, blocking or non-blocking binding, and cancellation and timeout. It generates cross-platform client and server bindings for multiple languages. The most common usage scenarios include connecting services in a microservice style architecture and connecting mobile devices and browser clients to back-end services.

​

• Hot wallet

  • Hot wallets (also known as online wallets) allow users to use their private keys online and use self-developed encryption algorithms to ensure the security of funds and stocks held by users.

​

• JDK

  • The Java Development Kit is the Java SDK for Java applications. It is the core of Java development, including Java application environment (JVM + Java class library) and Java tools.

​

• OY-BDB

  • GTP has OY-BDB in the memory of the full node, which can store all new branch chains generated within a certain period of time, and supports witnesses to quickly switch their active chains from the main chain to the new main chain.

​

• Level database

  • The main purpose of initially adopting LevelDB is to meet the requirements of rapid R/W and rapid development. After launching GTP-NET (Independent Network Communication Protocol), GTP upgraded its database to a fully customized database to meet its own needs and secure transactions with hundreds of billions of dollars a day.

​

• Merkelgen

  • The Merkle root is the hash of all the hashes of all transactions included as part of the block in the blockchain network.

​

• Public Testnet (Sofia)

  • The network version that runs in a single-node configuration. Developers can connect and test functions without worrying about financial losses. Testnet tokens have no value, anyone can ask for more from the public faucet.

​

• RPC

  • In distributed computing, remote procedure call (RPC) refers to a computer program that makes a procedure (subroutine) execute in a different address space (usually on another computer sharing a network), and its encoding is like ordinary (Local) procedure call without the programmer explicitly coding the details for remote interaction.

​

• Scalability

  • Scalability is a function of the GTP protocol. It is the ability of a system, network, or process to handle an ever-increasing workload, or its potential to be expanded to accommodate this growth.

​

• Smallest unit

  • BMCS replaces drop as the smallest unit of GTP. 1 GTP = 1,000,000

​

• BMCS.

  • Flux

  • High throughput is a function of the GTP main network.

​

• SR

  • Super representative, contribution ranking or election winning

​

​

2 Technical architecture

​

GTP uses a three-tier architecture, divided into storage layer, core layer and application layer. The GTP protocol complies with Google Protobuf, which essentially supports multi-language extensions.

 

2.1 Core

​

The core layer has several modules, including smart contracts, account management and consensus. A stack-based virtual machine is implemented on GTP, and an optimized instruction set is used. In order to better support DAPP developers, Solidity4 was selected as the smart contract language, and later other high-level languages were also supported. In addition, the consensus mechanism of GTP is based on entrusted proof of equity

(DPoS), and many innovations have been made to meet its unique requirements.

 

2.2 Storage

​

GTP has designed a unique distributed storage protocol, which includes block storage and state storage. In the design of the storage layer, the concept of graph database is introduced to better meet the needs of diversified data storage in the real world. And there is artificial intelligence AI under development.

 

2.2.1 Blockchain storage

​

GTP blockchain storage chooses to use LevelDB, which was developed by Google and has been proven successful by many companies and projects. It has high performance and supports arbitrary byte arrays as keys and values, singular acquisition, placement and deletion, batch placement and deletion, two-way iterators, and simple compression using the very fast Snappy algorithm.

 

2.2.2 State storage

​

GTP has an OY-BDB in the memory of the full node, which can store the chains of all new branches generated within a certain period of time, and supports the witnesses to quickly switch from their active chains to the new main chain. It can also protect blockchain storage by making it more stable to prevent abnormal termination in an intermediate state.

 

2.3 Application

​

Developers can create various DAPP interesting functions and custom wallets on GTPAPP. Since GTP can deploy and execute smart contracts, the opportunities for utility applications are limitless.

 

2.4 Agreement

​

The GTP protocol complies with Google Protocol Buffer 5, which is a language-independent, platform-independent and extensible method of serializing structured data. It can be used for communication protocols and data storage, so that software engineers from all over the world can join in the development of derivative programs. Come in.

 

2.4.1 Protocol buffer

 

Protocol buffer (Protobuf) is a flexible, efficient, and automated mechanism for serializing structured data, similar to JSON or XML, but smaller, faster, and simpler. Protobuf(.proto) definition can be used through the official code generator for C++,

Generate code in Java, C#, Python, Ruby, Golang and Objective-C languages. Various third-party implementations are also available for many other languages. Protobuf simplifies client development by defining and optimizing data transmission through a unified API. Customers can obtain API .proto from GTP's protocol repository and integrate through the automatically generated code library. As a comparison, the protocol buffer is 3 to 10 times smaller than XML, and 20 to 100 times faster than XML, and the syntax is less ambiguous. Protobuf generates easily accessible data access classes.

 

2.4.2 HTTP

​

The GTP protocol provides a RESTful HTTP API alternative to the Protobuf API. They share the same interface, but the HTTP API can be easily used in a javascript client.

​

2.5 Decentralized exchange GTPex

​

The GTP network itself supports decentralized switching functions. The decentralized exchange is composed of multiple trading pairs. A trading pair (denoted as an "exchange") is a trading market between GTP-30 tokens or between GTP tokens and BID. Any account can create a trading pair between any tokens, even if the same trading pair already exists on the GTP network. The GTP network stipulates that the weights of two tokens in all transaction pairs are equal, so their

The balance ratio is the price between them. For example, consider a trading pair containing two tokens, namely

ABC and DEF. The balance of ABC is 10 million, and the balance of DEF is 1 million. Since their weights are equal, 10 ABC = 1 DEF. This means that the ratio of ABC to DEF is 10 ABC / DEF.

​

3 Consensus mechanism

​

3.1 Entrusted Proof of Stake (DPoS)

​

The earliest consensus mechanism is the Proof of Work (PoW) consensus mechanism. The protocol is currently implemented in Bitcoin and Ethereum. In the PoW system, transactions broadcast over the network are grouped into new blocks for confirmation by miners. The confirmation process involves using a cryptographic hash algorithm to hash the transaction until the merkle root is reached, thereby creating a merkle tree. Input/output length size-the algorithm can pass in input of any length and output a fixed-length hash value. Efficiency-The algorithm is relatively easy and fast to calculate.

​

Resistance before imaging-For a given output B, it is impossible to find any input x such that h(x) = z. In other words, the hash algorithm h(x) is a one-way function, given the input, only the output can be found. The opposite is impossible.

​

Collision resistance-Finding any pair X1 + x? of h(xj = h(x ^) is computationally infeasible, in other words, the probability of finding two different input hashes to the same output is very low. Imply that the second preimage resists.

​

The second pre-image resistance-given x7, so given h(x ^), it is impossible to find x computationally feasible? Make h(xj = h(x ^.) although this property is similar to collision resistance, but the The difference in attributes is that it says that an attacker with a given x, I will find that the same x? hash output cannot be found computationally.

Determinism-Map each input to one and only one output.

​

Avalanche effect-a small change in the input will cause the output to be completely different.  These attributes give the cryptocurrency network its intrinsic value by ensuring that the attack will not harm the network. When miners confirm the block, they will receive reward tokens as a built-in incentive for network participation. However, with the steady growth of capital in the global cryptocurrency market, miners began to centrally manage and concentrate their computing resources on hoarding tokens as assets, rather than for network participation purposes. CPU miners gave way to GPUs, and GPUs gave way to powerful ASICs. In a noteworthy study, the total power consumption of Bitcoin mining is estimated to be as high as 3 GW, which is comparable to the power consumption in Ireland. This study also predicts that the total power consumption will reach 8 GW in the near future.

​

In order to solve the problem of energy waste, many new networks have proposed a Proof of Stake (PoS) consensus mechanism. In the PoS network, token holders lock their token balances to become block verifiers. The validators take turns to suggest and vote for the next block. However, the problem with standard PoS is that the influence of the verifier is directly related to the number of locked tokens. This has caused all parties to hoard a large amount of network base currency, which has undue influence on the network ecosystem.

 

The GTP protocol network generates a block every three seconds, and each block grants 32 B-IDs to the super representative. A total of B-IDs will be awarded to 27 super representatives (super representatives) each year. Whenever the Super Representative completes the production of commodities, the reward will be sent to the sub-account in the Super Ledger. Super representatives can check but cannot use these B-ID tokens directly.

​

Each super representative can withdraw money once every 24 hours and transfer the reward from the sub-account to the designated super representative account.

 

 

4 accounts

​

4.1 Type

​

  The three types of accounts in the GTP network are ordinary accounts, token accounts and contract accounts.

1. Regular accounts are used for standard transactions.

2. The token account is used to store GTP-30 tokens.

3. A contract account is a smart contract account created by a regular account, and it can also be triggered by a regular account.

​

4.2 Creation

​

  There are three ways to create a GTP account:

1. Create a new account via API

2. Transfer B-ID to new account address

3. Transfer any GTP-30 tokens to a new account address

It can also generate an address (public key) and a private key, and it is not

Offline key pair recorded by GTP network. User address generation algorithm includes generating key pair,

Then extract the public key (a 64-byte byte array representing the x and y coordinates). Use the SHA3-256 function (the SHA3 protocol used is KECCAK-256) to hash the public key and extract the last 20 bytes of the result. Add 41 at the beginning of the byte array and make sure that the initial address length is 21 bytes. Use the SHA3-256 function to hash the address twice, and use the first 4 bytes as the verification code. Add the verification code to the end of the initial address, and obtain the address in base58check format through base58 encoding. The encoded Mainnet address starts with T and is 34 bytes in length.

​

4.3 Structure

​

  The three different account types are "general", "asset issuance" and "contract". The account contains 7 parameters:

1. account_name: The name of this account, for example ZhouAccount.

2. type: What is the type of this account, such as 0 (representing the "normal" type).

3. balance: The balance of the account, for example, 2354678.

4. Vote: get votes for this account, for example {(" 0x1b7w ... 9xj3", 323), (" 0x8djq ... j12m", 88), ..., (" 0x82nd ... mx6i", 10001)}.

5. asset: Other assets of the expected B-ID in this account, such as {<" WishToken", 66666>, <" Dogie", 233>}. Simply put, funds, options, stocks, etc.

6. latest_operation_time: The latest operation time of the account.

​

5 blocks

​

  A block usually contains a block header and several transactions.

​

                     Protobuf data structure:

 

5.1 Block header

​

  The block header contains raw_data, witness signature and blockID

 

5.1.1 Raw data

​

  The raw data is represented as raw_data in Protobuf. It contains the original data of the message, which contains 6 parameters:

1. timestamp: The timestamp of this message, for example, 1543884429000.

2. txTrieRoot: The root of the Merkle tree, 7dacsa...3ed.

3. parentHash: The hash of the last block, for example, 7dacsa...3ed.

4. number: The height of the block-for example 4638708.

5. witness_address: The address of the witness packaged in this block, for example: 41928c ... 4d21.

​

5.1.2 Witness signature

​

The witness signature is expressed as a "witness signature" in Protobuf, which is the signature of this block header from the witness node.

​

5.1.3 Block ID

​

  In Protobuf, the block ID is represented as blockID. It contains the atomic identifier of a block. The block ID contains 2 parameters:

1. hash: The hash of the block.

2. number: The hash value and height of the block.

​

5.2 Transaction

​

5.2.1 Signature

 

The GTP transaction signature process follows the standard ECDSA encryption algorithm, with SECP256K1 selection curve. The private key is a random number, and the public key is a point on the elliptic curve. The public key generation process includes: first generating a random number as the private key, and then multiplying the base point of the elliptic curve by the private key to obtain the public key. When a transaction occurs, the original transaction data is first converted into byte format. Then SHA-256 hash the original data. Then, the private key corresponding to the contract address signs the result of the SHA256 hash. Then add the signature result to the transaction.

​

5.2.2 Bandwidth Model

​

Ordinary transactions only consume bandwidth points, while smart contract operations consume energy and bandwidth points. There are two types of bandwidth points available. Users can obtain bandwidth points by freezing B-id, and at the same time, they can use 5000 available bandwidth points every day.

​

When broadcasting a B-ID transaction, it will be transmitted and stored on the network in the form of a byte array. The number of bandwidth points consumed by a transaction = the number of transaction bytes multiplied by the bandwidth point rate. For example, if the byte array length of a transaction is 200, the transaction consumes 200 bandwidth points. However, if the B-ID or token transfer results in the creation of the target account, only the bandwidth points used to create the account will be deducted, and no other bandwidth points will be deducted. In the case of creating an account, the network will first consume the bandwidth points obtained by the transaction initiator from the frozen B-ID. If this number is insufficient, the network will consume the B-ID of the transaction initiator.

​

In the standard B-ID transmission scheme from one B-ID account to another B-ID account, the network first consumes the bandwidth points obtained by the transaction initiation program to freeze the BID. If this is not enough, then it will be consumed from the free 5000 daily bandwidth points. If this is not enough, then the network will consume the B-ID of the transaction initiator. This number is calculated by multiplying the number of bytes in the transaction by 10 BMCS. Therefore, for most B-ID holders who may not have to freeze their B-ID to participate in the Super Representative voting, the first step will be automatically skipped (because the frozen B-ID balance = 0), and there are 5000 available every day Bandwidth powers transactions.

​

For GTP-30 token transmission, the network first verifies whether the total available bandwidth points of the issued token assets are sufficient. If not, consume the bandwidth points obtained by freezing the B-ID. If there are still not enough bandwidth points, it will consume the B- of the transaction initiator

ID.

​

5.2.3 Cost

​

GTP networks usually do not charge fees for most transactions, but due to system limitations and fairness, bandwidth usage and transactions do charge certain fees.

The fees are divided into the following categories:

1. Bandwidth points are occupied by normal transactions. Users can use free daily bandwidth points (5000) or freeze B-ID to get more. When the bandwidth point is not enough, the B-ID will be used directly from the sending account. The required B-ID is the number of bytes * 10 BMCS.

2. Smart contracts consume energy (Section 6), but bandwidth points are needed to broadcast and confirm transactions. The bandwidth cost is the same as above.

3. All inquiry transactions are free. It does not consume energy or bandwidth.

4. The GTP network also defines a set of fixed fees for the following transactions:

   1. Create witness node: 9999 T

   2. Issue GTP-30 token: 1024 B-ID

   3. Create a new account: 0.1 B-ID

   4. Create exchange pair: 1024 B-ID

​

5.2.4 Transaction as proof of equity (TaPoS)

​

GTP uses TaPoS to ensure that all transactions are confirmed on the main blockchain, and it is difficult to forge counterfeit chains. In TaPoS, the network requires that every transaction includes part of the hash value of the most recent block header. This requirement prevents transactions from being replayed on branches that do not contain the referenced block, and also sends a signal to the network that certain users and their interests are on certain branches. This consensus mechanism can protect the network from denial of service, 51% denial, selfish mining and double spending attacks.

​

5.2.5 Transaction Confirmation

​

After broadcasting the transaction to the network, include it in future transactions. After 19 blocks (including its own block) are dug out on GTP, the transaction is confirmed. Each block is made by one of the top 27 super representatives in a round-robin way. It takes about 3 seconds for each block to be mined on the blockchain. The time of each super representative may vary slightly due to network conditions and machine configuration. Usually, the transaction is considered fully confirmed after about 1 minute.

​

6 Smart contract

​

6.1 Introduction

 

Smart contract is a digital verification contract negotiation agreement. They define the rules and penalties associated with the agreement and automatically enforce these obligations. The smart contract code can facilitate, verify, and execute the negotiation or execution of an agreement or transaction. From the perspective of tokenization, smart contracts can also facilitate automatic fund transfers between participants if certain conditions are met.

 

GTP smart contracts are written in Solidity language. Once written and tested, they can be compiled into bytecode and then deployed on the GTP network of the GTP virtual machine. After deployment, the smart contract can be queried through the contract address. The Contract Application Binary Interface (ABI) shows the calling function of the contract and is used to interact with the network.

​

6.2 Energy Model

​

  The maximum energy limit for deploying and triggering smart contracts is a function of several variables:

• Freeze 1 B-ID generates dynamic energy of 50,000,000,000 (total energy limit)/(total energy weight)

• Energy limit is the daily account energy limit for freezing B-ID

• The remaining daily account energy in the frozen B-ID is calculated as energy limit-energy used

• The fee limit in B-ID is set in the smart contract deployment/triggering call

• Available B-IDs remaining in the account

• If you buy directly, the energy of each B-ID (10 BMCS = 1 energy) = 100,000, and SR can vote for adjustments. There are two consumption scenarios that can be used to calculate the maximum energy limit and trigger for deployment.  

 

6.3 Deployment

 

When compiling the GTP physical smart contract, the GTP virtual machine will read the compiled bytecode. The bytecode consists of parts used for code deployment, contract code and Auxdata.

​

Auxdata is an encrypted fingerprint of the source code for verification. Deploy the bytecode to run the constructor and set the initial storage variables. The deployment code also calculates the contract code and returns it to TVM. ABI is a JSON file that describes the functions of the GTP smart contract. This file defines the function name, its payability, function return value and its state variability.   

​

6.4 Energy Model

​

  The maximum energy limit for deploying and triggering smart contracts is a function of several variables:

• Freezing 1 GTP generates dynamic energy of 50,000,000,000 (total energy limit)/(total energy weight)

• Energy limit is the daily account energy limit for freezing GTP

• The remaining daily account energy in the frozen GTP is calculated as energy limit-energy used

• The fee limit in GTP is set in the smart contract deployment/triggering call

• Available GTP remaining in the account

• If you buy directly, the energy of each GTP (BMCS = 1 energy) = 100,000, and SR can vote on adjustments

​

There are two consumption scenarios that can be used to calculate the maximum energy limit and trigger for deployment. The logic can be expressed as follows:

​

6.5 Trigger function

​

After the GTP smart contract is deployed, its functions can be triggered separately through GTPStudio or through API calls. State change functions require energy, while read-only functions can be executed without energy.

​

7 Governance

​

7.1 Super Representative

​

7.1.1 General

 

Every account in the GTP network can apply and have the opportunity to become a super representative (represented as SR). Everyone can vote for SR candidates. The top 27 candidates with the highest number of votes will become SRs with voting rights and obligations. Voting is calculated every 6 hours, and the SR will be changed accordingly.

 

In order to prevent malicious attacks, it is necessary to pay a price to become an SR candidate. When applying, 9999 GTP will be deducted from the applicant's account. Once successful, the account can join the SR election.

​

7.1.2 Election

​

GTP Power (denoted as BP) is required to vote, and the number of BP depends on the voter’s frozen assets (GTP).

BP is calculated in the following way:

​

1 BP = 1 GTP frozen to get bandwidth

​

Each account in the GTP network has the right to vote for its own SR.

​

After the release (unfreeze, available in three days), users will not have any frozen assets and will lose all BP accordingly. As a result, unless the GTP is frozen again for voting, all votes will be invalid for ongoing votes and future votes.

​

Please note that the GTP network only records the most recent votes, which means that each new vote will negate all previous votes.

​

7.1.3 Rewards

​

Voting reward

​

Also known as candidate rewards, the top 127 candidates updated every round (6 hours) will share 115,200 GTP. Rewards will be distributed according to the voting weight of each candidate. Each year, the total reward for candidates will be 168,192,000 GTP.

​

Total voting rewards per round

Why is 115,200 GTP per round?

115, 200 GTP = total vote reward per round (VR/round)

VR/round = 16 GTP/block × 20 blocks/min × 60 mins/hr × 6 hrs/round

 

Annual total voting reward

Why is it 168,192,000 GTP per year?

168, 192, 000 GTP = total vote reward per year (VR/year)

VR/year = 115, 200 GTP/round × 4 rounds/day × 365 days/year

​

Block reward

​

Also known as the Super Representative Award, the top 27 elected candidates (SR) will share approximately 230,400 GTP per round (6 hours). The reward will be evenly distributed between 27 SRs (minus the total reward blocks missed due to network errors). In total, 336,384,000 GTP will be awarded to 27 SRs each year.

 

Total block reward per round

Why is 230,400 GTP per round?

230, 400 GTP = total block reward per round (BR/round)

BR/round = 32 GTP/bloc × 20 blocks/min × 60 mins/hr × 6 hrs/round

​

Annual total block reward

Why is it 336,384,000 GTP per year?

336, 384, 000 GTP = total block reward per year (BR/year)

BR/year = 230, 400 GTP/round × 4 rounds/day × 365 days/year

​

January 1, 2022

Before January 1, 2022, there will be no inflation in the GTP network and the GTP Foundation. All block rewards and candidate rewards will be awarded before that date.

 

Reward calculation

​

SR reward calculation:

total reward = vote reward (VR) + block reward (BR)

VR = total VR ×(votes SR candidate received / total votes)

BR = (total BR / 27)-block missed × 32

Reward calculation for SR candidates ranked 28-127:

total reward = vote reward (VR)

VR = total VR ×(votes SR candidate received / total votes)

​

8 DAPP development

​

8.1 API

​

The GTP network provides more than 60 HTTP API gateways for you to choose from to interact with the network through complete and physical nodes. In addition, GTPWeb is a comprehensive JavaScript library containing API functions, enabling developers to deploy smart contracts, change the state of the blockchain, query blockchain and contract information, conduct transactions on GTPex, and more. These API gateways can be directed to the local private network, GTPtest test network or GTP main network.

​

8.2 Network

 

GTP has a SOFIA testnet and a Mainnet. Developers can connect to the network by deploying nodes, interacting through GTPStudio, or using APIs through GTPGrid service. The GTPGrid service consists of a cluster of load balancing nodes hosted on AWS servers around the world. With the expansion of the scale of DAPP development and the increase in API calls, GTPGrid successfully coped with the increase in API traffic.

​

8.3 Tools

​

GTP provides a set of development tools that enable developers to create innovative DAPPs. GTPBox is a framework that allows developers to test and deploy smart contracts through GTPWeb API. GTPGrid is a load balancing and managed API service that allows developers to access the GTP network without running their own nodes. GTPGrid provides access to the Sofia testnet and GTP mainnet. GTPStudio is a comprehensive integrated development environment (IDE) that enables developers to compile, deploy and debug their Solidity smart contracts. GTPStudio contains an internal full node that can create a private local environment for smart contract testing before deployment. The GTPWeb API library connects developers to the network through a variety of HTTP API calls wrapped in JavaScript.

 

8.4 Resources

​

The GTP Developer Center is a comprehensive API documentation website dedicated to developers who want to build on the GTP network. The Developer Center provides a high-level conceptual understanding of GTP and guides users to the detailed information of interaction with the network. These guidelines will guide developers through the process of node setup, smart contract deployment and interaction, API interaction and implementation, building sample DApps, and using each developer tool.

​

In addition, you can get developer community channels through Discord.