SC transaction verification mechanism

1. Micronode SC transaction generation

Generate micronode transactions

  1. Micronodes generate transactions operating SC.

  2. Generated transactions are delivered to supernodes.

2. Verification pool selection

Select source file holders as verifiers

  1. Macronodes keeping source files required for each transaction are selected as verifiers of each transaction.

Record verifiers on the chain

  • Information of who has what source file is recorded in the block by distributing the information of what source file selected supernodes should have.

3. Arrange and deliver transactions of supernodes

The necessity to arrange transactions

  • If the fore and alt relationship of transactions has a significant effect, a standard is required to decide what transaction should be processed first.

Select supernodes arranging transactions

  • Each supernode processes transaction arrangement in a promised oerder among supernodes.

Method of transaction arrangement

  1. 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.

  2. In case of micronodes generated transactions are under penalty, the transactions sent by the micronodes are pushed back from priority.

The number of transactions delivered to verifiers as a bundle

  1. It should not cause the network inefficiency from the low number of arrangement creating more verification pools and transaction radio waves.

  2. It should not delay transaction processes because of the high number of arrangement.

  3. If the certain number is not fulfilled for a certain time period, transactions arranged in micronodess are sent.

4. Macronode verification

Receive transactions

  • Macronodes selected as verifiers downloads transactions arranged by supernodes.

Verification method

  • After executing source files and SC corresponing to received transactions, result values are computed.

Vote result values and select valid blocks

  1. Generates blocks with result values of each transaction by each source file and submits the header hash to supernodes.

  2. Delivers the hash of relevant blocks to three supernodes.

  3. Supernodes receiving the voting result value are determined sequentially.

5. Block confirmation

Confirm supernodes SC blocks

  1. Supernodes received the hash values record who submitted what value and who did not submit the answer among verifiers.

  2. 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.

  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.

  4. In case of more than 2/3 supernodes disagreed to generate blocks, the block generation is nullified.

  5. For supernodes disagreed on the agreement by more than 2/3, a certain proportion of their Staking is slashed. (See the participant-supernode )

Share the newest condition value

  • Supernodes always release the newest condition, and macronodes always renew the newest condition.

In case of disagreement

  • 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.

6. Compensation for the macronode transaction process

The necessity of the SC computing price table

  1. The more complicated computing process is necessary for verification, the more computing resources are used by macronodes.

  2. To cover the consuming computing costs, it should be defined that how much compensation is given to what kind of computing pattern.

  3. 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.

SC computing price table introduction method

  1. When the foundation starts the network, it specifies available types of SC in the GBT Protocol and calculates computing resources consumed by relevant transactions.

  2. Defines the amount of compensation based on the amount of consumed computing resources by each transaction on a Fiat basis.

Staking tokens of developers

  1. Developers stake the expected amount of tokens in advance which are necessary to their Dapp transaction process.

  2. Developers are alarmed if their staking is shorter than the amount to be settlled on every first day of every month.

  3. 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.

  4. 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.

Compensation delivery method

  1. Dapp developers stake tokens to pay for macronodes processing the relevant computing to the Dapp in the Staking contract.

  2. 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)

  3. 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.

7. Punishment

Staking deduction, in case of incorrect verification

  • For macronodes disagreed on the agreement by more than 2/3, a certain proportion of their Staking is slashed.

Decrease Staking or not compensate, in case of value not submitted

  1. 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.

  2. In this case, they cannot get compensation for the relevant verification.