From 65e4d2142cd83a48f527a6bd30800acf30a0f09c Mon Sep 17 00:00:00 2001 From: antews Date: Tue, 15 Oct 2024 19:42:53 +0300 Subject: [PATCH 1/3] Fixed errors --- docs/advanced/deployment-best-practices.md | 2 +- docs/advanced/monitoring.md | 6 +++--- docs/advanced/quickstart-builder-api.mdx | 6 +++--- docs/advanced/test-command.md | 10 +++++----- 4 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/advanced/deployment-best-practices.md b/docs/advanced/deployment-best-practices.md index 4822fc0f34..6d33277c43 100644 --- a/docs/advanced/deployment-best-practices.md +++ b/docs/advanced/deployment-best-practices.md @@ -58,7 +58,7 @@ Each node in the cluster should have its own independent beacon node (EL+CL) and ## Placement of Charon clients -If you wish to divide a Distributed Validator node across multiple physical or virtual machines; locaate the Charon client on the EL/CL machine instead of the VC machine. This setup reduces latency from Charon to the consensus layer, as well as keeping the public-internet connected clients separate from the clients that hold the validator private keys. Be sure to use encrypted communication between your VC and the Charon client, potentially through a cloud-provided network, a self-managed network tunnel, a VPN, a Kubernetes [CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/), or other manner. +If you wish to divide a Distributed Validator node across multiple physical or virtual machines; locate the Charon client on the EL/CL machine instead of the VC machine. This setup reduces latency from Charon to the consensus layer, as well as keeping the public-internet connected clients separate from the clients that hold the validator private keys. Be sure to use encrypted communication between your VC and the Charon client, potentially through a cloud-provided network, a self-managed network tunnel, a VPN, a Kubernetes [CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/), or other manner. ## Node Configuration diff --git a/docs/advanced/monitoring.md b/docs/advanced/monitoring.md index 75d988c6f8..62accafa2c 100644 --- a/docs/advanced/monitoring.md +++ b/docs/advanced/monitoring.md @@ -12,7 +12,7 @@ The local Grafana server will have a few pre-built dashboards: 1. Charon Overview - This is the main dashboard that provides all the relavant details about the Charon node, for example - peer connectivity, duty completion, health of beacon node and downstream validator, etc. To open, navigate to `charon-distributed-validator-node` directory and open the following `uri` in the browser `http://localhost:3000/d/d6qujIJVk/`. + This is the main dashboard that provides all the relevant details about the Charon node, for example - peer connectivity, duty completion, health of beacon node and downstream validator, etc. To open, navigate to `charon-distributed-validator-node` directory and open the following `uri` in the browser `http://localhost:3000/d/d6qujIJVk/`. 2. Single Charon Node Dashboard (deprecated) @@ -24,8 +24,8 @@ The local Grafana server will have a few pre-built dashboards: | Alert Name | Description | Troubleshoot | | --- | --- | --- | -| ClusterBeaconNodeDown | This alert is activated when the beacon node in a the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. | -| ClusterMissedAttestations | This alert indicates that there have been missed attestations in the cluster. Missed attestations may suggest that validators are not operating correctly, compromising the security and efficiency of the cluster. | This alert is triggered when 3 attestation are missed in 2 minutes. Check if the minimum threshold of peers are online. If correct, check for beacon node API errors and downstream validator errors using Loki. Lastly, debug from Docker using `docker compose debug`. | +| ClusterBeaconNodeDown | This alert is activated when the beacon node in the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. | +| ClusterMissedAttestations | This alert indicates that there have been missed attestations in the cluster. Missed attestations may suggest that validators are not operating correctly, compromising the security and efficiency of the cluster. | This alert is triggered when 3 attestations are missed in 2 minutes. Check if the minimum threshold of peers are online. If correct, check for beacon node API errors and downstream validator errors using Loki. Lastly, debug from Docker using `docker compose debug`. | | ClusterInUnknownStatus | This alert is designed to activate when a node within the cluster is detected to be in an unknown state. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` metric is 0. | This is most likely a bug in Charon. Report to us via [Discord](https://discord.com/channels/849256203614945310/970759460693901362). | | ClusterInsufficientPeers | This alert is set to activate when the number of peers for a node in the cluster is insufficient. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` equals 4. | If you are running group cluster, check with other peers to troubleshoot the issue. If you are running solo cluster, look into other machines running the DVs to find the problem. | | ClusterFailureRate | This alert is activated when the failure rate of the cluster exceeds a certain threshold, more specifically - more than 5% failures in duties in the last 6 hours. | Check the upstream and downstream dependencies, latency and hardware issues. | diff --git a/docs/advanced/quickstart-builder-api.mdx b/docs/advanced/quickstart-builder-api.mdx index a27af478a2..e2e8787a8a 100644 --- a/docs/advanced/quickstart-builder-api.mdx +++ b/docs/advanced/quickstart-builder-api.mdx @@ -91,7 +91,7 @@ The following flags need to be configured on your chosen consensus client. A Fla --payload-builder-url="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"`} - You should also consider adding --local-block-value-boost 3 as a flag, to favour locally built blocks if they are withing 3% in value of the relay block, to improve the chances of a successful proposal. + You should also consider adding --local-block-value-boost 3 as a flag, to favour locally built blocks if they are with 3% in value of the relay block, to improve the chances of a successful proposal. Lodestar can communicate with a single relay directly: @@ -156,10 +156,10 @@ When your cluster is running, you should see if Charon is logging something like 13:10:47.094 INFO bcast Successfully submitted validator registration to beacon node {"delay": "24913h10m12.094667699s", "pubkey": "84b_713", "duty": "1/builder_registration"} ``` -This indicates that your Charon node is successfully registering with the relay for a blinded block when the time comes. +This indicates that your Charon node is successfully registering with the relay for a blind block when the time comes. If you are using the [ultrasound relay](https://relay.ultrasound.money), you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered. -You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your cluster-lock file, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster. +You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your `cluster-lock.json file`, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster. Once a proposal has been made, you should look at the `Block Extra Data` field under `Execution Payload` for the block on [Beaconcha.in](https://beaconcha.in/block/18450364), and confirm there is text present, this generally suggests the block came from a builder, and was not a locally constructed block. diff --git a/docs/advanced/test-command.md b/docs/advanced/test-command.md index dad97635dd..5c5a5b22a3 100644 --- a/docs/advanced/test-command.md +++ b/docs/advanced/test-command.md @@ -12,7 +12,7 @@ import TabItem from '@theme/TabItem'; The `charon alpha test` command is in an alpha state and is subject to change until it is made available as `charon test` in a future version. ::: -Charon test commands are designed to help you evaluate the performance and readiness of your candidate cluster. It allows you to test your connection to other Charon peers, the performance of your beacon node(s), and the readiness of your validator client. It prints a performance report to the standard output (which can be omitted by with the `--quiet` flag) and a machine-readable TOML format of the report if the `--output-toml` flag is set. +Charon test commands are designed to help you evaluate the performance and readiness of your candidate cluster. It allows you to test your connection to other Charon peers, the performance of your beacon node(s), and the readiness of your validator client. It prints a performance report to the standard output (which can be omitted with the `--quiet` flag) and a machine-readable TOML format of the report if the `--output-toml` flag is set. ## Test your connection to peers @@ -22,11 +22,11 @@ To be able to establish direct connection, you have to ensure: - Your machine is publicly accessible on the internet or at least a specific port is. - You add flag `p2p-tcp-address` (i.e.: `127.0.0.1:9001`) flag and the port specified in it is free and publicly accessible. -- You add the flag `p2p-external-ip` (i.e.: `8.8.8.8`) and specify your public ip. +- You add the flag `p2p-external-ip` (i.e.: `8.8.8.8`) and specify your public IP. If all points are satisfied by you and the other peers, you should be able to establish a direct TCP connection between each other. Note that a relay is still required, as it is used for peer discovery. -At least 1 enr is required to be supplied to the `--enrs` flag. +At least 1 ENR is required to be supplied to the `--enrs` flag. ### Pre-requisites @@ -96,7 +96,7 @@ docker run obolnetwork/charon:v1.1.1 alpha test validator ## Test MEV relay -Run tests towards MEV relay(s), to evaluate its effectiveness for a Distributed Validator cluster. If a MEV boost instance is configured for the validator node, it is of utmost importance that the connection to it is fast. If not, the chance of missing a block proposal raises significantly, because of a slow building of the block from the MEV. +Run tests towards MEV relay(s), to evaluate its effectiveness for a Distributed Validator cluster. If a MEV-Boost instance is configured for the validator node, it is of utmost importance that the connection to it is fast. If not, the chance of missing a block proposal increases significantly, because of a slow building of the block from the MEV. At least 1 endpoint is required to be supplied to the `--endpoints` flag. @@ -119,7 +119,7 @@ docker run -it obolnetwork/charon:v1.1.1 alpha test mev --endpoints="https://0xa ## Test your machine and network performance -Run tests towards your machine and network, to evaluate its effectiveness for a Distributed Validator cluster. While Charon does not require highly performant hardware, the network connectivity of the machine it is running on should be good. In comparison, the beacon node requires not only good connectivity, but also performant storage with high input-output operations per second, enough memory and also good network connectivity. This test aims to address all those requirements and give a good overview of the system. +Run tests towards your machine and network, to evaluate their effectiveness for a Distributed Validator cluster. While Charon does not require highly performant hardware, the network connectivity of the machine it is running on should be good. In comparison, the beacon node requires not only good connectivity, but also performant storage with high input-output operations per second, enough memory and also good network connectivity. This test aims to address all those requirements and give a good overview of the system. ### Pre-requisites From b61d1e65881136edb7f6501eb56553b989b9d783 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ois=C3=ADn=20Kyne?= <4981644+OisinKyne@users.noreply.github.com> Date: Mon, 28 Oct 2024 17:53:36 +0000 Subject: [PATCH 2/3] Update docs/advanced/quickstart-builder-api.mdx --- docs/advanced/quickstart-builder-api.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/advanced/quickstart-builder-api.mdx b/docs/advanced/quickstart-builder-api.mdx index dacd386371..7e40b88e39 100644 --- a/docs/advanced/quickstart-builder-api.mdx +++ b/docs/advanced/quickstart-builder-api.mdx @@ -161,6 +161,6 @@ This indicates that your Charon node is successfully registering with the relay If you are using the [ultrasound relay](https://relay.ultrasound.money), you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered. -You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your `cluster-lock.json file`, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster. +You should check that your validator client's logs look healthy, and ensure that you haven't added a `fee-recipient` address that conflicts with what has been selected by your cluster in your `cluster-lock.json` file, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster. Once a proposal has been made, you should look at the `Block Extra Data` field under `Execution Payload` for the block on [Beaconcha.in](https://beaconcha.in/block/18450364), and confirm there is text present, this generally suggests the block came from a builder, and was not a locally constructed block. From a6ab82edeea75538f2edc5c71e6c0d5ad3af6740 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ois=C3=ADn=20Kyne?= <4981644+OisinKyne@users.noreply.github.com> Date: Mon, 28 Oct 2024 17:53:46 +0000 Subject: [PATCH 3/3] Update docs/advanced/quickstart-builder-api.mdx --- docs/advanced/quickstart-builder-api.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/advanced/quickstart-builder-api.mdx b/docs/advanced/quickstart-builder-api.mdx index 7e40b88e39..6ab2c8a04e 100644 --- a/docs/advanced/quickstart-builder-api.mdx +++ b/docs/advanced/quickstart-builder-api.mdx @@ -157,7 +157,7 @@ When your cluster is running, you should see if Charon is logging something like 13:10:47.094 INFO bcast Successfully submitted validator registration to beacon node {"delay": "24913h10m12.094667699s", "pubkey": "84b_713", "duty": "1/builder_registration"} ``` -This indicates that your Charon node is successfully registering with the relay for a blind block when the time comes. +This indicates that your Charon node is successfully registering with the relay for a blinded block when the time comes. If you are using the [ultrasound relay](https://relay.ultrasound.money), you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered.