-
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.
Etna Content (PoA vs PoS / Intro to ValidatorManager) (#1956)
* poa-pos first draft * headings * add meta.json * add validator management doc * Update content/docs/evm-l1s/validator-manager/poa-vs-pos.mdx Co-authored-by: Meaghan FitzGerald <[email protected]> Signed-off-by: Owen <[email protected]> * Update content/docs/evm-l1s/validator-manager/poa-vs-pos.mdx Co-authored-by: Meaghan FitzGerald <[email protected]> Signed-off-by: Owen <[email protected]> * feedback changes --------- Signed-off-by: Owen <[email protected]> Co-authored-by: Meaghan FitzGerald <[email protected]>
- Loading branch information
1 parent
f922ce8
commit d44d67d
Showing
4 changed files
with
133 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
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,89 @@ | ||
| --- | ||
| 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 can be 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. | ||
| - 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. | ||
|
|
||
| ### Rewards | ||
|
|
||
| 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. | ||
|
|
||
| ### Parameters | ||
|
|
||
| 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. | ||
|
|
||
| <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> | ||
|
|
||
| ### Rewards | ||
|
|
||
| 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. | ||
|
|
||
| ### Parameters | ||
|
|
||
| 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. | ||
|
|
||
|
|
||
|
|
||
| ## 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. | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
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
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,42 @@ | ||
| --- | ||
| title: Validator Management | ||
| description: Learn about the Validator Manager contract suite for Avalanche L1s | ||
| --- | ||
|
|
||
| The Validator Manager contract suite allows Avalanche Layer 1s (L1s) to manage and enforce custom logic for validator sets through smart contracts. | ||
|
|
||
| ### Choosing Between Proof of Authority and Proof of Stake Chains | ||
|
|
||
| Organizations may opt to run a Proof of Authority (PoA) or a Proof of Stake (PoS) chain based on their specific needs and objectives. | ||
|
|
||
| #### Proof of Authority | ||
|
|
||
| In a PoA chain, a limited number of validators are pre-approved and recognized entities. This model is ideal for organizations that require: | ||
|
|
||
| - **Control and Compliance**: Regulatory compliance or the need for trusted validators. | ||
| - **Simplified Governance**: Easier coordination among validators. | ||
|
|
||
| PoA is often used by private enterprises, consortiums, or government agencies where validator identity is crucial, and a controlled environment is preferred. | ||
|
|
||
| #### Proof of Stake | ||
|
|
||
| In a PoS chain, validators are selected based on the amount of stake (tokens) they hold and are willing to lock up. This model is suitable for organizations aiming for: | ||
|
|
||
| - **Decentralization**: Encouraging a wide distribution of validators. | ||
| - **Security**: Economic incentives align validator behavior with network health. | ||
| - **Community Participation**: Allowing token holders to participate in network validation. | ||
|
|
||
| PoS chains are ideal for public networks or organizations that wish to build an open ecosystem with active community involvement. | ||
|
|
||
|
|
||
| ### Enforcing Custom Validation Logic via Smart Contracts | ||
|
|
||
| Avalanche L1s have the unique capability to enforce any validation logic that can be encoded via smart contracts. This flexibility allows developers and organizations to define custom rules and conditions for validator participation in their networks. By leveraging smart contracts, L1s can implement complex validation mechanisms, such as dynamic validator sets, customized staking requirements, or hybrid consensus models. | ||
|
|
||
| Smart contracts act as the governing code that dictates how validators are selected, how they behave, and under what conditions they can participate in the network. This programmable approach ensures that the validation logic is transparent, auditable, and can be updated or modified as needed to adapt to changing requirements or threats. | ||
|
|
||
| --- | ||
|
|
||
| [Learn more about the Validator Manager contract suite](/evm-l1s/validator-manager/contract) | ||
|
|
||
| [Build your first Avalanche L1](/avalanche-l1s/build-first-avalanche-l1) |