publish v0.14.0

docs/int/faq/errors.mdx

@@ -8,15 +8,15 @@ description: Errors & Resolutions
 All operators should try to restart their nodes and should check if they are on the latest stable version before attempting anything other configuration change as we are still in beta and frequently releasing fixes. You can restart and update with the following commands:
 
 ```
-docker-compose down
+docker compose down
 git pull
-docker-compose up
+docker compose up
 ```
 
 You can check your logs using
 
 ```
-docker-compose logs
+docker compose logs
 ```
 <details open className="details">
   <summary>
@@ -344,15 +344,15 @@ docker-compose logs
   </details>
   <details className="details">
     <summary>
-      <h4 id="running-docker-compose-up-error"> I see a lot of errors after running <code>docker-compose up</code>
+      <h4 id="running-docker-compose-up-error"> I see a lot of errors after running <code>docker compose up</code>
       </h4>
     </summary> It's because both geth and lighthouse start syncing and so there's connectivity issues among the containers. Simply let the containers run for a while. You won't observe frequent errors when geth finishes syncing. You can also add a second beacon node endpoint for something like infura by adding a comma separated API URL to the end of <code>CHARON_BEACON_NODE_ENDPOINTS</code> in the docker-compose(./docker-compose.yml#84).
   </details>
   <details className="details">
     <summary>
       <h4 id="loki-plugin-not-found-error"> How do I fix the <code>plugin "loki" not found</code> error?
       </h4>
-    </summary> If you get the following error when calling `docker-compose up`:<br/>
+    </summary> If you get the following error when calling `docker compose up`:<br/>
     <code>Error response from daemon: error looking up logging plugin loki: plugin "loki" not found</code>.<br/>Then it probably means that the Loki docker driver isn't installed. In that case, run the following command to install loki:<br/>
     <code>docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions </code>
   </details>

docs/int/faq/general.md

@@ -59,7 +59,7 @@ By the way, the more operators, the longer the DKG, but don't worry, there is no
 
 ## Debugging Errors in Logs 
 
-You can check if the containers on your node are outputting errors by running `docker-compose logs` on a machine with a running cluster.
+You can check if the containers on your node are outputting errors by running `docker compose logs` on a machine with a running cluster.
 
 Diagnose some common errors and view their resolutions [here](./errors.mdx).
 
@@ -80,7 +80,7 @@ cd charon-distributed-validator-node
 
 nano bootnode/docker-compose.yml
 
-docker-compose -f bootnode/docker-compose.yml up
+docker compose -f bootnode/docker-compose.yml up
 ```
 
 Test whether the bootnode is publicly accessible. This should return an ENR:

docs/int/quickstart/group/quickstart-group-leader-creator.md

@@ -52,7 +52,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr
   cd charon-distributed-validator-node
 
   # Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory
-  docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.13.0 create enr
+  docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.14.0 create enr
   ```
 
 You should expect to see a console output like

docs/int/quickstart/group/quickstart-group-operator.md

@@ -35,7 +35,7 @@ git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git
 cd charon-distributed-validator-node
 
 # Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory
-docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.13.0 create enr
+docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.14.0 create enr
 ```
 
 You should expect to see a console output like
@@ -112,7 +112,7 @@ With the DKG ceremony over, the last phase before activation is to prepare your
 
 Before completing these instructions, you should assign a static local IP address to your device (extending the DHCP reservation indefinitely or removing the device from the DCHP pool entirely if you prefer), and port forward the TCP protocol on the public port `:3610` on your router to your device's local IP address on the same port. This step is different for every person's home internet, and can be complicated by the presence of dynamic public IP addresses. We are currently working on making this as easy as possible, but for the time being, a distributed validator cluster isn't going to work very resiliently if all charon nodes cannot talk directly to one another and instead need to have an intermediary node forwarding traffic to them.
 
-**Caution**: If you manually update `docker-compose` to mount `lighthouse` from your locally synced `~/.lighthouse`, the whole chain database may get deleted. It'd be best not to manually update as `lighthouse` checkpoint-syncs so the syncing doesn't take much time.
+**Caution**: If you manually update `docker compose` to mount `lighthouse` from your locally synced `~/.lighthouse`, the whole chain database may get deleted. It'd be best not to manually update as `lighthouse` checkpoint-syncs so the syncing doesn't take much time.
 
 **Note**: If you have a `geth` node already synced, you can simply copy over the directory. For ex: `cp -r ~/.ethereum/goerli data/geth`. This makes everything faster since you start from a synced geth node.
 
@@ -121,7 +121,7 @@ Before completing these instructions, you should assign a static local IP addres
 rm -r ./data/lighthouse
 
 # Spin up a Distributed Validator Node with a Validator Client
-docker-compose up
+docker compose up
 
 # Open Grafana dashboard
 open http://localhost:3000/d/singlenode/
@@ -140,7 +140,7 @@ If at any point you need to turn off your node, you can run:
 
 ```
 # Shut down the currently running distributed validator node
