Touch up dkg debugging, add client config page (#403)

* Touch up dkg debugging, add client config page

* Address changes, improve links across site

docs/advanced/quickstart-builder-api.mdx

@@ -43,7 +43,7 @@ charon run --builder-api
 
 ### Consensus Clients
 
-The following flags need to be configured on your chosen consensus client. A Flashbots relay URL is provided for example purposes, you should choose a relay that suits your preferences from [this list](https://github.com/eth-educators/ethstaker-guides/blob/main/MEV-relay-list.md#mev-relay-list-for-mainnet). 
+The following flags need to be configured on your chosen consensus client. A Flashbots relay URL is provided for example purposes, you should use the [charon test mev command](./test-command.md#test-mev-relay) and select the two or three relays with the lowest latency to your node that also conform to your block building preferences. A public list of MEV relays is available [here](https://github.com/eth-educators/ethstaker-guides/blob/main/MEV-relay-list.md#mev-relay-list-for-mainnet).
 
 <Tabs groupId="consensus-clients">
   <TabItem value="teku" label="Teku" default>

docs/faq/client_configurations.md

@@ -0,0 +1,82 @@
+---
+sidebar_position: 5
+description: A reference for extra configuration of Ethereum Clients when running in DVs. 
+---
+
+# Client Configuration
+
+Many execution, consensus, and validator clients need custom flags or parameters to work best with Distributed Validators. These settings are often dispersed across a number of documentation pages or example repos. This page aims to be a reference for each client and the specific additions they may require.
+
+
+
+
+## Lighthouse
+
+### Consensus Client
+
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+
+### Validator Client
+
+Required flags:
+```shell
+--distributed
+```
+
+## Lodestar
+
+### Consensus Client
+
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+
+### Validator Client
+
+Required flags:
+```shell
+--distributed
+```
+
+## Nimbus
+
+### Consensus Client
+
+When running a Nimbus Consensus Client you must add the following flag **to `charon run`**:
+```shell
+--feature-set-enable=json_requests
+```
+
+### Validator Client
+
+Required flags:
+```shell
+--distributed
+```
+
+## Prysm
+
+### Consensus Client
+
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+
+### Validator Client
+
+Required flags:
+```shell
+--distributed
+```
+
+## Teku
+
+### Consensus Client
+
+Required flags:
+```shell
+--validators-graffiti-client-append-format=DISABLED
+```
+
+### Validator Client
+
+Required flags:
+```shell
+--Xobol-dvt-integration-enabled
+```

docs/faq/dkg_failure.md

@@ -9,9 +9,9 @@ While the DKG process has been tested and validated against many different confi
 
 Our DKG is designed in a way that doesn't allow for inconsistent results: either it finishes correctly for every peer, or it fails.
 
-This is a **safety** feature: you don't want to deposit an Ethereum distributed validator that not every operator is able to participate to, or even reach threshold for.
+This is a **safety** feature: you don't want to deposit an Ethereum distributed validator that not every operator is able to participate in.
 
-The most common source of issues lies in the network stack: if any of the peer's Internet connection glitches substantially, the DKG will fail.
+The most common source of issues lies in the network stack: if any of the peers' Internet connection glitches substantially, the DKG will fail. If you are attempting to run the `dkg` command in two places at once, or you have a `charon run` command with the same `charon-enr-private-key` as you are trying to DKG with, these may also disrupt a key generation ceremony.
 
 Charon's DKG doesn't allow peer reconnection once the process is started, but it does allow for re-connections before that.
 
@@ -68,16 +68,19 @@ In order to retry the DKG process one must delete the following entities, if pre
 :::warning
 The `charon-enr-private-key` file **must be preserved**, failure to do so requires the DKG process to be restarted from the beginning by creating a new cluster definition.
 :::
+
 If you're doing a DKG with a custom cluster definition - for example, create with `charon create dkg`, rather than the Obol Launchpad - you can re-use the same file.
 
 Once this process has been completed, the cluster operators can retry a DKG.
 
 ## Further debugging
 
-If for some reason the DKG process fails again, node operators are advised to reach out to the Obol team by opening an [issue](https://github.com/ObolNetwork/charon/issues), detailing what troubleshooting steps were taken and providing **debug logs**.
+If you are trying to create an extremely large, geographically diverse cluster, there is a chance the process could be timing out. Consider adding the flags `--timeout=5m --shutdown-delay=60s` to allow more time for the ceremony to complete and safely shut down across all nodes.
+
+If for some reason the DKG process still fails, node operators are advised to reach out to the Obol team by opening an [issue](https://github.com/ObolNetwork/charon/issues), detailing the troubleshooting steps that were taken and providing **debug logs**.
 
-To enable debug logs first clean up the Charon data directory as explained in [the previous paragraph](#cleaning-up-the-charon-directory), then run your DKG command by appending `--log-level=debug` at the end.
+To enable debug logs, first clean up the Charon data directory as explained in [the previous section](#cleaning-up-the-charon-directory), then run your DKG command while appending `--log-level=debug` at the end.
 
-In order for the Obol team to debug your issue as quickly and precisely as possible please provide full logs in textual form, not through screenshots or display photos.
+In order for the Obol team to debug your issue as quickly and precisely as possible, please provide full logs in text form, not through screenshots or display photos.
 
-Providing complete logs is particularly important, since it allows the team to reconstruct precisely what happened.
+Providing complete debug logs from all peers is particularly important, since it allows the team to reconstruct precisely what happened throughout the ceremony.

docs/faq/general.mdx

@@ -140,7 +140,7 @@ It is possible to migrate your Charon node to another machine running the same c
 
 Currently, the minimum is 4 operators with a threshold of 3.
 
-The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../int/key-concepts.md).
+The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../int/key-concepts.md#distributed-validator-threshold).
 
 ## Obol Splits
 

docs/faq/peer_score.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 7
 description: Measuring Individual Performance in Distributed Validators
 ---