Document PoS concept page (#1125)

* Document PoS concept page

Signed-off-by: Roland Tyler <roland.tyler@consensys.net>

* Nav fix

Signed-off-by: Roland Tyler <roland.tyler@consensys.net>

Signed-off-by: Roland Tyler <roland.tyler@consensys.net>
pull/1129/head
rolandtyler 2 years ago committed by GitHub
parent 1d313bbee7
commit dae36d48d3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
  1. 52
      docs/public-networks/concepts/proof-of-stake.md
  2. 6
      docs/public-networks/concepts/the-merge.md
  3. 1
      mkdocs.navigation.yml
  4. 2
      mkdocs.redirects.yml

@ -0,0 +1,52 @@
---
description: Ethereum proof of stake
---
# Proof of stake
[The Merge](the-merge.md) transitions Ethereum Mainnet to
[proof of stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) consensus.
PoS is preferred over proof of work and proof of authority as a consensus mechanism
because it is more secure, requires less energy, and lowers the barrier to entry.
The PoS mechanism randomly chooses validators to propose or validate blocks on the
[Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) in defined time frames.
Proposers are responsible for proposing new consensus blocks, and non-proposing validators are responsible for
validating (attesting to) proposed blocks.
Validators are rewarded for proposing and attesting to consensus blocks eventually included in the Beacon Chain, and
penalized for malicious behavior.
Validators also receive [transaction fees](https://docs.teku.consensys.net/en/latest/HowTo/Prepare-for-The-Merge/#configure-the-fee-recipient) for included
blocks.
Each consensus block contains an execution payload, which contains a list of transactions and other data required to
execute and validate the payload.
When a node validates a consensus block, its [consensus client](the-merge.md#consensus-clients) processes
the block and sends the execution payload to the [execution client](the-merge.md#execution-clients), which:
1. Assembles a block on the execution layer.
1. Verifies pre-conditions.
1. Executes transactions.
1. Verifies post-conditions.
1. Sends the validity result back to the consensus client.
If the block is valid, the execution client includes it in the execution chain and stores the new state in execution
state storage.
If a consensus block receives attestations backed by enough staked ETH, the block is included in the Beacon Chain.
In Ethereum's PoS, you must run a [full node](the-merge.md#execution-and-consensus-clients) and
[stake 32 ETH](https://ethereum.org/en/staking/) to become a validator.
!!! important
Withdrawing staked ETH isn't yet supported and will be included in a separate upgrade following The Merge.
!!! note
You must run a beacon node and an execution client to operate a full node on Mainnet post-Merge.
To become a validator, you must also run a validator client (either
[in the same process as the beacon node](https://docs.teku.consensys.net/en/stable/HowTo/Get-Started/Run-Teku/#start-the-clients-in-a-single-process) or
[separately](https://docs.teku.consensys.net/en/stable/HowTo/Get-Started/Run-Teku/#run-the-clients-separately)).

@ -8,7 +8,7 @@ description: What is the Merge?
Ethereum Mainnet, turning Mainnet into a combination of an
[execution layer and consensus layer](#execution-and-consensus-clients).
The Merge transitions Mainnet from proof of work to
[proof of stake consensus](https://docs.teku.consensys.net/en/stable/Concepts/Proof-of-Stake/).
[proof of stake consensus](proof-of-stake.md).
Update and configure Besu to be [ready for The Merge](../how-to/prepare-for-the-merge.md).
You can also test Besu with a consensus client such as [Teku] on the [Kiln Merge testnet](../tutorials/merge-testnet.md).
@ -34,7 +34,7 @@ peer-to-peer network.
Consensus clients, such as [Teku], contain beacon node and validator client implementations.
The beacon node is the primary link to the [Beacon Chain] (consensus layer).
The validator client performs [validator duties](https://docs.teku.consensys.net/en/latest/Concepts/Proof-of-Stake/) on
The validator client performs [validator duties](proof-of-stake.md) on
the consensus layer.
Consensus clients serve [REST API](https://docs.teku.consensys.net/en/stable/Reference/Rest_API/Rest/) requests and
communicate with each other in a peer-to-peer network.
@ -60,7 +60,7 @@ To become a validator, you must also run a validator client (either
or [separately](https://docs.teku.consensys.net/en/stable/HowTo/Get-Started/Run-Teku/#run-the-clients-separately).
After The Merge, validators earn rewards for performing
[validator duties](https://docs.teku.consensys.net/en/stable/Concepts/Proof-of-Stake/), and
[validator duties](proof-of-stake.md), and
[fee recipients](https://docs.teku.consensys.net/en/latest/HowTo/Prepare-for-The-Merge/#configure-the-fee-recipient)
will also earn rewards for the inclusion of execution layer transactions.

@ -58,6 +58,7 @@ nav:
- Trace transactions: public-networks/how-to/troubleshoot/trace-transactions.md
- Concepts:
- The Merge: public-networks/concepts/the-merge.md
- Proof of stake: public-networks/concepts/proof-of-stake.md
- Data storage formats: public-networks/concepts/data-storage-formats.md
- Transactions:
- Transaction types: public-networks/concepts/transactions/types.md

@ -44,7 +44,7 @@ plugins:
HowTo/Deploy/Lite-Network-Monitor.md: https://github.com/Alethio/ethstats-network-dashboard
HowTo/Configure/Consensus-Protocols/QuorumIBFT.md: private-networks/how-to/configure/consensus/qbft.md
HowTo/Configure/Configure-Data-Storage.md: public-networks/concepts/data-storage-formats.md
Concepts/Consensus-Protocols/Proof-of-Stake.md: public-networks/concepts/the-merge.md
Concepts/Consensus-Protocols/Proof-of-Stake.md: public-networks/concepts/proof-of-stake.md
Tutorials/Examples/Private-Network-Example.md: private-networks/tutorials/quickstart.md
Tutorials/Examples/Privacy-Example.md: private-networks/tutorials/privacy/quickstart.md
Tutorials/Examples/Nat-Manager-Kubernetes.md: private-networks/tutorials/kubernetes/nat-manager.md

Loading…
Cancel
Save