Tweaking docs to reflect latest changes

docs/cg/docs.md

@@ -228,7 +228,7 @@ The following rules and guidelines define how to use and store images.
 
 #### Storage location
 
-All images must be placed in the `/website/static/img` folder. For multiple images attributed to a single topic, a new folder within `/img/ the may be needed.
+All images must be placed in the `/static/img` folder. For multiple images attributed to a single topic, a new folder within `/img/` may be needed.
 
 #### File names
 

docs/dv/01_introducing-charon.md

@@ -22,7 +22,7 @@ The below graphic visually outlines the internal functionalies of Charon.
 The `charon` client is in an early alpha state, and is not ready for mainnet, see [here](https://github.com/ObolNetwork/charon#supported-consensus-layer-clients) for the latest on charon's readiness.
 
 ```
-docker run ghcr.io/obolnetwork/charon:v0.6.0 --help
+docker run ghcr.io/obolnetwork/charon:v0.7.0 --help
 ```
 
 For more information on running charon, take a look at our [quickstart guide](../int/quickstart/index.md). 

docs/dv/02_validator-creation.md

@@ -17,10 +17,10 @@ To create a distributed validator cluster, you and your group of operators need
     - This data is stored in the DV Launchpad data layer and a shareable URL is generated. This is a link for the other operators to join and complete the ceremony.
 2.  The other operators in the cluster follow this URL to the launchpad.
     - They review the terms of the cluster configuration.
-    - The submit the ENR of their charon client.
+    - They submit the ENR of their charon client.
     - They sign both the hash of the cluster config and their charon ENR to indicate acceptance of the terms.
 3. Once all operators have submitted signatures for the cluster configuration and ENRs, they can all download the cluster definition file. 
-4. Every operator loads this cluster definition file into `charon dkg`. The definition provides the charon process with the information it needs to complete the DKG ceremony with the other charon clients. 
+4. Every operator passes this cluster definition file to the `charon dkg` command. The definition provides the charon process with the information it needs to find and complete the DKG ceremony with the other charon clients involved. 
 5. Once all charon clients can communicate with one another, the DKG process completes. All operators end up with:
     - A `cluster-lock.json` file, which contains the original cluster configuration data, combined with the newly generated group public keys and their associated public key shares. This file is needed by the `charon run` command. 
     - Validator deposit data

docs/dv/04_middleware-daemon.md

@@ -12,6 +12,4 @@ The Charon daemon sits as a middleware between the consensus layer's [beacon nod
 
 The middleware strives to be stateless and statically configured through 777 file systems. The lack of a control-plane API for online reconfiguration is deliberate to keep operations simple and secure by default.
 
-The daemon offers a config reload instruction through Unix signals which is useful to join or leave Obol clusters on-the-fly without interruption.
-
 The `charon` package will initially be available as a Docker image and through binary builds. An APT package with a systemd integration is planned.

docs/dv/08_distributed-validator-cluster-manifest.md

@@ -30,21 +30,18 @@ The schema of the `cluster-definition.json` is defined as:
   "name": "best cluster",               // Optional name field, cosmetic.
   "fee_recipient_address":"0x123..abfc",// ETH1 fee_recipient address
   "withdrawal_address": "0x123..abfc",  // ETH1 withdrawal address
-  "algorithm": "foo_dkg_v1" ,           // Optional DKG algorithm
+  "dkg_algorithm": "foo_dkg_v1" ,           // Optional DKG algorithm
   "fork_version": "0x00112233",         // Fork version lock, enum of known values
   "operators": [
     {
       "address": "0x123..abfc",         // ETH1 operator identify address
+      "config_signature": "123...ef",   // Signature of config hash by Eth1 priv key
       "enr": "enr://abcdef...12345",    // charon client ENR
-      "signature": "123456...abcdef",   // Signature of enr by ETH1 address priv key
-      "nonce": 1                        // Nonce of signature
+      "enr_signature": "123456...ef",   // Signature of enr by Eth1 address priv key
+      "nonce": 0                        // Nonce of signature
     }
   ],
-  "definition_hash": "abcdef...abcedef",// Hash of above field (except free text)
-  "operator_signatures": [              // Operator signatures (seals) of definition hash
-    "123456...abcdef",
-    "123456...abcdef"
-  ]
+  "definition_hash": "abcdef...abcede", // Hash of above field (except free text)
 }
 ```
 
@@ -57,7 +54,7 @@ The `cluster-lock.json` has the following schema:
   "distributed_validators": [                               // Length equaled to num_validators.
     {
       "distributed_public_key":  "0x123..abfc",             // DV root pubkey
-      "threshold_verifiers": [ "oA8Z...2XyT", "g1q...icu"], // length of threshold
+      "public_shares": [ "oA8Z...2XyT", "g1q...icu"],       // Public Key Shares
       "fee_recipient": "0x123..abfc"                        // Defaults to withdrawal address if not set, can be edited manually
     }
   ],

docs/dv/09_charon_cli_reference.md

@@ -10,7 +10,7 @@ The `charon` client is under heavy development, interfaces are subject to change
 
 :::
 
-The following is a reference for charon version [`v0.6.0`](https://github.com/ObolNetwork/charon/releases/tag/v0.6.0). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+The following is a reference for charon version [`v0.7.0`](https://github.com/ObolNetwork/charon/releases/tag/v0.7.0). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
 
 ### Available Commands
 
@@ -74,7 +74,7 @@ Usage:
   charon create enr [flags]
 
 Flags:
-      --data-dir string                The directory where charon will store all its internal data (default ".charon/data")
+      --data-dir string                The directory where charon will store all its internal data (default ".charon")
   -h, --help                           Help for enr
       --p2p-allowlist string           Comma-separated list of CIDR subnets for allowing only certain peer connections. Example: 192.168.0.0/16 would permit connections to peers on your local network only. The default is to accept all connections.
       --p2p-bootnode-relay             Enables using bootnodes as libp2p circuit relays. Useful if some charon nodes are not have publicly accessible.
@@ -83,8 +83,8 @@ Flags:
       --p2p-denylist string            Comma-separated list of CIDR subnets for disallowing certain peer connections. Example: 192.168.0.0/16 would disallow connections to peers on your local network. The default is to accept all connections.
       --p2p-external-hostname string   The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
       --p2p-external-ip string         The IP address advertised by libp2p. This may be used to advertise an external IP.
-      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:16003])
-      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:16004")
+      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:3610])
+      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:3630")
 ```
 
 #### Create a full cluster locally
@@ -129,7 +129,7 @@ Flags:
       --network string                 Ethereum network to create validators for. Options: mainnet, prater, kintsugi, kiln, gnosis. (default "prater")
       --num-validators int             The number of distributed validators the cluster will manage (32ETH staked for each). (default 1)
       --operator-enrs strings          Comma-separated list of each operator's Charon ENR address
-      --output-dir string              The folder to write the output cluster-definition.json file to. (default ".")
+      --output-dir string              The folder to write the output cluster-definition.json file to. (default ".charon")
   -t, --threshold int                  The threshold required for signature reconstruction. Minimum is n-(ceil(n/3)-1). (default 3)
       --withdrawal-address string      Withdrawal Ethereum address (default "0x0000000000000000000000000000000000000000")
 ```
@@ -148,7 +148,7 @@ Usage:
   charon dkg [flags]
 
 Flags:
-      --data-dir string                The directory where charon will store all its internal data (default ".charon/data")
+      --data-dir string                The directory where charon will store all its internal data (default ".charon")
       --definition-file string         The path to the cluster definition file. (default ".charon/cluster-definition.json")
   -h, --help                           Help for dkg
       --log-format string              Log format; console, logfmt or json (default "console")
@@ -160,8 +160,8 @@ Flags:
       --p2p-denylist string            Comma-separated list of CIDR subnets for disallowing certain peer connections. Example: 192.168.0.0/16 would disallow connections to peers on your local network. The default is to accept all connections.
       --p2p-external-hostname string   The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
       --p2p-external-ip string         The IP address advertised by libp2p. This may be used to advertise an external IP.
-      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:16003])
-      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:16004")
+      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:3610])
+      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:3630")
 ```
 
 ### Run the Charon middleware
@@ -177,7 +177,7 @@ Usage:
 
 Flags:
       --beacon-node-endpoint string    Beacon node endpoint URL (default "http://localhost/")
-      --data-dir string                The directory where charon will store all its internal data (default ".charon/data")
+      --data-dir string                The directory where charon will store all its internal data (default ".charon")
       --feature-set string             Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
       --feature-set-disable strings    Comma-separated list of features to disable, overriding the default minimum feature set.
       --feature-set-enable strings     Comma-separated list of features to enable, overriding the default minimum feature set.
@@ -187,17 +187,17 @@ Flags:
       --lock-file string               The path to the cluster lock file defining distributed validator cluster (default ".charon/cluster-lock.json")
       --log-format string              Log format; console, logfmt or json (default "console")
       --log-level string               Log level; debug, info, warn or error (default "info")
-      --monitoring-address string      Listening address (ip and port) for the monitoring API (prometheus, pprof) (default "127.0.0.1:16001")
+      --monitoring-address string      Listening address (ip and port) for the monitoring API (prometheus, pprof) (default "127.0.0.1:3620")
       --p2p-allowlist string           Comma-separated list of CIDR subnets for allowing only certain peer connections. Example: 192.168.0.0/16 would permit connections to peers on your local network only. The default is to accept all connections.
       --p2p-bootnode-relay             Enables using bootnodes as libp2p circuit relays. Useful if some charon nodes are not have publicly accessible.
       --p2p-bootnodes strings          Comma-separated list of discv5 bootnode URLs or ENRs. (default [http://bootnode.gcp.obol.tech:16000/enr])
       --p2p-bootnodes-from-lockfile    Enables using cluster lock ENRs as discv5 bootnodes. Allows skipping explicit bootnodes if key generation ceremony included correct IPs.
       --p2p-denylist string            Comma-separated list of CIDR subnets for disallowing certain peer connections. Example: 192.168.0.0/16 would disallow connections to peers on your local network. The default is to accept all connections.
       --p2p-external-hostname string   The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
       --p2p-external-ip string         The IP address advertised by libp2p. This may be used to advertise an external IP.
-      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:16003])
-      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:16004")
+      --p2p-tcp-address strings        Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. (default [127.0.0.1:3610])
+      --p2p-udp-address string         Listening UDP address (ip and port) for discv5 discovery. (default "127.0.0.1:3630")
       --simnet-beacon-mock             Enables an internal mock beacon node for running a simnet.
       --simnet-validator-mock          Enables an internal mock validator client when running a simnet. Requires simnet-beacon-mock.
-      --validator-api-address string   Listening address (ip and port) for validator-facing traffic proxying the beacon-node API (default "127.0.0.1:16002")
+      --validator-api-address string   Listening address (ip and port) for validator-facing traffic proxying the beacon-node API (default "127.0.0.1:3600")
 ```

