Transactions for GBT transfer generated by micronodes are delivered to supernodes.
Three supernodes select verifier micronodes in order, referring the activation dashboard.
Three selected supernodes randomly select 100 verifier micronodes every 3 minutes in order.
Supernodes selecting verifiers are assigned in order of supernode registration. In case of new supernodes, they are assigned in the last order. In case of the order has passed, the first supernode’s turn comes back.
What micronode becomes a verifier is recorded in the supernode result value block.
If the balance is insufficient compared to the amount required by transactions, the acceptance of transactions may vary according to an order.
Therefore, it is required to arrange an order of which transaction should be processed first.
Each supernode processes transaction arrangement in a promised oerder among supernodes. The order assignment is processed in an order of supernode registration. The first supernode’s turn comes back if the order has passed.
Supernodes arrange transactions in an order of acceptance and confirm the process order.
In case of micronodes generated transactions are under penalty, the transactions sent by the micronodes are pushed back from priority.
If there are transactions received at the same time, they are arranged an order at discretion of supernodes.
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.
Micronodes verify the validity of transactions based on their condition values of downloaded transactions.
Verifier micronodes only store valid transactions verified by themselves.
Hash of the block is given to three supernode participated in the verifier selection.
Supernodes decide voting result values of who paid what value.
Supernodes received the hash values record who submitted what value and who did not submit the answer among verifiers.
According to the verification value, three supernodes vote whether to generate GBT blocks. In case of more than 2/3 agreement, GBT blocks are generated.
Supernodes regards nodes are correct if they submitted the hash value agreed by more than 2/3 and connect micronode blocks by downloading them. Supernodes define these connected blocks as the newest block status.
In case of more than 2/3 supernodes disagreed to generate blocks, the block generation is nullified. In this case, the verifier pool is re-selected and re-verifieid as the new verifier pool is slected.
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 micronodes always renew the newest condition.
In case of more than 2/3 of verifiers out of 100 fail to make an agreement on time, the verifier pool will be re-selected and the verification round is re-proceeded.
If the verification does not happen more than three times, all supernodes join to verify and conclude.
If microsnode cannot submit the verification (hash values) on time or fails to make a result satisfying 2/3 of nodes, it is regarded as the incorrect verification of micronodes.
Supernodes execute the compensation contract referring to micro verification result blocks. (See the GBT Protocol contract mechanism )
Incorrectly verified transactions sent by micronodes are pushed back from priority. They are pushed back from priority in SC operation.
For example, if transactions occurred by normal micronodes have an index of 100, transactions of micronodes caused 1 mistake have an index of 99. Micronodes having an index of 99 can be processed after other transactions are proceeded in the pool.
These values are restored to have a normal transaction order after a week.