Assign Dapp source files to supernodes
All source files of the Dapp to be assigned to each Supernode are assigned to be received from Dapp developers.
Records information about the storage and provided CR of each supernode and the source files currently held by each supernode in the supernode routing table.
Distribute all Dapp source files to store up to the maximum capacity of storage provided by each supernode.
At least three supernodes should hold the same source files so that supernodes can reliably deliver source files to another subject. The minimum number of supernodes required can then be changed through an irregular agreement between supernodes.Each supernode receives compensation according to the amount of storage from Dapp developers.
Therefore, supernodes have no incentives to distinguish or prefer certain Dapp source files.
Therefore, supernodes select the storage space that can be provided when participating in the network and allocates the storage space accordingly.
Selected supernodes decide that which source file of what Dapp is assigned aboout MCR of macronodes.
For this, macronodes reveal how much MCR will be mendatorily provided to join the network. (The minimum amount follows a standard amount in the network.)
Macronodes can provide SCR by additional token staking other than MCR and get compensation.
The number of MCR slots per Dapp source file is determined by selected supernodes, and the number of SCRslots is determined by Dapp developers. Dapp developers may request additional number of MCR slots if desired.
Selected supernodes assign source files according to the provided MCR capacity of macronodes and selection result.
Selected supernodes have the overall mean MCR for each macronode. Distribute each source file so that it does not differ from the macro-node verification/operation participation rate.This is to execute all Dapps in the network better.
To execute the pool of verifiers, need to know which micronode is online.
The activation dashboard that checks the online status of micronodes is required.
One dashboard does not reveal the online status of the entire micronodes. Each selected supernode divides the micro-node into open dashboards. This is because if a dashboard is managed by one person, it will be possible to manipulate the pool of verifiers.
Screened supernodes each indicate whether their micronodes are online or not on their own dashboards.
All registered micronodes are allocated according to the number of selected supernodes.
Based on the activation dashboard, micronodes that will verify GBT movements using micronode’s GBT UTXO will be selected.
Record the GBT price online.