docs/int/faq.md

@@ -31,3 +31,7 @@ enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGD
 ### Where can I learn more about Distributed Validators?
 
 Have you checked out our [blog site](https://blog.obol.tech) and [twitter](https://twitter.com/ObolNetwork) yet? Maybe join our [discord](https://discord.gg/obol) too.
+
+### What's with the name Charon?
+
+[Charon](https://www.theoi.com/Khthonios/Kharon.html) is the Ancient Greek Ferryman of the Dead. He was tasked with bringing people across the Acheron river to the underworld. His fee was one Obol coin, placed in the mouth of the deceased. This tradition of placing a coin or Obol in the mouth of the deceased continues to this day across the Greek world. 

docs/int/quickstart/quickstart-group.md

@@ -24,7 +24,7 @@ To create a distributed validator cluster with a group of other node operators r
 
 ## Getting started with Charon
 
-1. Clone the [charon-distributed-validator-node](https://github.com/ObolNetwork/charon-distributed-validator-cluster) template repository from Github, and `cd` into the directory.
+1. Clone the [charon-distributed-validator-node](https://github.com/ObolNetwork/charon-distributed-validator-node) template repository from Github, and `cd` into the directory.
 
    ```sh
    # Clone the repo

docs/int/working-groups.md

@@ -86,8 +86,8 @@ The Obol core team has begun work on all three phases of the effort, and will pr
 
 **Progress:**
 
-- Phase 0: 60%
-- Phase 1: 25%
+- Phase 0: 70%
+- Phase 1: 65%
 - Phase 1.5: 30%
 
 The core team plans to release the different phases for proto community feedback as they approach 75% completion.

docs/sc/01_introducing-obol-managers.md

@@ -10,7 +10,7 @@ Obol develops and maintains a suite of smart contracts for use with Distributed
 
 The key to a distributed validator is understanding how a withdrawal is processed. The most common way to handle a withdrawal of a validator operated by a number of different people is to use an immutable withdrawal recipient contract, with the distribution rules hardcoded into it. 
 
-For the time being Obol uses `0x01` withdrawal credentials, and intends to upgrade to [0x03 withdrawal credentials](https://www.dropbox.com/s/z8kpyl5r2lh1ixe/Screenshot%202021-12-26%20at%2013.53.48.png?dl=0) when smart contract initiated exits are enabled. 
+For the time being Obol uses `0x01` withdrawal credentials, and intends to upgrade to [0x03 withdrawal credentials](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021) when smart contract initiated exits are enabled. 
 
 ### Ownable Withdrawal Recipient
 

docs/testnet.md

@@ -13,7 +13,7 @@ The following is a break down of the intended testnet roadmap, the features that
 # Testnets
 
 - [x] Dev Net 1
-- [ ] Dev Net 2
+- [x] Dev Net 2
 - [ ] Athena Public Testnet 1
 - [ ] Bia Attack net
 - [ ] Circe Public Testnet 2
@@ -64,7 +64,7 @@ A core focus of this devnet will be to collect network performance data. This wi
 
 **Network:** Kiln
 
-**Target start date:** May 2022
+**Target start date:** June 2022
 
 **Duration:** 2 weeks
 
@@ -93,7 +93,7 @@ This will be an unincentivised testnet, and will form as the basis for us figuri
 
 **Network:** Kiln or a Merged Test Network (e.g. Görli)
 
-**Target start date:** June 2022
+**Target start date:** July 2022
 
 **Duration:** 2 week setup, 4 weeks operation