-docker-compose down
+docker compose down
 ```
 
 ## Step 5. Activate the deposit data
@@ -214,7 +214,7 @@ A threshold of operators in the cluster need to perform this task to exit a vali
   - `compose-volutary-exit.yml` is configured with `--epoch=112260` which is the latest Bellatrix fork on Prater.
   - If the Charon cluster is running on a different chain, **ALL** operators must update `--epoch` to the same latest fork version returned by `curl $BEACON_NODE/eth/v1/config/fork_schedule`.
 - Run the command to submit this node's partially signed voluntary exit:
-  - `docker-compose -f compose-voluntary-exit.yml up`
+  - `docker compose -f compose-voluntary-exit.yml up`
   - Confirm the logs: `Exit for validator XXXXX submitted`
   - Exit the container: `Ctrl-C`
 - The charon metric `core_parsigdb_exit_total` will be incremented each time a voluntary exit partial signature is received, either from this node or from peers.
@@ -238,7 +238,7 @@ There are some additional compose files in this repository, `compose-debug.yml`,
 
 - `compose-debug.yml` contains some additional containers that developers can use for debugging, like `jaeger`. To achieve this, you can run:
 ```
-docker-compose -f docker-compose.yml -f compose-debug.yml up
+docker compose -f docker-compose.yml -f compose-debug.yml up
 ```
 
 - `docker-compose.override.yml.sample` is intended to override the default configuration provided in `docker-compose.yml`. This is useful when, for example, you wish to add port mappings or want to disable a container.
@@ -247,16 +247,16 @@ docker-compose -f docker-compose.yml -f compose-debug.yml up
 ```
 cp docker-compose.override.yml.sample docker-compose.override.yml
 
-# Tweak docker-compose.override.yml and then run docker-compose up
-docker-compose up
+# Tweak docker-compose.override.yml and then run docker compose up
+docker compose up
 ```
 
 - You can also run all these compose files together. This is desirable when you want to use both the features. For example, you may want to have some debugging containers AND also want to override some defaults. To achieve this, you can run:
 ```
-docker-compose -f docker-compose.yml -f docker-compose.override.yml -f compose-debug.yml up
+docker compose -f docker-compose.yml -f docker-compose.override.yml -f compose-debug.yml up
 ```
 
 - To run [mev-boost](https://boost.flashbots.net/), run:
 ```
-docker-compose -f docker-compose.yml -f mevboost-compose.yml up
+docker compose -f docker-compose.yml -f mevboost-compose.yml up
 ```

docs/int/quickstart/quickstart-alone.md

@@ -41,12 +41,12 @@ Run the following command:
 
 ```sh
 # Create a distributed validator cluster
-docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.13.0 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead" --nodes 6 --threshold 5
+docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.14.0 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead" --nodes 6 --threshold 5
 ```
 
 This command will create a subdirectory `.charon/cluster`. In it are six folders, one for each charon node created. Each folder contains partial private keys that together make up the distributed validator described in `.charon/cluster/cluster-lock.json`.
 
-This guide will launch all six charon clients in separate containers along with an execution client and consensus client. To distribute your cluster physically, copy each directory with one (or several) private keys within it to the other machines you want to use. Consider using the single node [docker-compose](https://github.com/ObolNetwork/charon-distributed-validator-node), the kubernetes [manifests](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node), or the [helm chart](https://github.com/ObolNetwork/helm-charts) example repos to get your nodes up and connected.
+This guide will launch all six charon clients in separate containers along with an execution client and consensus client. To distribute your cluster physically, copy each directory with one (or several) private keys within it to the other machines you want to use. Consider using the single node [docker compose](https://github.com/ObolNetwork/charon-distributed-validator-node), the kubernetes [manifests](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node), or the [helm chart](https://github.com/ObolNetwork/helm-charts) example repos to get your nodes up and connected.
 
 ### Distributed Validator Cluster
 
@@ -69,7 +69,7 @@ Run this command from each machine containing private keys to start your cluster
 
 ```sh
 # Start the distributed validator cluster
