Budget balancer
Budget Balancer is a Phat Contract used to balance the computing power rewards between Phala and Khala networks, aiming to ensure the effective working of the Gemini Tokenomics.
How it works
The budget balancer adjusts the rewards budget by querying the total number of shares for workers on both Phala&Khala networks daily, calculating the reward allocation between the two chains, and sending a budget change transaction to both chains.
It consists of three major components:
Subsquid query service
Regularly query information on Phala and Khala chains and store data snapshots
Generate snapshot database and output API for the phat contract to read relevant data
Contract, which is divided into two parts:
Computation part
The strategy (rules) of the contract is all coded in the computation part, which calculates the budget amount of the two chains for each period.
Transaction sending
Based on the calculated amount and comparing the on-chain transaction restrictions, it determines whether a transaction has been issued within this period (only one transaction can be completed in a period).
If the judgment is correct, send the transaction request to the chain from the contract-generated address. The transaction will be sent to both Phala&Khala.
On-chain functions and on-chain contract account whitelist
The function of flexibly adjusting the on-chain budget through transactions has been developed on the chain, and the budget can be adjusted by sending transactions from specific accounts
There are two ways to change the budget on the chain
Using the above function, the whitelisted account configured on the chain can be used to send transactions, which can directly change the budget without going through community governance; however, the configuration of whitelist permissions for the account needs to be authorized through
Motionvoting.Submit a
Motionproposal to directly change the budget to a specific value, and the change will take effect after the vote is passed
Replacing the balancer strategy is to deploy a new balancer contract, thereby generating a new contract address, and replace the old contract address in the whitelist through Motion voting to achieve the strategy update.
The mathematical logic of the balancer
As we mentioned in Gemini Tokenomics (Worker Rewards), Phala and Khala share a total of 700 million in computing power rewards. The reward distribution between the two chains depends on the computing power quality & quantity of each chain, that is, the sum of shares of workers on the chain.
Basic parameters
Halving cycle = 180 days
It's physical time, regardless of the number of blocks
Starting from the 3rd halving cycle on June 12, 2023
Initial total budget for each unit = 720K / 24 / 60 * P = 500P
Assuming the time of each calculation cycle is P minutes
720K is the standard daily budget for the first halving cycle
The real-time halving coefficient = 0.75^(n-1)
n is the halving period (n for the first period is 1, not 0).
n = 3 + roundup[(day(now) - (2023.6.12)) / 180days]
In summary, each unit's real-time total budget = 500P * 0.75^(n-1)
key equations
Real-time total budget per unit = Phala's total budget per unit + Khala's total budget per unit
Phala's total budget per unit / Phala total share = Khala's total budget per unit / Khala total share
Phala's total budget per unit = Phala's total budget per block * Phala's actual block number per unit
Khala's total budget per day = Khala's total budget per block * Khala's actual block number per unit
From this, we can deduce the equations and get the final formula
Phala's total budget per block = Khala's total share / (Phala's total share + Khala's total share) / Phala's actual block number per unit * Initial total budget per unit * Real-time halving coefficient
Khala's total budget per block = Phala's total share / (Phala's total share + Khala's total share) / Khala's actual block number per unit * Initial total budget per unit * Real-time halving coefficient
The actual block number of each unit on each chain and the total share of workers can be calculated via the Subsquid query service.
Budget balancer & Halving period
Once we calculated the halving cycle using block time.
Before the Budget balancer was launched, Khala staking mechanism started on #1,467,069, and it went to the next halving period every 1,296,000 blocks.
Phala staking mechanism started on #2,491,061, and it went to the next halving period after the Budget balancer launched
Now we calculated the halving cycle using calendar days
The internal rules of the Budget Balancer implement it.
We have set the initial value to June 12th, 2023 (this day is the start of the third halving period of the Khala network). From then on, every 180 calendar days, it will enter the next halving period.
Phala network follows the same rule.
Why we made it
When two chains share one tokenomics, it is necessary to unify the halving periods; otherwise, the two chains may easily experience situations where one side has significantly higher rewards due to the gap in halving periods.
It is difficult to ensure that the block speeds on both sides are the same, making it impossible to guarantee consistent halving periods based on blocks. Therefore, it must be adjusted to use natural time as the unit.
The block production speed will be considered in the budget balancer's adjustment parameters, ensuring that workers' earnings on both sides are equal within the same unit of natural time. If the block production speed slows down, the budget will naturally increase, so the current issue of unstable returns due to blocked blocks will also be resolved.
Two constraints for budget adjustment
Nonce constraint
Only one transaction can be successfully executed in a unit of time.
This is to prevent excessive budget adjustments due to Balancer bugs.
Additionally, if the Balancer does experience a bug, we can propose a motion for a budget change, inputting the nonce value for the next period's transaction. In this way, a buggy Balancer cannot interfere with on-chain information during the current and next period, serving as a protective measure.
Max budget
To avoid excessively issuing computing rewards due to unusually high budgets caused by special circumstances (hacks, bugs, etc.), we have set a basic limit: the budget on a single chain can only be adjusted up to twice the total budget for a single block under normal circumstances.
At the same time, if an extreme situation occurs where block production is slow, causing a shortage of rewards for a given period, we need to consider how to compensate for this issue in the next nonce period. One precondition is ensuring the block production speed can recover after the t+1 period. Thus, even if no rewards were issued in the previous period, as long as the second period is normal, we can effectively compensate for the amount of the first period using the twice-the-budget limit.
Therefore, we have set the maximum budget value to twice the total budget, which can be used to compensate for deficiencies in the previous period during extreme situations.
Potential issues and solutions
How to ensure security?
The contract deployed on Phat Contract is not controlled by humans but by open-source with controllable strategies.
The whitelist accounts for transactions sent on the chain are contract accounts, not controlled by humans.
Is the Budget Balancer decentralized?
Yes, it is.
The governance of the whitelist relies on the community, and the data query service is deployed in a decentralized manner through Subsquid, not locally.
How to handle risks when they occur? (fallback plan)
If there is an issue with Subsquid:
We can deploy a local Subsquid database for temporary use within 2-4 hours and complete motion governance to change the contract (in reality, using the same contract strategy but changing the database API connected to the contract) within 2 days. This temporary solution can resolve the issue within 1 period of the contract strategy.
If there is an issue with the contract:
We can directly modify the on-chain budget through motion voting and remove the contract address from the whitelist to prevent the contract from causing secondary on-chain failure.
Last updated
