Update site configuration and content (#453)

* Update site configuration and content

* add redirects and rearrange how-tos

* npm install

* don't revert line breaks

* fix linting errors

* fix lint quotes

* fix: fix lint prettier errors

* Apply suggestions from code review

Co-authored-by: Byron Gravenorst <50852695+bgravenorst@users.noreply.github.com>

* font size / minor edits

---------

Co-authored-by: Joshua Fernandes <joshua.fernandes@consensys.net>
Co-authored-by: Byron Gravenorst <50852695+bgravenorst@users.noreply.github.com>

.gitignore

@@ -20,3 +20,4 @@ yarn-debug.log*
 yarn-error.log*
 .vercel
 .idea
+.yarn

docs/Concepts/ArchitectureOverview.md → docs/concepts/architecture.md

@@ -1,17 +1,19 @@
 ---
 title: Architecture
-description: Teku architecture
+description: Learn about the Teku high-level architecture.
 sidebar_position: 1
 ---
 
 # Teku architecture
 
 The following diagram outlines the Teku high-level architecture.
 
-![Architecture](../images/Architecture.png)
+![Architecture](../images/architecture.png)
 
-Teku contains both a beacon node and validator client implementation. The beacon node is the primary link to the Beacon Chain. The validator client performs [validator duties](Proof-of-Stake.md).
+Teku contains both a beacon node and validator client implementation.
+The beacon node is the primary link to the Beacon Chain.
+The validator client performs [validator duties](proof-of-stake.md).
 
-You can [run the beacon node only](../HowTo/Get-Started/Run-Teku.md#start-the-beacon-node), or [run the beacon node and validator client](../HowTo/Get-Started/Run-Teku.md#start-the-clients-in-a-single-process).
+You can [run the beacon node only](../get-started/start-teku.md#start-the-beacon-node), or [run the beacon node and validator client](../get-started/start-teku.md#start-the-clients-in-a-single-process).
 
 Read more about the [Ethereum consensus client architecture](https://ethereum.org/en/developers/docs/nodes-and-clients/). For more information about the Teku architecture, contact us on [Teku Discord channel](https://discord.com/invite/consensys).

docs/concepts/builder-network.md

@@ -0,0 +1,29 @@
+---
+title: Builder network and MEV-Boost
+description: Learn about external builders and MEV-Boost.
+sidebar_position: 2
+---
+
+# Builder network and MEV-Boost
+
+[Consensus clients](merge.md#consensus-clients) are responsible for proposing
+blocks containing an execution payload obtained from their local
+[execution clients](merge.md#execution-clients) via the Engine API.
+
+A consensus client can optionally configure an external builder and delegate the
+execution payload construction to it, instead of using the execution client.
+
+## MEV-Boost
+
+The most common builder deployment is to run a specialized external software
+such as [MEV-Boost](https://github.com/flashbots/mev-boost).
+MEV-Boost works by requesting a payload proposal from several entities (called 
+relays), and selecting the best bid in order to improve validator rewards and
+increase the maximal extractable value (MEV).
+
+Teku allows you to
+[configure the beacon node to use a builder network](../how-to/configure/builder-network.md)
+to generate execution payloads.
+In case of failures or non-timely responses, Teku falls back to the payload
+produced by the local execution client specified using
+[`--ee-endpoint`](../reference/cli/index.md#ee-endpoint).

docs/Concepts/Merge.md → docs/concepts/merge.md

@@ -1,6 +1,6 @@
 ---
 title: The Merge
-description: What is the Merge?
+description: Learn about The Merge, and execution and consensus clients.
 sidebar_position: 4
 ---
 
@@ -12,7 +12,7 @@ The Merge was executed on **September 15, 2022**.
 
 :::
 
-[The Merge](https://ethereum.org/en/upgrades/merge/) was an Ethereum upgrade that merged the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) into Ethereum Mainnet, turning Mainnet into a combination of an [execution layer and consensus layer](#execution-and-consensus-clients). The Merge transitioned Mainnet from proof of work to [proof of stake consensus](Proof-of-Stake.md).
+[The Merge](https://ethereum.org/en/upgrades/merge/) was an Ethereum upgrade that merged the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) into Ethereum Mainnet, turning Mainnet into a combination of an [execution layer and consensus layer](#execution-and-consensus-clients). The Merge transitioned Mainnet from proof of work to [proof of stake consensus](proof-of-stake.md).
 
 You can run Teku as a consensus client with:
 
@@ -27,15 +27,15 @@ After The Merge, a full Ethereum Mainnet node is a combination of an execution c
 
 Execution and consensus clients communicate with each other using the [Engine API](https://besu.hyperledger.org/en/latest/HowTo/Interact/APIs/Engine-API/).
 
-![Ethereum Merge node](../images/Execution-Consensus-Clients.png)
+![Ethereum Merge node](../images/execution-consensus-clients.png)
 
 ### Execution clients
 
 Execution clients, such as [Besu](https://besu.hyperledger.org/en/stable/), manage the execution layer, including executing transactions and updating the world state. Execution clients serve [JSON-RPC API](https://besu.hyperledger.org/en/stable/Reference/API-Methods/) requests and communicate with each other in a peer-to-peer network.
 
 ### Consensus clients
 
-Consensus clients, such as Teku, contain beacon node and validator client implementations. The beacon node is the primary link to the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) (consensus layer). The validator client performs [validator duties](Proof-of-Stake.md) on the consensus layer. Consensus clients serve [REST API](../Reference/Rest_API/Rest.md) requests and communicate with each other in a 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](https://ethereum.org/en/upgrades/beacon-chain/) (consensus layer). The validator client performs [validator duties](proof-of-stake.md) on the consensus layer. Consensus clients serve [REST API](../reference/rest.md) requests and communicate with each other in a peer-to-peer network.
 
 ## What happened during The Merge
 
@@ -45,8 +45,8 @@ The consensus layer enabled the Merge configuration (Bellatrix) before reaching
 
 :::tip
 
-After The Merge, a Mainnet node operator must run both an execution client and a beacon node at the same time. To become a validator, you must also run a validator client (either [in the same process as the beacon node](../HowTo/Get-Started/Run-Teku.md#start-the-clients-in-a-single-process) or [separately](../HowTo/Get-Started/Run-Teku.md#run-the-clients-separately)).
+After The Merge, a Mainnet node operator must run both an execution client and a beacon node at the same time. To become a validator, you must also run a validator client (either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately)).
 
 :::
 
-After The Merge, validators earn rewards for performing [validator duties](Proof-of-Stake.md), and fee recipients earn rewards for the inclusion of execution layer transactions.
+After The Merge, validators earn rewards for performing [validator duties](proof-of-stake.md), and fee recipients earn rewards for the inclusion of execution layer transactions.

docs/concepts/p2p-private-key.md

@@ -0,0 +1,19 @@
+---
+title: Peer-to-peer private key
+description: Learn about the peer-to-peer private key.
+sidebar_position: 5
+---
+
+# Peer-to-peer private key
+
+The peer-to-peer (P2P) private key is used to identify the beacon node on the network and secures the information channel between nodes.
+
+When starting Teku, if the [`--p2p-private-key-file`](../reference/cli/index.md#p2p-private-key-file) option is not specified, and the `generated-node-key.dat` file does not exist in the node's data directory, Teku generates a P2P private key and writes it to the `generated-node-key.dat` file.
+
+If the `generated-node-key.dat` file exists in the data directory when starting Teku, the node starts using the private stored in the file.
+
+:::info
+
+The `generated-node-key.dat` file is stored by default in the `<data-beacon-path>/kvstore` directory, where `<data-beacon-path>` is specified using the [`--data-beacon-path`](../reference/cli/index.md#data-beacon-path) option.
+
+:::

docs/Concepts/Proof-of-Stake.md → docs/concepts/proof-of-stake.md

@@ -1,14 +1,14 @@
 ---
 title: Proof of stake
-description: Ethereum proof of stake
+description: Learn about Ethereum proof of stake consensus.
 sidebar_position: 3
 ---
 
 # Proof of stake
 
-[The Merge](Merge.md) transitioned Ethereum Mainnet to [proof of stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) consensus.
+[The Merge](merge.md) transitioned Ethereum Mainnet to [proof of stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) consensus.
 
-In Ethereum's PoS, you must run a [full node](Merge.md#execution-and-consensus-clients) and [stake 32 ETH](https://ethereum.org/en/staking/) to become a validator.
+In Ethereum's PoS, you must run a [full node](merge.md#execution-and-consensus-clients) and [stake 32 ETH](https://ethereum.org/en/staking/) to become a validator.
 
 :::warning
 
@@ -18,7 +18,7 @@ Withdrawing staked ETH isn't yet supported and will be included in a separate up
 
 :::note
 
-You must run a beacon node and an execution client to operate a node on Mainnet. To become a validator, you must also run a validator client (either [in the same process as the beacon node](../HowTo/Get-Started/Run-Teku.md#start-the-clients-in-a-single-process) or [separately](../HowTo/Get-Started/Run-Teku.md#run-the-clients-separately).
+You must run a beacon node and an execution client to operate a node on Mainnet. To become a validator, you must also run a validator client (either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately).
 
 :::
 
@@ -28,7 +28,7 @@ Proposers are responsible for proposing new consensus blocks, and non-proposing
 
 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](Merge.md#execution-and-consensus-clients) processes the block and sends the execution payload to the [execution client](Merge.md#execution-and-consensus-clients), which:
+When a node validates a consensus block, its [consensus client](merge.md#execution-and-consensus-clients) processes the block and sends the execution payload to the [execution client](merge.md#execution-and-consensus-clients), which:
 
 1. Assembles a block on the execution layer.
 1. Verifies pre-conditions.

docs/Concepts/Slashing-Protection.md → docs/concepts/slashing-protection.md

@@ -1,14 +1,14 @@
 ---
 title: Slashing protection
-description: Describe how slashing protection works in Teku
+description: Learn about Teku's slashing protection.
 sidebar_position: 6
 ---
 
 # Slashing protection
 
 Teku implements slashing protection to prevent validators from signing blocks or attestations based on what it has already signed.
 
-By default, Teku also locks keystore files listed in the [`--validator-keys`](../Reference/CLI/CLI-Syntax.md#validator-keys) option to prevent other processes from using it. You can enable and disable this functionality using the [`--validators-keystore-locking-enabled`](../Reference/CLI/CLI-Syntax.md#validators-keystore-locking-enabled) option.
+By default, Teku also locks keystore files listed in the [`--validator-keys`](../reference/cli/index.md#validator-keys) option to prevent other processes from using it. You can enable and disable this functionality using the [`--validators-keystore-locking-enabled`](../reference/cli/index.md#validators-keystore-locking-enabled) option.
 
 :::warning
 
@@ -20,15 +20,15 @@ To protect validators from slashable offenses, Teku stores a record of the most
 
 :::note
 
-Set `<data-path>` using the [`--data-path`](../Reference/CLI/CLI-Syntax.md#data-path) command line option.
+Set `<data-path>` using the [`--data-path`](../reference/cli/index.md#data-path) command line option.
 
 :::
 
 Teku provides command line options to [import] or [export] the slashing protection file.
 
 :::tip
 
-Teku also supports [doppelganger detection](../HowTo/Doppelganger-Detection.md) to help prevent slashing. This is an early access feature.
+Teku also supports [doppelganger detection](../how-to/doppelganger-detection.md) to help prevent slashing. This is an early access feature.
 
 :::
 
@@ -69,7 +69,7 @@ If moving a validator from one Teku node to another, you can manually migrate th
 For example, to manually move the file from node A to node B:
 
 - Stop Teku node A and confirm the process has fully exited and won't be restarted.
-- Remove the validator key from node A, for example from the [`--validator-keys`](../Reference/CLI/CLI-Syntax.md#validator-keys) option.
+- Remove the validator key from node A, for example from the [`--validator-keys`](../reference/cli/index.md#validator-keys) option.
 - Copy the file from `<nodeA-data-path>/validators/slashprotection/` to `<nodeB-data-path>/validators/slashprotection/`.
 - Start node B with the migrated validator key.
 - Restart node A if required.
@@ -89,5 +89,5 @@ Start the Teku node with the validator key.
 
 [YAML file is stored per validator]: #validator-slashing-protection-file
 [create a new slashing protection file]: #validator-slashing-protection-file
-[import]: ../HowTo/Prevent-Slashing.md#import-a-slashing-protection-file
-[export]: ../HowTo/Prevent-Slashing.md#export-a-slashing-protection-file
+[import]: ../how-to/prevent-slashing.md#import-a-slashing-protection-file
+[export]: ../how-to/prevent-slashing.md#export-a-slashing-protection-file

docs/Concepts/Weak-Subjectivity.md → docs/concepts/weak-subjectivity.md

@@ -1,6 +1,6 @@
 ---
 title: Weak subjectivity
-description: Describe weak subjectivity
+description: Learn about the weak subjectivity period.
 sidebar_position: 7
 ---
 
@@ -20,8 +20,8 @@ If a node is aware that a validator has withdrawn its funds, the node will rejec
 
 Teku provides two methods to safely sync a node that is new to the network or has been offline for an extended period.
 
-1. Use [`--initial-state`](../Reference/CLI/CLI-Syntax.md#initial-state) to supply an SSZ encoded state file from which to sync.
-2. Use [`--ws-checkpoint`](../Reference/CLI/CLI-Syntax.md#ws-checkpoint) to supply a weak subjectivity checkpoint by which a node can securely validate its view of the current state.
+1. Use [`--initial-state`](../reference/cli/index.md#initial-state) to supply an SSZ encoded state file from which to sync.
+2. Use [`--ws-checkpoint`](../reference/cli/index.md#ws-checkpoint) to supply a weak subjectivity checkpoint by which a node can securely validate its view of the current state.
 
 We recommend using `--initial-state`. It provides the same security benefits as `--ws-checkpoint`, but syncs faster. The only exception is when syncing an archive node, in which case, use `--ws-checkpoint`.
 
@@ -31,4 +31,6 @@ Use the [`/eth/v2/debug/beacon/states/<state_id>`](https://consensys.github.io/t
 
 :::
 
-Another option is to utilize the [Reconstruct Historical States Service](../HowTo/Reconstruct-Historical-States-Service.md). This allows the creation of a full archive node, ensuring that once the node is up to date, the concerns associated with weak subjectivity are cleared.
+Another option is to [reconstruct historical states](../how-to/reconstruct-historical-states.md).
+This allows the creation of a full archive node, ensuring that once the node is
+up-to-date, the concerns associated with weak subjectivity are cleared.