-docker-compose up --build
+docker compose up --build
 ```
 Check the monitoring dashboard and see if things look all right
 
@@ -115,7 +115,7 @@ A threshold of nodes in the cluster need to perform this task to exit a validato
   - `compose-volutary-exit.yml` is configured with `--epoch=112260` which is the latest Bellatrix fork on Prater.
   - If the Charon cluster is running on a different chain, **ALL** operators must update `--epoch` to the same latest fork version returned by `curl $BEACON_NODE/eth/v1/config/fork_schedule`.
 - Run the command to submit this node's partially signed voluntary exit:
-  - `docker-compose -f compose-voluntary-exit.yml up`
+  - `docker compose -f compose-voluntary-exit.yml up`
   - Confirm the logs: `Exit for validator XXXXX submitted`
   - Exit the container: `Ctrl-C`
 - The charon metric `core_parsigdb_exit_total` will be incremented each time a voluntary exit partial signature is received, either from this node or from peers.
@@ -136,7 +136,8 @@ which needs a prysm beacon node to work alongside a REST based beacon node. Here
    docker compose -f docker-compose.yml -f compose-prysm.yml -f docker-compose.override.yml up --build
    ```
 
-Note: Support for prysm VCs with is in experimental phase as prysm doesn't provide complete support of REST API compatible validator client.
+Note: Support for prysm VCs is in experimental phase as prysm doesn't provide [complete support](https://github.com/prysmaticlabs/prysm/issues/11580)
+of REST API compatible validator client.
 
 ## Feedback
 

docs/int/quickstart/quickstart-cli.md

@@ -32,7 +32,7 @@ git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git
 cd charon-distributed-validator-node
 
 # Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory
-docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.13.0 create enr
+docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.14.0 create enr
 ```
 
 You should expect to see a console output like
@@ -59,7 +59,7 @@ Finally, share your ENR with the leader or creator so that he/she can proceed to
 
 3. Run the `charon create dkg` command that generates DKG cluster-definition.json file.
   ```
-  docker run --rm -v "$(pwd):/opt/charon" --env-file .env.create_dkg obolnetwork/charon:v0.13.0 create dkg
+  docker run --rm -v "$(pwd):/opt/charon" --env-file .env.create_dkg obolnetwork/charon:v0.14.0 create dkg
   ```
 
   This command should output a file at `.charon/cluster-definition.json`. This file needs to be shared with the other operators in a cluster.
@@ -72,7 +72,7 @@ Every cluster member then participates in the DKG ceremony. For Charon v1, this
 
 ```
 # Participate in DKG ceremony, this will create .charon/cluster-lock.json, .charon/deposit-data.json and .charon/validator_keys
-docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.13.0 dkg
+docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.14.0 dkg
 ```
 
 >This is a helpful [video walkthrough](https://www.youtube.com/watch?v=94Pkovp5zoQ&ab_channel=ObolNetwork).
@@ -106,7 +106,7 @@ Before completing these instructions, you should assign a static local IP addres
 rm -r ./data/lighthouse
 
 # Spin up a Distributed Validator Node with a Validator Client
-docker-compose up
+docker compose up
 
 # Open Grafana dashboard
 open http://localhost:3000/d/singlenode/
@@ -125,7 +125,7 @@ If at any point you need to turn off your node, you can run:
 
 ```
 # Shut down the currently running distributed validator node
-docker-compose down
+docker compose down
 ```
 
 ## Step 5. Activate the deposit data
@@ -199,7 +199,7 @@ A threshold of operators in the cluster need to perform this task to exit a vali
   - `compose-volutary-exit.yml` is configured with `--epoch=112260` which is the latest Bellatrix fork on Prater.
   - If the Charon cluster is running on a different chain, **ALL** operators must update `--epoch` to the same latest fork version returned by `curl $BEACON_NODE/eth/v1/config/fork_schedule`.
 - Run the command to submit this node's partially signed voluntary exit:
-  - `docker-compose -f compose-voluntary-exit.yml up`
+  - `docker compose -f compose-voluntary-exit.yml up`
   - Confirm the logs: `Exit for validator XXXXX submitted`
   - Exit the container: `Ctrl-C`
 - The charon metric `core_parsigdb_exit_total` will be incremented each time a voluntary exit partial signature is received, either from this node or from peers.
@@ -214,7 +214,7 @@ The above steps should get you running a distributed validator cluster. The foll
 
 ### Docker power users
 
-This section of the readme is intended for the "docker power users", i.e., for the ones who are familiar with working with `docker-compose` and want to have more flexibility and power to change the default configuration.
+This section of the readme is intended for the "docker power users", i.e., for the ones who are familiar with working with `docker compose` and want to have more flexibility and power to change the default configuration.
 
 We use the "Multiple Compose File" feature which provides a very powerful way to override any configuration in `docker-compose.yml` without needing to modify git-checked-in files since that results in conflicts when upgrading this repo.
 See [this](https://docs.docker.com/compose/extends/#multiple-compose-files) for more details.
@@ -223,7 +223,7 @@ There are two additional files in this repository, `compose-debug.yml` and `dock
 
 - `compose-debug.yml` contains some additional containers that developers can use for debugging, like `jaeger`. To achieve this, you can run:
 ```
-docker-compose -f docker-compose.yml -f compose-debug.yml up
+docker compose -f docker-compose.yml -f compose-debug.yml up
 ```
 
 - `docker-compose.override.yml.sample` is intended to override the default configuration provided in `docker-compose.yml`. This is useful when, for example, you wish to add port mappings or want to disable a container.
