[RFC-201/205] Staking and validator storage rework

[goran-ethernal]

Description

This PR refactors the workflow of validators staking and validator set storage in accordance to RFCs 201 and 205.

Edge is now used as L2, meaning it can operate only in bridge mode, and from now on called a Supernet. Its validators are registered on, and stake on the rootchain. A stake is transferred to childchain through the bridge mechanism, and the validator set is updated on the client itself. It is worth noting that staking is done in the native root token on the rootchain.

Two new contracts are deployed to rootchain:

1. StakeManager - a single instance contract on rootchain that has references to each supernet and handles staking for each of them on rootchain.
2. CustomSupernetManager - a contract that will be deployed for each supernet, which stores the validator info for a given supernet, whitelists, registers, and bridges stake to its supernet (childchain).

After StakeManager is deployed, and SupernetManager is deployed for the given supernet, deployer needs to register the SupernetManager to StakeManager by calling the registerChildChain function. This function will emit an event that contains an id of the SupernetManager (or given supernet). That id will be our new chainID of the childChain and needs to be added to genesis file generated by the genesis command (this can be done manually, but the deploy command provided by Edge, does this automatically).

After the contracts are deployed on the rootchain, SupernetManager deployer can whitelist validators in the genesis file to it, by calling the whitelist function (note, only the deployer can do this).

After the validators are whitelisted on the rootchain, each of them can proceed to register itself on the SupernetManager, by calling the register function. They need to provide their public bls key and signature when registering.

After validators register themselves on the SupernetManager, they can do the initial staking on the rootchain, by calling the stakeFor function on StakeManager, and providing the chainID the StakeManager emitted when registering SupernetManager, and the amount of tokens they want to stake. By using the chainID, StakeManager knows on which supernet the given validator wants to stake. It is worth noting that validators can change stakes as they wish before starting the child chain. Once the genesis staking is finalized by the SupernetManager deployer, validators stake at that moment will be considered final, and childchain can be started.

Genesis staking is finalized by the SupernetManager deployer by calling the finalizeGenesis function on the contract.

After genesis staking is finalized on the rootchain, supernet (childchain) can be started.

Once the supernet is started, each stake change on the rootchain is bridged to the ValidatorSet contract on the child chain which acts as an ERC20 implementation, where balances of accounts are their stake on the rootchain.

Unstaking is done on the supernet first, by calling the unstake function on the ValidatorSet contract. The user needs to wait for one epoch so that he can withdraw his stake from the supernet to the rootchain. Withdraw on the ValidatorSet contract, bridges the unstaked amount to the rootchain StakeManager contract. This releases the given stake on the rootchain and the user can withdraw it from the StakeManager by calling the withdrawStake function.

On the supernet (childchain) we have two new contracts:

1. ValidatorSet - as mentioned earlier is just a ERC20 implementation that wraps the stake change on rootchain to the childchain, where balance of an account on ValidatorSet is the stake of the given account on the rootchain. It also has bridge functionality to bridge the stake/unstake changes from one chain to the other. ValidatorSet has the old commitFunction to commit the ending of an epoch, but does not handle rewards distribution.
2. RewardPool - is a new contract that handles the reward distribution. It is called by the edge client in a state transaction to distribute rewards to block signers at the epoch-ending block. It uses a reward token (an ERC20 implementation, which can be either a native ERC20 token on childchain or a custom ERC20 token provided by the client.

A graphical look of the new flow can be seen on the picture below:

Deployment steps are now changed to support this:

1. Initialize secrets for initial validators.
2. Do genesis command. It is important to note that we added two new flags in genesis command:

• --reward-token - hex encoded byte code of a custom reward ERC20 token if clients want to use a custom ERC20 token for rewards. If not provided, native ERC20 token on child chain will be used for rewards.
• --reward-wallet - a mandatory flag where users define a reward wallet address and the amount of tokens that need to be premined to it on genesis (address:amount).

3. Either manually deploy the StakeManager and CustomSupernetManager contracts, initialize them and register supernet to StakeManager, or use the provided deploy command by Edge that simplifies this workflow. Keep in mind that if you opt to do the manual deployment of rootchain contracts, you will need to extract the chainID of you supernet that is emitted by StakeManager when registering the supernet to it, by reading the transaction logs, and updating the genesis file manually. That is why we recommend using the deploy command, which does all this automatically.
4. Whitelist genesis validators to CustomSupernetManager. You can use the whitelist-validators command provided by Edge.
5. Each validator needs to register itself to CustomSupernetManager.
6. Each validator needs to stake some tokens on the StakeManager. Keep in mind they need to provide the chainID from genesis.
7. SupernetManager deployer needs to finalize genesis staking on it as a final step before starting the supernet. We recommend using the supernet command provided by Edge.

Changes include

• Bugfix (non-breaking change that solves an issue)
• Hotfix (change that solves an urgent issue, and requires immediate attention)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)

Breaking changes

• Edge can only be run as L2 (operating only in bridge mode, therefore it is not possible to run it as L1, sovereign chain anymore).
• More steps in deployment.
• Staking is done on rootchain.
• Validator set storage and update are done on edge client based on changed stake in rootchain.
• Existing commands are changed.
• Reward distribution needs a wallet address.

Checklist

• I have assigned this PR to myself
• I have added at least 1 reviewer
• I have added the relevant labels
• I have updated the official documentation
• I have added sufficient documentation in code

Testing

• I have tested this code with the official test suite
• I have tested this code manually