-
Notifications
You must be signed in to change notification settings - Fork 400
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
15f6ea2
commit 958a0ec
Showing
1 changed file
with
82 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,82 @@ | ||
| --- | ||
| title: PoA vs PoS | ||
| description: Learn the differences between Proof of Authority and Proof of Stake Validator Manager contracts. | ||
| --- | ||
| import { Steps, Step } from 'fumadocs-ui/components/steps'; | ||
|
|
||
| ## Overview | ||
|
|
||
| At a high level, the `ValidatorManager` abstract is used to manage the validator set on the P-Chain. | ||
|
|
||
| <Steps> | ||
| <Step> | ||
| - Proof of Authority networks are secured by validators who can be added or removed from the `PoAValidatorManager` implementation by an owner address (can be a smart contract). | ||
| - Proof of Stake networks are secured by validators who stake some type of tokens for a duration into an implementation of `PoSValidatorManager`. | ||
| </Step> | ||
| <Step> | ||
| Once the transaction confirms, the `ValidatorManager` (which both `PoAValidatorManager` and `PoSValidatorManager` inherit) emits a warp message. | ||
| </Step> | ||
| <Step> | ||
| The warp message is signed off by quorum of the current validator set and submitted to the P-Chain. | ||
| </Step> | ||
| <Step> | ||
| The P-Chain then adds, removes or modifies the validator in the registry using information from the warp message. | ||
| </Step> | ||
| </Steps> | ||
|
|
||
|
|
||
| ## Proof of Authority | ||
|
|
||
| There is one implementation of Proof of Authority based on the `ValidatorManager` abstract called `PoAValidatorManager`. | ||
|
|
||
| In the `PoAValidatorManager` implementation, the owner of the contract can add and remove validators from the set. The owner can also set the weight of the validator. | ||
| The owner can either be a smart contract or an EOA. | ||
|
|
||
| By default, no rewards are distributed to validators in the `PoAValidatorManager` implementation. However, rewards can be distributed to validators by extending the `PoAValidatorManager` contract and adding the desired functionality. | ||
|
|
||
| The `PoAValidatorManager` has a couple of parameters that it can be initialized with to fit the needs of the network. These parameters include: | ||
| - `ChurnPeriodSeconds`: The time period in seconds that a validator must wait before being removed from the set. | ||
| - `MaximumChurnPercentage`: The maximum percentage of the validator set that can be removed in a single churn period. | ||
|
|
||
| ## Proof of Stake | ||
|
|
||
| There are two implmentations offered of Proof of Stake based on the `PoSValidatorManager` abstract: | ||
|
|
||
| - `NativeTokenStakingManager`: This contract is used for staking native tokens. | ||
| - `ERC20TokenStakingManager`: This contract is used for staking ERC20 tokens. | ||
|
|
||
| These are both permissionless implementations, meaning that anyone can stake tokens and become a validator. | ||
|
|
||
| Rewards are calculated using a `RewardCalculator` contract. The `PoSValidatorManager` will distribute rewards to the validator based off their node's liveliness in consensus and after the validator is removed from the set. | ||
|
|
||
| In the `NativeTokenStakingManager` implmentation, rewards are minted through use of the `NativeMinter` precompile. Which the address of `NativeTokenStakingManager` is enabled on. | ||
|
|
||
| In the `ERC20TokenStakingManager` implementation, rewards are minted through calling the ERC20 token's `mint` function. | ||
|
|
||
|
|
||
|
|
||
| The `PoSValidatorManager` has a number of parameters that it can be initialized with to fit the needs of the network. These parameters include: | ||
|
|
||
| - `MinimumStakeAmount`: The minimum amount of tokens required to stake. | ||
| - `MaximumStakeAmount`: The maximum amount of tokens required to stake. | ||
| - `MinimumStakeDuration`: The minimum duration that tokens must be staked for. | ||
| - `MinimumDelegationFeeBips`: The minimum fee charged to delegators for delegating their tokens. | ||
| - `MaximumStakeMultiplier`: The maximum multiplier that can be applied to a validator's weight. | ||
| - `WeightToValueFactor`: The factor used to convert a validator's weight to a value. | ||
| - `RewardCalculator`: The address of the reward calculator contract. | ||
|
|
||
| <Callout> | ||
| The `PoSValidatorManager` asbtract also comes with a notion of `delegation`. Delegators can delegate their tokens to a validator. This will increase the validator's weight and the delegator will receive a portion of the rewards. | ||
| </Callout> | ||
|
|
||
|
|
||
| ## Customization | ||
|
|
||
| The `ValidatorManager` abstract contract is designed to be flexible and can be easily extensible to fit the needs of the network. | ||
|
|
||
| For example, the `PoSValidatorManager` abstract could be extended to include additional parameters or functionality. This can be done by creating a new contract that inherits from the `PoSValidatorManager` abstract and adding the desired functionality such as NFT staking, slashing, or additional rewards for certain actions. | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|