Micronodes generate transactions operating SC.
Generated transactions are delivered to supernodes.
Macronodes keeping source files required for each transaction are selected as verifiers of each transaction.
Information of who has what source file is recorded in the block by distributing the information of what source file selected supernodes should have.
If the fore and alt relationship of transactions has a significant effect, a standard is required to decide what transaction should be processed first.
Each supernode processes transaction arrangement in a promised oerder among supernodes.
Supernodes arrange transactions sent from micronodes in chronological order. In case of transactions occuring at the same time, transactions arrived earlier are arranged in the first place.
In case of micronodes generated transactions are under penalty, the transactions sent by the micronodes are pushed back from priority.
It should not cause the network inefficiency from the low number of arrangement creating more verification pools and transaction radio waves.
It should not delay transaction processes because of the high number of arrangement.
If the certain number is not fulfilled for a certain time period, transactions arranged in micronodess are sent.
Macronodes selected as verifiers downloads transactions arranged by supernodes.
After executing source files and SC corresponing to received transactions, result values are computed.
Generates blocks with result values of each transaction by each source file and submits the header hash to supernodes.
Delivers the hash of relevant blocks to three supernodes.
Supernodes receiving the voting result value are determined sequentially.
Supernodes received the hash values record who submitted what value and who did not submit the answer among verifiers.
Three supernodes vote whether to generate a GBT block according to the verification value by each source file. A GBT block is generated upon the agreement of 2/3.
A supernode recognizes verifiers who submitted Hash that is agreed by more than 2/3 as positive and generate a SC block by downloading transactions submitted by the macronodes. A block connected through this process is defined as the newest condition value.
In case of more than 2/3 supernodes disagreed to generate blocks, the block generation is nullified.
For supernodes disagreed on the agreement by more than 2/3, a certain proportion of their Staking is slashed. (See the participant-supernode )
Supernodes always release the newest condition, and macronodes always renew the newest condition.
If verifiers did not reach an agreement of transactions of certain source files, a bundle of the relevant transactions are defined as a block after supernodes verify them.
The more complicated computing process is necessary for verification, the more computing resources are used by macronodes.
To cover the consuming computing costs, it should be defined that how much compensation is given to what kind of computing pattern.
It is because of the difficulty to calculate the price based on the amount of computing for every transaction for the high number of transaction.
When the foundation starts the network, it specifies available types of SC in the GBT Protocol and calculates computing resources consumed by relevant transactions.
Defines the amount of compensation based on the amount of consumed computing resources by each transaction on a Fiat basis.
Developers stake the expected amount of tokens in advance which are necessary to their Dapp transaction process.
Developers are alarmed if their staking is shorter than the amount to be settlled on every first day of every month.
Developers should stake more to fill up the insufficient amount.
4 . If the amount of developer’s staking is insufficient to the requirement on every first day of every month, the computing process of the Dapp is not executed anymore.
If the sufficient amount of tokens for Dapp is not added over a week, source files of the Dapp are deleted from macronodess and supernodes.
Dapp developers stake tokens to pay for macronodes processing the relevant computing to the Dapp in the Staking contract.
On every first day of every month, supernodes execute the supernode storage compensation / punishment contract referring to the price table of each SC operation and macro verification result blocks. (See the GBT Protocol contract mechanism)
The settlement is proceeded through the contract operation, and tokens are shifted to GBT accounts of nodes receiving compensation in the Dapp developer’s Staking contract.
For macronodes disagreed on the agreement by more than 2/3, a certain proportion of their Staking is slashed.
In case of the verification value not submimited, as it is regarded as non-participation in the verification, a certain proportion of staking is deducted.
In this case, they cannot get compensation for the relevant verification.