@@ -232,11 +232,11 @@ docker-compose -f docker-compose.yml -f compose-debug.yml up
 ```
 cp docker-compose.override.yml.sample docker-compose.override.yml
 
-# Tweak docker-compose.override.yml and then run docker-compose up
-docker-compose up
+# Tweak docker-compose.override.yml and then run docker compose up
+docker compose up
 ```
 
 - You can also run all these compose files together. This is desirable when you want to use both the features. For example, you may want to have some debugging containers AND also want to override some defaults. To achieve this, you can run:
 ```
-docker-compose -f docker-compose.yml -f docker-compose.override.yml -f compose-debug.yml up
+docker compose -f docker-compose.yml -f docker-compose.override.yml -f compose-debug.yml up
 ```

versioned_docs/version-v0.12.0/int/quickstart/quickstart-alone.md

@@ -38,7 +38,7 @@ Charon is in an early alpha state and is not ready to be run on mainnet
 1. Start the cluster
    ```sh
    # Start the distributed validator cluster
-   docker-compose up
+   docker compose up
    ```
 1. Checkout the monitoring dashboard and see if things look all right
 

versioned_docs/version-v0.14.0/cg/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Contribution guidelines",
+  "position": 10,
+  "collapsed": true
+}

versioned_docs/version-v0.14.0/cg/bug-report.md

@@ -0,0 +1,57 @@
+# Filing a bug report
+
+Bug reports are critical to the rapid development of Obol. In order to make the process quick and efficient for all parties, it is best to follow some common reporting etiquette when filing to avoid double issues or miscommunications.
+
+## Checking if your issue exists
+
+Duplicate tickets are a hindrance to the development process and, as such, it is crucial to first check through Charon's existing issues to see if what you are experiencing has already been indexed.
+
+To do so, head over to the [issue page](https://github.com/ObolNetwork/charon/issues) and enter some related keywords into the search bar. This may include a sample from the output or specific components it affects.
+
+If searches have shown the issue in question has not been reported yet, feel free to open up a new issue ticket.
+
+## Writing quality bug reports
+
+A good bug report is structured to help the developers and contributors visualize the issue in the clearest way possible. It's important to be concise and use comprehensive language, while also providing all relevant information on-hand. Use short and accurate sentences without any unnecessary additions, and include all existing specifications with a list of steps to reproduce the expected problem. Issues that cannot be reproduced **cannot be solved**.
+
+If you are experiencing multiple issues, it is best to open each as a separate ticket. This allows them to be closed individually as they are resolved.
+
+An original bug report will very likely be preserved and used as a record and sounding board for users that have similar experiences in the future. Because of this, it is a great service to the community to ensure that reports meet these standards and follow the template closely.
+
+
+## The bug report template
+
+Below is the standard bug report template used by all of Obol's official repositories.
+
+```sh
+<!--- Provide a general summary of the issue in the Title above -->
+
+## Expected Behavior
+<!--- What should be happening? -->
+
+## Current Behavior
+<!--- What happens instead? -->
+
+## Steps to Reproduce
+<!--- Provide a concise set of steps to reproduce this bug.  -->
+1.
+2.
+3.
+4.
+5.
+
+## Detailed Description
+<!--- Provide some context for the issue you are experiencing. -->
+
+## Specifications
+<!--- Provide some information regarding your local system. --->
+Operating system:
+Version(s) used:
+
+## Possible Solution
+<!--- (Optional) Suggest a fix, reason or implementation for the bug. -->
+
+## Further Information
+<!--- Anything else to add?
+```
+